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:40:48 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Message-id: <42D6CDD0.6060208@tibco.com>
Martin Gudgin wrote:

> I agree with your analysis of the three steps. I don't see why we want
> to mandate a fault in such a case. The client gets to decide whether
> he wants a fault or not based on whether he marks the header mU='true'
> or not...

What would happen to the [reply endpoint] in this case (or rather, these
cases, as mU may be true or not)?  Would it be used as a reply address? 
Would it be silently ignored? Something else?

In the first case, it seems strange to follow WSA rules but not complain
about a missing mandatory header.  In the second case, it seems less
than robust to silently ignore a field that would otherwise have a
significant effect on processing.

Not sure about the third case.

>  
> Gudge
>
>     ------------------------------------------------------------------------
>     *From:* David Hull [mailto:dmh@tibco.com]
>     *Sent:* 14 July 2005 21:21
>     *To:* Martin Gudgin
>     *Cc:* Katy Warr; public-ws-addressing@w3.org
>     *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>     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:41:01 GMT

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