Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration

From: Dave Crocker <[email-masked]>
Date: Fri, 01 Feb 2002 09:09:35 -0800

<[email-masked]>,
   hoho <[email-masked]>,
   Kenny Huang  <[email-masked]>,
        Chun-Hsin Wu <[email-masked]>,
    sstseng <[email-masked]>,
        Wen-Sung Chen <[email-masked]>,
    Nai-Wen Hsu <[email-masked]>,
        yktham <[email-masked]>,
    jasonho  <[email-masked]>,
        alanysho <[email-masked]>,
        christine  <[email-masked]>
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk

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:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Dave Crocker <[email-masked]>
Date: Fri, 01 Feb 2002 09:09:35 -0800

<[email-masked]>,
        "Vinton G. Cerf" <[email-masked]>, Masanobu Katoh
<[email-masked]>,
        John klensin <[email-masked]>, harald <[email-masked]>,
        Fred baker <[email-masked]>, Stuart Lynn <[email-masked]>,
        Paul Haffman <[email-masked]>,
        Mohamed Sharil Tarmizi <[email-masked]>,
        JET Members <[email-masked]>, Thomas Narten
<[email-masked]>,
        Erik Nordmark <[email-masked]>,
        Andrew McLaughlin <[email-masked]>, "H. T. Kung"
<[email-masked]>,
        Marc Blanchet <[email-masked]>,
        James Seng/Personal <[email-masked]>,
        Masanobu Katoh <[email-masked]>,
        Mouhamet Diop <[email-masked]>, Patrik F?lstr?m
<[email-masked]>,
        Qiheng Hu <[email-masked]>,
        Sang-Hyon Kyong <[email-masked]>,
        Elisabeth Porteneuve <[email-masked]>,
        hlqian <[email-masked]>, mao <[email-masked]>,
        Zhang Wen Hui  <[email-masked]>, xiang deng
<[email-masked]>,
        xiaodong lee  <[email-masked]>,
        "=?Big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?="
<[email-masked]>,
        hoho <[email-masked]>, Kenny Huang
<[email-masked]>,
        Chun-Hsin Wu <[email-masked]>, sstseng
<[email-masked]>,
        Wen-Sung Chen <[email-masked]>, Nai-Wen Hsu
<[email-masked]>,
        yktham <[email-masked]>, jasonho  <[email-masked]>,
        alanysho <[email-masked]>,
        christine  <[email-masked]>
In-Reply-To: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk

d/

----------

---

From: John C Klensin <[email-masked]>
Date: Sat, 02 Feb 2002 08:28:19 -0800

(correction)
Message-ID: <6315254.1012648130@localhost>
X-Mailer: Mulberry/2.1.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [email-masked]
Precedence: bulk

[Note: header line too long error - To & Cc list snapped - JS]

My apologies to everyone on this distribution whom I may have
confused...

I have been thinking about the upcoming IETF meeting in
Minneapolis, and my note mentioned discussions in Minneapolis
when I intended to say "Salt Lake City".  I don't know if this
implies that I have lost track of where or when I am, but my
apologies in any event.

    john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 04 Feb 2002 11:25:27 -0500

In message <[email-masked]>, Dave Crocker
writes:
>Steve,
>
>At 09:35 PM 2/3/2002 -0500, Steven M. Bellovin wrote:
>>There'a a good discussion of the security risks of the code point
>>problem at http://www.csl.sri.com/users/neumann/insiderisks.html#140
>
>homographic attacks are not new with the IDN effort.
>
>for example, MICROS0FT.COM was done.
>
>For that matter, choice of different top-level domains permits a degree
>of homographic attack.  Try looking at dnso.com, rather than dnso.org.
>(No, this approach does not qualify precisely as homographic, but it
>takes advantage of a small difference from the real name, hoping that
>users will not notice.  And it does work.)

I know -- see slide 4 of http://www.research.att.com/~smb/talks/www.ps
(or .pdf), from 1996.

>
>Hence, the IDN work does not introduce a new risk.
>

It amplifies it, however.

--Steve Bellovin, http://www.research.att.com/~smb
Full text of "Firewalls" book now at http://www.wilyhacker.com

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 04 Feb 2002 11:25:27 -0500

of
>homographic attack.  Try looking at dnso.com, rather than dnso.org.
(No,
>this approach does not qualify precisely as homographic, but it takes
>advantage of a small difference from the real name, hoping that users
will
>not notice.  And it does work.)

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Feb 2002 14:43:23 -0800

