[Standards] summary: allowable characters

Mridul Muralidharan mridul at sun.com
Thu Aug 2 22:59:15 UTC 2007

Just mentioning a basic problem which was discussed at jdev.

If two 1.0 server move to 1.1, all the 'older' 1.0 jid's will become 
unroutable - which are present in user roster/affiliations/privacylists/etc.


Robin Redeker wrote:
> (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 contact\26id at domain will now become
>>> contact&id at domain - causing incompatibilities.
>> Well we're having a looooong discussion about this in the jdev room
>> right now:
>> http://www.jabber.org/muc-logs/jdev@conference.jabber.org/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
> contact\26id at domain 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 contact\26id at domain and also some jabberd2 servers allow
> authentication as contact\26id at domain 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 stpeter\20 at jabber.org 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 stpeter\20 at jabber.org 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 stpeter\20 at jabber.org. 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 stpeter\20 at jabber.org is a JID from the
> pre-1.1 times, he can assume that stpeter\20 at jabber.org 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 ' stpeter at jabber.org' can register if no
> '\20stpeter at jabber.org' existed before (he knows that from his
> database with the marks of old JIDs).
> If ' stpeter at jabber.org' now wants to talk with 'elmex at chrome.pl', it
> would look like this:
>    <message from=" stpeter at jabber.org" to="elmex at chrome.pl" />
> 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="\20stpeter at jabber.org" to="elmex at chrome.pl" />
> In elmex at chrome.pl's client will now popup a message from
> "\20stpeter at jabber.org" and except some weird JID he can talk with him.
> Because if he sends a message back:
>    <message from="elmex at chrome.pl" to="\20stpeter at jabber.org" />
> Then jabber.org will unescape the to-field and deliver the message to
> ' stpeter at jabber.org'.
> 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 ' stpeter at jabber.org', 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 ' stpeter at jabber.org' 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. elmex at chrome.pl got a new client, fancy new
> tkabber with 1.1 support. Now he enters ' stpeter at jabber.org' 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 ' stpeter at jabber.org' when
> sending it to a 1.0 server.
> 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/jdev@conference.jabber.org/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
> ' stpeter at jabber.org' to talk with people on 1.0 servers. I'm just a
> client developer :-)
> Robin

More information about the Standards mailing list