Re: CR20

Either of option 0 or 3 seems reasonable. Option 2 would work too, but 
will then require the response message in soap/http case to include 
wsa:To. But more importantly, we don't define what 'anon' means and say 
that the binding must/should define it. It seems strange to ban the use 
of a URI whose semantics are defined by some other spec.

Option 1, as I (and Marc, IIRC) mentioned on last week's call makes it 
harder to validate the message independent of the context (context here 
means whether it is a request or a reply or something else). In case of 
CR17, since one is already in the middle of sending a reply and trying 
to figure out where to send it, defaulting does not pose a burden.

Another option is to make [destination] optional. This is the option I 
prefer, but not sure if there is a whole lot of support for it within 
the WG. Defaulting to something whose semantics is undefined (in the 
core) just doesn't seem right.

-Anish
--

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
> unmodified.
> 
> 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.
> 
> Paco
> 
> 
>

Received on Monday, 6 February 2006 19:52:14 UTC