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 16:20:48 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Message-id: <42D6C920.6030606@tibco.com>
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".
>>>
>>>
>>>             (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 20:21:08 GMT

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