- From: David Hull <dmh@tibco.com>
- Date: Thu, 14 Jul 2005 16:20:48 -0400
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
- Message-id: <42D6C920.6030606@tibco.com>
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
> *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
>> *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 20:21:08 UTC