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/[EMAIL PROTECTED] and domain/[EMAIL PROTECTED] cant be differentiated if > / is > allowed.
Interesting, I think you're right. Consider "foo.com/[EMAIL PROTECTED]", 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 "[EMAIL PROTECTED]". 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. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
