RE: [ws-rx] issue 115: clarifying question

["Patil, Sanjay" <sanjay.patil@sap.com>]

Rejoinders inline ...

> -----Original Message-----
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Tuesday, Apr 25, 2006 16:05 PM
> To: Patil, Sanjay
> Cc: Gilbert Pilz; Paul Fremantle; wsrx
> Subject: RE: [ws-rx] issue 115: clarifying question
> 
> 
> So, in this case the mU has different semantics as to whether 
> it is used in the soap:Header vs a soap:Body? 
I was trying to point out the issues with using SOAP mU for RM
extensions. That's all. Having said that, I would expect that a proposal
defining wsrm:mU would specify the same semantic whether the attribute
appears in a header or the body.

> 
> The spec currently says that for "piggy-backed" RM elements, 
> that a fault in processing should be ignored, but for 
> others? Do we ignore the extension mU fault or proceed to 
> process the rest of the message, just without RM?
Good point. I hope that any proposal for asserting RM extensions would
define this behavior in concise terms.

> 
> Do we actually have any specific use cases that we can use to 
> vet this new wsrm:mU against besides the obvious one 
> of CS/STR? 
CS/STR seems to be the implicit driver looking at the messages on the
list!

> 
> As I have previously noted, the spec already has an 
> extensibility strategy; SHOULD ignore. Why are we proposing 
> to change that?
SHOULD ignore semantic may get in our way to build any runtime assertion
capability in the protocol, wouldn't it?
-- Sanjay

