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

Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)



----- Original Message ----- 
From: "Dave Crocker" <dhc@dcrocker.net>
 

> At 08:20 AM 6/17/2002 +0900, Soobok Lee wrote:
> >At least, IETF/ICANN/DoC could issue warnings, since they sit on the top 
> >of the DNS hierarchy.
> >Proposing a half-baked or unimplementable soluion as standards does not 
> >help, since
> >it will be abandoned  and it will be classified as yet another proprietary 
> >solution by industries
> >as long as everyone knows they are just quick fix for registries, not for 
> >all the public.
> 
> 1. You are entitled to your opinion.
> 
> 2. The apparent IETF rough consensus differs from your opinion, markedly.
> 
> 3. Why you believe the technology is unimplementable is a matter of some 
> curiosity.

I18n without proper localization loses usability,interoperability and implementability.
Proposed IDN standards are not adquate for any mission critical use. This argument may be extended to
the IDN concept itself, but not up to the concept of micro-i18n-directory-layer above DNS,
which can deal more easily with approximations ,heuristic suggestion and exception handlings
about extended and open char sets.


> 
> 4, The design principles are very far from half-baked.  In fact they are 
> very well established, with extensive practical history that demonstrates 
> their real, high utility.

I have been not talking about IDNA(ACE) principle, but,
some advocates of UTF8-based solution would argue in that same way against ACE,
because UTF8 use is well established and encouraged in numorous IETF standards.
But,it's clear that even UTF8-based solutions will suffer from the same kind of
l10n and implementability problems as those of IDNA.

> 
> 5. Calling something from the IETF "proprietary" suggests that you also 
> have a definition of proprietary that is at odds with standard industry 
> nomenclature.
> 

The application/OS industries and TLD registries will answer for it by actions.