You could add .bz and .tv to the list of TLDs that allow 8bit query, although we do not use a redirection service but utilizes a dynamic CNAME mechanism to provider the requesting application with an ACE domain so the delegated host can host the domain with only the ACE RR. Edmon
----- Original Message ----- From: "tsenglm@計網中心.中大.tw" <[EMAIL PROTECTED]> To: "Soobok Lee" <[EMAIL PROTECTED]>; "Dave Crocker" <[EMAIL PROTECTED]> Cc: "IETF idn working group" <[EMAIL PROTECTED]> Sent: Monday, June 24, 2002 6:57 AM Subject: Re: [idn] 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 > > > > > >
