[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [idn] stringprep comment 1



At 1:02 PM -0800 2/1/02, Yves Arrouye wrote:
>  > At 9:56 AM -0800 2/1/02, Yves Arrouye wrote:
>>  >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.
>>
>>  That scenario will happen, and it is *supposed* to happen. It is
>>  identical to if Nameprep-08 mapped U+XXXX to U+XYZX. The client must
>>  not get a positive response to a query that includes characters that
>>  are not allowed in the version on the authoritative server.
>
>But they *are* allowed because the Server S uses Nameprep-08!

I'm misunderstanding your scenario then. You said in nameprep-08, 
character U+XXXX has a "deleting mapping". I understood that as 
"character U+XXXX is now assigned but is prohibited". If that's not 
what you meant, please help me.

>No this one is a specific critic of IDN breaking the existing DNS "matching
>must be case insensitive rule." If it is not must (MUST) then maybe it's not
>an issue.

There is no such rule: there is a strong attempt. The Turkish dotless 
I is an example of where the attempt will inherently fail in one case 
or the other.

--Paul Hoffman, Director
--Internet Mail Consortium