- From: Francisco Curbera <curbera@us.ibm.com>
- Date: Tue, 24 Jan 2006 16:15:48 -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: <OFB0CA683F.0E42853E-ON85257100.0074802C-85257100.0074CDE8@us.ibm.com>
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
Attachments
- application/octet-stream attachment: smime.p7s
Received on Tuesday, 24 January 2006 21:16:01 UTC