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

+1!  In particular, I don't see the value in trying to standardize
dual-mode operation.  It is sufficient for us to describe how a WS-A
conformant endpoint should behave, ensure that nothing we have prevents
such algorithms from being developed and deployed, and leave the
particulars of the algorithm for determining when to switch between WS-A
conformance and not to the service.  Status quo seems to do just that.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Marc Hadley
> Sent: Friday, July 15, 2005 8:25 AM
> To: David Hull
> Cc: Martin Gudgin; David Orchard; Katy Warr;
public-ws-addressing@w3.org
> Subject: 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.
>

Received on Friday, 15 July 2005 19:53:52 UTC