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 17:24:55 -0400
To: Martin Gudgin <mgudgin@microsoft.com>
Cc: David Orchard <dorchard@bea.com>, Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Message-id: <42D6D827.4060105@tibco.com>
Martin Gudgin wrote:

> +1

Am I correct in reading that as "we should throw a fault if there is a
wsa:ReplyTo but no wsa:Action" and we're back on the same page?  I hope
so, but when you say things like "I don't see why we want to mandate a
fault in such a case." it seems like you're saying that we shouldn't (or
at least shouldn't feel obliged to) throw a fault in such cases.

Perhaps you could enumerate with which combinations of headers a
WSA-compliant endpoint should and should not produce a fault?  We can
then check that against the rules in section 3 and know whether we need
to have any further discussion.

>  
> Gudge
>
>     ------------------------------------------------------------------------
>     *From:* David Orchard [mailto:dorchard@bea.com]
>     *Sent:* 14 July 2005 22:03
>     *To:* David Hull; Martin Gudgin
>     *Cc:* Katy Warr; public-ws-addressing@w3.org
>     *Subject:* RE: LC 76 - What makes a msg WS-A?
>
>     It seems to me that you can't pick and choose which headers to
>     support.  If there are any insufficient ws-a information (like
>     contains a replyTo but no Action) then none of the ws-a processing
>     can be invoked.  It's not a smorgasborg.
>
>      
>
>     Dave
>
>      
>
>     ------------------------------------------------------------------------
>
>     *From:* public-ws-addressing-request@w3.org
>     [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *David Hull
>     *Sent:* Thursday, July 14, 2005 1:41 PM
>     *To:* Martin Gudgin
>     *Cc:* Katy Warr; public-ws-addressing@w3.org
>     *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>      
>
>     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
>         <mailto: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
>             <mailto: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
>                 <mailto: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
>                     <mailto: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
>                         <mailto: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>
>>                             [mailto:public-ws-addressing-request@w3.org]
>>                             *On Behalf Of *Katy Warr
>>                             *Sent:* 14 July 2005 16:07
>>                             *To:* public-ws-addressing@w3.org
>>                             <mailto: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 21:25:11 GMT

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