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

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

From: David Orchard <dorchard@bea.com>
Date: Mon, 18 Jul 2005 14:00:49 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF11445878@ussjex01.amer.bea.com>
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>
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 GMT

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