Web Services Addressing Candidate Recommentation Issues List

I notice that WS-Addressing [1] has security recommendations that include the signing of elements by those producing EPRs (and message addressing properties). Such signing usually requires the presence of an identifying attribute on each signed element. I note that WS-Addressing does not define any such attribute, but relies on a wildcard for this and other attribute definitions. This seems to require that users of WS-Addressing must define the use of such an attribute themselves, prior to being able to implement the security considerations recommended by WS-A. This implies that one cannot use the basic EPR and MAP definitions directly from the WS-Addressing specification (if one wishes to sign EPRs and be interoperable with anyone else.)

In order to aid interoperability of this specification, and implementation of the security considerations within, would it be possible to specify the use of an ID attribute within the WS-Addressing specification?

Perhaps best would be to use the recommendation specified in the xml:id specification.

wsa:InvalidAddress is used when an [address] property is invalid, as opposed to having the destination unreachable, which is to be indicated with wsa:DestinationUnreachable.

My understanding is that it means that wsa:InvalidAddress will occur when [address] is an invalid property, i.e. that [address] is actually NOT an IRI.

Interestingly, wsa:InvalidAddress's description reads "[Details] MAY contain a wsa:ProblemIRI element", and wsa:ProblemIRI's type is xs:anyURI, so it cannot be used to return the value of [address].

Also, in the spirit of cr2 and eliminating redundant information, the information carried by wsa:ProblemIRI can also be carried by wsa:ProblemHeader.

From the discussion of wsa:UsingAddressing, wsdl:required and so forth, it appears that there is some ambiguity as to how to define the set of MAPs present in an incoming SOAP message. Indeed, section 2 of the SOAP binding deals solely with the outbound side, defining how MAPs become headers, but not vice versa. The infoset description in section 3.1 of the core provides most of the needed information, but there is at least one gray area: Since wsa:To is given a default value, it is possible to define the [destination] property of a message which contains no wsa:Headers in its infoset.

This in turn appears to complicate the handling of messages received by an endpoint whose wsa:UsingAddressing property is present but with wsdl:required = false. Essentially, the receiver must be able to distinguish two cases, ideally without explicit reference to SOAP-level concepts such as header blocks: wsa: SOAP headers were present, and therefore the endpoint should follow the full WSA rules (in particular, it MUST fault if required headers are absent) No wsa:SOAP headers were present, and therefore the endpoint handles the message without regard to WSA.

The definition of wsa:Action says: "/wsa:Action - This REQUIRED element of type xs:anyURI conveys the [action] property."

I was wondering what value Action takes where a general SOAP fault is encountered such as malformed XML? This will not match any fault defined in the WSDL. Also, what value does it take when of the the WSA faults occur? I assume REQUIRED means on both request and response even if the response is a fault?

In section 3.2 it says: " Populate the reply message's message addressing properties o [destination]: ... o [relationship]: ... o [reference parameters]: ..."

Missing from this is [action]? The examples that follow should wsa:Action in each case.

Does there need to be general fault action URIs?

Promoting effective use of the World Wide Web is of course the raison d'être of the W3C and of the TAG in particular. So, it's worth some care to ensure that every W3C Recommendation integrates well with the Web. The use of a single naming mechanism (URI) for all resources is key to the network effects that underly the extraordinary success of the Web, and so the TAG pays particular attention to ensuring that Recommendations make appropriate use of URIs.

WSA End Point References contain an [address] property which is a URI, but the TAG is concerned that other non-URI properties will also sometimes be used for resource identification. We also have come to understand that there are practical reasons why the Web Services community finds XML-based, QNamed parameters to be powerful and convenient, and that those advantages sometimes extend to their use for identification. For example, we are aware that there is a large body of widely deployed software that aids in the creation and processing of SOAP headers, including those resulting from bound EPR parameters. Taking all these factors together, the TAG today resolved to ask that the Web Services Addressing Working Group include the following note in a suitable section of the Web Services Addressing 1.0 - Core Proposed Recommendation:

Note: Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to Web Architecture. In certain circumstances, use of such additional properties may be convenient or beneficial, perhaps due to the availability of QName-based tools. When building systems that violate this principle, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the Web.

We hope that this strikes a reasonable balance between promoting effective use of the Web, and recognizing the other factors that appropriately contribute to design and implementation choices.

WS-Addressing 1.0 SOAP Binding, in its SOAP 1.1 Addressing 1.0 Extension says:

"Use of the SOAPAction HTTP header is required when using the SOAP 1.1 HTTP binding. The value of the SOAPAction HTTP header MUST either be identical to the value of the wsa:Action header, or be empty. The latter case supports the ability to obscure the wsa:Action header through SOAP-level security mechanisms, without requiring otherwise unnecessary transport-level security. Failure to have an identical value, or an empty value for SOAPAction, results in an Invalid Message Addressing Property fault (see 5.4.1 Invalid Addressing Header)."

This was modified to: "Use of the SOAPAction HTTP header is required when using the SOAP 1.1 HTTP binding. The value of the SOAPAction HTTP header MUST either be "[action]" or "" (quotes are significant). The latter case supports the ability to obscure the wsa:Action header through SOAP-level security mechanisms, without requiring otherwise unnecessary transport-level security. A SOAPAction value different to "[action]" or "", results in the generation of an Action Mismatch fault (see 5.4.1.6 Action Mismatch)." as a resolution to issue cr8.

There is an editorial issue with the paragraph quoted above (old as well as new). SOAPAction HTTP header is required by SOAP 1.1 and BP 1.1 only in the case of HTTP request and not for the HTTP response. The current wordings make it appear that the value of SOAPAction HTTP header must be either "[action]" or "" for both the HTTP request and response.

In SOAP binding CR document [1], several builtin SOAP faults have been identified. The Predefined Faults list in Section 5.4 indicates in an editorial note that additional faults may need to be defined based on feedback given during CR period.

The predefined InvalidAddressing Header faults in Section 5.4.1 do not contain two important categories of faults for indicating the endpoint/binding's capability to handle

• only anonymous
• only non-anonymous addresses

2 new faults are needed in order to indicate an endpoint/bindings's level of support for handling anonymous addresses, especially to be used for indicating the endpoint's level of capability of handling asynchronous binding for SOAP/HTTP when the client uses the endpoint/binding in a non-supported manner.

The following two categories may be added to Section 5.4.1 to resolve this issue:

• wsa:OnlyAnonymousAddressSupported
• wsa:OnlyNonAnonymousAddressSupported

Currently, we constrain the HTTP SOAPAction request header to be either identical to the [action] MAP (and the wsa:Action) header or to be (effectively) blank. This is a narrow ruling, however. We do not place any constraints on other transport-level metadata that may overlap in function with MAPs, for example, the from:, to: reply-to:, message-id: and in-reply-to: headers in an email binding, nor do we even provide guidance for such a situation.

Note that the case of reply-to: and similar constructs is a bit special, in that they will likely be used in the definition of the SOAP request-response MEP, which section 3.5 explicitly links to the anonymous URI. Aside from this, the general question is: "If the transport provides a from: header or similar construct, must this be identical to (or a default for) the [source endpoint] MAP?", and analogously for message-id: and [message id], in-reply-to: and [relationship] (bearing in mind that [relationship] is more general than in-reply-to:).

Section 3.5 of the SOAP binding states: When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified as the address of an EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP request-response message exchange pattern provides such a channel for response messages. For instance, the SOAP 1.2 HTTP binding[SOAP 1.2 Part 2: Adjuncts] puts the reply message in the HTTP response.

The first sentence is not necessarily true as it stands (though I realize we did discuss the wording at some length). Including an anonymous address in an EPR does not necessarily provide the protocol binding with a channel at all. It's most likely an error to use such an EPR with a binding that only supports one-way messaging. Note also that this statement does not confine itself to response endpoints, but simply says "an EPR".

As I understand it, our current consensus is that an anonymous URI in a response endpoint (i.e., [reply endpoint] and [fault endpoint] in the context of a request message) means use the response message of a SOAP request-response MEP. We specifically don't say what it may or may not mean in other contexts. Even if we allow anonymous for other types of endpoints (e.g., extensions defined elsewhere), we still only define it in the context of request-response.

