W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

Proposed resolution of issue 37

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Wed, 24 Oct 2001 16:43:07 -0700
Message-ID: <79107D208BA38C45A4E45F62673A434D034423E4@red-msg-07.redmond.corp.microsoft.com>
To: <xml-dist-app@w3.org>

I took an action item to write up what SOAP 1.2 provides in the way of
extensibility relating to issue [1] which refers to requirement R302 [2]
from the XML Protocol Requirements document. The description of the
issue is as follows:

"SOAP1.1 defines a vocabulary with certain types of extensibility. XML
Protocol requirements declare a need for extensibility which supports
"decentralized extensibility without prior agreement". It's not clear
whether the types of extensibility in SOAP are adequate for this

SOAP provides an extensibility mechanism that allows for addition of an
open-ended set of header blocks to any SOAP message. The default SOAP
processing model for such blocks is that they are optional and intended
for the ultimate recipient. This behavior can be overridden by using the
"mustUnderstand" and "actor" SOAP attributes.

Header blocks are identified by the fully qualified element name of the
outermost element of the block allowing for deployment of both publicly
defined header blocks as well as privately defined header blocks defined
in a decentralized manner.

A SOAP sender can in principle add any header block to any SOAP message
independently of any other block and without prior agreement with the
recipient of the message. It is not within the scope of SOAP 1.2 to
describe whether or how header block interactions are defined or

A SOAP receiver can generate a SOAP fault while processing a message if
required header blocks are not present. SOAP 1.2 defines a
"mustUnderstand" fault code along with a mechanism for indicating which
blocks were not understood without prior agreement with the sender.
While the SOAP 1.2 envelope itself does not define a mechanism for
routing or otherwise returning SOAP fault messages, such mechanisms may
be provided by the underlying protocol or by additional SOAP modules.

Given this, I would claim that SOAP 1.2 fulfills both the
"decentralized" and the "without prior agreement" part of this
requirement and will propose that we close issue 37.

Henrik Frystyk Nielsen 

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x37
[2] http://www.w3.org/TR/xmlp-reqs/#z302
[3] http://www.w3.org/TR/soap12-part1/#mufault
Received on Wednesday, 24 October 2001 19:44:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT