- From: David Orchard <dorchard@bea.com>
- Date: Mon, 18 Jul 2005 14:00:49 -0700
- To: "Rogers, Tony" <Tony.Rogers@ca.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, "Jonathan Marsh" <jmarsh@microsoft.com>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>
- Cc: "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>
- Message-ID: <32D5845A745BFB429CBDBADA57CD41AF11445878@ussjex01.amer.bea.com>
If I get a wsa:Action marked mU="false", then presumably I can ignore
wsa for whatever reason, such as I don't understand WSA at all.
Dave
_____
From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
Sent: Monday, July 18, 2005 1:56 PM
To: Yalcinalp, Umit; Jonathan Marsh; Anish Karmarkar
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?
I thought the condition was EITHER a wsa:Action is present OR there is a
wsa header marked mU.
Tony
-----Original Message-----
From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: Tue 19-Jul-05 6:37
To: Jonathan Marsh; 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?
> -----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
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
>
>
Received on Monday, 18 July 2005 21:01:26 UTC