On Monday 10 March 2008 2:01 am, Sergei Golovan wrote: > On 3/10/08, Justin Karneges <[EMAIL PROTECTED]> wrote: > > Further, since some XML parsers throw error when an unrecognized prefix > > is encountered, those clients/servers would most likely respond not with > > a stanza error, but with an xml-not-well-formed *stream* error and close > > the connection. > > > > I think we have to be very careful about how this stuff is routed. > > Obviously clients shouldn't be generating invalid XML, but servers > > shouldn't be routing it either. A good server would disconnect whoever > > sent gajim:die rather than routing it and DoS'ing other clients. > > I would like to see (probably in a separate section) rules for closing > streams like the following: > > 1) If an entity sends non-well-formed XML as defined in > http://www.w3.org/TR/2006/REC-xml-20060816 then the receiving entity > MUST close the stream and return xml-not-well-formed error. > > 2) If an entity sends namespace-non-well-formed XML as defined in > http://www.w3.org/TR/REC-xml-names then the receiving entity MUST > close the stream and return xml-not-well-formed error (or may be it's > better to introduce a separate error for this case). > > 3) IF an entity defines XMLNS prefix in a stream header and use it in > a stanza (which means that the stanza isn't routable as is) then the > receiving entity MAY close the stream and return xml-non-well-formed > error, but SHOULD move namespace definition to a stanza level (or > convert namespace prefix into xmlns attribute) and process the stanza. > > (The third rule is arguable though.) These rules ensure > namespace-well-formedness of XMPP streams, and no custom XML parsers > will be necessary to parse XMPP streams. Currently, general XML > parsers either ignore namespace prefixes at all (which means that > clients using them will loose some data) or break on unbound prefixes > (which means disconnections on <gajim:die/>).
+1 -Justin
