Web Services Addressing Candidate Recommentation Issues List

Issue List Revision: 1.67 , Date: 2007/06/05 17:23:45

XSL Revision: 1.13 , Date: 2007/04/02 22:03:32

Statistics

core soap schema all total
active 0 0 0 0 0
postponed 0 0 0 0 0
closed 9 15 0 1 41
duplicate 0 0 0 0 1
total 9 15 0 1 42

Open Issues Summary

id owner title target type SC

Closed Issues Summary

id owner title target type SC
cr1 [Details] for wsa:ActionMismatch Subsubcode soap editorial
cr2 [Details] for wsa:ActionMismatch Subsubcode soap design
cr3 ID-typed attribute on WS-Addressing EPRs? core design
cr4 The utility of the anonymous address in SOAP binding specification is too restrictive soap design
cr5 Generating Non-Reply Messages core editorial
cr6 wsa:InvalidAddress: redundancy and wsa:ProblemIRI error soap design
cr7 Mapping of headers to MAPs and "WSA is engaged" soap design
cr8 SOAPAction soap editorial
cr9 wsa:Action for undefined faults all design
cr10 TAG Request for Change to WS Addressing Core core design
cr11 SOAP Binding and SOAPAction in SOAP 1.1 soap design
cr12 Is [reference parameters] ordered or unordered? core design
cr13 Two additional predefined faults soap design
cr14 Relation of SOAP Headers to transport-level headers soap design
cr15 Exact relationship of anonymous URI to SOAP request-response soap design
cr16 Core Specification is inconsistent with wg resolutions (Issue 20 subissue d) core editorial
cr17 OPTIONAL or REQUIRED? core design
cr18 Precise meaning of an anonymous destination in a request message soap design
cr19 The basic interaction pattern from which all others are composed is "one-way". core design
cr20 Default value of To property core design
cr21 Resolution of CR17 introduced contradiction core design
cr22 Strengthen guidance on protocol-specifc fault action values soap design
cr23 Katy Warr cr15 resolution nullified cr4 resolution soap design
cr24 Use of predefined fault actions for application faults soap
cr25 Use SOAP 1.2 properties where possible in describing SOAP 1.2 behavior soap editorial
cr26 Unclear SOAP action precedence wsdl editorial
cr27 Philippe Le Hégaret Errata: WS-A SOAP Binding: Two occurances of <wsa:ProblemHeader> SOAP errata
cr28 SOAP Action; interpretation of zero length string WSDL editorial
cr29 Errata page has bad title and link Errata editorial
cr30 Tony Rogers What happens when the soapAction value is specified in WSDL but is not an absolute URI WSDL
cr31 Undefined combinations with Anonymous WSDL
cr32 None URI should be a special case and allowed when wsaw:anonymous=required WSDL
cr33 Spec does not support alternative anonymous URIs WSDL design
cr34 Non-Normative Reference to Policy WSDL editorial
cr35 Shall WS-Addressing Publish a Primer editorial
cr36 Remove text in SOAP binding that mentions other anonymous URIs SOAP editorial
cr37 New title for WSDL binding document wsdl editorial
cr38 Use a new Namespace for ws-addressing Metadata Document metadata elements wsdl design
cr39 Default Action Pattern wsdl editorial
cr40 Capitalizaiton discrepancy in default action pattern wsdl editorial
cr41 Issue with Default WSDL 2.0 Action Pattern for faults wsdl design
cr42 Example 4-5 within WSDL Binding document isn't schema valid wsdl editorial
SC key:
* open issue with at least one proposal
+ issue with action item
resolution accepted by reviewer
resolution rejected by reviewer

Detailed Listing

cr1 [Details] for wsa:ActionMismatch Subsubcode soap - editorial - closed
Description
In SOAP Binding, Candidate Recommendation, section 5.4.1.6, [Details] should contain <wsa:ProblemAction> instead of <wsa:ProblemHeader> or <wsa:ProblemHeaderQName> since that is more relevant information regarding the fault.
Origin
Arun Gupta (source)
Resolution2005-08-29 accepted by originator
Replace "ActionMismatch" with "ProblemAction".
cr2 [Details] for wsa:ActionMismatch Subsubcode soap - design - closed
Description
There is redundant information present when ProblemAction is used (i.e., we already know the problem header).
Origin
Arun Gupta (source)
Proposal 1 2005-08-29
Resolution 2006-03-03 accepted by originator
Close with no Action
cr3 ID-typed attribute on WS-Addressing EPRs? core - design - closed
Description

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.

