W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2006

Re: New issue: Default value of To property

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:11 GMT