Subject: CDNC Final Comments on Last call of IDN drafts

From: "xiaodong lee" <[email-masked]>
Date: Wed, 5 Jun 2002 17:13:58 +0800

----------------------------------------------------------
Chinese Domain Name Consortium (CDNC) Final Comments
----------------------------------------------------------

The following comments are made by CDNC:

1.Currently, IETF IESG has begun Last Call on the set of
core documents IDNA+NAMEPREP+PUNYCODE of IDN WG, but the
architecture of IDN defined in the above three documents
does not solve the traditional and simplified Chinese
character variant problem: it’s a half-baked solution
for Chinese users. That will cause serious delegation
problem in the application of Chinese Domain Name.

2.IETF IDN WG does not solve Chinese Domain Name technical
problems. Under the current condition, if IETF approves
these IDN drafts without publishing any complementary
documents simultaneously, registrars will open Chinese
Domain Name registration without considering the requirements
of Chinese Domain Name and Chinese Domain Name will fall
into confusion. This will damage Chinese Internet community
seriously.

3.What’s more, it stands a good chance that software
vendors will not deploy or modify client software to support
IDN too, because the current so-called IDN solution is a
defective solution, which will be widely against end users,
administrators and Chinese Internet communities, and bring
them into much trouble.

----------------------------------------------------------
Chinese Domain Name Consortium
CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC
Co-chair of CDNC: Qian Hualin, Professor
Co-chair of CDNC: Shian-Shyong Tseng, Professor
June 5, 2002
----------------------------------------------------------

---

From: James Seng <[email-masked]>
Date: Sun, 9 Jun 2002 20:04:58 +0800 (SGT)

I have no doubt some of the concerns are very real (others are red herrings) . 
The question is whether we have a solution that have rough consensus or not to 
address these valid concerns.

When we have acceptable solutions to these concerns, then we can discuss them.

-James Seng

> Gee, maybe some of the concerns are real, in spite of two years of harping
> that we are finished.

---

From: liana Ye <[email-masked]>
Date: Fri, 7 Jun 2002 21:07:01 -0700

This is CDNC final comments.  Please respect their experties
in dealing with large character sets.  Yes, it is difficult to
standardize character mapping tables, as we know well
enough.  Without the mapping tables there is no IDN either.

Yes, you are right on divide and conquor.  What is dividable
what is not dividable is what we have been debating on this
list.

UCS is not dividable is your position.  I say it is dividable
with langage tag.

IDNA is diviable from a standarded character mapping
table is your position.  I say it is undividable from the
IDNA specification.

Liana

On Thu, 06 Jun 2002 08:17:29 -0700 Dave Crocker <[email-masked]>
writes:
> At 12:52 PM 6/6/2002 +0200, Simon Josefsson wrote:
> >This means IDN is not guaranteed to be secure on non-Unicode
> systems.
> >There are alot of non-Unicode systems out there today...
>
> 1.  I assume your use of "secure" does not refer to security
> technology,
> but rather to something like correct or productive use.
>
> 2.  New standards are about new capabilities.  If a system does not
> support
> the standard -- in its entirety -- then of course it cannot use the
> standard.
>
> With respect to use of data formats, a system implementing a
> standard must
> map between the network standard format and their internal format.
> That is
> the nature of interoperability formats; it has been the approach to
> open
> systems standards for more than 30 years and it works well.
>
>
> > > When standards bodies for character sets define such
> equivalences, and
> > > when those equivalences gain popularity, it might be appropriate
> for
> > > the IDN effort to consider incorporating these new standards.
> >
> >This isn't an adequate solution IMHO, when the consequences of
> errors
> >made by such standard bodies, or conflicts between different
> standard
>
> It appears that you want to do standards development in a different
> world
> than the one we currently occupy.  Most folks prefer to work within
> the
> current reality.
>
> On the plus side, the nature of the model is called divide and
> conquor.  To
> make a complex problem tractable, solve as little of it as is
> practical,
> using an many existing component solutions as can be found.
>
> My own belief is that the single biggest cause of failed standards
> efforts
> is failure to constrain the initial solution effort, leading to
> confusion
> and delay.
>
>
> >(The details of how to attack systems based on charset equivalence
> >mapping tables differences, or changes in Unicode decomposition
> >tables, has been discussed recently on the IDN list.)
>
> Discussions are fine.  However the only things that really matters
> is
> specifications and their acceptance.
>
> This issue has been under discussion for a few years.
>
> Please point me to the detailed specification that solves the
> equivalence
> problem.
>
> Please point me at the base of community support for this
> specification.
>
> Absent a concrete specification and community support for it, all
> you are
> suggesting it that we wait more years in the hope of developing
> something
> that has so far proved extremely elusive.
>
> That's not a very good plan for getting anything useful and getting
> it in a
> timely manner.
>
> d/
>
>
> ----------
> Dave Crocker <mailto:[email-masked]>
> TribalWise, Inc. <http://www.tribalwise.com>
> tel +1.408.246.8253; fax +1.408.850.1850
>
>