The CR Core Specification provides a definition of an EPR, but it appears that it does not reflect the resolution of an Issue [2] subissue d (decided on 2/14/2005) to indicate that an EPR may have several Web Service descriptions and multiple EPRs can be used to convey information needed to address a particular WS endpoint.

I would have expected this resolution to be integrated in the second paragraph

{A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint.}

I argue that the language in this paragraph does not really reflect the intention of the wg. I also checked the current draft of the WSDL binding document and it does not contain the resolution. The reason for this resolution was to illustrate that an EPRs may be expressed via different WSDL descriptions and for some reason this notion and the resolution has been omitted from the specification. My review on the other resolutions did not provide any clues as to why this resolution was not applied. I suspect that this was a simple omission and the resolution of the wg should be reflected in the current specification.

This change will not affect the testing or implementations of the specification.

Several sections of the Core Specification [1] are in contradiction wrt to the default values for reply endpoint and its optionality. Currently the specification treats the reply endpoint as a required property instead of an optional property and contradicts itself in several sections as follows:

-- Section 3.1 lists reply endpoint/fault endpoint as "optional" properties as their cardinality is defined as (0..1)

-- Section 3.2 lists the corresponding headers wsa:ReplyTo/wsa:FaultTo as OPTIONAL elements. However, the "default" value for the reply endpoint property is designated to be anonymous URI. This aspect makes the property required and is in conflict with its definition in Section 3.1. Consequently, the message exchanges will always assume a response, instead of using the URI "http://www.w3.org/2005/08/addressing/none".

-- Section 3.3.1 (Formulating a Reply Message) first bullet second statement says "If none is present, the processor MUST fault.". It is not clear what "none" refers to here. There are two possibilities:

(a) There is no reply endpoint property (refers to "0" as in Section 3.1). If this is the case, this is in contradiction with the fact that there is a value (anonymous) as the "Note" in the following paragraph suggests. This is again the reflection of the contradiction between the sections in 3.1 and 3.2. Perhaphs the intention of this paragraph is to say that there is always a reply endpoint property when a reply is expected and it is an error not to have a reply endpoint in this case. However, this intention itself contradicts the fact that an EPR with an anonymous reply endpoint is always assumed which will result in ALWAYS having a reply endpoint, deeming it to be REQUIRED, not OPTIONAL.

(b) The value of the reply endpoint property is "http://www.w3.org/2005/08/addressing/none". This case is covered in 2, therefore probably (b) is not the intended semantics for "none".

Default values and optional values do not mix well. The specification should clearly indicate whether the value is mandatory and supplied by a default or optional.

An issue which arose during the construction of test cases for the CR testing of the SOAP binding and Core documents, was the precise meaning of an anonymous [destination] property in a 'request' message.

The example messages in the Test Suite are designed to be as minimal as possible. As a result many of the initial messages in an exchange lacked the wsa:To SOAP header meaning the [destination] property value is 'anonymous'.

This is where the trouble starts: when writing the test cases, I assumed that 'anonymous' would default to the endpoint the message was HTTP POST'ed to, whereas others have read and implemented the spec differently. Mike has an excellent rollup of Microsoft's understanding of this issue:

http://lists.w3.org/Archives/Public/public-ws-addressing-tests/2006Jan/0027.html

• This has nothing to do with the information model and syntax of MAPs
• As far as WSA is concerned, one-way and request-response are both primitives on an equal basis. If that's not entirely clear, consider the amount of effort we've put into dealing with the anonymous address.
• The quotes around "one-way" suggest that we're weaseling our way around the semantic issues of message delivery and MEPs, which we are.
• The discussion of extended patterns of interaction suggests that we are defining an extensible framework as opposed to building blocks that can be used within one's choice of framework.

I see two possible ways forward:

• (i) Reinstate the defaulting in the infoset serialization
• (ii) Remove all instances of the mandatory [reply endpoint] in WSDL binding section 5.

The [action] property below designates WS-Addressing fault messages:

