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

I don't understand the italicised line in your table. Surely this line
only makes sense if I'm an endpoint that accepts WS-A and non-WS-A
messages. If I'm an endpoint that only accepts WS-A messages I'll fault
because there is no wsa:Action. Also, the line under the italicized one
should read 'Fault due to missing wsa:Action header', surely?
 
I believe that requiring WS-A endpoints to fault if there is no wsa:
Action is sufficient. I don't really understand why you think this is
arbitrary.
 
Gudge



________________________________

	From: David Hull [mailto:dmh@tibco.com] 
	Sent: 15 July 2005 15:26
	To: Martin Gudgin
	Cc: David Orchard; Katy Warr; public-ws-addressing@w3.org
	Subject: Re: LC 76 - What makes a msg WS-A?
	
	
	Martin Gudgin wrote: 

		 


________________________________

			From: David Hull [mailto:dmh@tibco.com] 
			Sent: 15 July 2005 06:31
			To: Martin Gudgin
			Cc: David Orchard; Katy Warr;
public-ws-addressing@w3.org
			Subject: Re: LC 76 - What makes a msg WS-A?
			
			
			Martin Gudgin wrote: 

				 [snip]

				[MJG] How about this? Is wsa:Action is
missing then you MUST proceed as if you DO NOT understand WS-Addressing.
And if wsa:Action is present and any other constraints in the spec are
violated, then you MUST generate a fault. 
				
				The upshot of the first 'MUST' is that
during the mU check, if any wsa: header is found with mU='true' then a
check to make sure wsa:Action is present has to occur to determine
whether you 'understand' that wsa: header. Essentially, understanding
wsa:Action becomes part of understanding all the other wsa: headers.
				 
				This approach has the advantage of
producing consistent behaviour between WS-A and non-WS-A nodes for
messages that DO NOT contain wsa:Action. 
				
				

			This helps, I think.  I continue to be uneasy
with using the fact that Action happens to be the one mandatory property
that's also a mandatory header, but at this point, any port in a storm. 
			[MJG] What would make you less uneasy?
			

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