- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Mon, 18 Jul 2005 12:54:45 -0700
- To: "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "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>
After reading this thread for a while, I observe there is an
inconsistency that has been nagging me, which is not related to
generating Faults but ensuring the consistency of the consuming the
message that is regarded a WS-Addressing message.
An endpoint may support but not mandate WS-Addressing. Engaging
WS-Addressing is indicated by the mU=1 on any header that is specified
by WS-Addressing. (There seems to me some disagreement about the level
of engagement as well in the wg).
What happens in the following situation:
Action mU=1, ReplyTo mU=1, FaultTo mU=0?
There is clearly no problem here, but based on SOAP processing
semantics, I could conclude that FaultTo can safely be ignored. However,
clearly WS-Addressing is engaged, the headers are valid.
Does the ultimate receiver have the luxury to ignore FaultTo?
May the FaultTo address be utilized by the receiver in the example I
have given? Under which conditions can this happen at the ultimate
receiver? (provided that an intermediatery has not deleted it...)
This is just an example. One can have a similar combination of valid
headers. It seems to me that Message Addressing headers should either
all be designated by mU=1 or mU=0, but not with a combination of mU=1
and mU=0. All Message Addressing Headers must be marked similarly to
designate that the addressing must be engaged, and all relevant ones
must be considered as a "bag". Some of them marked with 0 (vice versa)
does not provide a clean semantics with respect to what the client
intends to happen.
I propose we require uniform treatment of the message addressing headers
with respect to mU, as a bag.
--umit
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> Anish Karmarkar
> Sent: Friday, Jul 15, 2005 1:06 PM
> To: Rogers, Tony
> Cc: Winkler, Steve; Martin Gudgin; David Orchard; David Hull;
> Katy Warr; public-ws-addressing@w3.org
> Subject: Re: LC 76 - What makes a msg WS-A?
>
>
> 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 Monday, 18 July 2005 19:54:41 UTC