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

Re: New issue: Default value of To property

From: Francisco Curbera <curbera@us.ibm.com>
Date: Tue, 24 Jan 2006 12:26:36 -0500
To: Marc Hadley <Marc.Hadley@Sun.COM>
Cc: Marc.Hadley@Sun.COM, Mark Nottingham <mnot@mnot.net>, WS-Addressing <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
Message-ID: <OFA120DC06.3AF16ECA-ON85257100.0058CC0E-85257100.005FD192@us.ibm.com>
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.

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



Received on Tuesday, 24 January 2006 17:26:47 GMT

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