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

New MTOM & XOP Issue: what if the input contains a xop:include?

From: <noah_mendelsohn@us.ibm.com>
Date: Thu, 15 Jan 2004 18:23:15 -0500
To: xml-dist-app@w3.org
Message-ID: <OF88AB4FE4.4E0D4C57-ON85256E1C.007F97D7@lotus.com>

(for those who have not been following discussion closely, XOP is the new
name for Miffy)

In reviewing the MTOM and XOP/Miffy drafts at [1,2] I notice that we have
not covered the case where the dm to be transmitted itself contains a
xop:include element.  I think our options are:

a) Disallow.  In this case, I think we must state in both MTOM and XOP
specs that SOAP Envelope or XML Document Data Models to be optimized MUST
NOT contain element nodes with the name xop:include.  In the case of the
binding, I think we must indicate that this is a (minor) deviation from the
general rules for SOAP, which in general do not disallow such content in a
SOAP message.  I think we must indicate that a binding-specific fault is to
be reflected if an attempt is made to transmit an envelop containing such
an element, and that conforming bindings MUST check for this condition.

b) Invent a quoting convention.  So:
   means do the include.
   means the include was in the original XML, and messily enough
   means the inner quote was in the original

Ugly, and potentially slow, but robust.  Note that this means checking and
being willing to rewrite all of the XML, including (potentially) headers
relayed intact through an intermediary.

c) Do nothing and let the system break if a malicious or clueless user puts
a xop:include into their data.  This is not completely far fetched.
Imagine a bug reporting system in which you wanted to carry a bug report on
a xop implementation, or sending around a fragment of xhtml describing xop.
It's not likely, but it could happen inadvertently, and I can certainly
imagine things malicious users would do to trick implementations that
weren't sufficiently defensive in their coding style.

I think all the options are to some degree ugly, but I find (c) to be
unacceptable on security and robustness grounds.  Unless someone can think
of an option I've missed, I think we need to choose some variant of (a) or
(b).  In any case, I recommend we open an issue and put a place holder
ednote in both documents until resolved.

Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Thursday, 15 January 2004 18:23:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC