- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Mon, 18 Jul 2005 13:37:29 -0700
- To: "Jonathan Marsh" <jmarsh@microsoft.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>
> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Monday, Jul 18, 2005 1:30 PM
> To: Yalcinalp, Umit; 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?
>
> "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.
It is not specified. Based on what I can follow in this thread, engaging
WS-Addressing appears to be indicated by using mU. Let me make this
clear. I am not saying that this should be the only way, but I am not
aware of an alternate way from the receiver's side to detect
WS-Addressing is engaged or not since we are relying on the SOAP
processing model only.
Putting this aside, assuming that WS-Addressing is engaged, my question
still applies.
--umit
>
> > -----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 21:00:29 UTC