- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Tue, 19 Jul 2005 07:43:44 -0700
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Matt Long" <mlong@mvsquared.net>
- Cc: <public-ws-addressing@w3.org>
- Message-ID: <DD35CC66F54D8248B6E04232892B63380660DC83@RED-MSG-43.redmond.corp.microsoft.com>
There are a few (somewhat orthogonal) things going on here;
1. The message sender specifies, using mU='true' and mU='false',
which headers it requires the receiver to process and which headers it
is happy for the receiver to ignore.
2. The message receiver has a set of headers it supports.
3. The message receiver has to follow the SOAP processing rules.
Let's assume for a moment that the message receiver supports all the
headers that the message sender puts in the message. In such a case, one
could argue that the values the message sender specifies for mU are
irrelevant, that is the receiver will just process all the headers it
supports. Conversely, one could argue that a receiver, despite
understanding all the headers, is still at liberty to ignore headers
marked mU='false'.
I sense in this thread a desire to *force* the first case, that is a
message receiver MUST process all the headers it supports, even if they
are marked mU='false'. I don't know why we would want to mandate that
behaviour.
Let's now look at a message that violates one of our spec contraints,
one that has multiple wsa:ReplyTo headers perhaps, or a wsa:FaultTo with
a missing wsa:Address element. I can see an argument that says a message
receiver that supports those headers should generate a fault because the
message is malformed. I can also see an argument that says if those
headers are marked mU='false' then the message receiver can ignore them
even though they are malformed.
Again, I sense a desire to force the first case (I'm slightly more
sympathetic toward this one...)
Gudge
________________________________
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Yalcinalp,
Umit
Sent: 19 July 2005 14:01
To: Matt Long
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?
This is exactly why I brought up this example. You can look at
this two different ways:
-- We follow SOAP processing rules. Hence, the headers that are
marked mU=0 may be ignored.
-- WS-Addressing is engaged, therefore all the headers,
including those that are marked mU=0, are processed.
I am asking that we clarify our position.
If we would like to follow both the SOAP processing semantics,
and achieve processing of all the headers, a combination approach,
namely marking all the WS-Addressing headers consistently (i.e.
treating them as a 'virtual' bag) will make sense.
Noone so far has come forward and explained why one would prefer
a combination of mU values, or the use cases that would support.
--umit
________________________________
From: Matt Long [mailto:mlong@mvsquared.net]
Sent: Monday, Jul 18, 2005 10:20 AM
To: Yalcinalp, Umit
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?
If you have a WS-A endpoint then by definition all WS-A
headers will be processed independent of mU semantics. I cannot see how
a WS-A header could be 'ignored' when performing WS-A processing on a
WS-A endpoint. Notice, I didn't address the dual-use scenario since I
don't believe this belongs in the spec.
Correct me if necessary, but isn't it just that simple!
-Matt Long
--------- Original Message --------
From: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
To: "Jonathan Marsh" <jmarsh@microsoft.com>,
"Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Rogers, Tony"
<Tony.Rogers@ca.com>
Cc: "Winkler, Steve" <steve.winkler@sap.com>,
"Martin Gudgin" <mgudgin@microsoft.com>, "David Orchard"
<dorchard@bea.com>, "David Hull" <dmh@tibco.com>, "Katy Warr"
<katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?
Date: 18/07/05 14:56
> -----Original Message-----
> From: Jonathan Marsh
[mailto:jmarsh@microsoft.com]
> Sent: Monday, Jul 18, 2005 1:30 PM
> To: Yalcinalp, Umit; Anish Karmarkar; Rogers,
Tony
> Cc: Winkler, Steve; Martin Gudgin; David
Orchard; David Hull;
> Katy Warr; public-ws-addressing@w3.org
> Subject: RE: LC 76 - What makes a msg WS-A?
>
> "Engaging WS-Addressing is indicated by the
mU=1 on any header that is
> specified by WS-Addressing."
>
> Where is this specified? I'm not sure I agree
this is a constraint
> rather than a heuristic.
It is not specified. Based on what I can follow
in this thread, engaging
WS-Addressing appears to be indicated by using
mU. Let me make this
clear. I am not saying that this should be the
only way, but I am not
aware of an alternate way from the receiver's
side to detect
WS-Addressing is engaged or not since we are
relying on the SOAP
processing model only.
Putting this aside, assuming that WS-Addressing
is engaged, my question
still applies.
--umit
>
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
[mailto:public-ws-
> > addressing-request@w3.org] On Behalf Of
Yalcinalp, Umit
> > Sent: Monday, July 18, 2005 12:55 PM
> > To: Anish Karmarkar; Rogers, Tony
> > Cc: Winkler, Steve; Martin Gudgin; David
Orchard; David Hull; Katy
> > Warr; public-ws-addressing@w3.org
> > Subject: RE: LC 76 - What makes a msg WS-A?
> >
> >
> > After reading this thread for a while, I
observe there is an
> > inconsistency that has been nagging me,
which is not related to
> > generating Faults but ensuring the
consistency of the consuming the
> > message that is regarded a WS-Addressing
message.
> >
> > An endpoint may support but not mandate
WS-Addressing. Engaging
> > WS-Addressing is indicated by the mU=1 on
any header that
> is specified
> > by WS-Addressing. (There seems to me some
disagreement
> about the level
> > of engagement as well in the wg).
> >
> > What happens in the following situation:
> >
> > Action mU=1, ReplyTo mU=1, FaultTo mU=0?
> >
> > There is clearly no problem here, but based
on SOAP processing
> > semantics, I could conclude that FaultTo can
safely be ignored.
> > However,
> > clearly WS-Addressing is engaged, the
headers are valid.
> >
> > Does the ultimate receiver have the luxury
to ignore FaultTo?
> >
> > May the FaultTo address be utilized by the
receiver in the example I
> > have given? Under which conditions can this
happen at the ultimate
> > receiver? (provided that an intermediatery
has not deleted it...)
> >
> > This is just an example. One can have a
similar combination of valid
> > headers. It seems to me that Message
Addressing headers
> should either
> > all be designated by mU=1 or mU=0, but not
with a
> combination of mU=1
> > and mU=0. All Message Addressing Headers
must be marked similarly to
> > designate that the addressing must be
engaged, and all relevant ones
> > must be considered as a "bag". Some of them
marked with 0
> (vice versa)
> > does not provide a clean semantics with
respect to what the client
> > intends to happen.
> >
> > I propose we require uniform treatment of
the message addressing
> > headers
> > with respect to mU, as a bag.
> >
> >
> > --umit
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: public-ws-addressing-request@w3.org
> > >
[mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > > Anish Karmarkar
> > > Sent: Friday, Jul 15, 2005 1:06 PM
> > > To: Rogers, Tony
> > > Cc: Winkler, Steve; Martin Gudgin; David
Orchard; David Hull;
> > > Katy Warr; public-ws-addressing@w3.org
> > > Subject: Re: LC 76 - What makes a msg
WS-A?
> > >
> > >
> > > Rogers, Tony wrote:
> > > > I'm beginning to think that we regard a
message as being
> > > sent down the
> > > > "this is a WS-A message" fork in the
trail when it has an
> > > Action header,
> > > > or another WS-A header with
mustUnderstand set to true.
> > > Otherwise it
> > > > goes down the "this is NOT a WS-A
message" fork.
> > > >
> > > > Agreed? Violently rejected?
> > > >
> > >
> > > I don't quite agree with the above
formulation (the 'otherwise'
> > part).
> > > The mU='1' simply states that the message
must be
> processed as a WSA
> > > message. If mU='0', it *may* still be
processed as a WSA
> > > message, if the
> > > receiver chooses to do so. In which case
the receiver has to
> > > ensure that
> > > all the WSA rules are adhered to. If not,
then throw a fault.
> > >
> > > -Anish
> > > --
> > >
> > > > Tony
> > > >
> > > > -----Original Message-----
> > > > *From:*
public-ws-addressing-request@w3.org on behalf
> > > of Winkler, Steve
> > > > *Sent:* Fri 15-Jul-05 18:59
> > > > *To:* Martin Gudgin; David Orchard;
David Hull
> > > > *Cc:* Katy Warr;
public-ws-addressing@w3.org
> > > > *Subject:* RE: LC 76 - What makes a msg
WS-A?
> > > >
> > > >
> > > > Hi Katy,
> > > >
> > > > Look what you started... ;-)
> > > >
> > > > In sifting through the mails, I've
gathered that:
> > > >
> > > > If the client expects that WS-A
machinery is to be
> > > engaged on the
> > > > endpoint to which they are sending, they
need to
> > > include at least
> > > > one wsa:Header with a mustUnderstand
attribute set to true.
> > The
> > > > receiving side needs to check if any of
the wsa:Header
> > elements
> > > > defined in the specification are present
with the mU
> > > attribute set
> > > > to true, if so they need to process the
message in
> > > accordance with
> > > > the WS-A spec (this includes faulting if
wsa:Action is
> > > not present,
> > > > one reason why I wasn't happy with
Gudge's original answer).
> > > >
> > > > Now for some questions:
> > > >
> > > > Does this reflect an accurate
understanding of the
> > > discussion up to
> > > > this point?
> > > > If so, Katy, does this satisfy your
original question?
> > > > Is the group satisfied with this
summary?
> > > > Should we state something like this
explicitly in the spec?
> > > >
> > > >
> > > > Cheers,
> > > > Steve
> > > >
> > > >
> > > > -------------------------
> > > > Steve Winkler
> > > > SAP AG
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > > *From:*
public-ws-addressing-request@w3.org
> > > >
[mailto:public-ws-addressing-request@w3.org]
> *On Behalf Of
> > > > *Martin Gudgin
> > > > *Sent:* Thursday, Jul 14, 2005 3:08 PM
> > > > *To:* David Orchard; David Hull
> > > > *Cc:* Katy Warr;
public-ws-addressing@w3.org
> > > > *Subject:* RE: LC 76 - What makes a msg
WS-A?
> > > >
> > > > I thought it was clear too. And it fits
with the
> > > SOAP processing
> > > > model and so works for endpoints which
were
> > > deployed long before
> > > > WS-A was a twinkle in the eye of it's
multiple
> parents...
> > > >
> > > > Gudge
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > > *From:* David Orchard
[mailto:dorchard@bea.com]
> > > > *Sent:* 14 July 2005 22:32
> > > > *To:* David Hull; Martin Gudgin
> > > > *Cc:* Katy Warr;
public-ws-addressing@w3.org
> > > > *Subject:* RE: LC 76 - What makes a msg
WS-A?
> > > >
> > > > I thought it was clear. As soon as a
single
> > > ws-a header is
> > > > marked with mU, then a fault will be
thrown if
> > > there are any
> > > > missing headers like Action. If there
are no
> > > headers marked
> > > > with mU and there are missing headers,
then
> > > it's up to the
> > > > receiver to decide whether to throw a
fault or
> > > ignore all
> > > > the ws-a headers.
> > > >
> > > >
> > > >
> > > > Dave
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:* David Hull
[mailto:dmh@tibco.com]
> > > > *Sent:* Thursday, July 14, 2005 2:25 PM
> > > > *To:* Martin Gudgin
> > > > *Cc:* David Orchard; Katy Warr;
> > > public-ws-addressing@w3.org
> > > > *Subject:* Re: LC 76 - What makes a msg
WS-A?
> > > >
> > > >
> > > >
> > > > Martin Gudgin wrote:
> > > >
> > > > +1
> > > >
> > > > Am I correct in reading that as "we
should
> > > throw a fault if
> > > > there is a wsa:ReplyTo but no
wsa:Action" and
> > > we're back on
> > > > the same page? I hope so, but when you
say
> > > things like "I
> > > > don't see why we want to mandate a fault
in
> > > such a case." it
> > > > seems like you're saying that we
shouldn't (or at
> > least
> > > > shouldn't feel obliged to) throw a fault
in such
> > cases.
> > > >
> > > > Perhaps you could enumerate with which
> combinations of
> > > > headers a WSA-compliant endpoint should
and
> should not
> > > > produce a fault? We can then check that
> > > against the rules
> > > > in section 3 and know whether we need to
have
> > > any further
> > > > discussion.
> > > >
> > > >
> > > >
> > > > Gudge
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:* David Orchard
[mailto:dorchard@bea.com]
> > > > *Sent:* 14 July 2005 22:03
> > > > *To:* David Hull; Martin Gudgin
> > > > *Cc:* Katy Warr;
public-ws-addressing@w3.org
> > > > <mailto:public-ws-addressing@w3.org>
> > > > *Subject:* RE: LC 76 - What makes a msg
WS-A?
> > > >
> > > > It seems to me that you can't pick and
choose
> > which
> > > > headers to support. If there are any
> > > insufficient ws-a
> > > > information (like contains a replyTo but
no
> > > Action) then
> > > > none of the ws-a processing can be
invoked.
> > > It's not a
> > > > smorgasborg.
> > > >
> > > >
> > > >
> > > > Dave
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:*
public-ws-addressing-request@w3.org
> > > >
<mailto:public-ws-addressing-request@w3.org>
> > > >
> > >
[mailto:public-ws-addressing-request@w3.org] *On Behalf
> > > > Of *David Hull
> > > > *Sent:* Thursday, July 14, 2005 1:41 PM
> > > > *To:* Martin Gudgin
> > > > *Cc:* Katy Warr;
public-ws-addressing@w3.org
> > > > <mailto:public-ws-addressing@w3.org>
> > > > *Subject:* Re: LC 76 - What makes a msg
WS-A?
> > > >
> > > >
> > > >
> > > > Martin Gudgin wrote:
> > > >
> > > > I agree with your analysis of the three
> > > steps. I don't
> > > > see why we want to mandate a fault in
such
> > > a case. The
> > > > client gets to decide whether he wants a
> > > fault or not
> > > > based on whether he marks the header
> > > mU='true' or not...
> > > >
> > > > What would happen to the [reply
endpoint]
> > > in this case
> > > > (or rather, these cases, as mU may be
true or
> > not)?
> > > > Would it be used as a reply address?
> Would it be
> > > > silently ignored? Something else?
> > > >
> > > > In the first case, it seems strange to
> > > follow WSA rules
> > > > but not complain about a missing
mandatory
> > > header. In
> > > > the second case, it seems less than
robust
> > > to silently
> > > > ignore a field that would otherwise have
a
> > > significant
> > > > effect on processing.
> > > >
> > > > Not sure about the third case.
> > > >
> > > >
> > > >
> > > >
> > > > Gudge
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:* David Hull
[mailto:dmh@tibco.com]
> > > > *Sent:* 14 July 2005 21:21
> > > > *To:* Martin Gudgin
> > > > *Cc:* Katy Warr;
public-ws-addressing@w3.org
> > > > <mailto:public-ws-addressing@w3.org>
> > > > *Subject:* Re: LC 76 - What makes a
> msg WS-A?
> > > >
> > > > Martin Gudgin wrote:
> > > >
> > > > Well, one could argue that the endpoint
> > > that accepts
> > > > WS-A messages and the one that
> accepts non-WS-
> > A
> > > > message are not actually the same
> > > endpoint despite
> > > > the fact that they're listening on the
> > > same URI, I
> > > > suppose...
> > > >
> > > > Sure, but the multiplexing still has to
> > > be done one
> > > > way or another.
> > > >
> > > >
> > > >
> > > >
> > > > I'm still not seeing why the endpoint
> > > can't use the
> > > > following sequence of steps;
> > > >
> > > >
> > > >
> > > > 1. Does the message contain a
> > > wsa:Action header?
> > > >
> > > > 2. If the answer to question 1. is 'Yes'
> > then
> > > > look for other wsa: * headers and
> > > populate abstract
> > > > properties as appropriate.
> > > >
> > > > 3. If the answer to question 1
> is 'No' then
> > > > process the message using normal SOAP
rules
> > > > (including raising mU faults if there
> > > are any other
> > > > wsa:* headers marked mU='true' )
> > > >
> > > > That will not produce a fault if a
> > > message contains
> > > > an explicit wsa:ReplyTo (with no mU) but
no
> > > > wsa:Action, right? The test in step 1
> > > fails and we
> > > > go straight to step 3. So it's OK iff
> > > we don't want
> > > > a fault in such a case. My
> > > understanding is we /do/
> > > > want a fault in such a case.
> > > >
> > > >
> > > >
> > > >
> > > > Gudge
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:* David Hull
> [mailto:dmh@tibco.com]
> > > > *Sent:* 14 July 2005 20:58
> > > > *To:* Martin Gudgin
> > > > *Cc:* Katy Warr; public-ws-
> > addressing@w3.org
> > > > <mailto:public-ws-addressing@w3.org>
> > > > *Subject:* Re: LC 76 - What makes a
> > > msg WS-A?
> > > >
> > > > Martin Gudgin wrote:
> > > >
> > > > Why is it a problem if a message
> > > which doesn't
> > > > have wsa:Action in it is NOT subject to
> > > > 'validation' (what does that mean,
> > > BTW) by the
> > > > receiver?
> > > >
> > > > Yeah, I'm not comfortable with the
> > > terminology
> > > > either.
> > > >
> > > > The question is, should a WSA compliant
> > > > /endpoint/ throw a fault if it gets
> > > a message
> > > > with (say) a [reply endpoint] and
> > > no [action]?
> > > >
> > > > If I understand right, you're
> saying that
> > > > (straightforwardly), it should. That's
> > > > certainly how I'd interpret the
> > > current core.
> > > >
> > > > Section 3 (specifically section
> > > 3.1) says that
> > > > [action] is required (i.e., its
> > > cardinality is
> > > > (1..1)), so the only question
> (and the one
> > I
> > > > think Katy was asking) is, when
> > > does section 3
> > > > apply?
> > > >
> > > > There appears to be consensus that
> > endpoints
> > > > should be able to accept both old-style
> > and
> > > > new-style requests without problem.
> > > This means
> > > > that such an endpoint must be
> > > prepared to accept
> > > > messages with no wsa: headers at
> > > all -- contrary
> > > > to as strict reading of section 3. In
> > > > particular, such an endpoint should
> > > /not/ fault
> > > > if wsa:Action is absent unless
> other wsa:
> > > > headers are present. In such a
> > > case, section 3
> > > > does not apply universally, and we
> > > want to be
> > > > able to say when it does and doesn't
> > apply.
> > > >
> > > > So what's the best way to say this?
> > > We can't
> > > > use abstract properties, since
> they may be
> > > > defined even if there are no wsa:
> > > headers in the
> > > > incoming message. So we have to look at
> > the
> > > > incoming infoset. In short, an
> > > endpoint capable
> > > > of handling both styles should apply the
> > > > constraints in section 3 if the
> > > incoming SOAP
> > > > message contains any wsa: headers,
> > > and should
> > > > follow the pre-WSA behavior
> > > otherwise. This is
> > > > fine as long as the underlying
> > > transport binding
> > > > doesn't synthesize wsa: headers that
> > aren't
> > > > explicitly there. Otherwise, we'd need
> > some
> > > > other way of figuring out if the
> > > sender meant to
> > > > use WSA.
> > > >
> > > > Does that make more sense? I
> > > believe this is a
> > > > long-standing and thoroughly
> > > discussed issue.
> > > > If you were thinking of something
> > > else, let's
> > > > sort that out first.
> > > >
> > > >
> > > >
> > > > Gudge
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:* David Hull
> > > [mailto:dmh@tibco.com]
> > > > *Sent:* 14 July 2005 20:29
> > > > *To:* Martin Gudgin
> > > > *Cc:* Katy Warr;
> > > public-ws-addressing@w3.org
> > > > <mailto:public-ws-addressing@w3.org>
> > > > *Subject:* Re: LC 76 - What
> > > makes a msg WS-A?
> > > >
> > > > Martin Gudgin wrote:
> > > >
> > > > OK, I'm confused.
> > > >
> > > >
> > > >
> > > > Why do you conclude that the
> > > answer to my
> > > > question "Given that the
> > > wsa:Action header
> > > > is mandatory, isn't it the
> > > presence of that
> > > > header?" is 'No'.
> > > >
> > > >
> > > >
> > > > I would have come to the
> > > opposite conclusion;
> > > >
> > > >
> > > >
> > > > I have an endpoint that understands
> > > > WS-Addressing. It receives a
> > > message that
> > > > contains wsa:ReplyTo but no
> > > wsa:Action. It
> > > > generates a fault. Seems pretty
> > > > straightforward to me.
> > > >
> > > > Sure. That is a perfectly
> > > straightforward
> > > > rule. In fact, it's implied by
> > > what we say
> > > > in section 3.3.
> > > >
> > > > I thought you were trying to answer
> > the
> > > > question "When is an incoming
> > > message deemed
> > > > to be a WS-Addressing message
> > > and therefore
> > > > subject to the appropriate WS-
> > Addressing
> > > > validation?" with (rephrasing
> > > the reply as a
> > > > statement) "It's subject to WSA
> > > validation
> > > > if the wsa:Action header is
> > > present." And
> > > > of course, this clearly won't
> > > work, since it
> > > > specifically doesn't try to
> validate a
> > > > message with wsa:ReplyTo and no
> > > wsa:Action.
> > > >
> > > > If you meant something else, then
> > never
> > > > mind. It's probably not worth
> > sorting.
> > > >
> > > >
> > > >
> > > >
> > > > I have an endpoint that doesn't
> > > understand
> > > > WS-Addressing. It receives a
> > > message that
> > > > contains one or more wsa:
> > > headers, it either
> > > > ignores them or generates a
> > > mustUnderstand
> > > > fault depending on whether
> > > those headers are
> > > > marked mustUnderstand='true' or
> > > not. Again,
> > > > seems pretty straightforward to me.
> > > >
> > > > Sure. As I said, we're
> talking about
> > > > behavior of endpoints, not
> properties
> > of
> > > > messages.
> > > >
> > > > As DaveO says, the interesting
> > > case is that
> > > > of an endpoint that wants to
> > > accept non-WSA
> > > > messages without complaint but
> > > also handle
> > > > WSA messages properly.
> > > >
> > > >
> > > >
> > > >
> > > > Gudge
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:* David Hull
> > > [mailto:dmh@tibco.com]
> > > > *Sent:* 14 July 2005 18:02
> > > > *To:* Martin Gudgin
> > > > *Cc:* Katy Warr;
> > > > public-ws-addressing@w3.org
> > > > <mailto:public-ws-
> > addressing@w3.org>
> > > > *Subject:* Re: LC 76 - What
> > > makes a msg
> > > > WS-A?
> > > >
> > > > Martin Gudgin wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
--------------------------------------------------------------
> > > ----------
> > > >
> > > > *From:* David Hull
> > > > [mailto:dmh@tibco.com]
> > > > *Sent:* 14 July 2005 16:32
> > > > *To:* Martin Gudgin
> > > > *Cc:* Katy Warr;
> > > > public-ws-addressing@w3.org
> > > >
> > > <mailto:public-ws-addressing@w3.org>
> > > > *Subject:* Re: LC 76 -
> > > What makes a
> > > > msg WS-A?
> > > >
> > > > Is this really a
> > > question of how to
> > > > support both WSA and
> > > old-style HTTP
> > > > requests on the
> same endpoint?
> > > > [MJG] I don't know, I
> > > didn't ask the
> > > > original question.
> > > >
> > > > Hmm ... my message was
> in-reply-to
> > > > yours, but the question was
> > > really aimed
> > > > more at Katy. Maybe we
> > > need BPEL here :-).
> > > >
> > > >
> > > >
> > > > I.e., if I don't
> see any WSA
> > > > headers at all, I
> assume it's
> > an
> > > > old-style request and act
> > > > accordingly, but if I
> > > see anything
> > > > WSA, I follow the rules
> > > in section 3?
> > > > [MJG] I guess one could
> > > do that...
> > > >
> > > > Well, one should do
> /something/ to
> > > > ensure that old-style
> requests are
> > > > accepted as such.
> > > >
> > > >
> > > >
> > > > The tricky bit is that,
> > > since MAPs
> > > > like [destination]
> and [reply
> > > > endpoint] can default, a
> > message
> > > > with no wsa: elements
> > > on the wire
> > > > could still be assigned
> > > values for
> > > > some of its MAPs, since the
> > > > /infoset/ will still
> > > have values for
> > > > the corresponding elements.
> > > >
> > > > [MJG] Which Infoset are
> > > you talking
> > > > about? The XML Infoset
> > > has no such
> > > > values.
> > > >
> > > > Sorry, I didn't get that
> > > quite right. I
> > > > was going by section 3.2,
> > > particularly
> > > > the descriptions of wsa:To:
> > > >
> > > > This OPTIONAL element
> > > (whose content is
> > > > of type xs:anyURI) provides
> > > the value
> > > > for the [destination]
> > > property. If this
> > > > element is NOT present then
> > > the value of
> > > > the [destination] property is
> > > >
> > >
"http://www.w3.org/@@@@/@@/addressing/anonymous"
> > > >
> > >
<http://www.w3.org/@@@@/@@/addressing/anonymous>.
> > > >
> > > >
> > > > (and similarly for
> wsa:ReplyTo). I
> > > > initially misread this as
> > > stating that
> > > > the element defaulted, as
> > > opposed to the
> > > > MAP. So s/since the /infoset/
> > will
> > > > still have values for the
> > > corresponding
> > > > elements/since the
> properties are
> > > > defaulted in the absence of the
> > > > corresponding elements in
> > > the infoset/.
> > > > This sort of confusion
> > > could be seen as
> > > > an argument against the two-
> > layered
> > > > approach (or simply as an
> > > argument that
> > > > I read too quickly).
> > > >
> > > > In any case, you can't
> > > simply look at
> > > > the abstract properties and
> > > say "some
> > > > WSA properties are defined,
> > > so it's a
> > > > WSA message".
> > > >
> > > >
> > > >
> > > > So either we have to
> > > drop down to
> > > > look at the infoset
> > > level, and in
> > > > particular at the non-
> > defaulted
> > > > elements in the
> > > infoset, or we have
> > > > to find some marker
> > > that can't be
> > > > defaulted away. This is why
> > the
> > > > [action] property looks
> > > significant
> > > > here. But on the other
> > > hand, what
> > > > if I include a
> > > wsa:ReplyTo element
> > > > and no action? By the
> > > "it's WSA iff
> > > > [action] is present"
> > > rule, that's
> > > > not a WSA message and
> > > therefore not
> > > > an error. This seems wrong.
> > > > [MJG] Why does it
> seem wrong?
> > > >
> > > > It seems wrong not to
> fault for a
> > > > message that contains a
> > > wsa:ReplyTo on
> > > > the wire but not a wsa:Action.
> > > >
> > > >
> > > >
> > > > Put another way, when
> > > would one get
> > > > a fault for
> omitting [action]?
> > > > [MJG] Whenever another wsa:
> > > > header is present in a
> > message.
> > > >
> > > > In other words, the
> answer to your
> > > > question ("Given that the
> > > wsa:Action is
> > > > mandatory, isn't it the
> > > presence of that
> > > > header?") is "No."
> > > >
> > > > This is why at the
> Berlin meeting
> > we
> > > > tried to make sure that all the
> > > > possibilities were covered
> > > for various
> > > > combinations of the MAPs. I
> > believe
> > > > we've satisfied ourselves
> > > that they are,
> > > > but perhaps we need to
> > > revisit this work?
> > > >
> > > >
> > > >
> > > >
> > > > Martin Gudgin wrote:
> > > >
> > > >> Given that the
> wsa:Action is
> > > >> mandatory, isn't it
> > > the presence
> > > >> of that header?
> > > >>
> > > >>
> > > >>
> > > >> Gudge
> > > >>
> > > >>
> > > >>
> > > >>
> > >
--------------------------------------------------------------
> > > ----------
> > > >>
> > > >> *From:*
> > > >>
> > > public-ws-addressing-request@w3.org
> > > >>
> > >
<mailto:public-ws-addressing-request@w3.org>
> > > >>
> > >
[mailto:public-ws-addressing-request@w3.org]
> > > >> *On Behalf Of
> *Katy Warr
> > > >> *Sent:* 14 July 2005
> > 16:07
> > > >> *To:*
> > > >> public-ws-
> > addressing@w3.org
> > > >>
> > > <mailto:public-ws-addressing@w3.org>
> > > >> *Subject:* LC 76 -
> > > What makes
> > > >> a msg WS-A?
> > > >>
> > > >>
> > > >> Please could we discuss
> > the
> > > >> following in the
> > > context of LC76?
> > > >>
> > > >> When is an incoming
> > message
> > > >> deemed to be a
> > > WS-Addressing
> > > >> message and
> > > therefore subject
> > > >> to the appropriate
> > > >> WS-Addressing
> > > validation? Is
> > > >> it based on
> the presence
> > of
> > > >> any
> WS-addressing Message
> > > >> Addressing
> Property? For
> > > >> example, does a message
> > > >> containing a reference
> > > >> parameter (but no other
> > > >> WS-Addressing
> > information)
> > > >> need to result in a
> > > >>
> > > MessageAddressingHeaderRequired?
> > > >> Or, for
> > > example, does the
> > > >> declaration of the wsa
> > > >> namespace rendor
> > > the message
> > > >> WS-Addressing?
> > > >>
> > > >> Thanks
> > > >> Katy
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
>
>
________________________________________________
Message sent using UebiMiau 2.7.2
Received on Tuesday, 19 July 2005 14:45:17 UTC