[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Re: Fwd: Unicode letter ballot
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.
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.