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:41:46 -0400
To: tim@mindreef.com
Cc: "'David Orchard'" <dorchard@bea.com>, "'Martin Gudgin'" <mgudgin@microsoft.com>, "'Katy Warr'" <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Message-id: <42D6BFFA.1070602@tibco.com>
I suppose this might be a good time to mention the "use it if you see it
rules" again.

    * If you see a [reply endpoint], send replies there.  Otherwise do
      what you'd ordinarily do (e.g., send your reply as an HTTP response)
    * If you see a [fault endpoint] send faults there.  Otherwise, do
      what you'd ordinarily do.
    * If you see a [message id] and you're sending a response, echo it
      back as per section 3.3.  Otherwise, do what you'd ordinarily do
      (i.e., nothing special).
    * If you see an [action] dispatch off of it.  Otherwise, do what
      you'd ordinarily do.

Just as a cross-check:

    * What if you require [action] for dispatching?  Then you would
      ordinarily throw a fault if you don't see it.  You should
      advertise this in your WSDL.
    * What if your site wants [message id] everywhere for auditing? 
      Then your site should advertise and enforce this using your
      favorite mechanism.  As it stands, you'll have to do something for
      in-only endpoints anyway, since the core actively discourages
      [message id] in such cases.
    * So in what cases are messages WSA messages?  We don't care. 
      That's the beauty of it.

Seems like a straightforward case of "be liberal in what you accept".

Tim Ewald wrote:

> 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
>             <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 19:42:32 GMT

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