[Standards] summary: allowable characters

Robin Redeker elmex at x-paste.de
Thu Aug 2 22:28:02 UTC 2007

(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.


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

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:


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 :-)


More information about the Standards mailing list