On Tue, Oct 14, 2008 at 3:28 AM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > > OK here's what I have now in my working copy of rfc3920bis: > > *** > > 12.3. Well-Formedness > > There are two varieties of well-formedness: > > o "XML-well-formedness" in accordance with the definition of "well- > formed" in Section 2.1 of [XML]. > o "Namespace-well-formedness" in accordance with the definition of > "namespace-well-formed" in Section 7 of [XML-NAMES]. > > The following rules apply. > > An XMPP entity MUST NOT generate data that is not XML-well-formed. > An XMPP entity MUST NOT accept data that is not XML-well-formed; > instead it MUST return an <xml-not-well-formed/> stream error and > close the stream over which the data was received. > > 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. > > Note: Because these restrictions were underspecified in an earlier > revision of this specification, it is possible that > implementations based on that revision will send data that does > not comply with the restrictions; an entity SHOULD be liberal in > accepting such data. > > *** > >
I think we should understand the consequenses of using SHOULD (and not MUST). > "an entity SHOULD be liberal in accepting such data." This translates to: "an entity SHOULD NOT use a namespace-validating parser (as defined in [XML-NAMES])" This is indeed the case. Entities in the XMPP world tend not to use namespace aware parsers. In fact most do not care about namespaces at all (aside from a few specific cases where the XEPs use a namespace prefix in the examples, the implementations are often coded to look for that prefix). Testing with ejabberd and gajim (quite a popular combination), it was quickly clear that both did not deal with valid <message>s where a prefix was used, and both did deal with <message>s with a namespace other than jabber:client. All implementations must be namespace non-aware if they don't wish to have the disconnection bug that gajim had. I would like to argue that it was not a bug at all. If we are going to allow non-namespace aware servers, then we should remove the reference to [XML-NAMES] (except maybe to specify that this is something which SHOULD NOT be complied to). With non xmlns-aware entities allowed, we might as well remove the illusion of the possibility of using namespaces too. After all, many entities don't care about it, and would very likely show non-compliant behavior if a different namespace is used, or if a prefix is used. At the moment the use of namespaces just causes developers to assume that they can use their own elements with names similar to those used by various RFC/XEP elements with a different namespace. Such use would of course result in incorrect behavior in all non-xmlns-aware entities. If non-xmlns-aware entities are going to be allowed, we should declare that all entities should be so, in order to save everyone from headaches. The behavior when a server receives a badly-namespaced stanza needs to be clarified. I have been working with Matthew Wild on a not-yet-released server. We are wondering whether we should discard the stanza, the element, or raise a stream error. After all, there really is no reason that any (non-malicious) entity should be sending invalid namespaces. If they do then it is a bug, just the same as if they sent invalid XML. Just discarding it has a problem. Someone could send a message with invalid namespaces to a conference.jabber.org room. Everyone (human) would see that, except entities which care about namespaces. From the protocol's perspective this would be "correct", but not from a normal user's perspective. Sorry if this sounds like a rant. I just don't like where we are headed. Waqas.
