[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wss] ISSUE 190: text for SOAP MustUnderstand issue
Chris, While all this is wunderbar stuff defined in soap 1.2, what if wss only normatively uses soap 1.1? I would argue that using soap 1.2 would be advantageous to wss in this regard because soap 1.2 is a clearer model. However, I don't think that wss is moving to soap 1.2, despite the suggestions of groups like the xml protocol wg. But then I guess there's some liaison history there. Dave > -----Original Message----- > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] > Sent: Wednesday, October 29, 2003 6:37 PM > To: Christopher B Ferris > Cc: Reid, Irving; wss@lists.oasis-open.org > Subject: Re: [wss] ISSUE 190: text for SOAP MustUnderstand issue > > > <decloak/> > Oops... I was just re-reading my post and noticed that I neglected to > apply a final edit to change 'element' to 'header block' to > be consistent > with the other comment form the XMLP WG. > > > Conforming implementations are said to "understand" a > > <wsse:Security> element if they are able to process the > > <wsse:Security> element and all of its descendant elements, > > including any elements or attributes defined by profiles > > or extensions. > > should have read: > > > Conforming implementations are said to "understand" a > > <wsse:Security> header block if they are able to > process the > > <wsse:Security> header block and all of its > descendant elements, > > > including any elements or attributes defined by profiles > > or extensions. > > <cloak> > > Cheers, > > Christopher Ferris > STSM, Emerging e-business Industry Architecture > email: chrisfer@us.ibm.com > phone: +1 508 234 3624 > > Christopher B Ferris/Waltham/IBM@IBMUS wrote on 10/29/2003 > 09:27:57 PM: > > > <decloak/> > > > > SOAP1.1 may have been somewhat ambiguous as regards the > intent behind > > soap:mustUnderstand attribute, but SOAP1.2 is quite clear on the > > matter[1]. > > "A SOAP header block is said to be understood by a > SOAP node if > > the software at that SOAP node has been written to > fully conform > > > to > > and implement the semantics specified for the XML > expanded name > > of the outer-most element information item of that header > block." > > > > IMO, it isn't a balance that must be struck. All it > requires is that > > the specification for the header block define the implied > semantics. > > > > The SOAP mustUnderstand attribute with a value of true does not > > mean "ignore at your own peril", it is an integral part of the > > SOAP protocol. > > > > Section 2.4 of the SOAP1.2 spec continues: > > > > "Mandatory SOAP header blocks are presumed to > somehow modify the > > > semantics of other > > SOAP header blocks or SOAP body elements. > Therefore, for every > > mandatory SOAP header > > block targeted to a node, that node MUST either process the > header > > block or not process the > > SOAP message at all, and instead generate a fault (see 2.6 > > Processing SOAP Messages > > and 5.4 SOAP Fault). Tagging SOAP header blocks as > mandatory > thus > > assures that such > > modifications will not be silently (and, presumably, > erroneously) > > ignored by a SOAP node > > to which the header block is targeted." > > > > The understanding of a SOAP header block labeled as > mandatory, by means > > of a SOAP mustUnderstand attribute, is not important only > to the SOAP > > node processing the message, it may have consequences for > the sender of > > that message as well. That's why the SOAP spec requires that a > > MustUnderstand fault be generated, so that both the sender > and receiver > > are protected from unintended consequences. > > > > One last point. It is not always possible to "return a fault". > > A SOAP fault is said to be "generated", which is distinct from > > returning a message containing that fault to the sender of the > > message that caused the fault to be generated. The important > > point is that the generation of a fault terminates all subsequent > > processing of the message beyond that which is necessary to > > handle the fault (e.g backing out uncommitted processing results > > and possibly creating a SOAP Fault message to transmit the > > fault to the sender). > > > > I would suggest the following refinement to your proposal: > > > > Conforming implementations are said to "understand" a > > <wsse:Security> element if they are able to process the > > <wsse:Security> element and all of its descendant elements, > > including any elements or attributes defined by profiles > > or extensions. > > > > If a <wsse:Security> header block is marked as mandatory by > > means of a SOAP mustUnderstand attribute, and also contains > > extension elements or attributes that are not recognized > > by the SOAP node to which the <wsse:Security> > header block is > > targetted, a conforming implementation MUST generate a > > SOAP MustUnderstand fault. > > > > The tricky part becomes what to do with non-mandatory > <wsse:Security> > > header blocks when they contain unrecognized extension elements or > > attributes. There are two possibilities, ignore the unrecognized > > content but process the <wsse:Security> header block as if they were > > not present, or discontinue processing the <wsse:Security> header > > block entirely (e.g. ignore it altogether). > > > > SOAP header blocks that are not marked as mandatory with a SOAP > > mustUnderstand attribute carry the semantic that they MAY be safely > > ignored if not understood. From the SOAP1.2 specification section > > 2.6: > > > > "4. ... A SOAP node MAY also choose to process > non-mandatory > > > SOAP > > header blocks targeted at it." > > > > Given this, and to be consistent with SOAP, I would suggest that > > the implementation be given the option of "ignoring unrecognized > > extensions at its peril" or ignoring the header block altogether. > > > > Suggested prose: > > > > If a <wsse:Security> header block is not marked as mandatory > > by means of a SOAP mustUnderstand attribute, and > also contains > > extension elements or attributes that are not > recognized by the > > SOAP node to which the <wsse:Security> header block is > targetted, > > a conforming implementation MAY choose not to process the > > <wsse:Security> header block. > > > > [1] http://www.w3.org/TR/soap12-part1/#muprocessing > > > > <cloak/> > > > > Cheers, > > > > Christopher Ferris > > STSM, Emerging e-business Industry Architecture > > email: chrisfer@us.ibm.com > > phone: +1 508 234 3624 > > > > "Reid, Irving" <irving.reid@hp.com> wrote on 10/29/2003 06:44:31 PM: > > > > > This message relates to Issue 190, raised by the W3C XMLP working > group. > > > > > > In WSS-SOAPMessageSecurity-17-082703-merged.pdf, lines > 455-457, the > > draft reads: > > > > > > 455 The optional mustUnderstand SOAP attribute on Security header > (sic) > > simply means you are aware of > > > 456 the Web Services Security: SOAP Message Security > specification, > and > > there are no implied > > > 457 semantics. > > > > > > > > > > > > The background is that SOAP allows header elements to contain a > > "MustUnderstand" attribute, and if > > > MustUnderstand="1" (or "true") then the recipient of the > message MUST > > return a fault if it does > > > not understand said header element. Unfortunately, it's > not clear what > > > "understand" means in this context. > > > > > > We need to strike a balance between the extremes of: > > > > > > o MustUnderstand just means "ignore at your own peril"; > a recipient > can > > completely ignore the > > > content, but if that leads to problems they have no one > to blame but > > themselves. In the real > > > world, this is what it really comes down to. We don't > have a protocol > > for sending Big Foam > > > Cluebats across the network to people who ignore MustUnderstand > > elements. > > > > > > o MustUnderstand means that a recipient must be able to > fully process > > > every optional sub-element > > > and possible extension of the MustUnderstand header > element. This is > > clearly too strict a constraint. > > > > > > > > > The problem is further complicated by the fact that > elements within > > wsse:Security may be > > > extensions defined in other specifications, so we can't clearly > specify > > where people need to look > > > to determine how to "understand" them. > > > > > > > > > I think the balance looks very much like the text we > already have in > the > > spec (WSS- > > > SOAPMessageSecurity-17-082703-merged.pdf) in the "Message > Security > > Model" section: > > > > > > 237 Where the specification requires that an element be > "processed" it > > > means that the element type > > > 238 MUST be recognized to the extent that an appropriate error is > > returned if the element is not > > > 239 supported.. > > > > > > and also immediately above the text in question: > > > > > > 450 All compliant implementations MUST declare which > profiles they > > support and MUST be able to > > > 451 process a <wsse:Security> element including any > sub-elements which > > > may be defined by that > > > 452 profile. > > > > > > > > > Now, there is also an open issue (189) complaining about > this text, > > since we don't provide a way > > > for implementations to "declare" which profiles they support and > > therefore this MUST is > > > unimplementable/unenforceable. > > > > > > Perhaps we could replace lines 450-452 and 455-457 with > the following, > > > and move lines 453-454 to > > > the end of the section: > > > > > > > > > Conforming implementations MUST be able to process the > <wsse:Security> > > > element and all sub- > > > elements, including any elements defined by profiles or > extensions > > supported by that > > > implementation. If the <wsse:Security> header has a SOAP > > mustUnderstand="true" attribute and the > > > implementation cannot process all sub-element and extensions, the > > implementation MUST return an > > > appropriate SOAP fault. If the <wsse:Security> header > does not have a > > mustUnderstand="true" > > > attribute, the implementation SHOULD return a fault if it cannot > process > > all sub-elements and extensions. > > > > > > > > > (I struggled a bit with the semantics of this - one > option would be to > > > try and effectively > > > override mustUnderstand by saying that conforming > implementations MUST > > > process or fault, > > > independent of mustUnderstand; I changed my mind on that > because SOAP > > listeners without Soap > > > Message Security implementations can legally ignore > <wsse:Security > > mustUnderstand="false"> > > > headers, so why can't conforming implementations?) > > > > > > > > > I think this says what we mean, modulo the above and the > fact that the > > > current specification isn't > > > always clear about what it means to "process" the contents of a > > <wsse:Security> header. Speak up > > > if you think I'm off track with the semantics, or if you > have better > > wording. > > > > > > - irving - > > > > To unsubscribe from this mailing list (and be removed from > the roster of > the OASIS TC), go to > > > http://www.oasis-open.org/apps/org/workgroup/wss/members/leave _workgroup.php. > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]