Sergei Golovan wrote:
> 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.
And I take it you think that's bad, right?
Maybe I agree with you ("simple clients, complex servers"), but I'd like
to hear what other server and client developers think.
Peter
--
Peter Saint-Andre
https://stpeter.im/
