Re: [idn] Re: Fwd: Unicode letter ballot

[Soobok Lee <lsb@postel.co.kr>]

On Thu, Nov 28, 2002 at 01:01:48PM +0900, Soobok Lee wrote:
> On Thu, Nov 28, 2002 at 03:12:04AM +0000, Adam M. Costello wrote:
> > 1. The decomposition mappings are changed.
> > 
> >   1b. Stringprep/Nameprep do not track Unicode updates; they remain
> >       frozen at a version containing the old mappings.
> > 
> >       If someone registers a name using a CNS 11643 string, and later
> >       someone tries to look up the name using the very same CNS 11643
> >       string, it will match.  But if a modern normalization operation
> >       gets inserted somewhere (for the heck of it, or because some
> >       other protocol that carries the domain name requires text to be
> >       normalized), it won't match.
> > 
> >       Names using the broken compatibility characters might not be
> >       registered in practice, because the Nameprepped form will look
> >       wrong.
> 
> Maybe. But, i think this is still over-simplified. I will add more sub-cases:
> 
> The compatiblity form has three equivalent forms.
> 0) the compatiblity form itself
> 1) the (falsely) nameprepped form  from  Unicode 3.2 false-NFC
> 2) the desired-and-correct-but-abandoned equivalent form from correct-NFC
> 
> Now,
> 0) can't be registered as itself in any case, 
>    because it is always mapped to something other.
> 1) may be abandoned as you described above because it renders differently
>    than expected when registration time.
> 1) may be, however, registered as un-nameprepped form itself 
>    by other applicants who may occasionally
>    have this 1) name as their biz name.
> 2) may be registered as un-nameprepped form itself 
>    by other applicants who may occasionally
>    have this 2) name as their biz name.

I forgot to add this:

     0) and 2) strings share the same character glyphs (by correct NFC!), 
     but 1)  string does not. Then, when  2) is registerd and end users 
     enter 0) for 2), this will lead to a failure or a wrong site '1)'
     since 1) != 2).

Soobok Lee

> 
> Adam, Could you continue to take your thorough analysis on these sub-cases?
> 
> Soobok Lee
> 
> > 
> >       Since Nameprep never changes again, there is no transition as
> >       software gets upgraded.  Names involving the five characters in
> >       question remain just as broken and undesirable in the far future
> >       as in the near future.  It is likely that these five characters
> >       would never be used in domain names in practice, forever.