W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2004

Proposed text of request for feedback on binding-specific MTOM faults

From: <noah_mendelsohn@us.ibm.com>
Date: Sat, 22 May 2004 19:39:20 -0400
To: xml-dist-app@w3.org
Message-ID: <OFFB5AB64D.3978F9EC-ON85256E9C.00800F47@lotus.com>

This note is in fulfillment of an action assigned to me on the 5/19 call.

Our editors' draft of MTOM contains in section 4.3.1 [1] the text:

"Implementations of this binding MUST enforce the restriction that XOP is
not to be used with Infosets that contain element information items of name
xop:Include (see [XOP] 3. XOP Infosets Constructs). In any case where a
SOAP envelope containing such an element information item is to be sent,
the binding MUST do one of the following:

* Fall back to use the application/soap+xml media type or any other
suitable media type, i.e., send the SOAP envelope without using the HTTP
Transmission Optimization Feature.
* Generate a binding-dependent SOAP fault. "

The SOAP Recommendation says in the binding framework section [2]:

"As described in 5. SOAP Message Construct, each SOAP message is specified
as an XML infoset that consists of a document information item with exactly
one child: the SOAP Envelope element information item. Therefore, the
minimum responsibility of a binding in transmitting a message is to specify
the means by which the SOAP message 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."

Nowhere in the binding framework is any license given for a binding to
decline to send envelopes that are otherwise legal SOAP content.  I have
always taken it as implicit that bindings are responsible for sending all
SOAP envelopes with fidelity, and indeed I would support an eventual
clarification to the rec that would make such a point explicit.

The MTOM text quoted above contradicts this reading of the SOAP rec insofar
as it specifies that implementations may generate an error when confronted
with a SOAP envelope containing a xop:Include.  We discussed my concern on
the 5/19 call and we agreed to:

* Retain the text above in the Last Call draft, but possibly remove it
later.
* Add a note explaining the issue and soliciting feedback.  I was given the
action item to draft proposed text of such a note.

Here is my proposal.  This text would follow the bullet above that says
"Generate a binding-dependent SOAP fault."

<proposedRequestForFeedback>
The binding framework of the SOAP recommendation provides that "the minimum
responsibility of a binding in transmitting a message is to specify the
means by which the SOAP message 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." [2].  Although illegal as input to XOP encoding,
elements named xop:Include are legal in SOAP Infosets, and may indeed be
useful in certain circumstances (perhaps in sending an error report on or
otherwise quoting a fragment of a XOP Infoset).  During preparation of this
MTOM specification some commentators noted that the second option provided
above, I.e. to generate an error, sets the potentially unfortunate
precedent of allowing particular bindings to decline to send otherwise
legal SOAP messages.  Accordinginly, the option to generate a
binding-dependent fault is included in this draft provisionally, and the
XML Protocols Workgroup solicits feedback on the advisability of retaining
this option in the final Recommendation.
</proposedRequestForFeedback>


[1]
http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html#httpof-sending
[2] http://www.w3.org/TR/soap12-part1/#bindfw

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Saturday, 22 May 2004 22:19:58 GMT

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