mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: [Vysper] Handling of unsupported XML features
Date Mon, 07 Dec 2009 18:47:14 GMT
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
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

   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.


View raw message