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

[no subject]



Thu, 7 Feb 2002 11:22:28 +0800 (CST)
Message-ID: <3C61F493.FAA13198@iis.sinica.edu.tw>
Date: Thu, 07 Feb 2002 11:29:23 +0800
From: hoho <hoho@iis.sinica.edu.tw>
X-Mailer: Mozilla 4.51 [zh-tw] (Win98; U)
X-Accept-Language: zh-tw
MIME-Version: 1.0
To: Dave Crocker <dhc@dcrocker.net>
CC: Erin Chen <erin@twnic.net.tw>, IESG <iesg@ietf.org>, IAB
<iab@isi.edu>,
   IETF IDN WG <idn@ops.ietf.org>,
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
References: <5.1.0.14.2.20020201084837.01caad88@127.0.0.1>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk

[Note: header field too long; To & Cc field trim - JS]

Dear Dave,

I understand that you are only interested in extending the range of
domain
names beyond ASCII and are not interested in solving either TC/SC or the
CJK variants problem. We are not asking you to do that either. Unicode
and
IDNA, etc., do extend the range of domain names for you. But, in the
mean
time, it extends too much and brings too many variants of Han characters
and the associated delegation and resolution problems to Internet users
in
other culture where these characters are used in their daily life.

In other words, what you called an IDN WG solution is a partial
solution.
It works for a portion of the world but not the whole. We are asking
people
here in the WG to take the part of solution you are happy with.  But,
please
bear in mind that there is no consensus regarding the IDN "solution" on
the
CJK portion, so we urge the WG to adopt a phased implementation
strategy.

-- Janming Ho

Dave Crocker ¼g¤J¡G

> At 06:27 PM 2/1/2002 +0800, Erin Chen wrote:
> >But, the architecture of IDN defined in above four documents does not
> >solve the traditional and simplified Chinese character variant
problem.
>
> There are many things the IDN specifications do not do.  Rather, the
> specifications focus on solving satisfying only the requirement they
are
> supposed to satisfy.
>
> Solution of TC/SC is one example of equivalence among Unicode
> sets.  Indeed, IDN does not attempt to specify such
> equivalences.  Equivalence among separate Unicode sets is essentially
an
> open technical topic for which there are no accepted practises.
>
> Still, this topic has been discussed, debated and explained
extensively
> within the IDN working group.  .
>
> The purpose of IDN is to permit use of an increased range of
characters in
> domain name, beyond the current limit of ASCII.  It is not the goal of
the
> working group to invent character set conventions such as equivalence
> between different sets.
>
> It will be wonderful when equivalence between sets is achieved.
However it
> is not the charter of IDN to solve basic issues of character set
> equivalence and it is not reasonable to delay the utility of the
character
> set enhancement specified by IDN, in the hope that some day the
question of
> character set equivalence is achieved.
>
> Contrary to the claim that the working group is moving too quickly, my
own
> guess is that it has been a major source of delay for the working
group for
> at least 6 months.  Perhaps much longer.
>
> d/
>
> ----------
> Dave Crocker  <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464