W3C home > Mailing lists > Public > public-ws-addressing@w3.org > July 2005

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

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Fri, 15 Jul 2005 09:02:57 -0700
Message-ID: <DD35CC66F54D8248B6E04232892B63380657558B@RED-MSG-43.redmond.corp.microsoft.com>
To: "Matt Long" <mlong@mvsquared.net>, "Marc Hadley" <Marc.Hadley@Sun.COM>, "David Hull" <dmh@tibco.com>
Cc: "David Orchard" <dorchard@bea.com>, "Katy Warr" <katy_warr@uk.ibm.com>, <public-ws-addressing@w3.org>


	From: Matt Long [mailto:mlong@mvsquared.net] 
	Sent: 15 July 2005 12:56
	To: Marc Hadley; David Hull
	Cc: Martin Gudgin; David Orchard; Katy Warr;
	Subject: Re: LC 76 - What makes a msg WS-A?
	The only normative issue is what comprises a compliant WS-A
message to a node that expects it (which is well documented). 
	If a node MAY not expect a WS-A message then standard SOAP
processing rules apply for headers (which is non-normative). Those
headers MAY be anything including WS-A headers, but is still
	[MJG] In what way is it non-normative? Doesn't SOAP defined
normatively what happens for unrecognised headers?
	Matt Long
	MV Squared Technologies

		--------- Original Message --------
		From: "Marc Hadley" <Marc.Hadley@Sun.COM>
		To: "David Hull" <dmh@tibco.com>
		Cc: "Martin Gudgin" <mgudgin@microsoft.com>, "David
Orchard" <dorchard@bea.com>, "Katy Warr" <katy_warr@uk.ibm.com>,
		Subject: Re: LC 76 - What makes a msg WS-A?
		Date: 15/07/05 09:21
		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
		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
		convinced we need to say anything else.
		> 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
		> 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
		> present
		> absent
		> OK, ReplyTo anonymous
		> present
		> present
		> OK, ReplyTo value used
		Marc Hadley <marc.hadley at sun.com>
		Business Alliances, CTO Office, Sun Microsystems.
		Content-Transfer-Encoding: base64
		Content-Type: application/pkcs7-signature;

	Message sent using UebiMiau 2.7.2
Received on Friday, 15 July 2005 16:27:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:10 UTC