Origin
John Kemp (source)
Resolution 2005-09-19 not accepted by originator
Individual security mechanisms will specify how to identify portions of a document; it's inappropriate for WS-A to constrain or encourage a particular mechanism. No change.
Resolution 2006-03-03
Editor will provide additional text pointing to existence of xml:id
cr4 The utility of the anonymous address in SOAP binding specification is too restrictive soap - design - closed
Description
OASIS WS-RX tc needs to utilize the semantics of the anonymous URI as defined by the WS-Addressing specification as the address of other EPRs that it defines, in particular as the value of wsrm:AcksTo EPR defined in the WS-ReliableMessaging specification[1]. OASIS WS-RX tc noticed that WS-Addressing SOAP binding specification defines the semantics of the anonymous URI we need, but only wrt the ReplyTo and FaultTo EPRs in Section 3.5.
Origin
Ümit Yalçınalp (source)
Proposal 12005-09-26
The paragraph in question should be extended to allow other EPRs to use the same semantics defined for the anonymous address
Resolution2005-09-29 accepted by originator
"the ReplyTo or FaultTo EPR" -> "an EPR", "..provides such a channel *for response messages.*"
cr5 Generating Non-Reply Messages core - editorial - closed
Description
Last Call issue number 89, comment 7, brought up the issue that we did (and do) not specify how to formulate anything other than a "reply" message in our spec. Especially in light of the fact that we have been discussing how to map EPRs to WSDL, there are clearly cases where one wants to know how to formulate and send a message to an EPR outside of the context of an explicit reply.
Origin
Glen Daniels (source)
Proposal 12005-09-29
  • Factor out most of the content of step 2 (all but the second bullet) in the current section 3.2 into a new section 3.2, called "Sending a Message to an EPR" or the like. The remaining stuff would be section 3.3, "Formulating a Reply Message".
  • The text of step 2 in the new section 3.3 would change to "send the message per 'sending a message to an EPR' above, and additionally populate the [relationship] property as follows: a new pair of IRIs... [rest of old text]"
Resolution2005-09-30 accepted by originator
Accept proposal 1.
cr6 wsa:InvalidAddress: redundancy and wsa:ProblemIRI error soap - design - closed
Description

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.

Origin
Hugo Haas (source)
Proposal 1 2005-09-29
Remove wsa:ProblemIRI wsa:InvalidAddress's description.
Resolution2005-10-10 accepted by originator
Accept Proposal 1.
cr7 Mapping of headers to MAPs and "WSA is engaged" soap - design - closed
Description

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.

Origin
David Hull (source)
Resolution 2005-09-30 accepted by originator
Add to the SOAP Binding: "If a receiver processes a message containing a wsa:Action header, this SOAP binding is engaged, [and the rules of this spec are in force]."
cr8 SOAPAction soap - editorial - closed
Description
A colleague noted what I believe to be an editorial oversight in the SOAP binding related to SOAPAction. Section 4.2 states: "The value of the SOAPAction HTTP header MUST either be identical to the value of the wsa:Action header, or be empty." However, according to the WS-I basic profile, the value of the SOAPAction header is a quoted string rather than a URI. What I think we want to say is that the value of the SOAPAction HTTP header must be either '"' [action] '"' or empty and I'd propose to update the document to reflect this.
Origin
Marc Hadley (source)
Proposal 1 2005-10-14
Resolution2005-10-17 accepted by originator
Accept proposal 1.
cr9 wsa:Action for undefined faults all - design - closed
Description

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?

