- From: David Orchard <dorchard@bea.com>
- Date: Mon, 18 Jul 2005 14:01:29 -0700
- 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 UTC