On Tue, Oct 14, 2008 at 2:28 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > OK here's what I have now in my working copy of rfc3920bis: > An XMPP entity MUST NOT generate data that is not namespace-well- > formed. An XMPP server SHOULD NOT route or deliver data that is not
Unfortunately, this 'SHOULD' doesn't solve the problem which I think is one of the main current issue with XMPP - to parse XMPP you have to use non-standard XML parser. Because buggy client (or malicious user) certainly will generate not namespace-well-formed XML, and some servers will route it to all clients. So, to write your own client or component you have to write own XML parser also. And this seems ridiculous to me. BTW, two ejabberd developers (ejabberd is a server which happily routes stanzas with unbound prefixes, and doesn't understand any XMLNS prefix other than 'stream') have chatted tomorrow morning and said the following: <zinid> An XMPP entity MUST NOT generate data that is not namespace-well- formed. An XMPP server SHOULD NOT route or deliver data that is not namespace-well-formed, but MUST NOT return a stream error in response to the receipt of such data. <zinid> вот что будет в bis <aleksey> т.е. можно ничо не трогать <zinid> ну получается так Which means: <zinid> this text will be in bis <aleksey> so, we don't have to change anything <zinid> it appears so So, I think that the proposed change just clarified a bit that it's a client responsibility to work with non-xmlns-well-formed XML. Cheers! -- Sergei Golovan
