OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



Sanjay,

When you match SHOULD ignore with soap:mU, I believe you get all you need. Clearly, an
endpoint that understands an extension isn't going to ignore it.

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>

04/26/2006 01:58 AM

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






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
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]