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

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

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Mon, 18 Jul 2005 16:59:18 -0400
To: 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 Orchard <dorchard@bea.com>, David Hull <dmh@tibco.com>, Katy Warr <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Message-id: <E897B478-EF32-4AA1-A957-61A787836D02@Sun.COM>
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 20:59:19 GMT

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