Origin
Jonathan Marsh (source)
Proposal 12005-10-17
Do nothing / Perhaps note in the spec that such action values are explicitly not defined.
Proposal 22005-10-17
Reuse http://www.w3.org/@@@@/@@/addressing/fault.
Proposal 32005-10-17
Define a new action URI for soap faults (e.g. /soap/fault).
Proposal 4 2005-10-24
Revised proposal 3
Resolution2005-11-07 accepted by originator

In SOAP Binding document, section 5:

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

http://www.w3.org/@@@@/@@/addressing/soap/fault

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

cr10 TAG Request for Change to WS Addressing Core core - design - closed
Description

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.

Origin
W3C TAG (source)
Proposal 12005-10-25
Add 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.
Proposal 22005-11-07
The Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than [destination] to identify a resource may result in it not being on the Web. In certain circumstances, use of such additional properties may be convenient or beneficial. When building systems that use non-URI identifiers, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the Web.
Proposal 32005-11-07
The Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than [destination] to identify a resource is out of the scope of the Web Architecture. In certain circumstances, use of such additional properties may be convenient or beneficial. When building systems that use non-URI identifiers, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the Web.
Proposal 42005-11-07
The Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than [destination] to identify a resource loses core benefits of the Web Architecture [AoWWW 2.1]. In certain circumstances, use of such additional properties may be convenient or beneficial. When building systems that use non-URI identifiers, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the Web.
Proposal 52005-11-21
The W3C Architecture of the World Wide Web [AoWWW] recommends as Best Practice [Section 2.1] the use of URIs to identify resources. Following this best practice precludes the use of abstract properties of an EPR other than [destination] to identify resources. In certain circumstances, such a use of additional properties may be convenient or beneficial. However, when building systems, the benefits or convenience of identifying a resource using reference parameters should be carefully weighed against the benefits of identifying a resource solely by URI.
Proposal 6 2005-12-05
The Architecture of the World Wide Web, Volume One [AoWWW] recommends [Section 2 of AoWWW] the use of URIs to identify resources. Using abstract properties of an EPR other than [destination] to identify resources is contrary to this recommendation. In certain circumstances, such a use of additional properties may be convenient or beneficial; however, when building systems, the benefits or convenience of identifying a resource using reference parameters should be carefully weighed against the benefits of identifying a resource solely by URI as explained in [Section 2.1] of the Web Architecture.
Resolution2006-01-20 accepted by originator
Accept proposal 6.
cr11 SOAP Binding and SOAPAction in SOAP 1.1 soap - design - closed
Description

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.

Origin
Anish Karmarkar (source)
Proposal 12005-10-27
"Use of the SOAPAction HTTP header is required in the HTTP Request when using the SOAP 1.1 HTTP binding. The value of the SOAPAction HTTP header, if present, 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)."
Resolution2005-11-07 accepted by originator
Use of the SOAPAction HTTP request header field is required when using the SOAP 1.1 HTTP binding. The field-value of the SOAPAction HTTP request header MUST either be the value of the [action] property enclosed in quotation marks, or the empty value "". The latter case supports the ability to obscure the [action] property through SOAP-level security mechanisms, without requiring otherwise unnecessary transport-level security. Any other value for SOAPAction results in an Invalid Message Addressing Property fault (see 5.4.1 Invalid Addressing Header).
cr12 Is [reference parameters] ordered or unordered? core - design - closed
Description
The definition of [reference parameters] in the core says that its type is "xs:any (0 .. unbounded)". There is no mention, either in the notation conventions in section 1.1, or in the description of [reference parameters] itself in section 2.1, of whether this means a list of 0 or more xs:any (order is significant and duplicates are OK) or a set (order is not significant and duplicates are ignored). On the one hand, the text in 1.1 suggests that order is not important, since it only mentions cardinality. On the other hand, [reference parameters] are to be represented as an XML infoset, which implies order. Given that [reference parameters] will ultimately be seen as SOAP headers, which are unordered, we should specifically say that [reference parameters] are unordered. Similar considerations apply to [metadata], but it is not clear whether metadata should be considered ordered or unordered.
Resolution2005-11-08 accepted by originator
Editors to specify reference parameters as unordered.
cr13 Two additional predefined faults soap - design - closed
Description

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
Origin
Ümit Yalçınalp (source)
Resolution2006-01-20 accepted by originator
Add two new faults.
cr14 Relation of SOAP Headers to transport-level headers soap - design - closed
Description

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:).

