Waqas wrote: > On Mon, Oct 20, 2008 at 9:01 PM, Dave Cridland <[EMAIL PROTECTED]> wrote: > >> If you receive invalid XMLNS, however, it might have come from anywhere, and >> merely been forwarded on to you. ANd there's at least three ways of handling >> it. >> >> a) Assume that undeclared prefixes are bound to an arbitrary "unknown" >> namespace. (This is what Gajim does, now). From there, process the stanza as >> much as is possible, which might include doing nothing at all, or rejecting >> it with <service-unavailable/>, just as with any other unrecognized >> namespace. >> >> b) Detect unbound namespaces as a special case, and bounce the stanza. >> >> c) Emit a stream error. This is what Gajim did previously, and what you're >> recommending everyone does. >> > > I am NOT suggesting everyone does that, or should do that. I'm saying > everyone tends to do that because server implementations (e.g., > ejabberd) do not conform to [XML-NAMES]. > > [XML-NAMES] does say "To conform to this specification, a processor > MUST report violations of namespace well-formedness", and parsers I > have tested with all seem to interpret that as a required fatal error.
For our purposes, does it need to be a fatal error instead of a warning, or (that is) a stream error instead of a stanza error? >>> 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. >> And this will have exactly the same effect with any of the above solutions, >> unless one is mandated. And the interesting thing is if a server passes >> through - as existing servers do, essentially doing (a) - and the clients >> all do (c). >> >> Because then, sending invalid XMLNS via a chat room kicks out all the users, >> and this doesn't seem to be appreciated. Believe me, we've see it in the jdev room (not everyone gets kicked, but it's still a selective DoS). > Yep, and while servers should indeed support this until the majority > of servers are namespace aware, this should be considered a bug, and > not legitimized by the spec. I tend to agree, but I'm also sympathetic to concerns about whether this can be implemented reasonably. >>> Sorry if this sounds like a rant. I just don't like where we are headed. >> I don't like where we are. I don't like where some people want us to go, >> because they seem to want to send us off into a fantasy land, where servers >> are redeployed in seconds. >> > > I understand this. But I do think that we should be stricter in the > long term. What you are suggesting (and did in Gajim) is basically a > hack. Something which needed to be done to cope with xmlns-unaware > servers. All client developers should roll their own XMLNS processing > code? They do, but they shouldn't have had to. I just don't think we > should legitimize a hack. > > What I'm saying is that yes, we do need to support the existing > deployments, but their (IMHO) incorrect behavior should be declared as > non-conforming. Right, and that's what the text I proposed (mostly) does. BTW, "where we are" is really a function of jabberd 1.x, which in 2004 (not sure about now) was not namespace-aware or namespace-correct in conformance with XML-NAMES, so we just punted and said it was OK to be out of compliance with XML-NAMES. Perhaps not such a good precedent, but we didn't want to break backwards-compatibility at the time -- in fact that was an explicit goal of the XMPP WG. >> Dave. >> -- >> Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] >> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ >> - http://dave.cridland.net/ >> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >> > > I understand developers today simply have to accept this non-XML-NAMES > conforming XML. But let's not force the developers writing clients in > 2015 to face the same problems. I think most would agree that that > would be pretty sad. Indeed. > Please understand that even if we use MUST instead of SHOULD with > respect to namespace-awareness, the existing servers are not going to > be left behind. Newer servers and server versions are still going to > continue to support their legacy counterparts. The benefit of course > would be that eventually we will have a sterilized network, where > clients wouldn't need to worry about rolling out their own > (non-conforming) namespace handling. In my opinion this is a better > long term direction. I too think that is a worthy goal. The question is: how can we get there in a reasonable fashion? Peter