SOAP modules and extensions MAY define custom [action] values for the faults they describe or MAY designate use of the following [action] value instead:

The above [action] value SHOULD be used for generic SOAP faults including version mismatch, must understand, and data encoding unknown.

We are learning that it is indeed good practice for each SOAP module or extension to define its own fault action IRIs. This helps with dispatch, logging, reporting, and recovery from faults. We'd like to see the SOAP Binding spec encourage other specs to follow the good practice WS-A defines by strengthening the guidance to protocol authors about defining fault actions specific to their protocol.

 The current resolution to CR 15 reads (in part): When
            "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified for the
            response endpoint and the request is the request part of a SOAP request-response MEP
            [soap 1.2 adjuncts ref], then any response MUST be the response part of the same SOAP
            request-response MEP [soap 1.2 adjuncts ref]. The "response part of the ...
            SOAP request-response MEP" is a property of the MEP denoted by the URI
            http://www.w3.org/2003/05/soap/mep/OutboundMessage. Given this, the intended semantics
            may be stated more precisely as When
            "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified for the
            response endpoint and the request is the request part of a SOAP request-response MEP
            [soap 1.2 adjuncts ref], then the value of the
            http://www.w3.org/2003/05/soap/mep/OutboundMessage property of the same SOAP
            request-response MEP MUST be the response. The statement for section 3.6.2 should be
            similarly reworded. In general, any discussion of SOAP 1.2 behavior should refer to
            already-defined features and properties wherever possible. 

 Section 4.4.1 defines a mechanism to explicitly set the action value (wsaw:Action).
            It says "In the absence of a wsaw:Action attribute" use the specified SOAP action.
            Section 4.4.2 defines a defaulting mechanism. It says "In the absence of a wsaw:Action
            attribute" calculate the action using the algorithm which follows. The use of the same
            text ("In the absence...") for each of these mechanisms renders it unclear whether the
            default action pattern or the specified SOAP action is to take precedence. I think the
            intention is clear - use wsaw:Action if present, else use specified SOAP action if
            present, otherwise use the default pattern. There appear to be a number of
            straightforward editorial remedies. 

 The <wsa:ProblemHeader> fault detail element was removed during the
            CR phase, yet there are still two incidental mentions [1, 2] of this element in the
            spec. [1] http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/#invalidmapfault [2]
            http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/#id2270759 

 Section 4.4.1 of WSDL Binding [1] says: -- cut here -- In the absence of a
            wsaw:Action attribute on a WSDL input element where a SOAPAction value is specified, the
            value of the [action] property for the input message is the value of the SOAPAction
            specified. -- cut here -- Consider the following 3 different SOAP bindings for an
            operation in WSDL 1.1: 1). <soap:operation
            soapAction="bindingSOAPAction"/> 2). <soap:operation
            soapAction=""/> 3). <soap:operation/> In 1).,
            SOAPAction is clearly specified. In 3). SOAPAction is clearly not specified. Should 2).
            be considered as specified or not specified ? A literal reading of the spec will mean
            that SOAPAction is specified, even though blank. I've seen 2). as a more common style in
            WSDLs. If there happens to more than one operation in a portType (not uncommon at all)
            and all the operation use 2)., then all the operations will have exactly same wsa:Action
            within a portType. I think the wording of the spec should be changed to specify that
            only a non-empty SOAPAction overrides the default Action. [1] http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#explicitaction
                        

 The Errata document at http://www.w3.org/2006/05/ws-addr-errata.html has a couple of errors in it. 1.
            The <title/> of the document is: Errata for SMIL 2.1 Reccomendation 2. The
            link to the public archive of this list is incorrect and does not work. 

 WS-A Action property is an absolute URI, but SOAPAction HTTP header is not
            necessarily an absolute URI. We have said in the SOAP binding doc that the WS-A Action
            property value must match that of the SOAPAction HTTP header value unless the SOAPAction
            HTTP header is "". The spec is silent on what happens when there is a non-empty
            non-absolute URI specified for SOAPAction when used with WS-Addressing engaged. Such a
            value for wsa:Action is not allowed, since it is not an absolute URI, but having a valid
            value for wsa:Action would mean violating the requirement that the two values be the
            same (unless SOAPAction is ""). Suggested solution: We could either remove the
            requirement that the two values be the same (unless SOAPAction is "") OR make such WSDL
            description incorrect/not valid. Given that the requirement for the two values to be the
            same (unless SOAPAction is "") is in the SOAP binding spec -- which is a REC -- not
            allowing something like this in WSDL is the easiest thing to do to fix this problem.
         

 Grey areas in th table [1] are undefined [1] http://www.w3.org/2002/ws/addr/6/08/cr31.html
                        

