- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Fri, 18 Nov 2005 08:00:58 -0500
- To: David Hull <dmh@tibco.com>
- Cc: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, WS-Addressing <public-ws-addressing@w3.org>
- Message-id: <F0AEC0BB-5747-4ACA-8A56-10E8037F8170@Sun.COM>
On Nov 16, 2005, at 1:58 PM, David Hull wrote: > I prefer (2). I believe the name of the attribute was to be (or > contain) "Anonymous", in which case > <wsa:UsingAddressing Anonymous="Allowed"/> > seems better than > <wsa:UsingAddressing Anonymous="AnonAllowed"/> Same here, adding 'Anon' to the value seems superfluous given that it is already the name of the attribute. Marc. > Again, I don't like the use of "async" anywhere in this, as the > term is too heavily overloaded. > > Yalcinalp, Umit wrote: >> 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.html >> [Marc] http://lists.w3.org/Archives/Public/public-ws-addressing/ >> 2005Nov/0039.html >> [Action Item] http://www.w3.org/2002/ws/addr/5/11/f2f-minutes.html >> >> > --- Marc Hadley <marc.hadley at sun.com> Business Alliances, CTO Office, Sun Microsystems.
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Friday, 18 November 2005 17:33:50 UTC