[Standards] Some issues in XEP-0106: JID Escaping

Peter Saint-Andre stpeter at stpeter.im
Mon Feb 15 16:32:33 UTC 2010


On 2/13/10 1:42 PM, Waqas Hussain wrote:
> Guus der Kinderen
> <http://jabber.markmail.org/message/kihf36azo2kvmczf?q=guus> pointed out
> some problems in XEP-0106 in the JDev chatroom.
> 
> Section 1. of the XEP lists nine code points which are forbidden in a
> node identifier. The character '\' is not in that list, and is used as
> the escape character in the algorithms described in the XEP.
> 
> Section 4.3 states:
> 
>     "In order to maintain as much backward compatibility as possible,
>     partial escape sequences and escape sequences corresponding to
>     characters not on the list of disallowed characters MUST be ignored."

EXCEPT as described under the business rules. There is a special case
for '\5c'.

> The sequence '\5c' (corresponding to the character '\') as input to the
> escaping algorithm needs to be escaped. But it isn't a partial escape
> sequence, and it doesn't correspond to a disallowed character, so the
> above text dictates that it not be escaped. 

Please read the text in context.

> This breaks the algorithm. 

There is a special case.

The first paragraph of section 4.3 currently reads:

In order to maintain as much backward compatibility as possible, partial
escape sequences and escape sequences corresponding to characters not on
the list of disallowed characters MUST be ignored.

Instead it should read:

In order to maintain as much backward compatibility as possible, partial
escape sequences and escape sequences corresponding to characters not on
the list of disallowed characters MUST be ignored (with the exception of
the escaping character '\' itself when the source address includes the
sequence '\5c').

> A
> possible correction is to refer to the mapping in tables 1 or 2, instead
> of the list of disallowed characters.

Tables 1 and 2 already refer to escaping, not disallowed characters.
What am I missing?

> In section 5.1, table 3, the last four examples 9, 10, 11 and 12 do not
> follow section 4.3 exceptions. The '\' characters in those examples MUST
> not be escaped, according to section 4.3. Example 12 in that list would
> be correct with the above suggested correction to section 4.3.

Unfortunately you are right that three (not four) of the examples
contain errors. Let's go over them...

In example 9, the user input is:

c:\net at example.com

But : is disallowed, so it needs to be escaped to '\3a'. However, '\' is
not disallowed and does not prepend the sequence 5c so it does not need
to be escaped here.

Therefore we escape to:

c\3anet at example.com

On the other end this is unescaped to:

c:\net at example.com

You are correct that escaping of '\' to '5c' in this example is wrong.

The same is true of examples 10 and 11:

c:\\net at example.com => c\3a\\net at example.com
c:\cool stuff at example.com => c\3a\cool\20stuff at example.com

However, in example 12 we have the following user input:

c:\5commas at example.com

Here the source address contains '\5c'. If this sequence were not
escaped for sending over the wire, on the receiving end this would be
unescaped to:

c:\ommas at example.com

Clearly that is not the desired functionality. So we need to escape '\'
here since it is followed by '5c'; thus the JID on the wire will be:

c\3a\5c5commas at example.com

The recipient would then unescape that to:

c:\5commas at example.com

My apologies for the errors. I'd like to double-check this with my
co-author before making any changes to the spec.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100215/1875bf3a/attachment.bin>


More information about the Standards mailing list