- 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 UTC