[Standards] JID Escaping
mridul at sun.com
Mon Jul 30 20:37:02 UTC 2007
Peter Saint-Andre wrote:
> Mridul Muralidharan wrote:
>> IMO, (un)escaping should only be done by the entities which need to do
>> so - we should not mix a routing construct with display.
> Sure. We never mess with the routing. From the client perspective,
> XEP-0106 is only for display purposes.
From a routing/resolution point of view, this xep makes a lot of sense.
There are much better and more unambiguous ways to handle display
problem - nick, roster, jud, etc.
>> A client wishing to display contact should not use this xep - there are
>> better ways to obtain what is to be displayed, and unescaping node is
>> not the right way to go about showing 'who' the contact is.
>> The only real usecase I can see with this xep from clients point of view
>> is to construct a jid for authorization when the node would otherwise
>> contain prohibited characters.
> If XEP-0106 support were in all the clients, you could tell other people
> that your JID is "tim.o'reilly at jabber.org" or whatever and things would
> "just work". The problem is that JID (node) escaping support is not in
> all the clients. :)
Allowing what is described above is going to hit too many edgecases
where things cant be handled properly.
For example, [user at id vs user\40id vs user\40id at defdomain vs
user at id@defdomain], etc .
It would be preferable to keep both the aspects separate and stop trying
to use this xep for display purpose. It cant do a good job of it anyway.
>> For the server, this xep is required since its user population could
>> include users which have these prohibited characters in the uid .. and
>> so requires it to identify the backend user (hence need to standardize)
> Well it's really required only if you have customers who want to port
> existing UserIDs (e.g., email addresses) to JIDs.
Unfortunately, this is a very frequent deployment.
It is not that is only mailid which has this issue - there are also SSO
mechanism of form uid at realm.
>> From a gateway's point of view - even if there is some other encoding
>> (urlencoding, etc), it does not matter - the rest of the system does not
>> depend on how the gateway encodes or decodes - ofcourse it helps to
>> standardize so that implementations dont end up with illegal nodes.
More information about the Standards