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

Martin Gudgin wrote:

> I don't understand the italicised line in your table. Surely this line
> only makes sense if I'm an endpoint that accepts WS-A and non-WS-A
> messages.

Right.  This is the case under consideration.

> If I'm an endpoint that only accepts WS-A messages I'll fault because
> there is no wsa:Action.

Right.  This is not under consideration.

> Also, the line under the italicized one should read 'Fault due to
> missing wsa:Action header', surely?

Perhaps I misunderstood your rules.  The latest  rules you gave for this
case are: "Is wsa:Action is missing then you MUST proceed as if you DO
NOT understand WS-Addressing. And if wsa:Action is present and any other
constraints in the spec are violated, then you MUST generate a fault."

In the line in question, wsa:Action is missing, so I MUST proceed as if
I DO NOT understand WS-Addressing.  I see a wsa:ReplyTo header.  I don't
understand WS-Addressing, and it's not mU, so I leave it alone.

In the line below that, wsa:Action is missing, so I don't understand
WS-Addressing.  I see a wsa:ReplyTo header, mU is true, and I fault
because ReplyTo was mU and I don't understand it.

In neither case do we fault for the missing wsa:Action, because we're
using that as our cue to forget everything we know about WSA.

>  
> I believe that requiring WS-A endpoints to fault if there is no wsa:
> Action is sufficient. I don't really understand why you think this is
> arbitrary.

I don't think that what you say here is arbitrary.  I believe that the
rule I quoted above, which says "Is wsa:Action is missing then you MUST
proceed as if you DO NOT understand WS-Addressing.", is arbitrary.  This
is what I meant when I said "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 [...]".  Sorry if this was not clear.

>  
> Gudge
>
>     ------------------------------------------------------------------------
>     *From:* David Hull [mailto:dmh@tibco.com]
>     *Sent:* 15 July 2005 15:26
>     *To:* Martin Gudgin
>     *Cc:* David Orchard; Katy Warr; public-ws-addressing@w3.org
>     *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>     Martin Gudgin wrote:
>
>>      
>>
>>         ------------------------------------------------------------------------
>>         *From:* David Hull [mailto:dmh@tibco.com]
>>         *Sent:* 15 July 2005 06:31
>>         *To:* Martin Gudgin
>>         *Cc:* David Orchard; Katy Warr; public-ws-addressing@w3.org
>>         *Subject:* Re: LC 76 - What makes a msg WS-A?
>>
>>         Martin Gudgin wrote:
>>
>>>          [snip]
>>>
>>>             [MJG] How about this? Is wsa:Action is missing then you
>>>             MUST proceed as if you DO NOT understand
>>>             WS-Addressing. And if wsa:Action is present and any
>>>             other constraints in the spec are violated, then you
>>>             MUST generate a fault. 
>>>             The upshot of the first 'MUST' is that during the mU
>>>             check, if any wsa: header is found with mU='true' then a
>>>             check to make sure wsa:Action is present has to occur to
>>>             determine whether you 'understand' that wsa: header.
>>>             Essentially, understanding wsa:Action becomes part of
>>>             understanding all the other wsa: headers.
>>>              
>>>             This approach has the advantage of producing consistent
>>>             behaviour between WS-A and non-WS-A nodes for messages
>>>             that DO NOT contain wsa:Action. 
>>>
>>         This helps, I think.  I continue to be uneasy with using the
>>         fact that Action happens to be the one mandatory property
>>         that's also a mandatory header, but at this point, any port
>>         in a storm. 
>>         [MJG] What would make you less uneasy?
>>
>     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.
>
>     The "WSA is engaged if at least one header is present" rule
>     doesn't care about mU except in the usual sense that someone who
>     doesn't understand WSA will fault on seeing a WSA header with
>     mU=true.  The table above then has one less row (the italicized
>     one) and one less thing to look at.  It's also easier to
>     characterize:  Follow the rules in section 3 if any wsa: headers
>     are present (This is in the context of an endpoint supporting both
>     modes.  A strict WSA endpoint just follows the rules in section 3
>     full stop, and faults if no wsa: headers are present).  Here's the
>     matrix under that rule:
>
>     *Action*
>     	*ReplyTo*
>     	*Result*
>     absent
>     	absent
>     	Old-style behavior
>     absent
>     	present
>     	Fault (missing action)
>     present
>     	absent
>     	OK, ReplyTo anonymous
>     present
>     	present
>     	OK, ReplyTo value used
>
>
>     For my money, the "use it as you see it" rules are better yet
>     because they present WSA as what it really is: A collection of
>     useful facilities that can be sensibly used a la carte.  With
>     them, you get flexible behavior without having to make an
>     exception for the no headers case and without having to be careful
>     about defaults in mapping from the infoset to the abstract
>     properties.  For completeness, here's the matrix under those rules:
>
>     *Action*
>     	*ReplyTo*
>     	*Result*
>     absent
>     	absent
>     	Old-style behavior
>     absent
>     	present
>     	Dispatch if possible, fault if dispatching requires [action].
>     present
>     	absent
>     	OK, ReplyTo anonymous
>     present
>     	present
>     	OK, ReplyTo value used
>
>