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

["Edmon Chung" <edmon@neteka.com>]

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" <tsenglm@cc.ncu.edu.tw>
To: "Soobok Lee" <lsb@postel.co.kr>; "Dave Crocker" <dhc@dcrocker.net>
Cc: "IETF idn working group" <idn@ops.ietf.org>
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
> >
> >
>
>