On 3/10/08, Justin Karneges <[EMAIL PROTECTED]> wrote: > On Sunday 09 March 2008 5:49 pm, Peter Saint-Andre wrote: > > > > Correct. The spec currently does not say that the server must enforce > > that rule. But naturally the recipient (or the sender's or recipient's > > server) could return a stanza error on receiving it. A <not-acceptable/> > > error seems appropriate: > > > > <message type='error'> > > <error type='modify> > > <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> > > </error> > > <gajim:die/> > > </message> > > > Hmm, you should probably not send the original XML back in this case, since it > is invalid.
The XML here isn't invalid, but so-called namespace-non-well-formed. And it indeed breaks XML parsers, which take into account XMLNS prefixes (which they MAY do according to clarified RFC-3290-bis). > > 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/>). -- Sergei Golovan
