- From: David Hull <dmh@tibco.com>
- Date: Thu, 26 Jan 2006 10:23:26 -0500
- To: Francisco Curbera <curbera@us.ibm.com>
- Cc: Marc Hadley <Marc.Hadley@Sun.COM>, Mark Nottingham <mnot@mnot.net>, WS-Addressing <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
- Message-id: <43D8E96E.2070408@tibco.com>
I'm increasingly convinced that the [destination] MAP should syntactically default to anonymous and, in the context of the SOAP binding, anonymous should mean "use the value of the [destination address] SOAP property." See [1] for how to define this and other useful properties. Actually, I find the whole "anonymous" thing a bit odd and indirect, but it's part of the landscape by now. [1] http://lists.w3.org/Archives/Public/xml-dist-app/2006Jan/0135.html Francisco Curbera wrote: >I should have been more accurate: the defaulting of the reply to endpoint >is limited to replies in general. That is also what I suggest we do with >the default of the destination property. Thanks for pointing that out. > >Paco > > > > > Marc Hadley > <Marc.Hadley@Sun. To: Francisco Curbera/Watson/IBM@IBMUS > COM> cc: Mark Nottingham <mnot@mnot.net>, WS-Addressing <public-ws-addressing@w3.org>, > Sent by: public-ws-addressing-request@w3.org > Marc.Hadley@Sun.C Subject: Re: New issue: Default value of To property > OM > > > 01/24/2006 04:00 > PM > > > > > >On Jan 24, 2006, at 12:26 PM, Francisco Curbera wrote: > > > >>We already have a default that is restricted to the request reply >>interaction - defaulting of the [reply endpoint] property. We went >>in some >>detail over why that should be the case at the f2f. This issue is >>just the >>completion of that discussion IMO. >> >> >> >I don't think defaulting of the [reply endpoint] is restricted to the >request-response MEP, the default should be valid for any MEP in >which a reply exists (e.g. request optional response). The defaulting >is a syntactic thing rather than a semantic thing; anywhere that an >explicit anonymous wsa:To makes sense its OK to take advantage of the >defaulting (IMO). > >I think it would be far more error prone to define a default that >only applies under very specific conditions (e.g. a particular >message of a particular MEP bound to a particular underlying >protocol) than to stay with the generic syntactic default we have now >that applies under all circumstances. > >Marc. > > > >>MOre explicitly, the motivation of the issue is, again, the >>observation >>that a default which does not capture a sufficiently common use >>case is >>unhelpful and possibly prone to error. The anonymous URI only makes >>sense >>in very specific situations, when the transport binding is such >>that an >>implicit channel is available. This is the case in a synchronous >>request >>reply, and may be the case in other situations we don't know about. An >>unqualified default for the destination seems to assume that most >>of the >>times such an implicit channel available, which is just not the case. >> >>The defaulting of properties to the anonymous URI or to EPRs with an >>anonymous address was intended to optimize the SOAP/HTTP request >>response >>case. For some perverse reason we've found ourselves with those >>defaults >>extended to every message and every binding w/o really knowing what >>purpose >>that extension would serve. >> >>Finally, I can imagine scenarios where an anonymous destination >>becomes >>meaningful based on the configuration of the binding and supporting >>infrastructure - MOM systems come to mind. So I don't think we need >>to be >>unnecessarily restrictive and try to prevent the use of anonymous >>addresses >>in the destination property altogether. >> >>Paco >> >> >> >> >> >> Marc Hadley >> <Marc.Hadley@Sun. To: Francisco >>Curbera/Watson/IBM@IBMUS >> COM> cc: Mark >>Nottingham <mnot@mnot.net>, WS-Addressing <public-ws- >>addressing@w3.org>, >> Sent by: public-ws- >>addressing-request@w3.org >> Marc.Hadley@Sun.C Subject: Re: New >>issue: Default value of To property >> OM >> >> >> 01/24/2006 11:07 >> AM >> >> >> >> >> >>I think it complicates things to have a default in some circumstances >>and not others. Provided the default value is always the same >>(anonymous in our case), it is easy to formulate the value of MAPs >>and check the validity of an inbound message regardless of whether >>the message is a request, response, notification, fault or some other >>classification that we haven't yet come up with. If we start adding >>provisos to the defaulting rules then things just get more complex >>and we'll end up introducing edge cases etc. >> >>To be honest I'm not clear what problem you are trying to solve, why >>is it better to have an explicit <wsa:To>http://.../../anonymous</ >>wsa:To> in the message than an implicit default one ? >> >>FWIW, I can see that having an anonymous wsa:To in a request message >>might cause some implementations difficulties, but changing the >>defaulting rules won't fix this problem (you could still get an >>explicit anonymous to) and as I outlined in my previous mail its >>unlikely to occur in the first place. If an anonymous wsa:To in >>request messages is the problem you are trying to attack then I think >>it would be much more effective to work on that directly rather than >>complicating the defaulting rules. >> >>Marc. >> >>On Jan 24, 2006, at 10:24 AM, Francisco Curbera wrote: >> >> >> >>>Hi Marc, >>> >>>You are taking the sender's view only; there is also the receiver's >>>view, >>>who may or may not have access to the EPR the sender used. In any >>>case, it >>>is clear that any default works as long as it is not ambiguous. >>>What I am >>>arguing is that a default only makes sense when it cover (and maybe >>>helps >>>optimize) a common case. It can certainly be argued that for >>>synchronous >>>request response interactions it makes sense to default the To of >>>the reply >>>message to anonymous. Arguing that that is also the case for all >>>other uses >>>of WSA is to take a very narrow perspective IMO - particularly >>>since one of >>>WSA's major contributions is to enable interoperable asynchronous >>>messaging over different interaction patterns. >>> >>>We essentially went through a similar argument when we recognized >>>that >>>defaulting the [reply endpoint] to an EPR with an anonymous address >>>makes >>>sense only in the context of Section 3.4 - Formulating a Reply >>>Message. I >>>think we just need to finish the job and scope the defaulting of the >>>[destination] property to anonymous to the case of reply messages >>>as well. >>> >>>Paco >>> >>> >>> >>> >>> >>> Marc Hadley >>> <Marc.Hadley@Sun.COM> To: >>>Francisco Curbera/Watson/IBM@IBMUS >>> Sent by: cc: >>>Mark Nottingham <mnot@mnot.net>, WS-Addressing >>> public-ws-addressing-req <public-ws- >>>addressing@w3.org> >>> uest@w3.org Subject: Re: >>>New issue: Default value of To property >>> >>> >>> 01/23/2006 10:50 AM >>> >>> >>> >>> >>> >>>I don't think we need to special-case things as you suggest since the >>>rules for sending a message[1] already require the wsa:To to have the >>>same address as that contained in the EPR to which the message is >>>sent. Therefore the only time the wsa:To value can be defaulted is >>>when the EPR to which the message is sent has an 'anonymous' address >>>and I don't see that happening regularly with request messages >>>because, if it did, you wouldn't know where to send then. >>> >>>Marc. >>> >>>[1] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- >>>core.html?content-type=text/html;%20charset=utf-8#sendmsgepr >>> >>> >>>On Jan 20, 2006, at 1:23 PM, Francisco Curbera wrote: >>> >>> >>> >>>>Can I please add this new CR issue against the WS-Addressing core >>>>spec. >>>> >>>>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. >>>> >>>>Paco >>>> >>>> >>>> >>>> >>>--- >>>Marc Hadley <marc.hadley at sun.com> >>>Business Alliances, CTO Office, Sun Microsystems. >>> >>> >>> >>> >>> >>>#### smime.p7s has been removed from this note on January 24, 2006 by >>>Francisco Curbera >>><smime.p7s> >>> >>> >>--- >>Marc Hadley <marc.hadley at sun.com> >>Business Alliances, CTO Office, Sun Microsystems. >> >> >> >> >> >>#### smime.p7s has been removed from this note on January 24, 2006 by >>Francisco Curbera >><smime.p7s> >> >> > >--- >Marc Hadley <marc.hadley at sun.com> >Business Alliances, CTO Office, Sun Microsystems. > > > > > >#### smime.p7s has been removed from this note on January 24, 2006 by >Francisco Curbera > >
Received on Thursday, 26 January 2006 15:23:57 UTC