[Standards] JID Escaping

Peter Saint-Andre stpeter at jabber.org
Mon Jul 30 16:49:05 UTC 2007

Robin Redeker wrote:
> On Fri, Jul 27, 2007 at 02:32:39PM -0600, Peter Saint-Andre wrote:
>> Matthias Wimmer wrote:
>>> Robin Redeker schrieb:
>>>> I propose to rename the XEP to make clear that this escaping/unescaping should
>>>> only happen in very rare cases (only at gateways or heavily specialized client
>>>> frontends). And that the terms 'escaping' and 'unescaping' are replaced by
>>>> 'mapping' and 'unmapping', because thats what is happening here.
>>> +100
>> Well, it's interesting, on the ejabberd list today someone said they
>> have an existing database of 45k email users and they want to offer
>> Jabber services to that user population, but re-use the same usernames.
>> I'm sure they have some users in there with addresses containing
>> characters like single quote, e.g., tim.o'reilly at domain.tld. In which
>> case I bet that they'll be interested in using JID Escaping.
> If they can live with the fact that clients like: psim gajim, kopete,
> pidgin, tkabber, ... http://www.jabber.org/software/clients.shtml
> That clients like those display the guy as tim.o\27reilly at domain.tld.
> And if they can teach their userbase that their JID contains \27 instead
> of '.

Or do what this person is going to do -- prevent people who have ' in
their email address from using Jabber! (Sorry, no address mapping for you!)

>> I really feel that this discussion is not going anywhere. The spec is
>> IMHO pretty clear. If you don't like the spec, don't implement it.
> I _certainly_ won't. But you are aware that you recommend every client
> author to implement XEP-0106? (Hint: http://www.xmpp.org/extensions/xep-0211.html )

Shockingly, I do tend to be aware of what is in the specifications I write.

> XEP-0106 is certainly useful, and noone says it should go away, I would
> just know WHO is supposed to implement it and in WHICH cases.

In a client, the first thing to support is at least to transform the
mapped characters to their unmapped equivalents on receipt. So show \27
as ' and so on. The second thing to support is: if the user attempts to
add a buddy (or register an account etc.) whose JID has a node
identifier containing ' or one of the other prohibited characters,
transform the character to the mapped equivalent; alternatively, the
client could reject the attempt ("sorry, those characters are
disallowed") since that is what clients do now -- be conservative in
what you send, liberal in what you accept.

It is possible that a server could perform the mapping as well,
depending on the authentication mechanisms in use. E.g., let's say that
at a certain deployment, the user's authzid is derived from the email
address in the user's X.509 certificate or LDAP record. In this case, if
the user's email address is tim.o'reilly at example.com then the server
would specify the user's JID as tim.o\27reilly at example.com.

Would it help to clarify this handling further in the spec?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070730/5a5176ae/attachment.bin>

More information about the Standards mailing list