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