Web Services Addressing Working Issues List

The specification currently mandates the serialization of some message addressing properties as SOAP headers in messages when they could be omitted without loss of information or is less than clear about their optionality:

1. Anonymous address: <wsa:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
2. <wsa:ReplyTo> - optional, "MUST be present if a reply is expected", "If the [reply endpoint] is absent, the contents of the [source endpoint] may be used to formulate a message to the source." I.e. it must be present, but if not use <wsa:From> instead.
3. <wsa:From> - optional, can be used to provide a default for ReplyTo and FaultTo.
4. <was:Action> is already being discussed elsewhere.

a) The spec states that the [action] property is supposed to uniquely identify the semantics implied by the message. Is the value of the [action] property required to be distinct within the scope of WSDL messages/operations/interface/service (?), when using WSDL to describe the Web service? It seems to me that the [action] property would be distinct at least within the scope of an interface/operation. Is there any good reason not require it to be distinct? If not distinct, there should at least be guidance regd re-use of the [action] value to the creators of WSDL docs.

This subissue was resolved at the Melbourne F2F; Action is not required to be distinct.

b) What is the relationship of the operation-name mapping requirement of WSDL 2.0 to the [action] property? If the [action] property is required to be distinct this can satisfy the operation-name mapping requirement of WSDL 2.0. If the [action] property is not required to be distinct, it would still be possible to define a feature that requires it to be distinct and use this feature to satisfy the operation-name mapping requirement.

This subissue was resolved on the 2005-08-22 teleconference with proposal 2 (adding explanatory text, but no flagging mechanism in WSDL itself.)

Subissue a: WS-Addressing submission section 2 (and now the WSDL binding spec section 2) talks about the current limits of WSDL as a justification to not reuse WSDL syntactic structures. These limits do not exist and therefore the justification should be removed. The same section also talks about usecases where WS-Addressing "will" be used. Those usecases can also be satisfied without using WS-Addressing.

We resolved this subissue (2005-01-17) by making the necessary editorial changes.

Subissue b: EPR represents things that the service element in WSDL can represent. Why does ws-addressing not reuse existing syntactic structures, where they do meet the requirements, instead of inventing new ones?

We decided to drop this subissue (2005-01-17), as we have WS-Addressing submission as our starting point and there is not a whole lot of support to redesign it.

Subissue c: An EPR allows one to include (optionally) a service endpoint/port. If such an endpoint/port is included in an EPR, what is the relationship between the value of the [address] property and the URI value in the [service-port] property? We have said that the [address] property is a logical address and not necessarily the physical endpoint where messages can be sent and how the mapping between logical to physical takes place is an extensibility point. Is that true if a service QName is present in the EPR. I.e., should our spec say that if the service QName is present then the physical address is what is specified by the wsdl port.

This subissue was resolved on the 2005-09-12 teleconference: see resolution.

Subissue d: WS-Addressing talks about an Endpoint Reference, but does not say what an endpoint is. So what does an EPR refer to? WSDL also has the concept of an endpoint. What is the difference between the two, if any.

This subissue was resolved on the 2005-02-14 teleconference: add "Note that WSDL 2.0 has an Endpoint component [ref] which along with other WSDL 2.0 components can be used to describe a Web service endpoint. A Web service endpoint may in fact have multiple such descriptions. Similarly, multiple EPRs can be used to convey information needed to address a particular Web service endpoint. An EPR is intended to convey information required to address a Web service endpoint whereas a WSDL 2.0 description is intended to describe a Web service." after "A Web service endpoint is a (referenceable) ... needed to address a Web service endpoint." in the core.

There is some confusion as to what precisely wsa:Action is meant to represent in the current specification. However, most people seem to have the opinion that it is used to represent the semantics of the message contained in the SOAP body. In which case, this element is used for dispatching the message (similar to using an opcode in other distributed environments).

However, if wsa:Action is used to optimize dispatching so that the same semantics do not have to be obtained by parsing the entire SOAP body, this is purely an optimization. As such, its presence or lack thereof does not affect the architecture/model defined by the specification; it is entirely feasible to implement the equivalent distributed application without wsa:Action, albeit in (perhaps) a less performant manner.

The current text uses an informal pseudo-EBNF to describe the XML syntax of the WS-Addressing header. See, for example, Example 2-1 in the editor's copy (as of 4-Nov-2004).

1. Should we describe the specification using XML Schema?
2. Should such a schema replace the "pseudo-schema"?
3. Should such a schema be normative?

Section 3.3 describes a WSDL 1.1-specific mechanism for determining a default Action MIH. If the service has a WSDL 2.0 description, another mechanism needs to be used, which is actually defined by the WSDL 2.0 specification.

Also, if there is a WSDL 1.1 and WSDL 2.0 description available, which is the implicit value of the action property? If in a year's time we release WSDL 2.1, what happens? I believe that there is an implicit value of the action URI recognized by the recipient of the addressing information for the description of the service made in each version of WSDL. Those are equivalent for the purpose of our specification.

