----- Original Message ----- From: "Dave Crocker" <[EMAIL PROTECTED]> > > The idea of defining something that is a transition, without already having > the the end-point of the transition also defined and in the process of > being deployed is simply not practical. > > When "transition" takes 5 years and more, it is counterproductive to think > of transition as temporary.
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
