[Standards] summary: allowable characters

Peter Saint-Andre stpeter at jabber.org
Thu Aug 2 18:53:09 UTC 2007

Mridul Muralidharan wrote:
> Peter Saint-Andre wrote:
>> 4. One solution would be to define version 2 of nodeprep in rfc3920bis.
>> As far as I can see, nodeprep2 would allow " & ' < > since those can be
>> escaped in XML (e.g., XMPP 'to' address) as the predefined entities
>> " & ' < >. I'm not sure why : was prohibited in the
>> first place so that would be allowed. I suppose / was prohibited because
>> it's used later in a full JID to differentiate the resource identifier,
>> but in a node identifier I don't think it would be confusing so that
>> would be allowed. 
> user/id at domain and domain/res at restofres cant be differentiated if / is
> allowed.

Interesting, I think you're right. Consider "foo.com/bar at jabber.org", it
could be the bare JID of a user "foo.com/bar" at jabber.org or a domain
of foo.com with a resource of "bar at jabber.org". Not good.

> Btw, changing nodeprep now will cause quite a lot of problem with
> existing deployments - since the contact jid's are part of the user data
> - and would pretty much mean we cant adopt bis spec.

What specifically breaks? Does it depend on which characters would be
allowed in nodeprep2? I agree that / and @ are problematic, but the
characters " & ' < > seem less so. But I may be missing something.

> The number of deployments with these usecases are not as specialized as
> it might seem.

I agree with that. Which is why I stand by XEP-0106. In part I think
that those who are so opposed to XEP-0106 are not familiar with the
deployment issues. But I agree that XEP-0106 needs to be clarified in
the ways we discussed recently. It's on my list to complete those
clarifications and post an interim version.


-------------- 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/20070802/106321ef/attachment.bin>

More information about the Standards mailing list