[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
>> >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,
>> >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
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