- From: David Hull <dmh@tibco.com>
- Date: Thu, 14 Jul 2005 16:40:48 -0400
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
- Message-id: <42D6CDD0.6060208@tibco.com>
Martin Gudgin wrote:
> I agree with your analysis of the three steps. I don't see why we want
> to mandate a fault in such a case. The client gets to decide whether
> he wants a fault or not based on whether he marks the header mU='true'
> or not...
What would happen to the [reply endpoint] in this case (or rather, these
cases, as mU may be true or not)? Would it be used as a reply address?
Would it be silently ignored? Something else?
In the first case, it seems strange to follow WSA rules but not complain
about a missing mandatory header. In the second case, it seems less
than robust to silently ignore a field that would otherwise have a
significant effect on processing.
Not sure about the third case.
>
> Gudge
>
> ------------------------------------------------------------------------
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* 14 July 2005 21:21
> *To:* Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
> 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:41:01 UTC