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

Re: CR20

From: David Hull <dmh@tibco.com>
Date: Mon, 06 Feb 2006 14:16:11 -0500
To: Francisco Curbera <curbera@us.ibm.com>
Cc: public-ws-addressing@w3.org
Message-id: <43E7A07B.4070602@tibco.com>

Francisco Curbera wrote:

>This is my summary of the options I think we have to close CR20.
>0. Get rid of the defaulting altogether. I don;t think anyone is pushing
>for this option anymore.
>1. Restrict the defaulting of To to the anonymous URI to response messages
>only. This is fully consistent with the resolution of CR17, that restricts
>the defaulting of ReplyTo (to the "anonymous EPR") to request messages.
>Advantages: consistent approach to the use of defaults for optimizing the
>synch request response patter, but leaving other potential issues
>2. Ban the use of anonymous in the To field altogether. Disadvantage: does
>not take into account the fact that anonymous has different meanings
>depending of the transport.
>3. Middle of the road approach: retain the defaulting of the To header to
>anonymous, but re-state that its use is actually dependent on the
>interpretation that the transport binding gives to the anonymous URI. Add a
>note indicating that for the SOAP/HTTP case the anonymous URI is only used
>to indicate the use of the HTTP back channel so it can only be used in
>reply messages.
>I think #3 provides an answer to CR 18 as well.
I would prefer

4. Use ImmediateDestination where applicable.  In the special case of
response messages in the context of request-response,
ImmediateDestination is not applicable, and sending to anonymous instead
means using the InboundMessage of the exchange.  This provides a
reasonable default for the general case [1], covers the response case
and avoids using the undefined term "back channel", instead using the
binding-defined property InboundMessage.

discussing ImmediateDestination in contexts other than request-response.

Received on Monday, 6 February 2006 19:16:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:12 UTC