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

+1 to the cases you mentioned, but there's more to it than that
methinks.

 

The boundary case I think is where there's an endpoint that understands
WS-A AND understands non-WS-A messages.  What triggers it to apply WS-A
rules, such as when to generate Faults, when messages aren't marked
mU="true".  Say that there is a wsa:ReplyTo and no wsa:Action, and they
are both marked mU="false".  The node could either ignore the WS-A
header blocks or generate a Fault. 

 

Dave 

 

 

  _____  

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

 

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.

 

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.

 

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