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/[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 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 [EMAIL PROTECTED] will now become
contact&[EMAIL PROTECTED] - causing incompatibilities.
Regards,
Mridul
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
