Re: LC 76 - What makes a msg WS-A?

This all makes fine sense.  In this context, the long discussion has
been over how we fill in "sender does not mandate WSA, receiver gets to
choose", and I agree with everyone who says this is outside the scope of
the core and SOAP binding documents.  I also agree with Jonathan that
there could be several different ways of making this choice, and we
don't want to preclude anything reasonable.

For what it's worth, I don't see why the "choose WSA if you see any wsa:
headers" won't work just fine as one such way of choosing.  I also don't
think keying off of wsa:Action is a good idea, and though I hadn't
thought it through that far previously, I really don't think mandating
it in the SOAP binding would be good, both because it's out of scope and
because I don't like it.

Anish Karmarkar wrote:

> Marc Hadley wrote:
>
>> On Jul 15, 2005, at 10:26 AM, David Hull wrote:
>>
>>> I'd be less uneasy with something less arbitrary.   The rule of 
>>> understanding (in the SOAP sense) only if a particular header is 
>>> present is not the first thing that would come to mind, and the 
>>> basis for choosing this particular header -- it happens to be 
>>> mandatory and not defaulted in the rules in section 3.2 -- is a 
>>> crock.  This approach also complicates the matrix we came up with 
>>> in Berlin.  Here's a version of that matrix, pretending that only 
>>> Action and ReplyTo exist.
>>>
>>> Action
>>> ReplyTo
>>> Result
>>> absent
>>> absent
>>> Old-style behavior
>>> absent
>>> present, mU false
>>> ReplyTo silently ignored (I don't understand it and I don't have to)
>>> absent
>>> present, mU true
>>> Fault (mandatory header ReplyTo not understood)
>>> present, mU=any
>>> absent
>>> OK, ReplyTo anonymous
>>> present, mU=any
>>> present, mU = any
>>> OK, ReplyTo value used
>>>
>>> My guess is that the italicized row will have a long and storied 
>>> career.
>>
>>
>>
>>
>> If wsa:Action is absent and and any other WS-Addr header is present 
>> with mU='false' then the receiving node can either:
>>
>> (i) Not process the other WS-Addr header and do normal non-WS-Addr 
>> processing, or
>> (ii) Process the other WS-Addr header and in so doing note that 
>> there's no Action (which is mandatory) and send a WS-Addr 'Message 
>> Addressing Header Required' fault.
>>
>> The spec already describes the required cardinality of WS-A headers, 
>> if a sender wants to make sure that WS-Addr processing happens then 
>> it can mark one of the WS-Addr headers as mU='true'. I'm not 
>> convinced we need to say anything else.
>>
>
> +1
>
> I'm a little bit baffled over this long email thread and why this is
> so confusing. I think Marc's (and Steve's email as well, IIRC) email
> says it quite well what the presence or absence of WSA header (and mU
> values) mean. The way I see it:
>
> if (mU='1' on any WSA header) //receiver must engage WSA or fault
> {
>   if (receiver does not understand WSA)
>   {
>      fault and stop processing the message
>   }
>   if (any WSA rule is violated) //including missing wsa:Action
>   {
>      fault and stop processing the message
>   }
>   process the message as a WSA message
> }
> else //sender does not mandate WSA, receiver gets to choose
> {
>   if (receiver wants to process the message with WSA engaged)
>   {
>     if (any WSA rule is violated) //including missing wsa:Action
>     {
>       fault and stop processing the message
>     }
>     process the message as a WSA message
>   }
>   else
>   {
>     ignore all WSA headers, if any
>     process the message as a non-WSA message
>   }
> }
>
>
> -Anish
> -- 
>
> <snip/>
>

Received on Friday, 15 July 2005 20:18:14 UTC