[Standards] JID Escaping
Richard Dobson
richard at dobson-i.net
Fri Jul 20 08:32:36 CDT 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.
Richard
More information about the Standards
mailing list