Re: [idn] IDN biting off more than it can chew

[liana Ye <liana.ydisg@juno.com>]

Dan, 
  While I don't think IDN biting off more than it can chew,
I do agree what you have said: 

> If, on the other hand, applications don't do any conversion, and
> registrars prohibit the bad characters, then the bad characters 
> simply
> won't work. There will be only one way to type a domain name. If 
> this
> turns out to be a mistake, we can change it later, without breaking
> anything. This is the simple, clean, conservative approach.

This is the reason that all the Chinese character processing 
systems like to use tables instead of conversion precedures 
discussed in [UAX15], no matter they are in applicantions or on 
servers.   This is to say that [UAX15] principles can 
be embedded in a table and applies to all combination 
characters.  

This is also agreement to say to let minimum numbers of IDN
identifiers in for testing IDN architechture before we expand 
them to all UCS codepoints.

Liana


On 25 Nov 2001 06:40:07 -0000 "D. J. Bernstein" <djb@cr.yp.to> writes:
> John C Klensin writes:
> > Absolutely.  And, if we get it seriously wrong, the DNS becomes
> > ambiguous and unmanageable, and we have no way back.  Hence,
> > conservatism is in order, IMO.
> 
> This is one of the reasons that programs shouldn't do nameprep.
> 
> Suppose we teach applications these horribly complicated 
> rules---rules
> in which we're still finding major errors---for converting bad 
> strings
> to good strings. Suppose it turns out that this was a huge mistake: 
> for
> example, users are constantly confusing uppercase Beta with 
> uppercase B.
> 
> We'll never be able to get rid of the conversion. We'll be stuck 
> with it
> for compatibility, just as we're stuck with treating uppercase ASCII 
> as
> equivalent to lowercase ASCII today.
> 
> If, on the other hand, applications don't do any conversion, and
> registrars prohibit the bad characters, then the bad characters 
> simply
> won't work. There will be only one way to type a domain name. If 
> this
> turns out to be a mistake, we can change it later, without breaking
> anything. This is the simple, clean, conservative approach.
> 
> ---Dan
>