[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
Dear Dave Crocker:
My friend give me an example about CJK UNICODE , It is
so ambiguous to me to deifferentiate which one is a correct Chinese
characters or not ? In our hand writting , each pair are used and mixed
.
淸眞敎 U+6DF8 U+771E U+654E
淸眞教 U+6DF8 U+771E U+6559
淸真敎 U+6DF8 U+771F U+654E
淸真教 U+6DF8 U+771F U+6559
清眞敎 U+6E05 U+771E U+654E
清眞教 U+6E05 U+771E U+6559
清真敎 U+6E05 U+771F U+654E
清真教 U+6E05 U+771F U+6559
L.M.Tseng
----- Original Message -----
From: "Dave Crocker" <dhc@dcrocker.net>
To: "Erin Chen" <erin@twnic.net.tw>
Cc: "IESG" <iesg@ietf.org>; "IAB" <iab@isi.edu>; "IETF IDN WG"
<idn@ops.ietf.org>
Sent: Tuesday, February 05, 2002 6:43 AM
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration
> [Note: header field too long; To & Cc field have been snapped - JS]
>
> At 06:29 AM 2/5/2002 +0800, Erin Chen wrote:
> > > 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.
> >
> >Do you mean the IDN-REQUIREMENT? It is no longer go with the goal of
> IDN
> >WG and will be dropped. And we has submit a Requirements of Chinese
> Domain
> >Name draft.
>
> no. I mean that it is only the goal of the IDN working group to extend
> the
> range of characters valid for domain names. It is NOT the goal of the
> working group to solve language problems. TC/SC is a language problem.
>
>
> >I understand the IDN WG has discussed for a long time. But if the
> >Unicode sets is still not well
> >defined as you said. Why IDN refer to a unwell defined Unicode sets?
>
> 1. If you wish to repair the Unicode definition, then the proper venue
> for
> discussions in the Unicode forum. At any rate, the IETF is clearly not
> the
> venue for trying to make modifications to Unicode.
>
> 2. Unicode was chosen by the working group because it is the best
> available specification for the working group's goal. The choice was
> considered extensively quite some time ago. I hope that you are not
> asking
> the question because you are unaware of that history.
>
>
> >If TC/SC equivalence could not be adopt by IDN, once IDN become
> standard
> >the serious expected delegation problem will occur. That means the user
> >could not
> >get the consistent resolving by DNS. DNS become untrust.
>
> You are making a technical assessment about the DNS. Your assessment is
> that it will provide inconsistent resolution of references.
>
> Your assessment is quite simply wrong. The IDN effort will not alter
> the
> stability or correctness of DNS resolutions at all.
>
>
> > > 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.
> >
> >I suggest we have to measure if we omit some requirement such as
> >equivalence between some variants like TC/SC, then what kind of serious
> >problem would be caused. And to review the original goal of IDN you
> >expressed is still proper or not.
>
> Yes, it is clear that that is what some of you wish. However it is
> equally
> clear that a) there is no ready technical solution to the problem you
> seek
> to solve, and b) the problem you are trying to solve is beyond the scope
> of
> this working group.
>
> To repeat: It will be good and useful to solve the problem of character
> set equivalences. However that problem is not part of the scope for
> this
> working group.
>
>
> > > 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.
> >
> >We made the CDNC declaration is not intend to hinder the progress of
> >IDN.
>
> When someone responds to an IETF working group Last Call with a claim
> that
> a specification is deficient, the clear and primary goal of that
> response
> is to delay the issuance of that specification.
>
> IETF participants who are primarily interested in making progress pursue
> that interest by creating and promosting viable specifications and
> gaining
> support for those specifications. You are encouraged to follow that
> path,
> rather than to pursue delay of the current specification.
>
>
> > If the IDN still could not consider or find a proper solution for CDN
> > requirement,
> >we rather the IDN switch off CDN temperarily till the proper solution
> >comes out to prevent
> >the expectedserious problem occur.
>
> The suggestion that use of a particular subset of Unicode be temporarily
> restricted suggests a failure to understand basic issues of Internet
> protocol design. Such special case handling is not viable in the scale
> of
> global Internet community.
>
> d/
>
>
> ----------
> Dave Crocker <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking <http://www.brandenburg.com>
> tel +1.408.246.8253; fax +1.408.273.6464
>
>
>
>
>