On 03/10/2008 10:44 AM, Justin Karneges wrote: > 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).
Thanks to Sergei for the suggestions. I've added a section on well-formedness to rfc3920bis and I have included these two rules. The section reads as follows in my working copy: A XMPP entity MUST NOT accept XML data from another entity if that data is not well-formed in accordance with both the definition of "well-formed" in Section 2.1 of [XML] and the definition of "namespace-well-formed" in Section 7 of [XML‑NAMES]. If an XMPP entity receives XML data that is not so well-formed, it MUST return an <xml-not-well-formed/> stream error and close the stream over which the data was sent. >> 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.) Yes I think this is quite arguable. This would require the receiving entity to remember all prefixes and apply them as necessary, which seems like an unnecessary burden. Our existing text from the "Extended Namespaces" section says: An implementation SHOULD NOT generate namespace prefixes for elements qualified by content (as opposed to stream) namespaces other than the default namespace. However, if included, the namespace declarations for those prefixes MUST be included on the stanza root or a child thereof, not at the level of the stream element (this helps to ensure that any such namespace declaration is routed and delivered with the stanza, instead of assumed from the stream). >> 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/>). That is a laudable goal. Do you think we achieve the goal with the well-formedness text above, plus the existing rule regarding extended namespaces? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] _______________________________________________
