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


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/26/2006 12:39:12 PM:

> Comments inline . . .
>
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Tuesday, April 25, 2006 7: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?
>  
> soap:mU and wsrm:mU have the same semantics but different processing
> models. The first is interpreted by the general SOAP processing
> engine, the later by the RM layer. I think this is the part that
> people are not picking up on. If you send a CreateSequence that
> contains an extension that has the "wsrm:mU" attribute to an RMD
> that does not support that extension it is the RMD that is
> responsible for detecting this fact and not the general-purpose SOAP
> engine. That's why our proposal includes a wsrm:MustUnderstandFault;
> we felt it would be misleading and incorrect to return a soap:
> MustUnderstand fault because, as far as the SOAP engine was
> concerned, there was nothing wrong with the message.

To be clear, I was not under the misimpression you cited. I was merely
inquiring as to whether the processing that Sanjay implied different
semantics based on whether the wsrm:mU appeared in a RM header block
or in an RM operation message carried in the soap:Body, because in some
cases, a wsrm:mU fault must be generated, and in others, not? Certainly,
if we are to adopt this, we must be crystal clear and IMO, consistent.

>
> 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?
>  
> These questions don't really make sense because you are assuming it
> is the SOAP processing engine that interprets wsrm:mU when it is
> not; wsrm:mU should only ever be processed by the RMS or the RMD.

Now who is placing words in whose mouth? I was not assuming any
such thing. I was pointing out that in certain cases, as in the case
of "piggy-backed" acks, etc. the spec explicitly says that the
normal processing of the message should not be impeded. e.g. that a
fault is generated and caught before terminating all subsequent
processing of the message. Does the same hold true in the case
of a wsrm:mU? Does this mean that in the case of a wsrm:mU fault
that the sender will never know about the fact that the recipient
doesn't understand the extension? Do we make an exception for the
wsrm:mU fault case? enquiring minds want to know.

>  
> Actually it is in the area of "piggy-backed" RM elements where the
> idea of using SOAP headers to refer to extensions inside of WS-RM
> defined components really runs into trouble. If you extend

Sigh... I disagree.

> SequenceAcknowledgment in a "mustUnderstand" way then piggy-back
> that header (plus the SOAP mU-header that refers to that extension)
> onto an arbitrary message the SOAP engine of a non-supporting node
> will fault on that message before it can reach the RMS where the
> special case on "the processing of the original message MUST NOT be affected
> " can take effect. The result is that the intended recipient would
> not get the message even though that message may not have been
> "carried reliably" or otherwise been involved in any way with WS-RM.

So, you intend mU semantics in which the sender can never ever learn
that the extension that mU is not understood? I am very confused as to
what value you think that this adds. In the case you describe above,
NO SequenceAcks will EVER be processed (regardless of whether the
rest of the message is processed) and hence the Sequence will NEVER
be completed because the sender does not think that any of the messages
have been acked, and in fact, it doesn't even know that the reason is
because it lacked understanding of some key extension. This is, IMNSHO,
fundamentally broken.

>  
> If you used "wsrm:mustUnderstand" to annotate the extension the SOAP
> engine wouldn't/shouldn't get involved and the RMS will (a) notice
> that it can't process this acknowledgment and (b) apply the special
> case and forward the message for further processing.
>
> 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?
>  
> By its nature you can't talk about specific use cases when it comes
> to supporting extensibility. I don't remember anyone providing a use
> case around why CloseSequence (to pick an example) needs to be
> extended but the extension points are there. If you agree that not
> all extensions are ignorable then you must have a way to indicate to
> the recipient that some extensions must be understood.

This is circular logic. You certainly CAN talk about use cases in the
context of extensibility. You just don't have to specify them because,
well, they are extensions. we have certainly been discussing a very specific
use case, the CS/STR. I certainly don't see why you would say that discussion
of use cases for extending say the AcksRequested with mU semantics
isn't something worthy of discussion as it would certainly help in
resolving some of the questions.

>  
> As I have previously noted, the spec already has an extensibility
> strategy; SHOULD ignore. Why are we proposing
> to change that?
>  
> Because "SHOULD ignore" is not sufficient to cover those cases where
> ignoring an extension could lead to serious negative consequences
> (such as the omission of any security processing by the RMD).

It does when coupled with SOAP mU. You previously said that you needed to
be able to annotate a specific instance of an extension. I would like to hear
of a use case in which the same extension occurred in multiple locations
but only a subset of those required mU and the others explicitly not.

>
> 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/CreateSequence
> > </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/CreateSequence
> > > </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]