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

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

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Fri, 15 Jul 2005 08:30:57 -0400
To: "Martin Gudgin" <mgudgin@microsoft.com>
Cc: "David Hull" <dmh@tibco.com>, "David Orchard" <dorchard@bea.com>, "Katy Warr" <katy_warr@uk.ibm.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF09323036.0D4ED2FF-ON8525703F.0042E953-8525703F.0044BFA2@us.ibm.com>

Gudge,

I think that this is pretty close to the mark. How about mandating that 
the wsa:Action carry a mU='true'
AND disallowing mU='true' on all other elements of the wsa: namespace. I 
think that that effectively
gets you something that can be assured to be consistent with the SOAP 
processing model since "understanding"
is predicated on the expanded name of the SOAP header block. An 
implementation that receives a
message containing a SOAP header block in the wsa: namespace that is not 
wsa:Action that also
has a mU='true' MUST return a soap:MustUndrstand fault. Further, you have 
the WS-A spec (in the SOAP binding) define
"understanding" of the wsa:Action to include the processing of all other 
SOAP header blocks that 
have the wsa: namespace.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295



"Martin Gudgin" <mgudgin@microsoft.com> 
Sent by: public-ws-addressing-request@w3.org
07/15/2005 01:43 AM

To
"David Hull" <dmh@tibco.com>
cc
"David Orchard" <dorchard@bea.com>, "Katy Warr" <katy_warr@uk.ibm.com>, 
<public-ws-addressing@w3.org>
Subject
RE: LC 76 - What makes a msg WS-A?






 

From: David Hull [mailto:dmh@tibco.com] 
Sent: 15 July 2005 06:31
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: 
 [snip]
[MJG] How about this? Is wsa:Action is missing then you MUST proceed as if 
you DO NOT understand WS-Addressing. And if wsa:Action is present and any 
other constraints in the spec are violated, then you MUST generate a 
fault. 
The upshot of the first 'MUST' is that during the mU check, if any wsa: 
header is found with mU='true' then a check to make sure wsa:Action is 
present has to occur to determine whether you 'understand' that wsa: 
header. Essentially, understanding wsa:Action becomes part of 
understanding all the other wsa: headers.
 
This approach has the advantage of producing consistent behaviour between 
WS-A and non-WS-A nodes for messages that DO NOT contain wsa:Action. 

This helps, I think.  I continue to be uneasy with using the fact that 
Action happens to be the one mandatory property that's also a mandatory 
header, but at this point, any port in a storm. 
[MJG] What would make you less uneasy?

If I read this right, the behavior if wsa:ReplyTo is present, mU false, 
and no wsa:Action is present, is that the ReplyTo is silently ignored -- 
since Action is missing, I have to not understand ReplyTo.  This doesn't 
seem like a good kind of silent failure, but the client at least has the 
option of turning on mU for the ReplyTo if it wants to be safe. 
[MJG] Right, if the client cares, it should put mU='true' on the ReplyTo. 

Where would we say this?  In the SOAP binding? 
[MJG] That would seem like the most sensible place. 
Received on Friday, 15 July 2005 12:31:11 GMT

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