- From: David Hull <dmh@tibco.com>
- Date: Thu, 14 Jul 2005 16:02:31 -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: <42D6C4D7.3020009@tibco.com>
I'm not dead-set against the idea of "WSA messages" and "non-WSA
messages", or however we want to put it. But empirically it does seem
to lead to confusion and extended debate, which leads me to fear that it
might also lead to confusion amongst implementors and thus to a round of
WS-I before things really get sorted. Given this, I want to be very
clear what we're gaining from this kind of formulation and how we're
gaining it.
Tim Ewald wrote:
> So I was responding to the question Katy posed about how you can
> identify a message as being a WSA message. If that's the goal, then I
> like Martin's wsa:Action solution, as long as we recognize all the
> cases. But your last bullet point - "We don't care. That's the beauty
> of it" suggests that in fact it is a goal not to care and that the
> answer to Katy's question is that it doesn't matter. While I like the
> sound of that, because it's so flexible, I wonder if it's really
> viable given the security issues raised against replyTo/faultTo. I
> think I'm going to have to be very careful about the details of this
> processing and I can imagine wanting to branch right up front into one
> of two paths - SOAP over HTTP or SOAP with WSA over whatever, where
> the details and precautions in the second path require a lot more
> attention.
>
> Tim-
>
> ------------------------------------------------------------------------
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* Thursday, July 14, 2005 3:42 PM
> *To:* tim@mindreef.com
> *Cc:* 'David Orchard'; 'Martin Gudgin'; 'Katy Warr';
> public-ws-addressing@w3.org
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
> 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 20:03:24 UTC