- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Tue, 19 Jul 2005 09:22:07 -0700
- To: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Matt Long" <mlong@mvsquared.net>
- Cc: <public-ws-addressing@w3.org>
- Message-ID: <DD35CC66F54D8248B6E04232892B63380660DE31@RED-MSG-43.redmond.corp.microsoft.com>
________________________________
From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: 19 July 2005 17:11
To: Martin Gudgin; Matt Long
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?
Let me clarify my point. It may seem orthagonal, but it is not.
We are discussing how SOAP processing semantics should behave when it is
combined with WS-Addressing semantics.
It seems to me by abiding SOAP Processing rules, the receiver is
at liberty to ignore the headers that are marked as mU=0, right? If I
was writing a client, I would most likely will not mark some of my
headers mu=0 in order for all of them to be processed by the received. I
would mark all my MAH as mU=1, otherwise I can not expect the receiver
to process them if we are only requiring SOAP processing model.
For the second example you bring up, again, by following the
SOAP processing model, I could just ignore the offending headers and NOT
generate an error.
What this illustrates me is that SOAP processing semantics is
NOT adequate to interpret the MAH alone or to verify whether a message
is wellformed! You want to treat the MAH as an implicit bag. You need
additional rules on top of what you do with mU headers or force the
sender (client) to use mU consistently to get the desired effect, which
was my original proposal.
[MJG] Please define 'you' above. Sender? Receiver? Both?
Software developer? Admin?
To answer Matt, the mixed case is a very real use case. Not all
clients will support WS-Addressing. An endpoint will need to support
both kinds of clients, those which may engage WS-Addressing and those
which don't.
I am trying to achieve consistent behaviour. If we will depend
on mU for engaging WS-Addressing, then we should really be enforce
consistent behaviour.
--umit
________________________________
From: Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: Tuesday, Jul 19, 2005 7:44 AM
To: Yalcinalp, Umit; Matt Long
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?
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 16:23:41 UTC