> 
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> 
> 
> "Patil, Sanjay" <sanjay.patil@sap.com> 
> 
> 04/25/2006 06:27 PM 
> 
> 	
> To
> 	Christopher B Ferris/Waltham/IBM@IBMUS 
> cc
> 	"Gilbert Pilz" <Gilbert.Pilz@bea.com>, "Paul Fremantle" 
> <paul@wso2.com>, "wsrx" <ws-rx@lists.oasis-open.org> 
> Subject
> 	RE: [ws-rx] issue 115: clarifying question
> 
> 	
> 
> 
> 
> 
>   
> There may other valid SOAP headers that are entirely 
> unrelated to RM (or just unrelated to the specific instance 
> of the problematic RM Sequence) which I believe should 
> rightfully see the day light. 
>   
> In the case of CS/STR mU that can not be respected, I do 
> expect that a fault be raised but I don't see why the other 
> valid parts of the message be discarded. 
>   
> -- Sanjay 
> 
> 
> ________________________________
> 
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Tuesday, Apr 25, 2006 15:19 PM
> To: Patil, Sanjay
> Cc: Gilbert Pilz; Paul Fremantle; wsrx
> Subject: RE: [ws-rx] issue 115: clarifying question
> 
> 
> What, then, would you have the processor do? Is it to take a 
> case-by-case assessment? 
> 
> In the case of the CS/STR, I certainly DO expect that the 
> entire message fault in this manner. 
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> "Patil, Sanjay" <sanjay.patil@sap.com> wrote on 04/25/2006 
> 05:51:48 PM:
> 
> >   
> > Doesn't SOAP mU processing model require that the entire message be 
> > abandoned and a fault raised if the mU semantic can not be respected
> > by the receiver. I am not sure we have enough reasons to justify 
> > triggering such a behavior for RM mU scenarios! 
> >   
> > -- Sanjay 
> > 
> > From: Paul Fremantle [mailto:paul@wso2.com] 
> > Sent: Tuesday, Apr 25, 2006 9:40 AM
> > To: Gilbert Pilz
> > Cc: Christopher B Ferris; wsrx
> > Subject: Re: [ws-rx] issue 115: clarifying question
> 
> > Gil
> > 
> > Why is creating a new SOAP header a problem? 
> > 
> > Paul
> > 
> > Gilbert Pilz wrote: 
> > So you are saying that the definition of qname of the header is the 
> > reference to the extension? This means that, for every extension for
> > which I want mU semantics, I need to define a unique header? Why is 
> > this preferable to defining a single new attribute? 
> >   
> > What if I extend something like the SequenceAcknowledgement header? 
> > Suppose an RMD is returning a message into which it inserts two 
> > separate SequenceAcknowledgement's, one of which has a 
> > mustUnderstand extension and the other which does not. It seems 
> > that, using your mechanism, an RMS that did not understand the 
> > extension would not be able to process either of the acknowledgments
> > despite the fact that one of them is not extended in any way. What 
> > if there were three SequenceAcknowledgement headers in the same 
> > message; one that carries a mustUnderstand extension, another that 
> > carries a mayIgnore extension, and a third that isn't 
> extended at all? 
> >   
> > - gp 
> > 
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> > Sent: Monday, April 24, 2006 6:07 PM
> > To: Gilbert Pilz
> > Cc: wsrx
> > Subject: Re: [ws-rx] issue 115: clarifying question
> 
> > 
> > Gil, 
> > 
> > Actually, I had something more like this in mind: 
> > 
> > <?xml version="1.0" encoding="UTF-8"?>
> > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope";
> > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200604"; 
> > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> > wssecurity-secext-1.0.xsd" 
> > xmlns:foo="http://example.org/foo";
> > xmlns:wsa="http://www.w3.org/2005/08/addressing";>
> > <S:Header>
> >  <foo:SecureRM S:mustUnderstand="1"/>
> >  <wsa:MessageID>
> >   http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
> >  </wsa:MessageID>
> >  <wsa:To>http://example.com/serviceB/123</wsa:To>
> >    
> <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200604/Creat
> eSequence
> > </wsa:Action>
> >  <wsa:ReplyTo>
> >   <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> >  </wsa:ReplyTo>
> > </S:Header>
> > <S:Body>
> >  <wsrm:CreateSequence>
> >    <wsrm:AcksTo>
> >      <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> >    </wsrm:AcksTo>
> >    <wsse:SecurityTokenReference>
> >      ...
> >    </wsse:SecurityTokenReference>
> >  </wsrm:CreateSequence>
> > </S:Body>
> > </S:Envelope>
> > 
> > Cheers, 
> > 
> > Christopher Ferris
> > STSM, Software Group Standards Strategy
> > email: chrisfer@us.ibm.com
> > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > phone: +1 508 377 9295 
> > 
> > "Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 04/24/2006 
> 05:41:23 PM:
> > 
> > > During the conference call of 4/20/2006 Chris asserted 
> that you can 
> > > use a SOAP header with a mustUnderstand attribute to flag 
> the fact 
> > > that some element in either another header or in the 
> message body is
> > > an extension that must be understood by the receiver. I'm 
> not sure I
> > > understood exactly what Chris thought this should look like. For 
> > > example, imagine the following CreateSequence message. 
> The extension
> > > elements have been marked in bold. What is supposed to go in the 
> > > <wsrm:Extension> header?
> > > 
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope";
> > > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200604";
> > > xmlns:wsa="http://www.w3.org/2005/08/addressing";>
> > >  <S:Header>
> > >   <wsrm:Extension S:mustUnderstand="1">
> > >     ????
> > >   </wsrm:Extension>
> > >   <wsa:MessageID>
> > >    
> http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
> > >   </wsa:MessageID>
> > >   <wsa:To>http://example.com/serviceB/123</wsa:To>
> > >     
> <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200604/Creat
> eSequence
> > > </wsa:Action>
> > >   <wsa:ReplyTo>
> > >    <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> > >   </wsa:ReplyTo>
> > >  </S:Header>
> > >  <S:Body>
> > >   <wsrm:CreateSequence>
> > >     <wsrm:AcksTo>
> > >       
> <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> > >     </wsrm:AcksTo>
> > >     <wsrm:SecurityComposition>
> > >       <wsrm:Identifier>
> > >         http://docs.oasis-open.org/ws-
> > > rx/wsrmsp/200604/profile/http_auth/samenode
> > >       </wsrm:Identifier>
> > >     </wsrm:SecurityComposition>
> > >   </wsrm:CreateSequence>
> > >  </S:Body>
> > > </S:Envelope>
> > > 
> > > I'm sure that most of us could all come up with a 
> reasonable design 
> > > to do what you suggest, but for the purposes of further 
> discussion 
> > > I'd like to know what design Chris had in mind?
> > > 
> > > - gp 
> > 
> > -- 
> > 
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > 
> > http://feeds.feedburner.com/bloglines/pzf
> > paul@wso2.com
> > 
> > "Oxygenating the Web Service Platform", www.wso2.com 
> 
>