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

Well, we may be going there, but I reject that such a choice is the
proper responsibility of the WS-A spec.  Whether the message goes down a
WS-A fork or not is a property of the service, not the message.  Keying
off wsa:Action seems like one possible approach, but I don't think we
can successfully bake that interpretation into the spec as the only
interpretation.  If I want to have a dual-mode algorithm that treats
messages from the southern hemisphere as WS-A compliant, and from the
northern hemisphere as not, or switch based on the phase of the moon, I
should be able to.  As long as we don't do anything that precludes
developing such an algorithm (which we don't), and we describe what the
WS-A fork entails (which we do) we're done.

 

________________________________

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Rogers, Tony
Sent: Friday, July 15, 2005 12:30 PM
To: Winkler, Steve; Martin Gudgin; David Orchard; David Hull
Cc: Katy Warr; public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?

 

I'm beginning to think that we regard a message as being sent down the
"this is a WS-A message" fork in the trail when it has an Action header,
or another WS-A header with mustUnderstand set to true. Otherwise it
goes down the "this is NOT a WS-A message" fork.

 

Agreed? Violently rejected?

 

Tony

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of Winkler,
Steve 
	Sent: Fri 15-Jul-05 18:59 
	To: Martin Gudgin; David Orchard; David Hull 
	Cc: Katy Warr; public-ws-addressing@w3.org 
	Subject: RE: LC 76 - What makes a msg WS-A?

	 

	Hi Katy, 

	 

	Look what you started... ;-)

	 

	In sifting through the mails, I've gathered that: 

	 

	If the client expects that WS-A machinery is to be engaged on
the endpoint to which they are sending, they need to include at least
one wsa:Header with a mustUnderstand attribute set to true.  The
receiving side needs to check if any of the wsa:Header elements defined
in the specification are present with the mU attribute set to true, if
so they need to process the message in accordance with the WS-A spec
(this includes faulting if wsa:Action is not present, one reason why I
wasn't happy with Gudge's original answer).  

	 

	Now for some questions:

	 

	Does this reflect an accurate understanding of the discussion up
to this point?  

	If so, Katy, does this satisfy your original question?  

	Is the group satisfied with this summary?  

	Should we state something like this explicitly in the spec?

	 

	 

	Cheers,

	Steve

	 

	 

	-------------------------

	Steve Winkler 

	SAP AG

	 

	
	 

		
________________________________


		From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Martin Gudgin
		Sent: Thursday, Jul 14, 2005 3:08 PM
		To: David Orchard; David Hull
		Cc: Katy Warr; public-ws-addressing@w3.org
		Subject: RE: LC 76 - What makes a msg WS-A?

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

		 

		Gudge

			 

			
________________________________


			From: David Orchard [mailto:dorchard@bea.com] 
			Sent: 14 July 2005 22:32
			To: David Hull; Martin Gudgin
			Cc: Katy Warr; public-ws-addressing@w3.org
			Subject: RE: LC 76 - What makes a msg WS-A?

			I thought it was clear.  As soon as a single
ws-a header is marked with mU, then a fault will be thrown if there are
any missing headers like Action.  If there are no headers marked with mU
and there are missing headers, then it's up to the receiver to decide
whether to throw a fault or ignore all the ws-a headers.

			 

			Dave

			 

			 

			
________________________________


			From: David Hull [mailto:dmh@tibco.com] 
			Sent: Thursday, July 14, 2005 2:25 PM
			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: 

			+1

			Am I correct in reading that as "we should throw
a fault if there is a wsa:ReplyTo but no wsa:Action" and we're back on
the same page?  I hope so, but when you say things like "I don't see why
we want to mandate a fault in such a case." it seems like you're saying
that we shouldn't (or at least shouldn't feel obliged to) throw a fault
in such cases.
			
			Perhaps you could enumerate with which
combinations of headers a WSA-compliant endpoint should and should not
produce a fault?  We can then check that against the rules in section 3
and know whether we need to have any further discussion.

			 

			Gudge

				 

				
________________________________


				From: David Orchard
[mailto:dorchard@bea.com] 
				Sent: 14 July 2005 22:03
				To: David Hull; Martin Gudgin
				Cc: Katy Warr;
public-ws-addressing@w3.org
				Subject: RE: LC 76 - What makes a msg
WS-A?

				It seems to me that you can't pick and
choose which headers to support.  If there are any insufficient ws-a
information (like contains a replyTo but no Action) then none of the
ws-a processing can be invoked.  It's not a smorgasborg.

				 

				Dave

				 

				
________________________________


				From:
