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

Dear  Soobok:
                     Your good suggestion reflects some exised facts and it
is very interesting.
                     The directory-for-8bit-query approach is currently used
in .CC , .NU, .TW . It is independent
on 8 bit or ASCII . The 8 bit approach is based on UTF-8 resolver  of  Win2k
OS . After the "*"  "match to any others" ,  The simulated  UTF-8 NS server
or a redirected  A RR web server can  redirect the client to get an ACE
name to do regular resolving .  By the PUNY code or RACE code approach , the
nameprep are solved in the simulated DNS server side.  Always, it is out of
scope in this working group to discuss  equivalence comparison of non-ASCII
code point, so it is a local issue based on TLD . This approach only work
for a DNS subtree .
                     Even it is safe without new plug-in to client , but
there are some other problems. One is that  need more effort on web proxy
servers to treat native to UTF-8 conversion . Another  important
interoperability protocol issue is the virtual host of web page , that is
how to pass what kind of identifier (native , utf-8 , ACE or others) to let
a web server to act as the "virtual host" of web page and  will guide the
client  re-direct to the target web page.

L.M.Tseng
> The directory-for-8bit-query approach for IDN need not be declared as
"transitional",
> rather may be independant one which may be later obsoleted smoothly by
"new class" solution.
> Non-ASCII octets in "IN" class  has no defined comparison rules and that
opens
> rooms and rationales for per-registry comparison rules that can be
implementable only in
> a directory approach.
>
> Each TLD registry can decide which one it deploy among "directory"
approach, "new class", or both.
> Both can coexist for two differnt audiences with/without "new class"
supports,respectively, IMO.
> Please correct me if it is impossible or problematic.
>
> Such directory approach allows each TLD registries to adopt its own
comparison rules, thus
> non-monolithic normalization rules and works better in dealing with
charset interoperability
> and look-similar/identical character problems. Such rules or experiences
would be implementable
> as multiple registrations or normalization rules in "new class" IDN in the
future
> when  stringprep,UNICODE and local charset standards become mature and
stablized.
>
> Most TLD registries feel strongly the need to add  native labels in *both*
UTF8 and local charsets,
> because existing applications  blindly  make 8bit queries. If those
queries are not served,
> end users experience failures. Current ACE architecture requries every end
user to install
> IDN-plugins to enjoy IDN  safely, but that is not the one that end users
and registries
> desperately need "right now". The directory approach can fulfill these
needs clealy and safely.
>
> Soobok Lee
>
>