- From: David Hull <dmh@tibco.com>
- Date: Thu, 14 Jul 2005 15:57:59 -0400
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
- Message-id: <42D6C3C7.4050106@tibco.com>
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 19:58:15 UTC