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

Re: [idn] Mapping and Prohibit of code points



Dear Patrik Fältström :
                  Sorry , the previous mail has a lot of spelling error.
>
> What you really talk about (I think) is how to handle the IDN solution as
> soon as possible, before applications have support for IDNA. And, your

            I  think there are some mistake in here.  About  JAN  2000 ,
one company come to Taiwan and announced they supply  ML-gTLD  "公司"
(chinese name of .com) registration and  it will be a IETF and ICANN
standard in near furture .  The worst , this company also announced they
also supply ML-ccTLD "台灣" (chinese name of  TW) .  We find this company
used the client solution to transform ML to ASCII string and append a domain
to it.  That is one of the technology will cause infringement.
           The customer of  TWNIC is very worry about their  chinese domain
name will be lose . Since  the registrant registered their name  with both
chinese full company name and  LDH domain name in paper form, so I suggest
TWNIC should  put the chinese company name as the domain name by  this form
ML.ML-com.tw  to show to  them that  their name is under best protection of
our NIC.  We will wait the true standard to be approved  then support them
too.  Our NIC does not prefer any approach to work as an IDN solution.
           After that experimental testbed , we find TC/SC problems, so we
keep all attention to this troubles come from UNICODE.  So, we have the
draft about UNAME that basically describe the ACE identifier is necessary,
especially in TC/SC  browser to cross visting another SC/TC web server.

> proposal is to store whatever garbage the applications will send over the
> network in the DNS servers in the encoding the clients happens to use.
This
> implies BIG5, UTF-8 encoded non-nameprepped Unicode, ISO-8859-1 and many
> other charsets.
>
           The experimental testbed is restrict to chinese character only
and testing before the nameprep propasal. Actually, the testing registration
do not allow  any  full width ASCII ,  so the problems of  nameprep is
mapped out in registration phase .  We keep only chinese character name and
still wait a world-wide  IDN solution to update.

> That should _NOT_ be done, as there is no way of discovering what charset
> is used, and this will because of this lead to explicit domain name
> infridgement which in turn is treated as trademark infringement.
>
           My  personal  Virtual DNS server is based on the registered
record to do code conversion and present the  equivalence  name to client,
it is a combined module of BIND DNS and  transliteral code-converter to do
it. If the zone record is legal in a DNS , the transliteral conversion of
name label is the same as the (nameprep + Punycode) doing in client .  The
DNS tree has strong  authorized tree relation check , so it is better than
the client  solution to avoid  infringement by domain name appending .  As I
know , there are still a lot of client side ACE solution to replace  a
ML-COM(chinese name  of .com) and append a ascii-domain name to re-direct it
.  I  just trust  the BIND DNS  software maintener has more experience in
SERVER than client to avoid infringement.  May be it is not true .  But I
must be say IDNA have good potential, because it has one powerful tool-
mult-case Punycode.

L.M.Tseng