A silly suggestion perhaps, but would this problem go away if there was a single addressing header that contains all the current separate header elements? It would also solve the problem of identifying other headers that belong to a particular EPR and another problem that properties (or whatever they are now) need to have SOAP attributes defined as part of their schema type in order for them to correctly validate when mU or role attributes are used. So something like

    <env:Header>
       <wsa:Addressing env:mustUnderstand="1">
          <wsa:Action>...</wsa:Action>

It seems that SOAP processing was not really designed with header bags in mind and an attempt is being made to define a new layer of behaviour on basic SOAP header processing.

Pete

Martin Gudgin wrote:
 


From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
Sent: 19 July 2005 17:11
To: Martin Gudgin; Matt Long
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?

Let me clarify my point. It may seem orthagonal, but it is not. We are discussing how SOAP processing semantics should behave when it is combined with WS-Addressing semantics.
 
It seems to me by abiding SOAP Processing rules, the receiver is at liberty to ignore the headers that are marked as mU=0, right? If I was writing a client, I would most likely will not mark some of my headers mu=0 in order for all of them to be processed by the received. I would mark all my MAH as mU=1, otherwise I can not expect the receiver to process them if we are only requiring SOAP processing model.
 
For the second example you bring up, again, by following the SOAP processing model, I could just ignore the offending headers and NOT generate an error.
 
 
What this illustrates me is that SOAP processing semantics is NOT adequate to interpret the MAH alone or to verify whether a message is wellformed! You want to treat the MAH as an implicit bag. You need additional rules on top of what you do with mU headers or force the sender (client) to use mU consistently to get the desired effect, which was my original proposal.  
[MJG] Please define 'you' above. Sender? Receiver? Both? Software developer? Admin?
 
To answer Matt, the mixed case is a very real use case. Not all clients will support WS-Addressing. An endpoint will need to support both kinds of clients, those which may engage WS-Addressing and those which don't.
 
I am trying to achieve consistent behaviour. If we will depend on mU for engaging WS-Addressing, then we should really be enforce consistent behaviour.  
 
--umit
 

From: Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: Tuesday, Jul 19, 2005 7:44 AM
To: Yalcinalp, Umit; Matt Long
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?

There are a few (somewhat orthogonal) things going on here;
 
1.    The message sender specifies, using mU='true' and mU='false', which headers it requires the receiver to process and which headers it is happy for the receiver to ignore.
 
2.    The message receiver has a set of headers it supports.
 
3.    The message receiver has to follow the SOAP processing rules.
 
Let's assume for a moment that the message receiver supports all the headers that the message sender puts in the message. In such a case, one could argue that the values the message sender specifies for mU are irrelevant, that is the receiver will just process all the headers it supports. Conversely, one could argue that a receiver, despite understanding all the headers, is still at liberty to ignore headers marked mU='false'.
 
I sense in this thread a desire to *force* the first case, that is a message receiver MUST process all the headers it supports, even if they are marked mU='false'. I don't know why we would want to mandate that behaviour.
 
Let's now look at a message that violates one of our spec contraints, one that has multiple wsa:ReplyTo headers perhaps, or a wsa:FaultTo with a missing wsa:Address element. I can see an argument that says a message receiver that supports those headers should generate a fault because the message is malformed. I can also see an argument that says if those headers are marked mU='false' then the message receiver can ignore them even though they are malformed.
 
Again, I sense a desire to force the first case (I'm slightly more sympathetic toward this one...)
 
Gudge
 


From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Yalcinalp, Umit
Sent: 19 July 2005 14:01
To: Matt Long
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?

This is exactly why I brought up this example. You can look at this two different ways:
 
-- We follow SOAP processing rules. Hence, the headers that are marked mU=0 may be ignored.
 
-- WS-Addressing is engaged, therefore all the headers, including those that are marked mU=0, are processed.
 
I am asking that we clarify our position.
 
If we would like to follow both the SOAP processing semantics, and achieve processing of all the headers, a combination approach, namely marking all the WS-Addressing headers consistently  (i.e. treating them as a 'virtual' bag) will make sense.
 
Noone so far has come forward and explained why one would prefer a combination of mU values, or the use cases that would support.
 
 
--umit
 


From: Matt Long [mailto:mlong@mvsquared.net]
Sent: Monday, Jul 18, 2005 10:20 AM
To: Yalcinalp, Umit
Cc: public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?

If you have a WS-A endpoint then by definition all WS-A headers will be processed independent of mU semantics.  I cannot see how a WS-A header could be 'ignored' when performing WS-A processing on a WS-A endpoint.  Notice, I didn't address the dual-use scenario since I don't believe this belongs in the spec.

Correct me if necessary, but isn't it just that simple!

-Matt Long



--------- Original Message --------
From: "Yalcinalp, Umit" <umit.yalcinalp@sap.com>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, "Anish Karmarkar" <Anish.Karmarkar@oracle.com>, "Rogers, Tony" <Tony.Rogers@ca.com>
Cc: "Winkler, Steve" <steve.winkler@sap.com>, "Martin Gudgin" <mgudgin@microsoft.com>, "David Orchard" <dorchard@bea.com>, "David Hull" <dmh@tibco.com>, "Katy Warr" <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org
Subject: RE: LC 76 - What makes a msg WS-A?
Date: 18/07/05 14:56





> -----Original Message-----
> From: Jonathan Marsh [mailto:jmarsh@microsoft.com]
> Sent: Monday, Jul 18, 2005 1:30 PM
> To: Yalcinalp, Umit; Anish Karmarkar; Rogers, Tony
> Cc: Winkler, Steve; Martin Gudgin; David Orchard; David Hull;
> Katy Warr; public-ws-addressing@w3.org
> Subject: RE: LC 76 - What makes a msg WS-A?
>
> "Engaging WS-Addressing is indicated by the mU=1 on any header that is
> specified by WS-Addressing."
>
> Where is this specified? I'm not sure I agree this is a constraint
> rather than a heuristic.

It is not specified. Based on what I can follow in this thread, engaging
WS-Addressing appears to be indicated by using mU. Let me make this
clear. I am not saying that this should be the only way, but I am not
aware of an alternate way from the receiver's side to detect
WS-Addressing is engaged or not since we are relying on the SOAP
processing model only.

Putting this aside, assuming that WS-Addressing is engaged, my question
still applies.



--umit

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








________________________________________________
Message sent using UebiMiau 2.7.2