W3C home > Mailing lists > Public > public-ws-addressing@w3.org > July 2005

RE: LC 76 - What makes a msg WS-A?

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Mon, 18 Jul 2005 13:37:29 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D6416521492D@uspale20.pal.sap.corp>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:06 GMT