[Standards] JID Escaping

Richard Dobson richard at dobson-i.net
Fri Jul 20 13:32:36 UTC 2007

> It is since you cannot uniquely separate the JID into its 
> node+domain+resource parts.
> You cannot tell which the node part is. In my example
> User JID: mats at home.se/coci at home.se/mats at home.se/coci
> the node part may be: mats\40home.se\2fcoci\40home.se\2fmats
> The problem is escaping both the "@" and "/" and be able to uniquely 
> identify the
> node+domain+resource parts of a JID. I think you can allow to escape 
> either of these characters but not both.

No it wont be like that, JID escaping has absolutely nothing to do with 
how you would parse a JID that a user had entered, according to your 
example and the rules defined in the RFCs you would separate out what 
the user had entered as:

node: mats
domain: home.se
resource: coci at home.se/mats at home.se/coci

I think you are confused as to what the purpose of JID escaping is, you 
do not escape JID's that a user has entered in any way shape or form 
ever, if a JID should have escaping in it then its the user who will 
input the already escaped version, the client should never transform it.

The purpose of JID escaping is so that addresses at things like 
transports (i.e. the msn transport) that have node parts that would not 
normally fit in with JID's in a standard way that can be potensially 
decoded by clients in a meaningful way, i.e. a client might treat MSN 
transport contacts differently in the UI and display just the msn 
address along with an MSN messenger icon next to it (like the multi 
protocol clients), i.e. user at example.com rather than the actual JID 
which is user\40example.com at msn.example.com.


More information about the Standards mailing list