Origin
David Hull (source)
Resolution 2006-01-20 accepted by originator
New section 3.5.
cr15 Exact relationship of anonymous URI to SOAP request-response soap - design - closed
Description

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.

Origin
David Hull (source)
Proposal 12005-12-01
Replace the first two sentences of the section so that the section as a whole reads: In the context of a SOAP request-response MEP, sending a response message to an EPR whose [address] is "http://www.w3.org/@@@@/@@/addressing/anonymous" means sending it as the response message of the MEP. For instance, the SOAP 1.2 HTTP binding[SOAP 1.2 Part 2: Adjuncts] puts the reply message in the HTTP response.
Resolution 2006-01-19 accepted by originator
cr16 Core Specification is inconsistent with wg resolutions (Issue 20 subissue d) core - editorial - closed
Description

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.

Origin
Ümit Yalçınalp (source)
Resolution2006-01-20 accepted by originator
Re-incorporate resolution of i020d.
cr17 OPTIONAL or REQUIRED? core - design - closed
Description

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.

Origin
Ümit Yalçınalp (source)
Resolution 2006-01-20 accepted by originator
Resolution 2006-03-02 accepted by originator
cr18 Precise meaning of an anonymous destination in a request message soap - design - closed
Description

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

Origin
Paul Downey (source)
Proposal 1 2006-02-06
option 3
Proposal 2 2006-02-08
Proposal 3 2006-02-09
Close clarifying status quo.
Resolution2006-02-20 accepted by originator
Close clarifying status quo.
cr19 The basic interaction pattern from which all others are composed is "one-way". core - design - closed
Description
Section 3 begins by stating "This section defines the information model and syntax of message addressing properties." However, not long after that, we state that "The basic interaction pattern from which all others are composed is "one-way"." and go on to discuss request-response and more exotic variants. This has always bothered me for several reasons, for example:
  • 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.
Origin
David Hull (source)
Resolution2006-01-20 accepted by originator
Start offending sentence with: "In a one-way interaction pattern, the source sends a message..."
cr20 Default value of To property core - design - closed
Description
The spec currently defaults the value of the To property to anonymous (Core, 3.2); the goal of this decision was to optimize the request reply synchronous interaction. However, as written in Section 3.2 this applies to arbitrary messages. Just as in the case of ReplyTo, addressed in CR13, I propose the defaulting of To to anonymous be moved to Section 3.4 and limited to request reply interactions
Origin
Francisco Curbera (source)
Proposal 1 2006-02-06
Initial proposal
Proposal 2 2006-02-16
Amalgamated Proposal
Proposal 3 2006-02-16
Close with no action.
Resolution 2006-02-20 accepted by originator
cr21 Resolution of CR17 introduced contradiction core - design - closed
Description
Section 5 of the WSDL binding document defines what abstract MAPs are mandatory in each message of the WSDL 1.1 and WSDL 2.0 defined MEPs. In each case where there is a reply message in the MEP, the [reply endpoint] is marked as mandatory. Previously, when absence of wsa:ReplyTo was a syntactic shortcut for inclusion of an anonymous [reply endpoint], this requirement would be satisfied using defaulting. By removing the defaulting from the infoset serialization we now *require* that wsa:ReplyTo always be present when a reply message is expected.

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.
Of the two, I prefer (i) since a simple serialization defaulting scheme is simplest to implement.
Origin
Marc Hadley (source)
Resolution 2006-03-02 accepted by originator
cr22 Strengthen guidance on protocol-specifc fault action values soap - design - closed
Description
Our spec allows a SOAP module or extension (e.g. reliability, security, transactions) to define a fault action specific to that module. The WS-Addressing spec itself defines its own custom fault action, and recommends one for SOAP-level faults:

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

http://www.w3.org/@@@@/@@/addressing/fault

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

http://www.w3.org/@@@@/@@/addressing/soap/fault

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.

Origin
Jonathan Marsh (source)
Proposal 1

change the above text as follows:

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

Resolution 2006-02-20 accepted by originator
Proposal 1 above was accepted
cr23 cr15 resolution nullified cr4 resolution soap - design - closed
Description
Apparently the resolution to cr15 removed text desired for the resolution of cr4
Origin
Anish Karmarkar (source)
Owner
Katy Warr
Proposal 1 2006-02-26
Proposal 2 2006-03-02
Resolution 2006-03-02 accepted by originator
cr24 Use of predefined fault actions for application faults soap - - closed
Description
SOAP Binding section 6
Origin
Jonathan Marsh (source)
Resolution 2006-03-02 accepted by originator
The above [action] value SHOULD be used for SOAP defined SOAP faults including
            version mismatch, must understand, and data encoding unknown. *This action SHOULD NOT be
            used as an action value in messages other than those carrying SOAP defined SOAP faults
            or those of SOAP modules and extensions.* I use SHOULD because this is a hard thing to
            test, seems like the appropriate level of guidance, and doesn't force a breaking change
            in implementations at this point.
cr25 Use SOAP 1.2 properties where possible in describing SOAP 1.2 behavior soap - editorial - closed
Description
 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. 
Origin
David Hull (source)
Resolution 2006-03-03 accepted by originator
cr26 Unclear SOAP action precedence wsdl - editorial - closed
Description
 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. 
Origin
Jonathan Marsh (source)
Resolution 2006-07-31 accepted by originator
cr27 Errata: WS-A SOAP Binding: Two occurances of <wsa:ProblemHeader> SOAP - errata - closed
Description
 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 
Origin
Jonathan Marsh (source)
Owner
Philippe Le Hégaret
Proposal 1 2006-08-16
Resolution 2006-08-21 accepted by originator
Philippe's E01 accepted as drafted
cr28 SOAP Action; interpretation of zero length string WSDL - editorial - closed
Description
 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
                        
Origin
Arun Gupta (source)
Proposal 12006-07-31
 Current text: In the absence of a wsaw:Action attribute on a WSDL input element
            where a SOAPAction value is specified, Proposed text: In the absence of a wsaw:Action
            attribute on a WSDL input element where a *non empty* SOAPAction value is specified,
         
Resolution 2006-07-31 accepted by originator
Proposal 1 as above accepted
cr29 Errata page has bad title and link Errata - editorial - closed
Description
 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. 
Origin
David Illsley (source)
Resolution 2006-08-07 accepted by originator
cr30 What happens when the soapAction value is specified in WSDL but is not an absolute URI WSDL - - closed
Description
 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.
         
Origin
Anish Karmarkar (source)
Owner
Tony Rogers
Proposal 1 2006-08-21

4.4.1

current first para:

WS-Addressing defines a global attribute, wsaw:Action, that can be used to explicitly define the value of the [action] property for messages in a WSDL description. The type of the attribute is xs:anyURI and it is used as an extension on the WSDL input, output and fault elements. A SOAP binding can specify SOAPAction values for the input messages of operations. 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. Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding] specifies restrictions on the relationship between the values of [action] and SOAPAction for SOAP 1.1 and SOAP 1.2.

suggested new first para:

WS-Addressing defines a global attribute, wsaw:Action, that can be used to explicitly define the value of the [action] property for messages in a WSDL description. The type of the attribute is xs:anyURI and it is used as an extension on the WSDL input, output and fault elements. A SOAP binding can specify SOAPAction values for the input messages of operations. 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. Note that the SOAPAction value is not required to be an absolute IRI, but the [action] property is required to be an absolute IRI; if wsaw:UsingAddressing is present, wsaw:Action is not specified, and SOAPAction is not an absolute IRI, then the document MUST be considered invalid. Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding] specifies restrictions on the relationship between the values of [action] and SOAPAction for SOAP 1.1 and SOAP 1.2.

Resolution 2006-08-21 accepted by originator
Tony's proposed text + exception for empty IRI as a valid SOAPAction value
cr31 Undefined combinations with Anonymous WSDL - - closed
Description
 Grey areas in th table [1] are undefined [1] http://www.w3.org/2002/ws/addr/6/08/cr31.html
                        
