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

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