<[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk

[Note: header field too long; To & Cc field have been snapped - JS]

At 06:29 AM 2/5/2002 +0800, Erin Chen wrote:
> > 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/

----------

---

From: Dave Crocker <[email-masked]>
Date: Wed, 06 Feb 2002 19:57:39 -0800

<[email-masked]>,
        IETF IDN WG <[email-masked]>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [email-masked]
Precedence: bulk

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

At 11:29 AM 2/7/2002 +0800, hoho wrote:
>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.

1.  This is not a matter of personal desires.  You do not help
discussion
by phrasing things as a matter of personal preference.

2.  This is a technical topic needing technical work.

3.  The technical work must be limited in scope or it will never finish.

4.  As I have said a number of times, the topic that you are interested
in
solving is very much an important topic.  Hence I would appreciate your
refraining from implying that I think it is not important.

However solutions are not readily available, and solving this topic is
not
required for making domain names support a broad range of characters.  I
am
assuming that you do want domain names to be useful for the entire
global
community, yes?

>In other words, what you called an IDN WG solution is a partial
>solution.

All interesting technical work is a partial solution.  That does not
make
the work useless, merely limited.

>It works for a portion of the world but not the whole.

It works for nearly all of the world, including those using Han.  The
concern you have is that it does not work as well for Han as you wish.
It
is fine that you wish the solution to be better, but that is quite
different from it not working at all.

d/

----------

---

From: "Ric Johnson" <[email-masked]>
Date: Thu, 07 Feb 2002 02:54:44 -0500

Dear Mr. Hoffman,

It it possible to set up a seperate mailing list for these types of 
discussions? I joined this list to work on DEVELOPMENT, and it seems to me 
that several members are abusing this forum.

My suggestion is that if anyone wants to continue to beat this dead horse, 
they should do it off THIS list, and anyone that does not understand this 
simple request should be BOUNCED.

Thanks for all your hard work!
Ric Johnson

>From: Paul Hoffman / IMC <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked], 
>[email-masked],   [email-masked], [email-masked], 
>[email-masked],   [email-masked], [email-masked], 
>[email-masked],   [email-masked], [email-masked], 
>[email-masked],   [email-masked], [email-masked], 
>[email-masked], [email-masked],   [email-masked], [email-masked], 
>[email-masked], [email-masked],   [email-masked], 
>[email-masked], [email-masked], [email-masked],   [email-masked], 
>[email-masked], [email-masked], [email-masked],   
>[email-masked], [email-masked], [email-masked],   
>[email-masked], [email-masked], [email-masked],   
>[email-masked], [email-masked], [email-masked],   
>[email-masked], [email-masked]
>Subject: Re: [idn] Re: Chinese Domain Name Consortium (CDNC) Declaration
>Date: Wed, 6 Feb 2002 20:07:29 -0800
>
>At 11:29 AM +0800 2/7/02, hoho wrote:
>>1. The TC/SC problem or variant problem comes from Unicode and the
>>decision
>>    to adopt Unicode as the basis to develop IDN technology. If the
>>working
>>    group chooses to use Unicode as basis, then it becomes a partial
>>solution
>>    to the "global" IDN problem because of this side-effect.
>
>This is exactly wrong. The decision to use the ISO/IEC 10646
>(Unicode) character repertoire was made to make IDN a global
>solution. Maybe I missed it, but what other solution has been
>proposed that is more global than using 10646? We already discussed
>this in detail on the mailing list many times, and no one came up
>with anything more global.
>
>>2. We do not want to delay your process either. Please refer to the
>>draft
>>    "Phased Implementation of Internationalized Domain Names in
>>Applications"
>>    for more details.
>
>The "phased implementation" draft is sure to cause a great deal more delay.
>
>- The draft has serious technical errors: the list in section 1 does
>not even vaguely match the list given in Appendix B.
>
>- As the draft admits, adopting the draft would have a very serious
>negative consequence on Japan and Korea. It is very insulting to say
>to people of other countries "because we have problems we cannot
>solve with our script, you will be reduced to using phonetic spelling
>of your names until we come up with a solution, even though we have
>failed numerous times in the past trying to do this". Discussing the
>political ramifications of this consequence could take years.
>
>- The draft is open-ended about what code points would be prohibited.
>Discussing whether to also prohibit additional code points will
>certainly delay IDN. If you are going to make this draft actually
>represent all of the scripts for which IDN is not perfect, the list
>will be huge, and it will probably affect many billions more people.
>
>If you feel that the IDN WG can deal with all those problems without
>delaying IDN, you have not been paying attention to the way this WG
>moves. :-)
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

---

From: liana Ye <[email-masked]>
Date: Sun, 10 Feb 2002 02:16:39 -0800

I just have to comment on your impression: 

It is not the whole picture!

> Due to the efforts of some CDNC members, the IETF is now well aware 
> of the "2^n" variant problem that is unique to the use of Han 
> characters in the Chinese language. Fortunately, using registration 
> guidelines will solve the problem. The only people seriously affected 
> by the size of DNS zones created by the "2^n" problem will be very 
> large, flat zones such as those managed by CDNC members, but they 
> are  able to compensate for the size of zones with no changes to the
DNS 
> protocols.

> Of course, the character variant problem exists in many different 
> languages, not just in Chinese. Because of this, each registry or 
> zone that includes IDN names needs to make decisions about name 
> equivalence (and therefore multiple registrations) before they enter 
> any IDN names into their zone. Based on this input during Working 
> Group last call from the CDNC, it seems clear that we need to 
> explain 
> these points more in the IDNA document.
> 

This provide another form of fragmented IDN.

Thanks.

Liana