W3C home > Mailing lists > Public > public-ws-addressing@w3.org > July 2005

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

From: David Hull <dmh@tibco.com>
Date: Thu, 14 Jul 2005 15:28:35 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Message-id: <42D6BCE3.5070000@tibco.com>
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".
>
>
>     (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
>>>
>>
>
Received on Thursday, 14 July 2005 19:28:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:06 GMT