- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Mon, 19 Dec 2005 09:02:46 -0800
- To: "David Hull" <dmh@tibco.com>
- Cc: <public-ws-addressing@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D64165CC201E@uspale20.pal.sap.corp>
David, It is my impression that the wg has spent quite a long time hashing what anonymous means and where it should go. The definition is now in the SOAP binding document. Yes, it is a specific transport specific, but my understanding is that it is the final position of the wg. I personally do not want to reopen the discussion again with respect to its definition. What is the new perspective/information that would lead us to do this? Perhaps this explains my position better. Thanks, --umit ________________________________ From: David Hull [mailto:dmh@tibco.com] Sent: Monday, Dec 19, 2005 8:49 AM To: Yalcinalp, Umit Cc: public-ws-addressing@w3.org Subject: Re: Amended proposal for i059 Yalcinalp, Umit wrote: David, We need to approach this from the perspective of problem solving. I'll bear that in mind. You seem to be changing the doc so that SOAP 1.1 and SOAP 1.2 have equal footing. I don't that I'd put it that way. Certainly the text falls out differently for 1.1 and 1.2. What I had meant to do was to pull out text that applies to any version of SOAP(or possibly beyond the context of SOAP; see below) and state it once instead of repeating it. The full structure is: 1. What are the rules for the WSDL markup (UsingAddressing, Anonymous)? This clearly has to go in the WSDL binding. The WSDL markup defines (among other things) when the anonymous endpoint is allowed to occur in a response endpoint. This is section 3.1, and 3.1.1, which I think is basically OK, modulo the changes regarding response endpoints, which we seem to agree on. 2. What does the anonymous endpoint mean in general? If this goes beyond the scope of SOAP messages (e.g., SOAP request, binary response, etc.), then this can't go in the SOAP binding. This would be the ideal place to set out the key idea of having anonymous tie the inbound and outbound messages to a request response MEP, instead of trying to define a "response channel" and just tie the individual outbound message to it. Though a purely technical point, it looks to make the definitions considerably shorter and clearer. Unfortunately, the only places I know of where "request-response" is defined concretely concretely are in HTTP and in the SOAP adjuncts. This is where introducing a transport-level MEP, independent of SOAP, could come in handy (if anyone would like to advocate this, please jump in :-) 3. What does the anonymous endpoint mean in the context of SOAP, in general? If we can say anything in general about SOAP, but not beyond SOAP, it would go here. My feeling is that we probably don't need anything in this slot, though right now it currently holds the material that would ideally go in slot 2 (section 3.1.2 in what I sent out). I agree that this and what follows is somewhat redundant with the definition of anonymous in the SOAP binding. Leaving potential process issues aside, I lean toward taking the section (3.5) out of the SOAP binding. I don't believe it's concrete enough to be useful on its own. To make it concrete enough to use, you have to talk about binding MEPs, and that's not only necessary, but sufficient. 4. What does anonymous mean for SOAP 1.1/HTTP and SOAP 1.2? I believe what I put in 3.1.2.x is what belongs there. (a) I like that you are more inclusive about response endpoints and they should be extended to other response endpoints, to cover acks to help other specifications. This is aligned with the CR issue we result wrt the definition of anonymous in the SOAP binding. (b) I do not follow why we need yet another definition of anonymous address here in Section 3.1.2. We already have the definition which we tinkered with in the SOAP binding document. I really can not follow what it adds in the WSDL document as stated. See above. The last paragraph of this section, however, is in the right direction. (c) You changed the slant by adding Section 3.1.2.1 which de-couples of the usage of the "Anonymous" marker and coupling it with the usage of "anonymous" on the wire. I think first the wg has to decide whether the semantics of the binding is with the extension and whether it is coupled with the WSDL document as an extension or it is defined in the SOAP binding. This change presupposes that we actually move this section to the SOAP binding document. If we were to do this, the writeup would make more sense as it talks about the behaviour from the perspective of the presence of the anonymous addresses on the wire (to be added to SOAP binding document) and then relating the semantics of the markup <Anonymous> to constrain the behaviour (in WSDL binding document), For example: {When the anonymous address is used, the outbound message MUST be sent over the same HTTP connection as the inbound message}. What does this usage apply to? What happens if the Anonymous marker was "prohibited" in WSDL? This is an error condition. A compliant processor that advertises Anonymous "prohibited" will not send an application-level message anonymously. Stepping back a bit, there is a clean split between whether an anonymous endpoint is used, which depends both on the WSDL markup and the behavior of the sender, and what it means if it is used. There's no need to talk about the markup in the context of the behavior. There is a separate issue of how we model the handling of the SOAP fault that MUST be generated. We'll have to deal both with SOAP's generate/send distinction and probably WSDL's notion of "fault replaces message" and "message triggers fault". I think any problems in both cases are basically to do with terminology. However, dealing with this has little to do with the Anonymous marker per se. A "anonymous prohibited" fault must be handled in the same way as a mustUnderstand fault, or any other fault that occurs before WSA is engaged. I really think that we should first answer the where the SOAP binding extension goes before we go there... Thanks, --umit ________________________________ From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull Sent: Friday, Dec 16, 2005 2:23 PM To: public-ws-addressing@w3.org Subject: Amended proposal for i059 In line with the discussion on Monday's call and the email I just sent out, here is an amended version of the proposal for UsingAddressing. My additions and changes are shown in green. Deleted text has been quietly omitted. Points of interest: * I have substituted "response endpoint" for [reply endpoint] and wsa:replyTo, and defined "response endpoint" as "[reply endpoint] or [fault endpoint] as the case may be". * I have tried to consistently use "inbound message" for "request" and "outbound message" for response, in line with WSDL use of "in" and "out" and in contrast to "request" and "response" in the SOAP and HTTP context. * In combining my proposal with the existing proposal, I noticed that much of the text in each was actually independent of which version of SOAP is in use. I have combined these and boiled them down a bit, shortening both in the process. * I completely removed the text about anonymous being "required" etc. from the SOAP section. I believe this is in line with Marc's comment about repeated text. The first section discusses when the anonymous URI can appear, the following sections discuss what that means, and as far as I can tell the two are independent. * All this notwithstanding, the core of the original proposal for SOAP1.1/HTTP is basically intact. In generally, I believe this latest version has essentially the same semantics as the previous one, but is briefer, (hopefully) clearer, and applicable to both SOAP 1.1 and SOAP 1.2 As always, comments are welcome.
Received on Monday, 19 December 2005 17:00:52 UTC