On Tue, Jul 31, 2007 at 01:28:43PM +0200, Alexander Gnauck wrote: > Ralph Meijer schrieb: > >I am curious which software this holds for. Most XMPP implementations > >are based on expat, as far as I know. Sure they might have their own > >DOM's (my Twisted XMPP stuff does), but that is irrelevant for parsing. > > There is many software which is using expat, but there is also lots of > software which has its own simple parsers. > * I have my own XML parser in many projects > * The Tigase and gloox have their own lightweight XML parsers > * Lots of mobile clients have their own parsers > > Of course it may be possible to replace this parsers with feature > complete XML parsers or add CDATA to them if it doesnt exists already. > But there are reasons why the developers wrote their own parsers.
The RFC3920 does not restrict usage of CDATA, so I always assumed it's a valid XML construct. But I would've never used it in my code just because I know that there are XMPP implementations which can't even read the ""XML"" described in RFC3920. > Today we talk about CDATA, hey but what is coming next? There seems to be an obvious large need for clearing up the CDATA case. It was never restricted by the RFC, some RFCs even used it: http://www.xmpp.org/rfcs/rfc3923.html 3.1. Process for Securing Messages ... a sending agent MUST use the following procedure: ... Provide the resulting signed and/or encrypted object within an XML CDATA section (see Section 2.7 of [XML] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (3rd ed),” February 2004.)) contained in an <e2e/> child of a <message/> stanza ... Of course that RFC was never relevant in any implementation as far as I know, but you couldn't know whether it might become adopted for e2e encryption. Within this perspective it becomes even less sane to rely on CDATA-free XML in XMPP stream parsers. R
