David,
The WG has decided to close issue 37 with the resolution stated below.
Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com
-----Original Message-----
From: Henrik Frystyk Nielsen
Sent: Wednesday, October 24, 2001 16:13
To: xml-dist-app@w3.org
Subject: Proposed resolution of issue 37
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
requirement."
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
enforced.
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
mailto:henrikn@microsoft.com
[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