Origin
Arun Gupta (source)
Proposal 1 2006-10-02
Partial proposal, needing discussion
Resolution
Rendered moot by changes in the document that eliminated the table in question.
cr32 None URI should be a special case and allowed when wsaw:anonymous=required WSDL - - closed
Description
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.
Origin
David Illsley (source)
Resolution 2006-08-14
none is acceptable for use when anon=required or anon=prohibited
cr33 Spec does not support alternative anonymous URIs WSDL - design - closed
Description
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
                        
Origin
Doug Davis (source)
Proposal 1 2006-08-14
Change MUST to SHOULD
Proposal 2 2006-08-16
<wsaw:NewConnection>
Proposal 3 2006-09-14
Delete <wsaw:anonymous>
Proposal 4 2006-09-18
new attribute boolean: wsaw:isAnon
Proposal 5 2006-10-02
Outline of a proposal casting wsaw:Anonymous in more policy friendly terms
Proposal 6 2006-10-31
A different syntactic approach
Proposal 7 2006-11-08
Proposal for policy assertions
Proposal 8 2006-11-13
Updated proposal for policy assertions
Proposal 9 2006-11-14
Alternative proposal for WS-Policy assertions
Proposal 10 2006-12-06
Proposal for nested policy assertion
Resolution 2006-12-11 accepted by originator
cr34 Non-Normative Reference to Policy WSDL - editorial - closed
Description

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]>)."

Origin
WS-Policy WG (source)
Resolution 2006-09-25 accepted by originator
proposal accepted as submitted
cr35 Shall WS-Addressing Publish a Primer - editorial - closed
Description
A primer migth significantly improve the community understqanding of WS-Addressing
Resolution
No significant interest in producing a primer
cr36 Remove text in SOAP binding that mentions other anonymous URIs SOAP - editorial - closed
Description
Resolution 2006-11-06 accepted by originator
WG agreed to remove the text
Resolution 2006-11-06 accepted by originator
Change does not affect conformance.
cr37 New title for WSDL binding document wsdl - editorial - closed
Description
Since the document no longer simply describes the wsdl for ws-addressing is deserves a more descriptive title
Origin
WG telecon 2006-12-04
Resolution 2006-12-11 accepted by originator
WSDL Binding to be renamed to "WS-Addressing Metadata"
cr38 Use a new Namespace for ws-addressing Metadata Document metadata elements wsdl - design - closed
Description
Due to the number and nature of changes, a new namespace is indicated.
Origin
WG Telecon 2006-12-11
Resolution 2006-12-11 accepted by originator
New namespace for ws-Addressing Metadata elements
cr39 Default Action Pattern wsdl - editorial - duplicate
Description
            Gurus,
            
            In the case of a WSDL 2.0 interface inheriting another interface, what wd be
            the Default Action pattern for Faults that were inherited from the parent
            interface ? Would it be still containing the targetNamespace of the parent
            interface [the declaring interface], and the name of the target interface,
            or would it be composed from the targetnamespace and the interface name of
            the child interface ?
            
            The semantics for this is Not clear in the document that describes the WSDL
            2.0 Binding for WS-Addressing.
            
            -Ram
            
         
Origin
Ramkumar Menon (source)
Resolution 2006-12-11
Close with no action,
cr40 Capitalizaiton discrepancy in default action pattern wsdl - editorial - closed
Description
            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
                        
Origin
Jonathan Marsh (source)
Resolution accepted by originator
Accepted as proposed
cr41 Issue with Default WSDL 2.0 Action Pattern for faults wsdl - design - closed
Description
            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.
            
         
Origin
Cindy McNally (source)
Resolution 2006-12-11
Close with no action,
Resolution2007-06-18 accepted by originator
Issue is a duplicate of LC141 and was closed and accepted by the same reviewer
cr42 Example 4-5 within WSDL Binding document isn't schema valid wsdl - editorial - closed
Description
         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.
Origin
Cindy McNally (source)
Resolution accepted by originator
Accepted as proposed