- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Wed, 16 Nov 2005 10:50:26 -0800
- To: "WS-Addressing" <public-ws-addressing@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D6416593C7F5@uspale20.pal.sap.corp>
Folks, I took an [action item] to send Proposal 1 so that it can be reevaluated and modified. I am wondering whether we could make high level decisions on the syntax first because this is where we will end up anyway. If we make a decision first on this, it is easier to write this section as it is a straightforward exercise. We have three options to represent asyncronous capabilities of the endpoint, binding or binding/operation to describe the granularity of supporting anonymous and non-anonymous URI as response addresses. We have three granularity levels to support (full capabilities of addressing, supporting only anonymous URIs as response addresses or supporting only non-anon) (1) Two elements (as [Proposal1]) usingAddressing element as currently described Async element which is used in conjunction with usingAddressing element with three values. (2) Marc's proposal (usingAddressing element with an attribute with three values) [Marc]. He proposes "Required", "Allowed", "Disallowed". I propose "AnonRequired", "AnonDisallowed", "AnonAllowed" to reflect the semantics we want to capture. (3) (new option) This came up during our conversations in writing Proposal 1 and I speculate it may be discussed again. Use three elements: usingAddressing: It corresponds to the full usage of addressing semantics including both anon/non-anon URI usingAddressingAnonURIRequired (obvious) usingAddressingNonAnonURIRequired (obvious) In option 1 and 2, we need to replace the text: {The inclusion of the wsaw:UsingAddressing element indicates that the applicable WS-Addressing specifications are supported within the constraints of the WSDL binding being used. That is, uses of the WS-Addressing specifications that may violate or are inconsistent with the semantics of the endpoint's WSDL binding are not supported unless explicitly stated by some other mechanism. Specifically, when included in a SOAP binding, the wsaw:UsingAddressing marker identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP <> ]. The presence of the wsaw:UsingAddressing element in the binding or endpoint (port) components of the endpoint description does not change the semantics of the binding. E.g. in the case of the WSDL SOAP/HTTP synchronous binding for request-response operations, the presence of the wsaw:UsingAddressing element does not change the requirement that the response message be sent over the same HTTP channel over which the request was received. In this case, the wsa:replyTo header in the request MUST NOT contain an address with a value different from the anonymous URI.} The last option requires changes section 3.1 somewhat as we need to introduce all the new elements. Let me know if you still want to see the full writeup for Option 1. I will be very happy to write the target text depending on which syntax that we choose to adopt as well. All syntax formulations must reflect the decision we have taken as a wg, namely == there are three levels of granularity == the new {Async element/attribute|?} is general, not targeted to SOAP1.1/HTTP and talks about anon/non-anon URIs in their definition. == scoping is extended to binding operation == separate section targets SOAP 1.1/HTTP binding semantics (semantics of separate connection, 202, etc). --umit [Proposal1] http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0116.ht ml [Marc] http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0039.ht ml [Action Item] http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html
Received on Wednesday, 16 November 2005 18:49:11 UTC