> To repeat, the loose vs strict approach works as follows: > > Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As > long as the client produces names that are only 3.1, no problem. > Stringprep on the client will produce results that the server accepts. > > Suppose the user has characters that are unassigned in 3.1 (but are in > 4.0). As long as the user (manually) picks lowercase characters (in > the right canonical form), those names will be accepted by the 4.0 > server. While it is not as easy as when the software does it for the > user, it will work for any new characters. > > This is important for another scenario. Client A is on Unicode 4.0, > client B is on Unicode 3.1, and the server is on Unicode 4.0. Client A > namepreps a string, sends to client B. Client B sends the string on to > the server. Everything works. It even works if client B re-namepreps > the string.
The interesting scenario is: Server S is on Nameprep-08 (where a deletion mapping has been introduced for codepoint U+XXXXX), Client A is on Nameprep-07 but his OS supports Unicode 4.0 and its IME generates U+XXXXX. Client A will then pas U+XXXXX unchanged (since it was unassigned when Nameprep-07's tables were generated) and Server S won't find a match, since its stored strings do not have U+XXXXX. Same for case mapping, if that were to happen. The user has no clue what is happening to her. YA
