- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Fri, 15 Jul 2005 13:06:06 -0700
- To: "Rogers, Tony" <Tony.Rogers@ca.com>
- CC: "Winkler, Steve" <steve.winkler@sap.com>, Martin Gudgin <mgudgin@microsoft.com>, David Orchard <dorchard@bea.com>, David Hull <dmh@tibco.com>, Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Rogers, Tony wrote:
> I'm beginning to think that we regard a message as being sent down the
> "this is a WS-A message" fork in the trail when it has an Action header,
> or another WS-A header with mustUnderstand set to true. Otherwise it
> goes down the "this is NOT a WS-A message" fork.
>
> Agreed? Violently rejected?
>
I don't quite agree with the above formulation (the 'otherwise' part).
The mU='1' simply states that the message must be processed as a WSA
message. If mU='0', it *may* still be processed as a WSA message, if the
receiver chooses to do so. In which case the receiver has to ensure that
all the WSA rules are adhered to. If not, then throw a fault.
-Anish
--
> Tony
>
> -----Original Message-----
> *From:* public-ws-addressing-request@w3.org on behalf of Winkler, Steve
> *Sent:* Fri 15-Jul-05 18:59
> *To:* Martin Gudgin; David Orchard; David Hull
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> *Subject:* RE: LC 76 - What makes a msg WS-A?
>
>
> Hi Katy,
>
> Look what you started... ;-)
>
> In sifting through the mails, I've gathered that:
>
> If the client expects that WS-A machinery is to be engaged on the
> endpoint to which they are sending, they need to include at least
> one wsa:Header with a mustUnderstand attribute set to true. The
> receiving side needs to check if any of the wsa:Header elements
> defined in the specification are present with the mU attribute set
> to true, if so they need to process the message in accordance with
> the WS-A spec (this includes faulting if wsa:Action is not present,
> one reason why I wasn't happy with Gudge's original answer).
>
> Now for some questions:
>
> Does this reflect an accurate understanding of the discussion up to
> this point?
> If so, Katy, does this satisfy your original question?
> Is the group satisfied with this summary?
> Should we state something like this explicitly in the spec?
>
>
> Cheers,
> Steve
>
>
> -------------------------
> Steve Winkler
> SAP AG
>
>
>
>
> ------------------------------------------------------------------------
> *From:* public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] *On Behalf Of
> *Martin Gudgin
> *Sent:* Thursday, Jul 14, 2005 3:08 PM
> *To:* David Orchard; David Hull
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> *Subject:* RE: LC 76 - What makes a msg WS-A?
>
> I thought it was clear too. And it fits with the SOAP processing
> model and so works for endpoints which were deployed long before
> WS-A was a twinkle in the eye of it's multiple parents...
>
> Gudge
>
> ------------------------------------------------------------------------
> *From:* David Orchard [mailto:dorchard@bea.com]
> *Sent:* 14 July 2005 22:32
> *To:* David Hull; Martin Gudgin
> *Cc:* Katy Warr; public-ws-addressing@w3.org
> *Subject:* RE: LC 76 - What makes a msg WS-A?
>
> I thought it was clear. As soon as a single ws-a header is
> marked with mU, then a fault will be thrown if there are any
> missing headers like Action. If there are no headers marked
> with mU and there are missing headers, then it's up to the
> receiver to decide whether to throw a fault or ignore all
> the ws-a headers.
>
>
>
> Dave
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* David Hull [mailto:dmh@tibco.com]
> *Sent:* Thursday, July 14, 2005 2:25 PM
> *To:* Martin Gudgin
> *Cc:* David Orchard; Katy Warr; public-ws-addressing@w3.org
> *Subject:* Re: LC 76 - What makes a msg WS-A?
>
>
>
> 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
> <mailto: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>
> [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
> <mailto: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 Friday, 15 July 2005 20:22:16 UTC