(Warning, long mail ahead! Get a coffee and some time first :-) On Thu, Aug 02, 2007 at 03:34:30PM -0600, Peter Saint-Andre wrote: > Mridul Muralidharan wrote: > > The problem essentially is that any place where we have a JID persisted > > in the backend (user roster, acl's, affiliations, privacy lists/block > > lists, etc), it will become incompatible change. > > For example, what used to be [EMAIL PROTECTED] will now become > > contact&[EMAIL PROTECTED] - causing incompatibilities. > > Well we're having a looooong discussion about this in the jdev room > right now: > > http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-02.html > > I volunteer elmex for posting a summary once we're done. :)
Yes, basically Mridul is completly right, we can't do much about the already deployed backslashes in JIDs. Especially in 1.0 server rosters. But... First we have to wonder whethere there are actually people with [EMAIL PROTECTED] in their roster, as registering a JID with a \ in the username is a considerable problem with XMPP 1.0 servers with SASL and DIGEST-MD5 (see some older message from me in the JID escaping thread). Of course that should be further investigaged as old-style IQ auth works with [EMAIL PROTECTED] and also some jabberd2 servers allow authentication as [EMAIL PROTECTED] without problems. But there exists a possibility to migrate our old JIDs to the 1.1 world and staying interoperable with 1.0 servers: First: A 1.1 server that is going to communicate with 1.0 server will escape the JIDs from his userbase when he SENDS to a 1.0 entity. Escaping can be performed as described in XEP-0106 (after dropping the silly \20 escaping rule). That will work great if the 1.1 server has NO old userbase. If we have for example jabber.org, a large userbase, and there is actually [EMAIL PROTECTED] as registered user in. And we want to upgrade to a 1.1 server then we will run into the problems Mridul pointed out: 1.0 servers have [EMAIL PROTECTED] in their roster, and if we have now 'stpeter @jabber.org' registering a new account he will collide with that, because his JID will be escaped to the in the 1.0 servers roster existing [EMAIL PROTECTED] Bang, we got a collision. There exists no real easy way to prevent that except just not allowing 'stpeter @jabber.org' to register. To detect a case like this, that a new user with a colliding JID registers, the 1.1 server needs to keep track of the old JIDs in his database. If the 1.1 server knows that [EMAIL PROTECTED] is a JID from the pre-1.1 times, he can assume that [EMAIL PROTECTED] is already in some rosters out there. So he MUST NOT allow anyone who might collide with that to register at jabber.org after the migration to 1.1. So when upgrading jabber.org could just mark all JIDs with a \ in their name to be a pre-1.1 JID and disallow anyone to register who might collide with one of the registered JIDs. This way ' [EMAIL PROTECTED]' can register if no '[EMAIL PROTECTED]' existed before (he knows that from his database with the marks of old JIDs). If ' [EMAIL PROTECTED]' now wants to talk with '[EMAIL PROTECTED]', it would look like this: <message from=" [EMAIL PROTECTED]" to="[EMAIL PROTECTED]" /> As jabber.org (1.1) knows that chrome.pl (1.0) is in fact 1.0 he escapes like XEP-0106 recommends and sends actually: <message from="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]" /> In [EMAIL PROTECTED]'s client will now popup a message from "[EMAIL PROTECTED]" and except some weird JID he can talk with him. Because if he sends a message back: <message from="[EMAIL PROTECTED]" to="[EMAIL PROTECTED]" /> Then jabber.org will unescape the to-field and deliver the message to ' [EMAIL PROTECTED]'. Of course this solution is not a perfect one for the end-users as I will describe below, but I argue that the incompatibilities will increase the pressure on developers a bit and on administrators to adapt XMPP 1.1. And thus that might speed up the migration while providing a compatibility-workaround for maybr 98-99% of the cases, or maybe even 99,9999% (this needs to be investigated a big IMO, maybe my assumptions are completly wrong). So much for the server-to-server interoperability. ======================================== Now about 1.1 clients and 1.0 clients. 1.0 clients will have no way to reach ' [EMAIL PROTECTED]', which is fine, either the user knows that guy's JID needs to be escaped because he uses an old client, or he has to upgrade to a client with 1.1 capabilities (what this means is described below). Not being able to send a message to ' [EMAIL PROTECTED]' will increase the pressure on the client developers as stated above. So 1.0 clients are basically out of luck if the user don't know how to escape, however, tell em: "get a new client". Of course it's blunt to say that, but I guess we can assume that not our WHOLE old userbase without spaces and all those fancy characters in their JID are NOT GOING TO signup a new account. So the users with spaces and & or whatever in their JID will probably come as slow as the XMPP world migrates to 1.1, and thus not experience any weird things. Lets assume now our guy, eg. [EMAIL PROTECTED] got a new client, fancy new tkabber with 1.1 support. Now he enters ' [EMAIL PROTECTED]' in the client and wants to send that. Now we assume that chrome.pl is still version 1.0. Ok. Our 1.1 client has to escape (back to JID escaping in clients here, eh? :-). Ok, our client escapes the user entered JID ' [EMAIL PROTECTED]' when sending it to a 1.0 server. Please note here that there MUST NOT BE ANY ESCAPING PERFORMED BETWEEN 1.1 ENTITIES (that means servers AND clients). Escaping should ONLY HAPPEN on the border between a 1.1 entity and a 1.0 entity. Such borders are 1.1 <-> 1.0 server2server connections and 1.1 <-> 1.0 client2server or server2client connections. Also note that a 1.1 server speaking with a 1.0 client ALSO has to perform escaping! ======================================== Phew, I hope you got the idea :-) And with this all being said I want to point out again that this all is only really going to work in the realworld out there if servers that migrate their userbase perform the "do we already have a pre-1.1 JID with \ in their nodepart in our database and is it possible he is in some roster out there?"-check and do not allow accounts with eg. spaces (or whatever new characters we are going to allow in the nodepart) to be created after the 1.1 change. If you are interested in further discussion of this topic I also want to point out the past discussion which lead to this mail in the jdev@ room: http://www.jabber.org/muc-logs/[EMAIL PROTECTED]/2007-08-02.html#15:07:48 It might show you how this idea evolved and maybe prevents unneccessary misunderstandings in further discussions :-) Tomasz Sterna (smoku) pointed out that he as jabberd2 developer would consider this compatibility-escaping-with-xep-106 as unneccessary :-) And I strongly recommend to talk with the server developers and admins about the consideration of a 1.1<->1.0 interoperability spec. Maybe it's good enough to not do any escaping and just don't allow ' [EMAIL PROTECTED]' to talk with people on 1.0 servers. I'm just a client developer :-) Robin
