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:\[email protected] 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\[email protected] On the other end this is unescaped to: c:\[email protected] You are correct that escaping of '\' to '5c' in this example is wrong. The same is true of examples 10 and 11: c:\\[email protected] => c\3a\\[email protected] c:\cool [email protected] => c\3a\cool\[email protected] However, in example 12 we have the following user input: c:\[email protected] 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:\[email protected] 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\[email protected] The recipient would then unescape that to: c:\[email protected] 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/
smime.p7s
Description: S/MIME Cryptographic Signature