None URI should be a special case and allowed in a ReplyTo/FaultTo when
            wsaw:anonymous=required which is not currently part of the spec. This seemed intuitive
            to me (because the none uri is explicitly defined and doesn't conflict with the idea of
            not using a separate response channel) and seems to have been for others I've raised it
            with.

To elaborate a little on Bob's note [1], in the WSA WSDL spec, when talking about
            the various values for the Anonymous Element it lists: "optional": This value indicates
            that a response endpoint EPR in a request message MAY contain an anonymous URI as an
            address. "required":This value indicates that all response endpoint EPRs in a request
            message MUST always use anonymous URI as an address. If a response endpoint EPR does not
            contain the anonymous URI as an address value, then a predefined InvalidAddressingHeader
            fault defined in Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP Binding]
            MUST be generated. "prohibited":This value indicates that any response EPRs in a request
            message MUST NOT use anonymous URI as an address. If a response endpoint EPR contains
            the anonymous URI as an address value, then a predefined InvalidAddressingHeader fault
            defined in Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP Binding] MUST
            be generated. The problem comes up when another spec defines their own version of
            anonymous - like WS-RM does. It defines an anon URI which acts almost exactly like the
            WSA one in that it means "send it on the transport specific back-channel". However, if
            the wsaw:Anonymous element is set to "required" then the above text would seem to imply
            that regardless of whether or not the RM spec is supported by the endpoint, the client
            can never send a wsa:ReplyTo with anything other than WSA's anonymous. So the above text
            precludes another spec from ever extending WSA to define their own anon URI where from a
            WSA perspective its equivalent. If the text were loosened up a bit to not mention the
            WSA anon URI specifically, but rather something more generic like: "... MUST always use
            a URI implying the transport specific back-channel" then the use of the wsaw:Anonymous
            element would not preclude other specs defining their own anon URI and not violate the
            meaning of the wsaw:Anonymous. thanks -Doug [1] http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/0009.html
                        

Due to timing issues of the WS-Addressing and WS-Policy WGs we suggest you make the following kind of non-normative change in the Web Services Addressing 1.0 - WSDL Binding specification

"The wsaw:UsingAddressing element MAY also be used in other contexts (e.g., as a policy assertion in a policy framework <such as WS-Policy [REF]>)."

            The algorithm for [direction token] [1] keys off of values of the {message
            label} property, specifically looking for the values "in" and "out".  In
            WSDL 2.0, the {message label} property values are typically "In" and "Out".

            [1] http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#defactionwsdl20
                        

            If a fault is referenced by more than one operation within an interface, the 
            default action pattern for WSDL 2.0 does not generate a value which, by 
            itself, can be used to distinguish the operation for which a message is 
            intended.
            
            The wsa:action property should be defined on wsdl:infault and wsdl:outfault 
            elements rather than wsdl:fault element.
            
            The default pattern should be:
            
            [target namespace][delimiter][interface name][delimiter][operation 
            name][delimiter][fault name][direction token]
            
            rather than:
            
            [target namespace][delimiter][interface name][delimiter][fault name]
            
            The intent of the action value should be to enable 'easy message dispatch' 
            (as mentioned within the WSDL 2.0 primer.) While the default action pattern 
            specified for WSDL 1.1 satisfies this requirement, the default action 
            pattern for WSDL 2.0 does not.
            
         

         Example 4-5 within WSDL Binding document isn't schema valid. Root element 
         should be 'description'. The 'name' attribute on 'input' and 'output' 
         element should be removed. Also, 'with explicit message names' should be 
         removed from title.