Propose resolution of issue 191

This note is in fulfillment of my action item to propose a resolution of
issue 191 [1].  I believe that this resolution is reasonably complete and
correct, but I suggest that someone who is more familiar with the HTTP
binding than I am doublecheck the suggested changes to the state tables for
that binding (basically, these are to ensure that a message received with a
DTD in its serialization causes the same fault is any other malformed
message.)

Background on issue 191:

Chapter 5 of the editors copy of the SOAP framework currently says [2]:

"The XML infoset of a SOAP message MUST NOT contain a document type
declaration information item. On receipt of a SOAP message containing a
document type declaration information item, a SOAP receiver MUST generate a
fault (see 5.4 SOAP Fault) with a value of "DTDNotSupported" for faultcode
."

As pointed out in the presentation of the issue, it is incoherent to talk
of a SOAP message being received with a DTD, except in the context of a
particular binding.  Indeed, this might be compared to saying that a SOAP
message is received which is not XML.  SOAP messages are by definition XML,
and by definition do not contain DTDs.  Therefore, the following is
proposed as a resolution to issue 191.

======= PROPOSE RESOLUTION OF ISSUE 191 =================

Several changes are suggested.  Each is marked with an asterisk (*).

* Change the quoted text above in chapter 5 to state:

"The XML infoset of a SOAP message MUST NOT contain a document type
declaration information item."

In other words, delete the second sentence of the paragraph.

* Remove the "DTDNotSupported" fault code from the table in section 5.4.6
[3]

* Section 4.2 on the binding framework currently says[4]:

<original fromSection="4.2">
As described in 5 SOAP Message Construct, each SOAP message is modeled as
an XML Infoset that consists of a document information item with exactly
one child: the envelope element information item. Therefore, the minimum
responsibility of a binding in transmitting a message is to specify the
means by which the SOAP XML Infoset is transferred to and reconstituted by
the binding at the receiving SOAP node and to specify the manner in which
the transmission of the envelope is effected using the facilities of the
underlying protocol.

The binding framework does NOT require that every binding use the XML 1.0
[8] serialization as the "on the wire" representation of the Infoset;
compressed, encrypted, fragmented representations and so on can be used if
appropriate. A binding, if using XML 1.0 serialization of the infoset, MAY
mandate that a particular character encoding or set of encodings be used.
</original>

Change this as follows:

<proposed forSection="4.2">
As described in 5 SOAP Message Construct, each SOAP message is modeled as
an XML Infoset that consists of a document information item with exactly
one child: the envelope element information item. Therefore, the minimum
responsibility of a binding in transmitting a message is to specify the
means by which the SOAP XML Infoset is transferred to and reconstituted by
the binding at the receiving SOAP node and to specify the manner in which
the transmission of the envelope is effected using the facilities of the
underlying protocol.

The binding framework does NOT require that every binding use the XML 1.0
[8] serialization as the "on the wire" representation of the Infoset;
compressed, encrypted, fragmented representations and so on can be used if
appropriate. A binding, if using XML 1.0 serialization of the infoset, MAY
mandate that a particular character encoding or set of encodings be used.
NOTE:  5 SOAP Message Construct provides that the envelope Infoset MUST NOT
include a DTD.  Accordingly, a binding that uses the XML 1.0 serialization
MUST NOT transmit a DTD; a binding that accepts XML 1.0 serializations MUST
fault in a binding specific manner if an XML 1.0 serialization
corresponding to a DTD for the envelope is received.
</proposed>

NOTE to those reading is proposed issue resolution: the above is carefully
worded to NOT say where that DTD might be found.  For example, it might be
in an internal subset (which is the XML 1.0 term for a DTD included in an
instance document).  One could imagine a different binding that used
multipart MIME to send an external DTD.  The wording above is intended to
preclude all such representations of a DTD for the envelope.

* In the description of the "FAIL" state when receiving a malformed message
in the HTTP binding in section 7.4.1.2.1 [5]:

<original>
The message is deemed to have been intended for the local SOAP node, but is
deemed badly formed: ill-formed XML, does contain a valid SOAP envelope.
</original>

<proposed>
The message is deemed to have been intended for the local SOAP node, but is
deemed badly formed: ill-formed XML, contains a serialized DTD, and/or does
contain a valid SOAP envelope.
</proposed>

In the fault code table below, I would clarify that reception of a DTD is
treated as an "Ill-formed" XML message.

* In section 7.4.1.1.3 [6]:

In the table for the receiving state, replace: "Malformed Response Message,
e.g. malformed XML, invalid SOAP Envelope" with "Malformed Response
Message, e.g. malformed XML, message contains a DTD,  invalid SOAP
Envelope"

Noah

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x191
[2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#soapenv
[3] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#faultcodes
[4] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#bindfw
[5]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-respbindreceive
[6]
http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.html#http-reqbindrecstate


------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Monday, 25 March 2002 18:19:20 UTC