public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Hull
				Sent: Thursday, July 14, 2005 1:41 PM
				To: Martin Gudgin
				Cc: Katy Warr;
public-ws-addressing@w3.org
				Subject: Re: LC 76 - What makes a msg
WS-A?

				 

				Martin Gudgin wrote: 

				I agree with your analysis of the three
steps. I don't see why we want to mandate a fault in such a case. The
client gets to decide whether he wants a fault or not based on whether
he marks the header mU='true' or not...

				What would happen to the [reply
endpoint] in this case (or rather, these cases, as mU may be true or
not)?  Would it be used as a reply address?  Would it be silently
ignored? Something else?
				
				In the first case, it seems strange to
follow WSA rules but not complain about a missing mandatory header.  In
the second case, it seems less than robust to silently ignore a field
that would otherwise have a significant effect on processing.
				
				Not sure about the third case.
				
				

				 

				Gudge

				 

				
________________________________


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

				Martin Gudgin wrote: 

				Well, one could argue that the endpoint
that accepts WS-A messages and the one that accepts non-WS-A message are
not actually the same endpoint despite the fact that they're listening
on the same URI, I suppose...

				Sure, but the multiplexing still has to
be done one way or another.
				
				

				 

				I'm still not seeing why the endpoint
can't use the following sequence of steps;

				 

				1.    Does the message contain a
wsa:Action header?

				2.    If the answer to question 1. is
'Yes' then look for other wsa: * headers and populate abstract
properties as appropriate.

				3.    If the answer to question 1 is
'No' then process the message using normal SOAP rules (including raising
mU faults if there are any other wsa:* headers marked mU='true' )

				That will not produce a fault if a
message contains an explicit wsa:ReplyTo (with no mU) but no wsa:Action,
right?  The test in step 1 fails and we go straight to step 3.  So it's
OK iff we don't want a fault in such a case.  My understanding is we do
want a fault in such a case.
				
				

				 

				Gudge

				 

				
________________________________


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

				Martin Gudgin wrote: 

				Why is it a problem if a message which
doesn't have wsa:Action in it is NOT subject to 'validation' (what does
that mean, BTW) by the receiver?

				Yeah, I'm not comfortable with the
terminology either.
				
				The question is, should a WSA compliant
endpoint throw a fault if it gets a message with (say) a [reply
endpoint] and no [action]?
				
				If I understand right, you're saying
that (straightforwardly), it should.  That's certainly how I'd interpret
the current core.
				
				Section 3 (specifically section 3.1)
says that [action] is required (i.e., its cardinality is (1..1)), so the
only question (and the one I think Katy was asking) is, when does
section 3 apply?
				
				There appears to be consensus that
endpoints should be able to accept both old-style and new-style requests
without problem.  This means that such an endpoint must be prepared to
accept messages with no wsa: headers at all -- contrary to as strict
reading of section 3.  In particular, such an endpoint should not fault
if wsa:Action is absent unless other wsa: headers are present.  In such
a case, section 3 does not apply universally, and we want to be able to
say when it does and doesn't apply.
				
				So what's the best way to say this?  We
can't use abstract properties, since they may be defined even if there
are no wsa: headers in the incoming message.  So we have to look at the
incoming infoset.  In short, an endpoint capable of handling both styles
should apply the constraints in section 3 if the incoming SOAP message
contains any wsa: headers, and should follow the pre-WSA behavior
otherwise.  This is fine as long as the underlying transport binding
doesn't synthesize wsa: headers that aren't explicitly there.
Otherwise, we'd need some other way of figuring out if the sender meant
to use WSA.
				
				Does that make more sense?  I believe
this is a long-standing and thoroughly discussed issue.  If you were
thinking of something else, let's sort that out first.
				
				

				
				Gudge

				 

				
________________________________


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

				Martin Gudgin wrote: 

				OK, I'm confused.

				 

				Why do you conclude that the answer to
my question "Given that the wsa:Action header is mandatory, isn't it the
presence of that header?" is 'No'. 

				 

				I would have come to the opposite
conclusion;

				 

				I have an endpoint that understands
WS-Addressing. It receives a message that contains wsa:ReplyTo but no
wsa:Action. It generates a fault. Seems pretty straightforward to me.

				Sure.  That is a perfectly
straightforward rule.  In fact, it's implied by what we say in section
3.3.
				
				I thought you were trying to answer the
question "When is an incoming message deemed to be a WS-Addressing
message and therefore subject to the appropriate WS-Addressing
validation?" with (rephrasing the reply as a statement) "It's subject to
WSA validation if the wsa:Action header is present."  And of course,
this clearly won't work, since it specifically doesn't try to validate a
message with wsa:ReplyTo and no wsa:Action.
				
				If you meant something else, then never
