- From: David Hull <dmh@tibco.com>
- Date: Thu, 14 Jul 2005 17:24:55 -0400
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: David Orchard <dorchard@bea.com>, Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
- Message-id: <42D6D827.4060105@tibco.com>
Martin Gudgin wrote:
> +1
Am I correct in reading that as "we should throw a fault if there is a
wsa:ReplyTo but no wsa:Action" and we're back on the same page? I hope
so, but when you say things like "I don't see why we want to mandate a
fault in such a case." it seems like you're saying that we shouldn't (or
at least shouldn't feel obliged to) throw a fault in such cases.
Perhaps you could enumerate with which combinations of headers a
WSA-compliant endpoint should and should not produce a fault? We can
then check that against the rules in section 3 and know whether we need
to have any further discussion.
>
> Gudge
>
> ------------------------------------------------------------------------
> *From:* David Orchard [mailto:dorchard@bea.com]
> *Sent:* 14 July 2005 22:03
> *To:* David Hull; Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> *Subject:* RE: LC 76 - What makes a msg WS-A?
>
> It seems to me that you can't pick and choose which headers to
> support. If there are any insufficient ws-a information (like
> contains a replyTo but no Action) then none of the ws-a processing
> can be invoked. It's not a smorgasborg.
>
>
>
> Dave
>
>
>
> ------------------------------------------------------------------------
>
> *From:* public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *David Hull
> *Sent:* Thursday, July 14, 2005 1:41 PM
> *To:* Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>
>
> 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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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 21:25:11 UTC