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

 



________________________________

	From: David Hull [mailto:dmh@tibco.com] 
	Sent: 15 July 2005 04:43
	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: 

		I thought it was clear too. And it fits with the SOAP
processing model and so works for endpoints which were deployed long
before WS-A was a twinkle in the eye of it's multiple parents...
		
		

	It's clear that if someone hands me a message with a wsa: header
with mU=true, and I know nothing about WSA, I fault.
	
	I thought it was also clear we're not talking about that case. 
	[MJG] I didn't say we were, I was just making an observation. 
	
	The main question is, what if someone hands me a message with
(say) wsa:ReplyTo, mU set however you like, but no wsa:Action (or a
second wsa:ReplyTo, or whatever other cardinality violation you like),
and I do understand WSA. 
	[MJG] Define 'I'. If you are the endpoint that accepts WS-A
messages, you fault. If you are the endpoint that accepts non-WS-A
messages, you get to choose (modulo mustUnderstand). 
	
	Granted, if mU is true we may be on somewhat firmer ground, as
the receiver is then obligated to process the wsa:ReplyTo, and this
could be taken to bring in the rest of WSA by reference.  I'm not
convinced that the processing model imposes this sort of processing
requirement across header blocks per se (and I rather hope it doesn't),
but I'm 100% convinced that a co-editor of SOAP 1.2 knows more about
SOAP than I do.  In any case, if this is the behavior we want, we might
want to sharpen the language in the SOAP binding to say explicitly that,
for purposes of the SOAP processing model, processing any header also
entails checking the cardinality of the other header blocks. 
	[MJG] The way I see it, if the message doesn't have a mandatory
header, then it violates the spec and the receiver should generate a
fault. I'm not sure which way I'd want to go on the cardinality issue.
	
	If the wsa:ReplyTo doesn't have mU true, then I agree (or at
least I hope I'm agreeing) that the SOAP processing model provides no
guidance here.  My understanding, though, was that we wanted the
faulting behavior in that case too.  If so, it seems to be up to us to
state that explicitly, whether in the core, in the SOAP binding, or in
the context of the WSDL binding.  Wherever we say it, we have to say it
about the SOAP infoset, not the abstract MAPs, since at the MAP level we
can't tell if wsa:ReplyTo (or wsa:To) was present or not. 
	[MJG] Yeah, I seem to remember I was somewhat against
defaults....
	 
	Anyhow, why can't we just say 'If wsa:Action isn't in the
message then you MUST fault' (if you are a WS-A aware endpoint). Surely
the only thing left after that is the cardinality issue.
	
	Right now, the main thing that's clear to me is that the
seemingly simple question of when a WSA compliant processor throws
faults for cardinality violations (a.k.a. "When is WSA engaged?" or
"When is WSA validation required?") does not have an obvious answer.  So
far we've seen:
	

	*	When wsa:Action is present 
	*	When any wsa: header is present 
	*	When any wsa: header is present with mU true, and maybe
other times too. 

	Interestingly, each of these has been put forth as being
perfectly straightforward and obvious. 
	[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. 
	 
	Gudge