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

Chris

I having trouble seeing the practical difference between what I proposed
and what you describe below...

Gudge

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: 15 July 2005 13:31
> To: Martin Gudgin
> Cc: David Hull; David Orchard; Katy Warr; 
> public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: RE: LC 76 - What makes a msg WS-A?
> 
> 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 13:24:17 UTC