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

The dead cat joke, I love it.  

 

You are right, let's have the wsa:ReplyTo marked mU="false".  

 

Fault or no fault my friend?

 

Dave

 

  _____  

From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
Sent: Thursday, July 14, 2005 12:03 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'd be tempted to have my service try to look in the box to see if the
cat was dead or not...

 

How do I have both headers marked mU='false' when one of them doesn't
appear in the message?

 

Gudge

	 

	
  _____  


	From: David Orchard [mailto:dorchard@bea.com] 
	Sent: 14 July 2005 20:02
	To: Martin Gudgin; David Hull
	Cc: Katy Warr; public-ws-addressing@w3.org
	Subject: 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