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

Re: New issue: Default value of To property

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Tue, 24 Jan 2006 16:00:42 -0500
To: Francisco Curbera <curbera@us.ibm.com>
Cc: Mark Nottingham <mnot@mnot.net>, WS-Addressing <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
Message-id: <512DB490-389A-42CB-A990-030EAA1D7803@Sun.COM>
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.




Received on Tuesday, 24 January 2006 21:01:42 GMT

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