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

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

From: David Orchard <dorchard@bea.com>
Date: Mon, 18 Jul 2005 14:01:29 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF1144587B@ussjex01.amer.bea.com>
To: <Marc.Hadley@Sun.COM>, "Jonathan Marsh" <jmarsh@microsoft.com>
Cc: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Rogers, Tony" <Tony.Rogers@ca.com>, "Winkler, Steve" <steve.winkler@sap.com>, "Martin Gudgin" <mgudgin@microsoft.com>, "David Hull" <dmh@tibco.com>, "Katy Warr" <katy_warr@uk.ibm.com>, <public-ws-addressing@w3.org>

+1.  

Dave

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM]
> Sent: Monday, July 18, 2005 1:59 PM
> To: Jonathan Marsh
> Cc: Yalcinalp, Umit; Anish Karmarkar; Rogers, Tony; 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?
> 
> On Jul 18, 2005, at 4:30 PM, Jonathan Marsh wrote:
> 
> >
> > "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.
> >
> Isn't this just standard SOAP section 2 processing ? If you mU=1 any
> WS-Addr header then you engage WS-Addr processing or get an mU fault.
> WS-Addr processing includes checking that the message conforms to the
> spec...
> 
> Marc.
> 
> 
> >
> >> -----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
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> >
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
> 
Received on Monday, 18 July 2005 21:01:56 GMT

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