We discuss the fact that extra elements/attributes might appear in the infoset of an EPR in section 2.2, but we do not discuss any sort of a processing model for these extensions.

Also, The abstract properties list in section 2.1 doesn't have any statement about extensibility.

Also, We should decide if we want to support a "mustUnderstand" marker on extensions a la SOAP/WSDL, or if we want to discuss "ignoreUnknown" semantics for unrecognized extensions/properties.

The Core spec, section 3.2 Formulating a Reply Message states:

The reply to a WS-Addressing compliant request message MUST be compliant to WS-Addressing and be constructed according to the rules defined in this section.

However, this section only defines an example and no rules.

There is a potential problem in the Action defaulting algorithm we've selected. It works great for http: URIs as the namespace, and continues the http hierarchy by adding new path components separated by slashes.

However, slash isn't allowed as a path component by all URI schemes. Notably, URNs don't allow slash as far as I can tell, and you often see paths delimited by ":" instead. If a URN is used as a targetNamespace (which seems reasonable, though we can argue whether this trend will wither or flourish), you might end up with a default Action like:

urn:com:microsoft:schemas:thisWsdl/dohicky/sendMoneyRequest

which is a bad URN.

Section 3 of the core spec presents faults as a type of reply: "A reply in this case can be either an application message, a fault, or any other message."

However, normal replies and faults are treated differently by WS Addressing processors, as the rules expressed in issue i044's resolution show:

• for a reply to be sent back, the incoming message MUST have wsa:ReplyTo header;
• the meaning of wsa:FaultTo, OTOH, is that if present, it specifies where faults should go; otherwise, other rules (e.g. the MEP's or the binding's) apply.

The discussion around i044 (see thread) has shown that:

• replies and faults work under different models/philosophies in the case of a reply to an incoming message: for the latter, it when wsa:FaultTo is absent, the processor behaves just as if Addressing wasn't in use; for the former, the absence of wsa:ReplyTo is a violation of the Addressing specification.
• this difference may cause confusion.

We define as message addressing properties concepts that happen to exist in certain SOAP underlying protocols. A good example is the [action] message addressing property and the action parameter of the application/soap+xml media type carried by HTTP's Content-Type header.

We need to clearly define the relationship for this information when it appears in different places, i.e. whether they are independent, equal, or related another way.

Questions arose about the relationship of this similar information appearing in different places[3]. Core hints that [action] and SOAP Action are similar for example[4] though the description provided is SOAP 1.1 specific.

We should provide a basis for such equivalence rules for a variety of message addressing properties and bindings.

Asynchronous applications may define interactions in which an incoming message may produce outgoing messages to any number of different endpoints.  To take a concrete example, a service may be required to receive a message and do one of

1. Send a fault to a fault destination.
2. Send application data to a "normal processing" destination.
3. Send (possibly different) application data to a "special processing" destination.

It is not clear from section 3 of the core spec exactly how to handle this in terms of Message Addressing Properties.

As many of you are aware, there is an ongoing debate on what kind of resource should be placed at the namespace URI. The TAG has been unable to recommend a practice in this area, despite a lot of discussion.

The W3C, AIUI, has a policy that there should be some document at the namespace URI, but does not enforce a particular format. In general namespace URIs seem to return HTML documents.

There are also many proponents of RDDL, which is simply an XHTML document with some machine-processable XLinks in it pointing to associated resources like schema.

We define the default action value for WSDL 1.1 faults as

[target namespace][delimiter][port type name][delimiter][operation name]Fault:[fault name]

IIRC part of our reasoning for using "Fault:" as part of the structure rather than [delimiter] was that having a constant number of delimiters in the pattern makes it easy to deconstruct the URI into its constituent parts (all our actions have the same number of delimiters, though the delimiter might also appear in the [target namespace]).

However, [delimiter] can be ":" which interacts with "Fault:" in a way that negates that advantage.

What is the correct behaviour for gen'ing wsa:Action in the client when the HTTP 1.1 SOAPAction is set ( i.e. not "") and there is no wsaw:Action explicitly specified in the WSDL?

The problem is that, the default action pattern for wsa:Action cannot be guaranteed to generate a wsa:action to match SOAPAction.

The wsaw:UsingAddressing element can appear on the binding and the endpoint (port) of the wsdl. Similarly, the associated wsaw:anonymous element can appear on the binding or endpoint.

Bearing this in mind, the following points require clarification in the WSDL specification:

1. Is it acceptable to specify wsaw:Anonymous on the endpoint if the corresponding wsaw:UsingAddressing is specified on the binding?
2. The spec indicates that it is not possible to specify wsaw:UsingAddressing on the port if it is already specified on the binding ("Alternatively, the wsaw:UsingAddressing element MAY be instead included as a child on the wsdl20:endpoint (or wsdl1.1:port)...").

So if the binding does not specify WS-Addressing, it is possible to override this at the endpoint. However, there is no mechanism to do the converse (i.e. to switch off the requirement for WS-Addressing at the endpoint if it is defined at the binding). Why are we allowing one without the other?