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: [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/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: [EMAIL PROTECTED]/[EMAIL PROTECTED]/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. [EMAIL PROTECTED] rather than the actual JID
which is [EMAIL PROTECTED]
Richard
