- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Mon, 18 Jul 2005 13:30:16 -0700
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "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>
"Engaging WS-Addressing is indicated by the mU=1 on any header that is
specified by WS-Addressing."
Where is this specified? I'm not sure I agree this is a constraint
rather than a heuristic.
> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Yalcinalp, Umit
> Sent: Monday, July 18, 2005 12:55 PM
> To: Anish Karmarkar; 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?
>
>
> 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 20:30:34 UTC