What other valid
parts of the message? If someone is adding something to the CS, in the example
below an STR, that they require be understood and it isn’t what would be
left in the message that they would want to be processed? Is that the idea of
having a attribute to add mU nested into header or body content? If you don’t
understand this extension don’t process this part of the message but
process the rest of it? Would that be the immediate parent of where the
extension was that was not understood? The whole header where it occurred? The
whole body?
From: Patil, Sanjay
[mailto:sanjay.patil@sap.com]
Sent: Tuesday, April 25, 2006 3:28
PM
To: Christopher
B Ferris
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: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