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

 


________________________________

	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;
"public-ws-addressing@w3.org"
	Subject: Re: LC 76 - What makes a msg WS-A?
	
	
	+1 
	
	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
non-normative. 
	[MJG] In what way is it non-normative? Doesn't SOAP defined
normatively what happens for unrecognised headers?
	
	--
	Matt Long
	MV Squared Technologies
	mlong@mvsquared.net
	901-848-2640
	
	
	

		--------- 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>,
public-ws-addressing@w3.org
		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
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.
		
		
		
		--Apple-Mail-4--747523558
		Content-Transfer-Encoding: base64
		Content-Type: application/pkcs7-signature;
		name=smime.p7s
		Content-Disposition:
>IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGU
gUGVy
	
c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDs1QMAkGBSsOAwIaBQCgggFTMBgGCSqGSIb3
DQEJ
	
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDcxNTE1MjQ0MVowIwYJKoZIhvcN
AQkE
	
MRYEFGEfwNFIRhcDHH6H2/Lv3X+LevO1MHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMC
WkEx
	
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQ
	
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOSK4wegYLKoZIhvcNAQkQAgsxa6BpMGIx
CzAJ
	
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQD
	
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDkiuMA0GCSqGSIb3DQEB
AQUA
	
BIIBAFqMVAiUgEfY4PQgwtlkju+76F00VU/FJlZkNrgxgDCXoaJNj+UmJce0AS4AUyeQ1IBf
jG7e
	
kPI+f93myUvD8w/OgZ+kQKFiy4BmlIjMURg1BRyu4grbz8ZBv9wlKu0x9hzo52NO1j+3a19T
aEDw
	
TpiQfCSmn3sg5Zxf+yokvN0NPl3LtLq0OplYjSPym0odvJFpQ3mHGiWrlFBGsFkOEb0xESRm
jSr5
	
bOdm5eI31JzP3+m014An3eJaI89DXRzxsxDFGShkarCBXWNTCTIlNJLhoN2TClRz3Rmh7XEy
LUIU
		Kqdbsh0g5LTSrHFCA4NSINYDCmJFFx 



	________________________________________________
	Message sent using UebiMiau 2.7.2