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

Reply via email to