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

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

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 19 Jul 2005 06:00:36 -0700
Message-ID: <2BA6015847F82645A9BB31C7F9D641652149D5@uspale20.pal.sap.corp>
To: "Matt Long" <mlong@mvsquared.net>
Cc: <public-ws-addressing@w3.org>
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 13:00:30 GMT

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