Comments inline . .
.
From: Christopher B Ferris
[mailto:]
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.
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.
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 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.
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.
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).
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/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:
> 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/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
>
>
> "Oxygenating the Web Service Platform",
www.wso2.com
