[Standards] JID Escaping

Mridul Muralidharan 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.
> 
> Probably.
> 
> 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.


Regards,
Mridul

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




More information about the Standards mailing list