[Standards] summary: allowable characters

Mridul Muralidharan mridul at sun.com
Thu Aug 2 21:23:14 UTC 2007

Hi Peter,

Peter Saint-Andre wrote:
> 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 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.


>> 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.
> /psa

More information about the Standards mailing list