[Standards] JID Escaping

Peter Saint-Andre stpeter at jabber.org
Mon Jul 30 22:32:33 UTC 2007

Mridul Muralidharan wrote:
> Peter Saint-Andre wrote:
>> Mridul Muralidharan wrote:

>>> For the server, this xep is required since its user population could
>>> include users which have these prohibited characters in the uid .. and
>>> so requires it to identify the backend user (hence need to standardize)
>> Well it's really required only if you have customers who want to port
>> existing UserIDs (e.g., email addresses) to JIDs.
> Unfortunately, this is a very frequent deployment.

Personally I think this is fortunate -- organizations are rolling out
Jabber services to their large installed base of email users. Let's ask
ourselves how we can make that easier. Enabling those organizations to
map existing userids to JIDs makes sense. Saying "you can't re-use
existing userids so some of your users will need to have different
addresses or not use Jabber at all" makes no sense.

Email allows the following characters that are disallowed in JIDs (by
which I mean local-part of email address and node identifier portion of


So IMHO the focus should be on those characters (the same mapping
applies to SIP addresses, which might be re-used in the same way that
email addresses are re-used, though I see that as less likely).

And again I ask, is that "gatewaying" or the automated construction of a
native XMPP address from an existing userid? I don't know that it makes
much of a difference really, but to me gatewaying is for exchange of
messages between different communication systems, not pure address
mapping to re-use userids.

> It is not that is only mailid which has this issue - there are also SSO
> mechanism of form uid at realm.

But is uid at realm going to be re-used as an XMPP node identifier?

-------------- 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/66011de8/attachment.bin>

More information about the Standards mailing list