mind.  It's probably not worth sorting.
				
				

				 

				I have an endpoint that doesn't
understand WS-Addressing. It receives a message that contains one or
more wsa: headers, it either ignores them or generates a mustUnderstand
fault depending on whether those headers are marked
mustUnderstand='true' or not. Again, seems pretty straightforward to me.

				Sure.  As I said, we're talking about
behavior of endpoints, not properties of messages.
				
				As DaveO says, the interesting case is
that of an endpoint that wants to accept non-WSA messages without
complaint but also handle WSA messages properly.
				
				

				 

				Gudge

				 

				
________________________________


				From: David Hull [mailto:dmh@tibco.com] 
				Sent: 14 July 2005 18:02
				To: Martin Gudgin
				Cc: 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: 14 July 2005 16:32
				To: Martin Gudgin
				Cc: Katy Warr;
public-ws-addressing@w3.org
				Subject: Re: LC 76 - What makes a msg
WS-A?

				Is this really a question of how to
support both WSA and old-style HTTP requests on the same endpoint?  
				[MJG] I don't know, I didn't ask the
original question.

				Hmm ... my message was in-reply-to
yours, but the question was really aimed more at Katy.  Maybe we need
BPEL here :-).
				
				

				
				  I.e., if I don't see any WSA headers
at all, I assume it's an old-style request and act accordingly, but if I
see anything WSA, I follow the rules in section 3? 
				[MJG] I guess one could do that... 

				Well, one should do something to ensure
that old-style requests are accepted as such.
				
				

				
				The tricky bit is that, since MAPs like
[destination] and [reply endpoint] can default, a message with no wsa:
elements on the wire could still be assigned values for some of its
MAPs, since the infoset will still have values for the corresponding
elements. 

				[MJG] Which Infoset are you talking
about? The XML Infoset has no such values.

				Sorry, I didn't get that quite right.  I
was going by section 3.2, particularly the descriptions of wsa:To:

				This OPTIONAL element (whose content is
of type xs:anyURI) provides the value for the [destination] property. If
this element is NOT present then the value of the [destination] property
is "http://www.w3.org/@@@@/@@/addressing/anonymous"
<http://www.w3.org/@@@@/@@/addressing/anonymous> .

				
				(and similarly for wsa:ReplyTo). I
initially misread this as stating that the element defaulted, as opposed
to the MAP.  So s/since the infoset will still have values for the
corresponding elements/since the properties are defaulted in the absence
of the corresponding elements in the infoset/.  This sort of confusion
could be seen as an argument against the two-layered approach (or simply
as an argument that I read too quickly).
				
				In any case, you can't simply look at
the abstract properties and say "some WSA properties are defined, so
it's a WSA message".
				
				

				
				   So either we have to drop down to
look at the infoset level, and in particular at the non-defaulted
elements in the infoset, or we have to find some marker that can't be
defaulted away.  This is why the [action] property looks significant
here.  But on the other hand, what if I include a wsa:ReplyTo element
and no action?  By the "it's WSA iff [action] is present" rule, that's
not a WSA message and therefore not an error.  This seems wrong. 
				[MJG] Why does it seem wrong?

				It seems wrong not to fault for a
message that contains a wsa:ReplyTo on the wire but not a wsa:Action.
				
				

				
				Put another way, when would one get a
fault for omitting [action]? 
				[MJG] Whenever another wsa: header is
present in a message.

				In other words, the answer to your
question ("Given that the wsa:Action is mandatory, isn't it the presence
of that header?") is "No."
				
				This is why at the Berlin meeting we
tried to make sure that all the possibilities were covered for various
combinations of the MAPs.  I believe we've satisfied ourselves that they
are, but perhaps we need to revisit this work?
				
				

				
				
				Martin Gudgin wrote: 

				Given that the wsa:Action is mandatory,
isn't it the presence of that header?

				 

				Gudge

				 

				
________________________________


				From:
public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Katy Warr
				Sent: 14 July 2005 16:07
				To: public-ws-addressing@w3.org
				Subject: LC 76 - What makes a msg WS-A?

				
				Please could we discuss the following in
the context of LC76? 
				
				When is an incoming message deemed to be
a WS-Addressing message and therefore subject to the appropriate
WS-Addressing validation?   Is it based on the presence of any
WS-addressing Message Addressing Property?  For example, does a message
containing a reference parameter (but no other WS-Addressing
information) need to result in a MessageAddressingHeaderRequired?    Or,
for example, does the declaration of the wsa namespace rendor the
message WS-Addressing? 
				
				Thanks 
				Katy