Niklas Gustavsson wrote: > Hi > > Section 11.1 in RFC 3920 mentions: > "With regard to XML processing, if an XMPP implementation receives > such restricted XML data, it MUST ignore the data." > > "restricted XML data" in this case is comments, PIs, CDATA, DOCTYPE > declarations, entities. The way I understand this is that if we > receive this, we should not fail, shut down the session or even send > an error to the user. Instead, we should just ignore the unsupported > piece of data and go on as usual. Would you agree?
That's an easy question: No (IMHO). ;-) Comments etc. are prohibited. They result in a stream error (eg. socket termination). XMPP does not put the burden on XMPP developers to parse the complete XML syntax. CDATA sections are ok, though, I think. >From http://tools.ietf.org/html/draft-saintandre-rfc3920bis-09#section-12.3 >>>> However, XMPP does not deal with XML documents but with XML streams. Because XMPP does not require the parsing of arbitrary and complete XML documents, there is no requirement that XMPP needs to support the full feature set of [XML]. In particular, the following features of XML are prohibited in XMPP: o comments (as defined in Section 2.5 of [XML]) o processing instructions (Section 2.6 therein) o internal or external DTD subsets (Section 2.8 therein) o internal or external entity references (Section 4.2 therein) with the exception of predefined entities (Section 4.6 therein) An XMPP implementation MUST behave as follows with regard to these features: 1. An XMPP implementation MUST NOT inject characters matching such features into an XML stream. 2. If an XMPP implementation receives characters matching such features over an XML stream, it MUST return a stream error, which SHOULD be <restricted-xml/> but MAY be <bad-format/>. <<<< But you are right, RFC3920 which you cite seems more relaxed with respect to parsing the XML superset. One might argue now that RFC3920 is normative, while the -bis drafts are not (yet). But I think that the drafts better reflect todays state of XMPP and support more robust (and more simple, maintainable etc.) parsers: Fail-fast is good for those parts of the parser which otherwise would be rarely executed and thus would be more prone to security holes. Bernd
