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

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.

Marc.

> 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
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.