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

Matt,
 
Thanks for clarifying. I now understand your statement.
 
Cheers
 
Gudge


________________________________

	From: Matt Long [mailto:mlong@mvsquared.net] 
	Sent: 15 July 2005 13:22
	To: Martin Gudgin; Matt Long; Marc Hadley; David Hull
	Cc: David Orchard; Katy Warr; "public-ws-addressing@w3.org"
	Subject: RE: LC 76 - What makes a msg WS-A?
	
	
	Gudge,
	
	Yes, SOAP does define normatively the processing for unknown
headers.  Since SOAP processing rules are normative to WS-A, why restate
normative SOAP processing rules in WS-A.  This is why I say
non-normative to WS-A since it is normative to SOAP.
	
	--
	Matt Long
	MV Squared Technologies
	mlong@mvsquared.net
	901-848-2640
	
	
	

		--------- Original Message --------
		From: "Martin Gudgin" <mgudgin@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
		Subject: RE: LC 76 - What makes a msg WS-A?
		Date: 15/07/05 10:01
		
		
		 


________________________________

			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
			



	________________________________________________
	Message sent using UebiMiau 2.7.2