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

I like Martin's approach wrt wsa:Action, but I think there are a couple more
cases to consider...
 
1) wsa:Action is present and mustUnderstand - my service must process the
message as a WSA message or issue a mU fault
2) wsa:Action is present and not mustUnderstand - my service may process the
message as a WSA message or as a non-WSA message at its discretion depending
on whether it understands
3) wsa:Action is not present, but another WSA header is and it is
mustUnderstand - my service must issue an mU fault because it must
understand the header and to do that it requires the wsa:Action header which
is not present
4) wsa:Action is not present, but another WSA header is and it is not
mustUnderstand - my service may issue an mU fault or treat the message as
not WSA at its discretion
5) No wsa headers - my service may treat the message as non-WSA or it may
fail if WSA was required
 
Thanks,
Tim-


  _____  

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of David Orchard
Sent: Thursday, July 14, 2005 3:02 PM
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