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:
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Patil, Sanjay"
<>
04/26/2006 01:58 AM
To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
"Gilbert Pilz" <>,
"Paul Fremantle" <>, "wsrx" <>
Subject
RE: [ws-rx] issue 115: clarifying question
Rejoinders inline ...
> -----Original Message-----
> From: Christopher B Ferris [mailto:]
> 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:
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
>
>
> "Patil, Sanjay" <>
>
> 04/25/2006 06:27 PM
>
>
> To
> Christopher
B Ferris/Waltham/IBM@IBMUS
> cc
> "Gilbert
Pilz" <>, "Paul Fremantle"
> <>, "wsrx" <>
> 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:]
> 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:
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> "Patil, Sanjay" <> 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:]
> > 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:]
> > 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:
> > blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> > phone: +1 508 377 9295
> >
> > "Gilbert Pilz" <> 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
> >
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
>
>
