Hi Peter!
Peter Saint-Andre schrieb:
I think the arguments against this way already have been said. In short:
- We are used to type in full JIDs as a whole for addressing.
We are?!?
I have never seen a Jabber client that expects you to type in a full JID
in order to (say) send someone a message or add someone to your roster.
That's always done based on bare JID ([EMAIL PROTECTED]).
I expect that you anyway understood what I wanted to say. My misstake to
use the term "full JID" which is already defined otherways. With full
JIDs in my sentence above I just refered to "not entering just a
username but a [EMAIL PROTECTED] address".
Therefore
with full escaping (including '@' and '/' ) we get ambiguous addresses.
That is true for full JIDs. But typically these are not shown to the end
user and I have never seen a way for a client to accept these for things
like sending message or roster additions.
Sorry? All clients I tried so far do accept it if you enter a full JID
(now really a full JID) when sending a message.
- [EMAIL PROTECTED] is an allowed JID by XMPP, but somehow
prohibited by JID escaping XEP. It is not very clear how to handle this
when doing unescaping. Not unescaping? Then we need an exception for the
escaping rules again, that when reescaping, this does not have to be
encoded as [EMAIL PROTECTED]
Yes, that case is messy. We added it to XEP-0106 mostly to handle an odd
gateway case for LDAP, not native XMPP addresses. I'm open to removing
it for native addresses.
Again some reason to separate the mapping case from the case where we
want to allow new characters in addresses.
That's why my recommendation is:
- Use XEP-0106 only for gatewaying external identifiers to traditional
JID addresses, but don't to unescaping at any other point then the
gateway again. (Especially not in clients or other user interfaces.)
What would you call the case of re-using an existing identifier (e.g.,
email address) as a JID? Is that "gatewaying"?
No.
- For introducing needed characters in node parts (e.g. the "'" indeed
is a good example what could be needed) find a better and cleaner way to
introduce them.
This is the case for re-using an existing identifier.
Alternatively we could define version 2 of nodeprep so that the desired
characters are allowable.
That's exactly what I proposed in my previous mail. Just with the fact
that I also said, that we need a stream feature, so that servers may
detect which version of nodeprep the other side of the stream where
stanzas are delivered to is using.
I'll formalize this and try to write a XEP proposal.
Matthias
