From owner-idn@ops.ietf.org  Tue Jan  1 18:37:29 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16587
	for <idn-archive@lists.ietf.org>; Tue, 1 Jan 2002 18:37:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16LXye-00051u-00
	for idn-data@psg.com; Tue, 01 Jan 2002 15:05:48 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: idn@ops.ietf.org
Subject: [idn] a stupid test
Message-Id: <E16LXSQ-0008pC-00@rip.psg.com>
Date: Tue, 01 Jan 2002 14:32:30 -0800
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

so, whoppens to this?





From owner-idn@ops.ietf.org  Tue Jan  1 21:02:57 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17697
	for <idn-archive@lists.ietf.org>; Tue, 1 Jan 2002 21:02:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16LaQm-00074z-00
	for idn-data@psg.com; Tue, 01 Jan 2002 17:43:00 -0800
Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16LaQl-00074s-00; Tue, 01 Jan 2002 17:42:59 -0800
Received: from [64.109.213.90] (adsl-64-109-213-90.dsl.lgnnmi.ameritech.net [64.109.213.90])
	by www.wordnic.com (8.9.3/8.9.3) with ESMTP id TAA10336;
	Tue, 1 Jan 2002 19:42:47 -0600
Mime-Version: 1.0
X-Sender: tedd1@sperling.com
Message-Id: <p05100300b85815dfdfc8@[64.109.212.189]>
In-Reply-To: <E16LXSQ-0008pC-00@rip.psg.com>
References: <E16LXSQ-0008pC-00@rip.psg.com>
Date: Tue, 1 Jan 2002 20:42:51 -0500
To: Randy Bush <randy@psg.com>
From: tedd <tedd@sperling.com>
Subject: Re: [idn] a stupid test
Cc: idn@ops.ietf.org
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

>so, whoppens to this?

Apparently, it's alive now -- must have been a new year thing.

tedd
-- 
http://sperling.com



From owner-idn@ops.ietf.org  Wed Jan  2 10:25:41 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05569
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 10:25:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ln09-000HOS-00
	for idn-data@psg.com; Wed, 02 Jan 2002 07:08:21 -0800
Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Ln08-000HOL-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 07:08:20 -0800
Received: from [64.108.77.242] (adsl-64-108-77-242.dsl.lgnnmi.ameritech.net [64.108.77.242])
	by www.wordnic.com (8.9.3/8.9.3) with ESMTP id JAA18699
	for <idn@ops.ietf.org>; Wed, 2 Jan 2002 09:07:54 -0600
Mime-Version: 1.0
X-Sender: tedd1@sperling.com
Message-Id: <p05100304b858d2a20b17@[64.108.77.242]>
Date: Wed, 2 Jan 2002 10:08:00 -0500
To: <idn@ops.ietf.org>
From: tedd <tedd@sperling.com>
Subject: Re: [idn] SLC minutes
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA05569

Edmon et al:

I sent the following before, but it didn't appear in the idn. The 
following is a repost:

>This is the same as my thinking about LGC (Latin/Greek/Cyrillic) mapping,
>that is
>
><ALPHA><a><A><alpha>.example
>
>will be matched as
>
><a'><a'><a'><a'>.example
>
>So, we can really fulfil the spirit of Nameprep that: "The user should not
>be limited to only entering exactly the characters that might have been
>used, but to instead be able to enter characters that unambiguously
>[represents] the characters in the [perceived] host name.
>
>Perhaps this issue (what I call, Character Equivalence Mapping) will be
>discussed in other wgs but I just want to clarify what I meant during the
>SLC-IDN meeting and that I think it is important for the usability of
>multilingual domain names when they are deployed.
>
>Edmon

Yes, capital Omega is mapped to lower case Omega, but why?

I can understand that "A" has to be mapped to "a" to stop multiple 
registrations of the same name with different capitalizations. But 
why extend that "solution" to other code points? Clearly, the two 
glyphs (� v. w) are different enough to be noticed as being different 
-- so, the rational for excluding one (i.e., Character Equivalence 
Mapping) in favor of the other must have some grounds. But, what?

Furthermore, if one had to map one code point to another, then why 
didn't it go the other way? In other words, why wasn't the capital 
Omega kept and the lower case mapped to the upper case. After all, 
the capital Omega (�) looks considerably different than all other 
glyphs -- where as the lower case Omega looks like a common to many 
languages "w". In addition, I would bet that the upper case Omega has 
better global recognition than its lower case brother. So, what's the 
point of Character Equivalence Mapping in this case?

tedd

-- 
http://sperling.com



From owner-idn@ops.ietf.org  Wed Jan  2 11:31:02 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06477
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 11:31:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Lo8y-000IUq-00
	for idn-data@psg.com; Wed, 02 Jan 2002 08:21:32 -0800
Received: from smtp13.singnet.com.sg ([165.21.6.33])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Lo8w-000IUk-00; Wed, 02 Jan 2002 08:21:30 -0800
Received: from jamessonyvaio (bb104-151.singnet.com.sg [165.21.104.151] (may be forged))
	by smtp13.singnet.com.sg (8.12.1/8.12.1) with SMTP id g02GG8Dv005220;
	Thu, 3 Jan 2002 00:16:08 +0800
Message-ID: <01a201c193a9$8e051b60$3001000a@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Randy Bush" <randy@psg.com>, "tedd" <tedd@sperling.com>
Cc: <idn@ops.ietf.org>
References: <E16LXSQ-0008pC-00@rip.psg.com> <p05100300b85815dfdfc8@[64.109.212.189]>
Subject: Re: [idn] a stupid test
Date: Thu, 3 Jan 2002 00:21:37 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

There was some problem with the list over the last few days. If you send
any message to the lists last few days, please kind resend it again.

-James Seng

----- Original Message -----
From: "tedd" <tedd@sperling.com>
To: "Randy Bush" <randy@psg.com>
Cc: <idn@ops.ietf.org>
Sent: Wednesday, January 02, 2002 9:42 AM
Subject: Re: [idn] a stupid test


> >so, whoppens to this?
>
> Apparently, it's alive now -- must have been a new year thing.
>
> tedd
> --
> http://sperling.com
>




From owner-idn@ops.ietf.org  Wed Jan  2 15:09:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09884
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 15:09:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16LrTM-000LvD-00
	for idn-data@psg.com; Wed, 02 Jan 2002 11:54:48 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16LrTL-000Lv7-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 11:54:47 -0800
Message-ID: <003801c193c8$97fd80c0$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: <idn@ops.ietf.org>, "tedd" <tedd@sperling.com>
References: <p05100304b858d2a20b17@[64.108.77.242]>
Subject: Re: [idn] SLC minutes
Date: Wed, 2 Jan 2002 15:03:45 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Character Equivalence mapping is to deal with this issue:

A registrant registers a domain <ALPHA><BETA>.example
Advertises it to other people as their capital form AB.example
An end user will not know whether it was Greek or English and attempts to
access the site with ab.example and does not get to it.

With Character Equivalance mapping, this situation would not occur.  No
matter how a domain name is represented, it is always unique.

Bear in mind that this need to happen only during matching of names within
the DNS server.

A registrant can register <ALPHA><b>.example all they want.  This is the
misconception that I wanted to point out.  Character Equivalence mapping
does not prohibit mixed scripts.

Edmon


----- Original Message -----
From: "tedd" <tedd@sperling.com>
To: <idn@ops.ietf.org>
Sent: Wednesday, January 02, 2002 10:08 AM
Subject: Re: [idn] SLC minutes


Edmon et al:

I sent the following before, but it didn't appear in the idn. The
following is a repost:

>This is the same as my thinking about LGC (Latin/Greek/Cyrillic) mapping,
>that is
>
><ALPHA><a><A><alpha>.example
>
>will be matched as
>
><a'><a'><a'><a'>.example
>
>So, we can really fulfil the spirit of Nameprep that: "The user should not
>be limited to only entering exactly the characters that might have been
>used, but to instead be able to enter characters that unambiguously
>[represents] the characters in the [perceived] host name.
>
>Perhaps this issue (what I call, Character Equivalence Mapping) will be
>discussed in other wgs but I just want to clarify what I meant during the
>SLC-IDN meeting and that I think it is important for the usability of
>multilingual domain names when they are deployed.
>
>Edmon

Yes, capital Omega is mapped to lower case Omega, but why?

I can understand that "A" has to be mapped to "a" to stop multiple
registrations of the same name with different capitalizations. But
why extend that "solution" to other code points? Clearly, the two
glyphs (? v. w) are different enough to be noticed as being different
-- so, the rational for excluding one (i.e., Character Equivalence
Mapping) in favor of the other must have some grounds. But, what?

Furthermore, if one had to map one code point to another, then why
didn't it go the other way? In other words, why wasn't the capital
Omega kept and the lower case mapped to the upper case. After all,
the capital Omega (?) looks considerably different than all other
glyphs -- where as the lower case Omega looks like a common to many
languages "w". In addition, I would bet that the upper case Omega has
better global recognition than its lower case brother. So, what's the
point of Character Equivalence Mapping in this case?

tedd

--
http://sperling.com





From owner-idn@ops.ietf.org  Wed Jan  2 18:35:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12946
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 18:35:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Luh5-000PJB-00
	for idn-data@psg.com; Wed, 02 Jan 2002 15:21:11 -0800
Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Luh4-000PIa-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 15:21:10 -0800
Received: from [64.108.76.134] (adsl-64-108-76-134.dsl.lgnnmi.ameritech.net [64.108.76.134])
	by www.wordnic.com (8.9.3/8.9.3) with ESMTP id RAA22919;
	Wed, 2 Jan 2002 17:20:50 -0600
Mime-Version: 1.0
X-Sender: tedd1@sperling.com
Message-Id: <p05100301b85942be4282@[64.108.77.242]>
In-Reply-To: <003801c193c8$97fd80c0$0601a8c0@neteka.com>
References: <p05100304b858d2a20b17@[64.108.77.242]>
 <003801c193c8$97fd80c0$0601a8c0@neteka.com>
Date: Wed, 2 Jan 2002 18:20:47 -0500
To: "Edmon" <edmon@neteka.com>, <idn@ops.ietf.org>
From: tedd <tedd@sperling.com>
Subject: Re: [idn] SLC minutes
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Edmon:

I understand the problem -- I think I said that.

Now, the question is specifically: "Why is upper case <OMEGA> mapped 
to lower case <omega>?"

In other words, why is the Greek Letter Omega (upper case) mapped to 
omega (lower case)?

Instead, why wasn't the lower case omega mapped to upper case OMEGA? 
What was the reasoning behind setting that rule FOR that specific 
glyph? After all, if one is trying to "solve" a problem of unique 
domain names, then why map a glyph that IS unique to something like 
looks like so many other glyph's?

For example, what's the difference between "w.com" and "w.com"? Just 
take a look at lower case omega and tell me that it looks more 
distinctive from all the other "w"'s as the upper case omega does 
from all other glyph's. It simply doesn't.

If one was trying to solve a problem here, then I claim they didn't 
think it out. Now, point out where I'm wrong.

tedd

--- you posted

>Character Equivalence mapping is to deal with this issue:
>
>A registrant registers a domain <ALPHA><BETA>.example
>Advertises it to other people as their capital form AB.example
>An end user will not know whether it was Greek or English and attempts to
>access the site with ab.example and does not get to it.
>
>With Character Equivalance mapping, this situation would not occur.  No
>matter how a domain name is represented, it is always unique.
>
>Bear in mind that this need to happen only during matching of names within
>the DNS server.
>
>A registrant can register <ALPHA><b>.example all they want.  This is the
>misconception that I wanted to point out.  Character Equivalence mapping
>does not prohibit mixed scripts.
>
>Edmon
>
>
>----- Original Message -----
>From: "tedd" <tedd@sperling.com>
>To: <idn@ops.ietf.org>
>Sent: Wednesday, January 02, 2002 10:08 AM
>Subject: Re: [idn] SLC minutes
>
>
>Edmon et al:
>
>I sent the following before, but it didn't appear in the idn. The
>following is a repost:
>
>>This is the same as my thinking about LGC (Latin/Greek/Cyrillic) mapping,
>>that is
>>
>><ALPHA><a><A><alpha>.example
>>
>>will be matched as
>>
>><a'><a'><a'><a'>.example
>>
>>So, we can really fulfil the spirit of Nameprep that: "The user should not
>>be limited to only entering exactly the characters that might have been
>>used, but to instead be able to enter characters that unambiguously
>>[represents] the characters in the [perceived] host name.
>>
>>Perhaps this issue (what I call, Character Equivalence Mapping) will be
>>discussed in other wgs but I just want to clarify what I meant during the
>>SLC-IDN meeting and that I think it is important for the usability of
>>multilingual domain names when they are deployed.
>>
>>Edmon
>
>Yes, capital Omega is mapped to lower case Omega, but why?
>
>I can understand that "A" has to be mapped to "a" to stop multiple
>registrations of the same name with different capitalizations. But
>why extend that "solution" to other code points? Clearly, the two
>glyphs (? v. w) are different enough to be noticed as being different
>-- so, the rational for excluding one (i.e., Character Equivalence
>Mapping) in favor of the other must have some grounds. But, what?
>
>Furthermore, if one had to map one code point to another, then why
>didn't it go the other way? In other words, why wasn't the capital
>Omega kept and the lower case mapped to the upper case. After all,
>the capital Omega (?) looks considerably different than all other
>glyphs -- where as the lower case Omega looks like a common to many
>languages "w". In addition, I would bet that the upper case Omega has
>better global recognition than its lower case brother. So, what's the
>point of Character Equivalence Mapping in this case?
>
>tedd
>
>--
>http://sperling.com


-- 
http://sperling.com



From owner-idn@ops.ietf.org  Wed Jan  2 19:31:38 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13312
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 19:31:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16LvdI-0000Id-00
	for idn-data@psg.com; Wed, 02 Jan 2002 16:21:20 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16LvdH-0000IW-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 16:21:19 -0800
Message-ID: <005501c193ed$cc020060$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: <idn@ops.ietf.org>, "tedd" <tedd@sperling.com>
References: <p05100304b858d2a20b17@[64.108.77.242]> <003801c193c8$97fd80c0$0601a8c0@neteka.com> <p05100301b85942be4282@[64.108.77.242]>
Subject: Re: [idn] SLC minutes
Date: Wed, 2 Jan 2002 19:30:02 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Tedd,

----- Original Message -----
From: "tedd" <tedd@sperling.com>
> Now, the question is specifically: "Why is upper case <OMEGA> mapped
> to lower case <omega>?"
>

It doesnt have to map to lower case.  It could map to upper case.  In fact
it could be mapped to some other code point too if that also needs to be
mapped.  We should however come up with a general strategy for Character
Equivalence mapping, for example, if there are 4 codepoints that could be
considered "equivalent" in perception then it will be mapped to the lowest
codepoint regardless whether it is uppercase or lowercase...

>
> For example, what's the difference between "w.com" and "w.com"?

I would argue that there is no difference perceptually.  That is the precise
reason why there needs to be character equivalence mapping.
Which means that all four codepoints: <W> <w> <OMEGA> <omega> should be
preped so that if a person registered:

<W><w><OMEGA><omega>.example

no matter how he represented it, (e.g. wwww.example) people will still be
able to get to the unique domain.

>
> If one was trying to solve a problem here, then I claim they didn't
> think it out. Now, point out where I'm wrong.
>

You are not wrong.  We are talking about the same thing I think...

Edmon


> tedd
>
> --- you posted
>
> >Character Equivalence mapping is to deal with this issue:
> >
> >A registrant registers a domain <ALPHA><BETA>.example
> >Advertises it to other people as their capital form AB.example
> >An end user will not know whether it was Greek or English and attempts to
> >access the site with ab.example and does not get to it.
> >
> >With Character Equivalance mapping, this situation would not occur.  No
> >matter how a domain name is represented, it is always unique.
> >
> >Bear in mind that this need to happen only during matching of names
within
> >the DNS server.
> >
> >A registrant can register <ALPHA><b>.example all they want.  This is the
> >misconception that I wanted to point out.  Character Equivalence mapping
> >does not prohibit mixed scripts.
> >
> >Edmon
> >
> >
> >----- Original Message -----
> >From: "tedd" <tedd@sperling.com>
> >To: <idn@ops.ietf.org>
> >Sent: Wednesday, January 02, 2002 10:08 AM
> >Subject: Re: [idn] SLC minutes
> >
> >
> >Edmon et al:
> >
> >I sent the following before, but it didn't appear in the idn. The
> >following is a repost:
> >
> >>This is the same as my thinking about LGC (Latin/Greek/Cyrillic)
mapping,
> >>that is
> >>
> >><ALPHA><a><A><alpha>.example
> >>
> >>will be matched as
> >>
> >><a'><a'><a'><a'>.example
> >>
> >>So, we can really fulfil the spirit of Nameprep that: "The user should
not
> >>be limited to only entering exactly the characters that might have been
> >>used, but to instead be able to enter characters that unambiguously
> >>[represents] the characters in the [perceived] host name.
> >>
> >>Perhaps this issue (what I call, Character Equivalence Mapping) will be
> >>discussed in other wgs but I just want to clarify what I meant during
the
> >>SLC-IDN meeting and that I think it is important for the usability of
> >>multilingual domain names when they are deployed.
> >>
> >>Edmon
> >
> >Yes, capital Omega is mapped to lower case Omega, but why?
> >
> >I can understand that "A" has to be mapped to "a" to stop multiple
> >registrations of the same name with different capitalizations. But
> >why extend that "solution" to other code points? Clearly, the two
> >glyphs (? v. w) are different enough to be noticed as being different
> >-- so, the rational for excluding one (i.e., Character Equivalence
> >Mapping) in favor of the other must have some grounds. But, what?
> >
> >Furthermore, if one had to map one code point to another, then why
> >didn't it go the other way? In other words, why wasn't the capital
> >Omega kept and the lower case mapped to the upper case. After all,
> >the capital Omega (?) looks considerably different than all other
> >glyphs -- where as the lower case Omega looks like a common to many
> >languages "w". In addition, I would bet that the upper case Omega has
> >better global recognition than its lower case brother. So, what's the
> >point of Character Equivalence Mapping in this case?
> >
> >tedd
> >
> >--
> >http://sperling.com
>
>
> --
> http://sperling.com




From owner-idn@ops.ietf.org  Wed Jan  2 20:19:19 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13680
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 20:19:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16LwPS-00017S-00
	for idn-data@psg.com; Wed, 02 Jan 2002 17:11:06 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16LwPR-00017M-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 17:11:06 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16LwPF-000MMJ-00; Thu, 03 Jan 2002 01:10:54 +0000
Date: Wed, 02 Jan 2002 20:10:52 -0500
From: John C Klensin <klensin@jck.com>
To: Edmon <edmon@neteka.com>, tedd <tedd@sperling.com>
cc: idn@ops.ietf.org
Subject: Re: [idn] SLC minutes
Message-ID: <16511329.1010002252@P2>
In-Reply-To: <005501c193ed$cc020060$0601a8c0@neteka.com>
References:  <005501c193ed$cc020060$0601a8c0@neteka.com>
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: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Edmon, Tedd,

Please don't interpret what I'm about to say as encouragement to
go down the "character equivalence" path.  I think it leads to
madness, especially when used with the exact-matching (i.e.,
"get it exactly right or fail completely) procedures of the DNS.
But, just as an exercise, I would suggest that one might start
with three principles:

(i) From observation, when scripts have two cases, the
upper-case form is more likely to be highly stylized, and hence
differentiated from characters in other scripts, than the
lower-case one.  Hence, if one is going to adopt
stylization-based (glyph-distinction, if you prefer)
canonicalization rules, one is better off treating upper case as
the normal form, rather than lower case.

(ii) Many alphabets, especially western European
"Roman-character-based" ones, utilize diacritical marks to
distinguish sounds of accents associated with a single base
letter.  However, in many languages and dictionaries, a
character without a diacritical mark (or with one diacritical
and not another) is treated as different from that character
without the marking.    As a typographical convention that has
been established into language practice in some places, those
diacritical marks are often dropped when a lower-case character
carrying them is converted to upper case (in other languages and
scripts, or with other characters, they are not dropped).  But,
since they are sometimes dropped, lower-case characters (which
always carry the diacriticals when they are appropriate) provide
better differentiation than upper-case characters.  Hence, if
one is going to adopt differentiation-based canonicalization
rules with recognition of scripts that use diacriticals, one is
better off treating lower case as the normal form, rather than
upper case. 

(iii) There is a theory among scholars of writing systems that
_all_ modern alphabetic writing systems are derived from a
single Old Semitic writing system (which didn't have case
distinctions).  One fairly extreme way to accomplish  the sort
of "equivalence" you are looking for is to drop all attempts to
visually distinguish or match these characters (a process that
depends heavily on the fonts chosen for each, which contradicts
a Unicode design principle), map every character onto its
equivalent in that ancient script, and drop all other
differentiation.  Of course, doing this would eliminate much of
the goal of IDN work, as it would equivalence not only Roman-
and Greek-based scripts but those with, e.g.,  the scripts of
the middle east, Africa, and the Indian subcontinent.  Just
depends on how far one wants to go.

Note that the three possibilities above are contradictory and
fairly close to being mutually exclusive, although a strong case
can be made for each if one starts to do "character
equivalences".

     john



--On Wednesday, 02 January, 2002 19:30 -0500 Edmon
<edmon@neteka.com> wrote:

> Hi Tedd,
> 
> ----- Original Message -----
> From: "tedd" <tedd@sperling.com>
>> Now, the question is specifically: "Why is upper case <OMEGA>
>> mapped to lower case <omega>?"
>> 
> 
> It doesnt have to map to lower case.  It could map to upper
> case.  In fact it could be mapped to some other code point too
> if that also needs to be mapped.  We should however come up
> with a general strategy for Character Equivalence mapping, for
> example, if there are 4 codepoints that could be considered
> "equivalent" in perception then it will be mapped to the lowest
> codepoint regardless whether it is uppercase or lowercase...
> 
>> 
>> For example, what's the difference between "w.com" and
>> "w.com"?
> 
> I would argue that there is no difference perceptually.  That
> is the precise reason why there needs to be character
> equivalence mapping. Which means that all four codepoints: <W>
> <w> <OMEGA> <omega> should be preped so that if a person
> registered:
> 
> <W><w><OMEGA><omega>.example
> 
> no matter how he represented it, (e.g. wwww.example) people
> will still be able to get to the unique domain.
> 
>> 
>> If one was trying to solve a problem here, then I claim they
>> didn't think it out. Now, point out where I'm wrong.
>> 
> 
> You are not wrong.  We are talking about the same thing I
> think...





From owner-idn@ops.ietf.org  Wed Jan  2 20:59:39 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13984
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 20:59:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Lx2X-0001mr-00
	for idn-data@psg.com; Wed, 02 Jan 2002 17:51:29 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Lx2W-0001mk-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 17:51:28 -0800
Received: from smtp1.sybase.com (sybgate.sybase.com [130.214.220.35])
	by inergen.sybase.com  with ESMTP id RAA22194
	for <idn@ops.ietf.org>; Wed, 2 Jan 2002 17:51:25 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id RAA27466
	for <idn@ops.ietf.org>; Wed, 2 Jan 2002 17:51:27 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id RAA27458;
	Wed, 2 Jan 2002 17:51:25 -0800 (PST)
Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5)
	id RAA01848; Wed, 2 Jan 2002 17:51:25 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id RAA03854;
	Wed, 2 Jan 2002 17:51:24 -0800 (PST)
Date: Wed, 2 Jan 2002 17:51:24 -0800 (PST)
From: Kenneth Whistler <kenw@sybase.com>
Message-Id: <200201030151.RAA03854@birdie.sybase.com>
To: edmon@neteka.com
Subject: Character equivalence mapping (was: Re: [idn] SLC minutes)
Cc: idn@ops.ietf.org
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Edmon suggested:

> Character Equivalence mapping is to deal with this issue:
> 
> A registrant registers a domain <ALPHA><BETA>.example
> Advertises it to other people as their capital form AB.example
> An end user will not know whether it was Greek or English and attempts to
> access the site with ab.example and does not get to it.
> 
> With Character Equivalance mapping, this situation would not occur.  No
> matter how a domain name is represented, it is always unique.

I think this example nicely points up the contrary problem that
cross-script mapping has. If you start doing cross-script equivalence
mapping to eliminate differences between (to Latin-trained eyes) confusable
letters, you violate the integrity of other scripts and start mapping
the set of possible strings in those scripts even more confusably into
the already crowded domain namespace of Latin strings.

In this particular example, suppose I was a Greek and actually wanted
to register <ALPHA><BETA>.com, in addition to <ALPHA><BETA>.gr for
the <ALPHA><BETA> construction company in Athens. Whoops! I'd be
out of luck since ab.com already exists and is registered to
Allen-Bradley. (See www.ab.com ) Why should I, as a Greek, find my
own Greek namespace unpredictably polluted by some arbitrary list
of equivalences between Greek letters and Latin letters?

And exactly what equivalences would you suggest? Greek uppercase
eta is basically indistinguishable in shape from a Latin uppercase "H".
So do I equivalence map it to Latin "H", which would make no sense at
all for transliteration and serve only the purposes of dumb equations
for people who know nothing about Greek whatsoever? Or do I equivalence map it
to Latin "I", which is the normal transliteration for eta in Modern Greek?
Or do I equivalence map it to Latin "E", which is the normal transliteration
for eta in Ancient Greek?

So does: <ALPHA><BETA>.<OMICRON><MU><ETA><RHO><OMICRON><SIGMA>

equate to: ab.omhpo<sigma> or ab.omiro<sigma> or ab.omero<sigma> or
           ab.omhpos or ab.omiros or ab.omeros ?

By the way, the 5th example is how the Greeks themselves would Latinize
it. (see www.omiros.gr )

The problem of "AB.example" is generally dealt with by context. First
of all "example" would be in Greek if I was really dealing with Greek.
Second, if I wanted people to enter "ab.whatever" I'd be advertising
in *English* to set the expectations. If I wanted people to enter
"<alpha><beta>.....", I'd be advertising in *Greek* to set the expectations,
and people would be using Greek keyboards and expect to enter Greek.

Furthermore, visual confusability quickly runs off the road as the basis
for determining equivalence classes when you start to deal with scripts
that have more complicated rules for the presentation of glyphs than
is typical for the Latin script. Which of several possible forms is
the basis for the confusability used to determine the equivalence?
And this turns into an N-body problem, because you start having to
account for visual confusability between N different scripts -- not just
between N scripts and Latin characters. Where do you draw the line, in
principle? Or do we just end up arguing for the next decade about all
the edge cases?

> 
> Bear in mind that this need to happen only during matching of names within
> the DNS server.
> 
> A registrant can register <ALPHA><b>.example all they want.  This is the
> misconception that I wanted to point out.  Character Equivalence mapping
> does not prohibit mixed scripts.

But it does severe damage to the integrity of namespaces in other scripts.

This is Latin- and English-centric thinking, in my opinion, that would
damage the whole point of having IDN's by folding other scripts towards
Latin characters.

--Ken

> 
> Edmon
> 
> 



From owner-idn@ops.ietf.org  Wed Jan  2 21:51:07 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15408
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 21:51:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16LxoI-0002j0-00
	for idn-data@psg.com; Wed, 02 Jan 2002 18:40:50 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16LxoH-0002iu-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 18:40:49 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16LxoF-000MUI-00; Thu, 03 Jan 2002 02:40:47 +0000
Date: Wed, 02 Jan 2002 21:40:46 -0500
From: John C Klensin <klensin@jck.com>
To: Kenneth Whistler <kenw@sybase.com>
cc: idn@ops.ietf.org
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC
 minutes)
Message-ID: <4524066.1010007646@localhost>
In-Reply-To: <200201030151.RAA03854@birdie.sybase.com>
References:  <200201030151.RAA03854@birdie.sybase.com>
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: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ken, 

We are in agreement that "equivalence matching" based on
character shapes is fairly hopeless.   But...

--On Wednesday, 02 January, 2002 17:51 -0800 Kenneth Whistler
<kenw@sybase.com> wrote:

>...
> The problem of "AB.example" is generally dealt with by
> context. First of all "example" would be in Greek if I was
> really dealing with Greek. Second, if I wanted people to enter
> "ab.whatever" I'd be advertising in *English* to set the
> expectations. If I wanted people to enter
> "<alpha><beta>.....", I'd be advertising in *Greek* to set the
> expectations, and people would be using Greek keyboards and
> expect to enter Greek.

The problem is that, with an international Internet and (short)
DNS names, the context may not be there, or may be unreliable
enough that users, in practice, will need an opportunity to pick
among alternatives.  While I think Edmon's notions would make
that problem worse, rather than better (hence my attempt at a
reductio ad absurdum argument in my earlier note), I don't
believe that "resolve by context" is going to be realistic in
practice --again, in the DNS context-- either.

    john





From owner-idn@ops.ietf.org  Wed Jan  2 23:42:56 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17476
	for <idn-archive@lists.ietf.org>; Wed, 2 Jan 2002 23:42:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16LzWl-0004ku-00
	for idn-data@psg.com; Wed, 02 Jan 2002 20:30:51 -0800
Received: from rwcrmhc52.attbi.com ([216.148.227.88])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16LzWk-0004kn-00
	for idn@ops.ietf.org; Wed, 02 Jan 2002 20:30:50 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc52.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020103043049.FMPZ6450.rwcrmhc52.attbi.com@c1340594a>;
          Thu, 3 Jan 2002 04:30:49 +0000
Message-ID: <00aa01c1940f$ac0fee30$08d8ea0c@c1340594a>
From: "Mark Davis" <mark.davis@macchiato.com>
To: "Kenneth Whistler" <kenw@sybase.com>, <edmon@neteka.com>
Cc: <idn@ops.ietf.org>
References: <200201030151.RAA03854@birdie.sybase.com>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Wed, 2 Jan 2002 20:32:37 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

In addition,

1. This issue was debated at length some time ago. I suggest that the people
arguing for visual confusability as a criterion for matching look at that
discussion in detail before proceding.

2. Moreover, stop and think about the implications; using both case folding
and visual confusability would have some very unpleasant consequences. For
example, it would force the ASCII letters N and V to be in the same
equivalence class:

- N is in the same class as GREEK NU, by visual confusability.
- GREEK NU is in the same class as greek nu, by casefolding.
- greek nu is in the same class as v, by visual confusability.
- v is in the same class as V, by visual casefolding.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Kenneth Whistler" <kenw@sybase.com>
To: <edmon@neteka.com>
Cc: <idn@ops.ietf.org>
Sent: Wednesday, January 02, 2002 17:51
Subject: Character equivalence mapping (was: Re: [idn] SLC minutes)


> Edmon suggested:
>
> > Character Equivalence mapping is to deal with this issue:
> >
> > A registrant registers a domain <ALPHA><BETA>.example
> > Advertises it to other people as their capital form AB.example
> > An end user will not know whether it was Greek or English and attempts
to
> > access the site with ab.example and does not get to it.
> >
> > With Character Equivalance mapping, this situation would not occur.  No
> > matter how a domain name is represented, it is always unique.
>
> I think this example nicely points up the contrary problem that
> cross-script mapping has. If you start doing cross-script equivalence
> mapping to eliminate differences between (to Latin-trained eyes)
confusable
> letters, you violate the integrity of other scripts and start mapping
> the set of possible strings in those scripts even more confusably into
> the already crowded domain namespace of Latin strings.
>
> In this particular example, suppose I was a Greek and actually wanted
> to register <ALPHA><BETA>.com, in addition to <ALPHA><BETA>.gr for
> the <ALPHA><BETA> construction company in Athens. Whoops! I'd be
> out of luck since ab.com already exists and is registered to
> Allen-Bradley. (See www.ab.com ) Why should I, as a Greek, find my
> own Greek namespace unpredictably polluted by some arbitrary list
> of equivalences between Greek letters and Latin letters?
>
> And exactly what equivalences would you suggest? Greek uppercase
> eta is basically indistinguishable in shape from a Latin uppercase "H".
> So do I equivalence map it to Latin "H", which would make no sense at
> all for transliteration and serve only the purposes of dumb equations
> for people who know nothing about Greek whatsoever? Or do I equivalence
map it
> to Latin "I", which is the normal transliteration for eta in Modern Greek?
> Or do I equivalence map it to Latin "E", which is the normal
transliteration
> for eta in Ancient Greek?
>
> So does: <ALPHA><BETA>.<OMICRON><MU><ETA><RHO><OMICRON><SIGMA>
>
> equate to: ab.omhpo<sigma> or ab.omiro<sigma> or ab.omero<sigma> or
>            ab.omhpos or ab.omiros or ab.omeros ?
>
> By the way, the 5th example is how the Greeks themselves would Latinize
> it. (see www.omiros.gr )
>
> The problem of "AB.example" is generally dealt with by context. First
> of all "example" would be in Greek if I was really dealing with Greek.
> Second, if I wanted people to enter "ab.whatever" I'd be advertising
> in *English* to set the expectations. If I wanted people to enter
> "<alpha><beta>.....", I'd be advertising in *Greek* to set the
expectations,
> and people would be using Greek keyboards and expect to enter Greek.
>
> Furthermore, visual confusability quickly runs off the road as the basis
> for determining equivalence classes when you start to deal with scripts
> that have more complicated rules for the presentation of glyphs than
> is typical for the Latin script. Which of several possible forms is
> the basis for the confusability used to determine the equivalence?
> And this turns into an N-body problem, because you start having to
> account for visual confusability between N different scripts -- not just
> between N scripts and Latin characters. Where do you draw the line, in
> principle? Or do we just end up arguing for the next decade about all
> the edge cases?
>
> >
> > Bear in mind that this need to happen only during matching of names
within
> > the DNS server.
> >
> > A registrant can register <ALPHA><b>.example all they want.  This is the
> > misconception that I wanted to point out.  Character Equivalence mapping
> > does not prohibit mixed scripts.
>
> But it does severe damage to the integrity of namespaces in other scripts.
>
> This is Latin- and English-centric thinking, in my opinion, that would
> damage the whole point of having IDN's by folding other scripts towards
> Latin characters.
>
> --Ken
>
> >
> > Edmon
> >
> >
>
>




From owner-idn@ops.ietf.org  Thu Jan  3 11:47:07 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05783
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 11:47:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MAdP-000GuR-00
	for idn-data@psg.com; Thu, 03 Jan 2002 08:22:27 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16MAdO-000GuK-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 08:22:27 -0800
Message-ID: <003201c19474$16030b60$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: "John C Klensin" <klensin@jck.com>, "Kenneth Whistler" <kenw@sybase.com>
Cc: <idn@ops.ietf.org>
References:  <200201030151.RAA03854@birdie.sybase.com> <4524066.1010007646@localhost>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Thu, 3 Jan 2002 11:31:22 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi John & Ken,

> > The problem of "AB.example" is generally dealt with by
> > context.

But the context of domain names is Internet, and the Internet is
conceptually and practically becoming multilingual, which is why we are
discussing this issue today.  Therefore, the point is that if the context is
multilingual, AB.example needs to be unique regardless of what the
"intended" "language" is, because the "perceived" character is what becomes
the context in itself.  Therefore, the context of a character is the
character itself.  Whether by a Latin-trained-eye or by an
Arabic-trained-eye or a Chinese-trained-eye, some characters are
unmistakably identical.  That is the root of the problem at hand.

> > First of all "example" would be in Greek if I was
> > really dealing with Greek. Second, if I wanted people to enter
> > "ab.whatever" I'd be advertising in *English* to set the
> > expectations. If I wanted people to enter
> > "<alpha><beta>.....", I'd be advertising in *Greek* to set the
> > expectations, and people would be using Greek keyboards and
> > expect to enter Greek.

This is a presumption.  And "localization" by TLD is beyond the
technicalities of trying to make a solid IDN solution.  We should not resort
to the management of TLDs to finish our job..?..

Again, context should be irrelevant because context is not known.
For example (really just an example, there could be other cases)
I dont know greek, but I see an interesting ad that I think might be for a
Greek translation service.
I see the domain A2<beta>.example, (the actual domain was
<ALPHA>2<beta>.example)
I try it as I see it, it goes elsewhere.

> While I think Edmon's notions would make
> that problem worse, rather than better (hence my attempt at a
> reductio ad absurdum argument in my earlier note),

My notion is to keep the DNS stupid and just map all Characters with
"perceived" equivalence during internal matching.  The domain names as they
conceptually exist however should remain user friendly.  In other words,
domain names for humans will contain context and meaning (an "ALPHA" will be
an "ALPHA" not "A"), but domain names as viewed in the DNS (machine) should
be devoid of context.  To bridge these two, a set of equivalent characters
are prepared as a table for the machine so that it can blindly treat them as
identical without contemplating its context.

> I don't
> believe that "resolve by context" is going to be realistic in
> practice --again, in the DNS context-- either.

Very Agreeable.

Edmon


...Just as a final note here, I think Character Equivalence mapping could be
an optional "best practice" type of configuration for zone operators to
provide to their users, however, it would be a good idea to have a
technically sound approach, which is what I am trying to discuss.




From owner-idn@ops.ietf.org  Thu Jan  3 11:57:15 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05966
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 11:57:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MAza-000HMp-00
	for idn-data@psg.com; Thu, 03 Jan 2002 08:45:22 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MAza-000HMj-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 08:45:22 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16MAzU-000Nu0-00; Thu, 03 Jan 2002 16:45:16 +0000
Date: Thu, 03 Jan 2002 11:45:15 -0500
From: John C Klensin <klensin@jck.com>
To: Edmon <edmon@neteka.com>
cc: idn@ops.ietf.org
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC
 minutes)
Message-ID: <55201632.1010058315@P2>
In-Reply-To: <003201c19474$16030b60$0601a8c0@neteka.com>
References:  <003201c19474$16030b60$0601a8c0@neteka.com>
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: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On Thursday, 03 January, 2002 11:31 -0500 Edmon
<edmon@neteka.com> wrote:

>...
> The domain names as they
> conceptually exist however should remain user friendly.  In
> other words, domain names for humans will contain context and
> meaning (an "ALPHA" will be an "ALPHA" not "A"), but domain
> names as viewed in the DNS (machine) should be devoid of
> context.  To bridge these two, a set of equivalent characters
> are prepared as a table for the machine so that it can blindly
> treat them as identical without contemplating its context.

But, Edmon, we already have disproofs of this in trademark
registrations and the registrars claim (and I believe them) that
the companies involved are anxious to take advantage of
internationalization to register their trademarks more directly
in the DNS.  We have organizations who want to be 
  <alpha><roman-i><digits123>
  toys-<cyrillic-ya>-us
and so on, a list that will certainly get longer as more
characters are perceived as available.  

What you are trying to do also involves some rather complex
judgement calls which I don't know how to make.  As someone who
is not very familiar with either, I've seen a number of font
forms of Arabic and Thai that I'm not sure I could tell apart,
at least without considerable context.  I would assume that
daily users of the two scripts wouldn't have that problem, but
who is to make the decision about equivalence?

It seems to me that there, in practice, are only two ways to get
what you want without ambiguity or confusion.  One goes down the
path that Ken points out, which results, ultimately, in
"equivalencing" some very different things.  And the other is to
say "ok, we will add characters to the LDH list, but only those
characters that cannot be confused with anything else,
regardless of the case or font used".  Maybe, in the long term,
they turn out to be the same option.

It would have the advantage of adding many useful characters to
the DNS-application-permitted set (and Harald and Patrik could
stop worrying about the names of their respective sons :-)), but
it would do almost nothing for internationalization other than
throwing us back into strange transliterations or transpositions
for many scripts.   Put differently, we would end up with a DNS
character set that would probably support Latin-1 and Han
characters properly, but maybe nothing else.  I don't find that
very satisfying, much as I am concerned about accurate
transcription of labels from printed form into the DNS.

     john





From owner-idn@ops.ietf.org  Thu Jan  3 12:36:41 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06596
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 12:36:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MBUp-000Hxh-00
	for idn-data@psg.com; Thu, 03 Jan 2002 09:17:39 -0800
Received: from bora.postel.to ([164.124.123.206] helo=bora.lsb.org)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MBUo-000HxU-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 09:17:38 -0800
Received: from marketing ([210.217.27.236] (may be forged))
	by bora.lsb.org (8.9.3/8.8.7) with SMTP id CAA16362;
	Fri, 4 Jan 2002 02:17:00 +0900
Message-ID: <014a01c1947a$73d8e600$ec1bd9d2@temp>
From: "Soobok Lee" <lsb@postel.co.kr>
To: "John C Klensin" <klensin@jck.com>, "Edmon" <edmon@neteka.com>
Cc: <idn@ops.ietf.org>
References:  <003201c19474$16030b60$0601a8c0@neteka.com> <55201632.1010058315@P2>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Fri, 4 Jan 2002 02:15:39 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0146_01C194C5.B416DD30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0146_01C194C5.B416DD30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi, John and Edmon

I feel it is interesting to try to find some analogy for fun(!) between famous old Babel Tower story and modern Internet name system
history. How about replacing 'Shnar->Internet' and 'brick->computer' and 'bitumen -> network' and 'one language->ASCII domain' ?
Just enjoy reading the next excerpts from Genesis.

  "Now the whole earth had one language and few words. And as men migrated from the east, they found a plain in the land of Shinar
and settled there. And they said to one another, 'Come, let us make bricks, and burn them thoroughly.' And they had brick for stone,
and bitumen for mortar. Then they said, 'Come, let us build ourselves a city, and a tower with its top in the heavens, and let us
make a name for ourselves, lest we be scattered abroad upon the face of the whole earth.' And the LORD came down to see the city and
the tower, which the sons of men had built. And the LORD said, 'Behold, they are one people, and they have all one language; and
this is only the beginning of what they will do; and nothing that they propose to do will now be impossible for them. Come, let us
go down, and there confuse their language, that they may not understand one another's speech.' So the LORD scattered them abroad
from there over the face of all the earth, and they left off building the city.' Therefore its name was called Babel, because there
the LORD confused the language of all the earth; and from there the LORD scattered them abroad over the face of all the earth."
(Genesis 11:1-9)

  "Babel" is composed of two words, "baa" meaning "gate" and "el," "god." Hence, "the gate of god." A related word in Hebrew,
"balal" means "confusion."     (http://www.ldolphin.org/babel.html)

Will IDN  be "the gate of god" or "confusion" to the mankind ?

Soobok Lee



----- Original Message -----
From: "John C Klensin" <klensin@jck.com>
To: "Edmon" <edmon@neteka.com>
Cc: <idn@ops.ietf.org>
Sent: Friday, January 04, 2002 1:45 AM
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)


> --On Thursday, 03 January, 2002 11:31 -0500 Edmon
> <edmon@neteka.com> wrote:
>
> >...
> > The domain names as they
> > conceptually exist however should remain user friendly.  In
> > other words, domain names for humans will contain context and
> > meaning (an "ALPHA" will be an "ALPHA" not "A"), but domain
> > names as viewed in the DNS (machine) should be devoid of
> > context.  To bridge these two, a set of equivalent characters
> > are prepared as a table for the machine so that it can blindly
> > treat them as identical without contemplating its context.
>
> But, Edmon, we already have disproofs of this in trademark
> registrations and the registrars claim (and I believe them) that
> the companies involved are anxious to take advantage of
> internationalization to register their trademarks more directly
> in the DNS.  We have organizations who want to be
>   <alpha><roman-i><digits123>
>   toys-<cyrillic-ya>-us
> and so on, a list that will certainly get longer as more
> characters are perceived as available.
>
> What you are trying to do also involves some rather complex
> judgement calls which I don't know how to make.  As someone who
> is not very familiar with either, I've seen a number of font
> forms of Arabic and Thai that I'm not sure I could tell apart,
> at least without considerable context.  I would assume that
> daily users of the two scripts wouldn't have that problem, but
> who is to make the decision about equivalence?
>
> It seems to me that there, in practice, are only two ways to get
> what you want without ambiguity or confusion.  One goes down the
> path that Ken points out, which results, ultimately, in
> "equivalencing" some very different things.  And the other is to
> say "ok, we will add characters to the LDH list, but only those
> characters that cannot be confused with anything else,
> regardless of the case or font used".  Maybe, in the long term,
> they turn out to be the same option.
>
> It would have the advantage of adding many useful characters to
> the DNS-application-permitted set (and Harald and Patrik could
> stop worrying about the names of their respective sons :-)), but
> it would do almost nothing for internationalization other than
> throwing us back into strange transliterations or transpositions
> for many scripts.   Put differently, we would end up with a DNS
> character set that would probably support Latin-1 and Han
> characters properly, but maybe nothing else.  I don't find that
> very satisfying, much as I am concerned about accurate
> transcription of labels from printed form into the DNS.
>
>      john
>
>
>

------=_NextPart_000_0146_01C194C5.B416DD30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>
<P><STRONG><FONT face=3D&#44404;&#47548; =
size=3D2></FONT></STRONG><STRONG><FONT face=3D&#44404;&#47548; =
size=3D2>Hi,=20
John and Edmon</FONT></STRONG></P>
<P><STRONG><FONT face=3D&#44404;&#47548; size=3D2>I feel it is =
interesting to try to find some=20
analogy for fun(!) between famous old Babel Tower story and modern =
Internet name=20
system history</FONT></STRONG><STRONG><FONT face=3D&#44404;&#47548; =
size=3D2>. How about replacing=20
'Shnar-&gt;Internet' and 'brick-&gt;computer' and 'bitumen -&gt; =
network' and=20
'one language-&gt;ASCII domain' ?&nbsp; </FONT></STRONG><STRONG><FONT =
face=3D&#44404;&#47548;=20
size=3D2>Just enjoy reading the next excerpts from =
Genesis.</FONT></STRONG></P>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <P><STRONG><FONT face=3D&#44404;&#47548; size=3D2>"<FONT size=3D3>Now =
the whole earth had one=20
  language and few words. And as men migrated from the east, they found =
a plain=20
  in the land of Shinar and settled there. And they said to one another, =
'Come,=20
  let us make bricks, and burn them thoroughly.' And they had brick for =
stone,=20
  and bitumen for mortar. Then they said, 'Come, let us build ourselves =
a city,=20
  and a tower with its top in the heavens, and let us make a name for =
ourselves,=20
  lest we be scattered abroad upon the face of the whole earth.' And the =
LORD=20
  came down to see the city and the tower, which the sons of men had =
built. And=20
  the LORD said, 'Behold, they are one people, and they have all one =
language;=20
  and this is only the beginning of what they will do; and nothing that =
they=20
  propose to do will now be impossible for them. Come, let us go down, =
and there=20
  confuse their language, that they may not understand one another's =
speech.' So=20
  the LORD scattered them abroad from there over the face of all the =
earth, and=20
  they left off building the city.' Therefore its name was called Babel, =
because=20
  there the LORD confused the language of all the earth; and from there =
the LORD=20
  scattered them abroad over the face of all the earth." (Genesis=20
  11:1-9)</FONT></FONT></STRONG></P>
  <P><STRONG><FONT face=3D&#44404;&#47548;>"Babel" is composed of two =
words, "baa" meaning=20
  "gate" and "el," "god." Hence, "the gate of god." A related word in =
Hebrew,=20
  "balal" means "confusion."&nbsp;&nbsp;&nbsp;&nbsp; (<A=20
  =
href=3D"http://www.ldolphin.org/babel.html">http://www.ldolphin.org/babel=
.html</A>)</FONT></STRONG></P></BLOCKQUOTE>
<P><STRONG><FONT face=3D&#44404;&#47548; size=3D2>Will IDN&nbsp; be "the =
gate of god" or=20
"confusion" to&nbsp;the mankind&nbsp;?</FONT></STRONG></P>
<P><STRONG><FONT face=3D&#44404;&#47548; size=3D2>Soobok =
Lee</FONT></STRONG></P>
<P><STRONG><FONT face=3D&#44404;&#47548; =
size=3D2></FONT></STRONG>&nbsp;</P></DIV>
<DIV><STRONG><FONT face=3D&#44404;&#47548; size=3D2>----- Original =
Message ----- </FONT></STRONG>
<DIV><STRONG><FONT face=3D&#44404;&#47548; size=3D2>From: "John C =
Klensin" &lt;</FONT></STRONG><A=20
href=3D"mailto:klensin@jck.com"><STRONG><FONT face=3D&#44404;&#47548;=20
size=3D2>klensin@jck.com</FONT></STRONG></A><STRONG><FONT =
face=3D&#44404;&#47548;=20
size=3D2>&gt;</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D&#44404;&#47548; size=3D2>To: "Edmon" =
&lt;</FONT></STRONG><A=20
href=3D"mailto:edmon@neteka.com"><STRONG><FONT face=3D&#44404;&#47548;=20
size=3D2>edmon@neteka.com</FONT></STRONG></A><STRONG><FONT =
face=3D&#44404;&#47548;=20
size=3D2>&gt;</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D&#44404;&#47548; size=3D2>Cc: =
&lt;</FONT></STRONG><A=20
href=3D"mailto:idn@ops.ietf.org"><STRONG><FONT face=3D&#44404;&#47548;=20
size=3D2>idn@ops.ietf.org</FONT></STRONG></A><STRONG><FONT =
face=3D&#44404;&#47548;=20
size=3D2>&gt;</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D&#44404;&#47548; size=3D2>Sent: Friday, =
January 04, 2002 1:45=20
AM</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D&#44404;&#47548; size=3D2>Subject: Re: =
Character equivalence mapping=20
(was: Re: [idn] SLC minutes)</FONT></STRONG></DIV></DIV>
<DIV><STRONG><BR><FONT face=3D&#44404;&#47548; =
size=3D2></FONT></STRONG></DIV><STRONG><FONT=20
face=3D&#44404;&#47548; size=3D2>&gt; --On Thursday, 03 January, 2002 =
11:31 -0500 Edmon<BR>&gt;=20
&lt;</FONT></STRONG><A href=3D"mailto:edmon@neteka.com"><STRONG><FONT =
face=3D&#44404;&#47548;=20
size=3D2>edmon@neteka.com</FONT></STRONG></A><STRONG><FONT =
face=3D&#44404;&#47548; size=3D2>&gt;=20
wrote:<BR>&gt; <BR>&gt; &gt;...<BR>&gt; &gt; The domain names as =
they<BR>&gt;=20
&gt; conceptually exist however should remain user friendly.&nbsp; =
In<BR>&gt;=20
&gt; other words, domain names for humans will contain context =
and<BR>&gt; &gt;=20
meaning (an "ALPHA" will be an "ALPHA" not "A"), but domain<BR>&gt; &gt; =
names=20
as viewed in the DNS (machine) should be devoid of<BR>&gt; &gt; =
context.&nbsp;=20
To bridge these two, a set of equivalent characters<BR>&gt; &gt; are =
prepared as=20
a table for the machine so that it can blindly<BR>&gt; &gt; treat them =
as=20
identical without contemplating its context.<BR>&gt; <BR>&gt; But, =
Edmon, we=20
already have disproofs of this in trademark<BR>&gt; registrations and =
the=20
registrars claim (and I believe them) that<BR>&gt; the companies =
involved are=20
anxious to take advantage of<BR>&gt; internationalization to register =
their=20
trademarks more directly<BR>&gt; in the DNS.&nbsp; We have organizations =
who=20
want to be <BR>&gt; &nbsp; =
&lt;alpha&gt;&lt;roman-i&gt;&lt;digits123&gt;<BR>&gt;=20
&nbsp; toys-&lt;cyrillic-ya&gt;-us<BR>&gt; and so on, a list that will =
certainly=20
get longer as more<BR>&gt; characters are perceived as available.&nbsp; =
<BR>&gt;=20
<BR>&gt; What you are trying to do also involves some rather =
complex<BR>&gt;=20
judgement calls which I don't know how to make.&nbsp; As someone =
who<BR>&gt; is=20
not very familiar with either, I've seen a number of font<BR>&gt; forms =
of=20
Arabic and Thai that I'm not sure I could tell apart,<BR>&gt; at least =
without=20
considerable context.&nbsp; I would assume that<BR>&gt; daily users of =
the two=20
scripts wouldn't have that problem, but<BR>&gt; who is to make the =
decision=20
about equivalence?<BR>&gt; <BR>&gt; It seems to me that there, in =
practice, are=20
only two ways to get<BR>&gt; what you want without ambiguity or =
confusion.&nbsp;=20
One goes down the<BR>&gt; path that Ken points out, which results, =
ultimately,=20
in<BR>&gt; "equivalencing" some very different things.&nbsp; And the =
other is=20
to<BR>&gt; say "ok, we will add characters to the LDH list, but only=20
those<BR>&gt; characters that cannot be confused with anything =
else,<BR>&gt;=20
regardless of the case or font used".&nbsp; Maybe, in the long =
term,<BR>&gt;=20
they turn out to be the same option.<BR>&gt; <BR>&gt; It would have the=20
advantage of adding many useful characters to<BR>&gt; the=20
DNS-application-permitted set (and Harald and Patrik could<BR>&gt; stop =
worrying=20
about the names of their respective sons :-)), but<BR>&gt; it would do =
almost=20
nothing for internationalization other than<BR>&gt; throwing us back =
into=20
strange transliterations or transpositions<BR>&gt; for many =
scripts.&nbsp;&nbsp;=20
Put differently, we would end up with a DNS<BR>&gt; character set that =
would=20
probably support Latin-1 and Han<BR>&gt; characters properly, but maybe =
nothing=20
else.&nbsp; I don't find that<BR>&gt; very satisfying, much as I am =
concerned=20
about accurate<BR>&gt; transcription of labels from printed form into =
the=20
DNS.<BR>&gt; <BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp; john<BR>&gt; <BR>&gt; =
<BR>&gt;=20
</FONT></STRONG></BODY></HTML>

------=_NextPart_000_0146_01C194C5.B416DD30--




From owner-idn@ops.ietf.org  Thu Jan  3 12:41:04 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06666
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 12:41:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MBg8-000IAn-00
	for idn-data@psg.com; Thu, 03 Jan 2002 09:29:20 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16MBg7-000IAh-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 09:29:19 -0800
Message-ID: <004701c1947d$6c394540$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: "John C Klensin" <klensin@jck.com>
Cc: <idn@ops.ietf.org>
References:  <003201c19474$16030b60$0601a8c0@neteka.com> <55201632.1010058315@P2>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Thu, 3 Jan 2002 12:38:12 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi John,

----- Original Message -----
From: "John C Klensin" <klensin@jck.com>
> --On Thursday, 03 January, 2002 11:31 -0500 Edmon
> <edmon@neteka.com> wrote:
>
> >...
> > The domain names as they
> > conceptually exist however should remain user friendly.  In
> > other words, domain names for humans will contain context and
> > meaning (an "ALPHA" will be an "ALPHA" not "A"), but domain
> > names as viewed in the DNS (machine) should be devoid of
> > context.  To bridge these two, a set of equivalent characters
> > are prepared as a table for the machine so that it can blindly
> > treat them as identical without contemplating its context.
>
> But, Edmon, we already have disproofs of this in trademark
> registrations and the registrars claim (and I believe them) that
> the companies involved are anxious to take advantage of
> internationalization to register their trademarks more directly
> in the DNS.

While I dont think that trademark struggles should have too much (note that
I used not "too much" and not "without") bearing on the way we need to treat
the DNS.  Additionally I think it would actually be better for the situation
with Character Equivalence preparation.

Imagine this:

Company 1: AB holds the trademark for AB and the domain AB.com
Company 2: <ALPHA><BETA> holds the trademark for <ALPHA><BETA> and the
domain <ALPHA><BETA>.com

Can Company 2 advertise as <ALPHA><BETA>.com literally in its capitalized
form as AB.com?

> We have organizations who want to be
>   <alpha><roman-i><digits123>
>   toys-<cyrillic-ya>-us
> and so on, a list that will certainly get longer as more
> characters are perceived as available.

They can be.  That is the whole point of IDN, and I do not refute it.  But
we need to make sure that as we introduce these extended characters, we do
not cannibalize on what the DNS should be and has become, and that is to
allow a human-friendly name to be publicized without ambiguity and used to
access a resource uniquely over the Internet.  What Character Equivalence
preparation tries to achieve is to preserve the two keys for the domain
names to be able to be "publicized without ambiguity" and to "access
resource uniquely".

> What you are trying to do also involves some rather complex
> judgement calls which I don't know how to make.  As someone who
> is not very familiar with either, I've seen a number of font
> forms of Arabic and Thai that I'm not sure I could tell apart,
> at least without considerable context.  I would assume that
> daily users of the two scripts wouldn't have that problem, but
> who is to make the decision about equivalence?

This is undeniably a good question, but does it mean that we should not do
anything about what we know?  So long as we remain open and make the
necessary ammendments as we go along, I dont think we will be condemned.
But not doing anything about it, we will risk being accused.

> it would do almost nothing for internationalization other than
> throwing us back into strange transliterations or transpositions
> for many scripts.   Put differently, we would end up with a DNS
> character set that would probably support Latin-1 and Han
> characters properly, but maybe nothing else.  I don't find that
> very satisfying, much as I am concerned about accurate
> transcription of labels from printed form into the DNS.

That is precisely the misconception I want to point out.  Because the DNS
matching process treats characters as equal doesnt mean that they cannot be
conveyed within context.  On the contrary, it is designed to better support
the ability for domain names to continue to become an integral part as it
has now in the everyday context of the Internet and its content.

For example, the owner of <Alpha><Beta>.example will not have to worry about
how his design on his business card or advertisements or letterheads look
like even if his designer decides that it looks best when everything is
capitalized.  Without Character Equivalence preparation, the owner has to
worry about the confusion and make sure that in all cases, whether it comes
out in a magazine article or an editorial on the local newspaper to remind
them that they must use the lowercase form and never use the uppercase form!
Does this not actually result in the strangeness that one might thought one
was avoiding by not introducing Character Equivalence preparations?

Edmon






From owner-idn@ops.ietf.org  Thu Jan  3 12:45:48 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06761
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 12:45:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MBmD-000IHz-00
	for idn-data@psg.com; Thu, 03 Jan 2002 09:35:37 -0800
Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MBmC-000IHl-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 09:35:36 -0800
Received: from [64.109.212.110] (adsl-64-109-212-110.dsl.lgnnmi.ameritech.net [64.109.212.110])
	by www.wordnic.com (8.9.3/8.9.3) with ESMTP id LAA20840
	for <idn@ops.ietf.org>; Thu, 3 Jan 2002 11:35:31 -0600
Mime-Version: 1.0
X-Sender: tedd1@sperling.com
Message-Id: <p05100301b85a3a6f6dd4@[64.109.212.110]>
In-Reply-To: <00aa01c1940f$ac0fee30$08d8ea0c@c1340594a>
References: <200201030151.RAA03854@birdie.sybase.com>
 <00aa01c1940f$ac0fee30$08d8ea0c@c1340594a>
Date: Thu, 3 Jan 2002 12:35:25 -0500
To: <idn@ops.ietf.org>
From: tedd <tedd@sperling.com>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA06761

Mark, john, Edmon:

>1. This issue was debated at length some time ago. I suggest that the people
>arguing for visual confusability as a criterion for matching look at that
>discussion in detail before proceding.

I'm not arguing (in this debate) the "look-a-like" position. In other 
words, it makes no difference to me if certain glyph's look identical 
in numerous char sets. I am arguing the opposite position -- the 
characters in my example don't look a like.

I am arguing the point that the decision "has been made" to map upper 
case Greek letters to lower case letters. For proof, look at the 
current version of nameprep ( http://www.imc.org/nameprep/  ) and try 
running code point 2126 (upper case omega) through it. You will find 
that it IS mapped to code point 03A9 (lower case omega).

My question is "Why?" What's the foundation for this determination? 
For what good reason is there to conclude that the upper case Omega 
should be mapped to a lower case omega?

I see no "A.com" to  "a.com" argument/problem here. Clearly, if 
someone registered �.com and someone else registered w.com there is 
significant difference in identification between the two names. Those 
two domain names can be completely unique domain names with no 
significant resultant problems. Whereas, in the Latin char set, I can 
see the reason for making W.com and w.com identical (i.e., mapping W 
to w) because there is an UC/LC consideration/distinction in the 
language. But, that's not a problem in the Greek char set -- is it... 
really?

>(i) From observation, when scripts have two cases, the
>upper-case form is more likely to be highly stylized, and hence
>differentiated from characters in other scripts, than the
>lower-case one.  Hence, if one is going to adopt
>stylization-based (glyph-distinction, if you prefer)
>canonicalization rules, one is better off treating upper case as
>the normal form, rather than lower case.

It looks to me as if someone has already made the determination to 
map other languages based upon the Latin char set UC/LC problem 
without concern that other languages may not have the UC/LC 
distinction and thus be absent of the UC/LC problem. I think the 
Greek example I gave above sufficiently demonstrates my observation.

tedd

-- 
http://sperling.com



From owner-idn@ops.ietf.org  Thu Jan  3 13:04:50 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07300
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 13:04:49 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MC2K-000Ifh-00
	for idn-data@psg.com; Thu, 03 Jan 2002 09:52:16 -0800
Received: from rwcrmhc51.attbi.com ([204.127.198.38])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MC2J-000Ifb-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 09:52:15 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020103175215.FNJI20119.rwcrmhc51.attbi.com@c1340594a>;
          Thu, 3 Jan 2002 17:52:15 +0000
Message-ID: <009d01c1947f$a1b2eda0$08d8ea0c@c1340594a>
From: "Mark Davis" <mark.davis@macchiato.com>
To: <idn@ops.ietf.org>, "tedd" <tedd@sperling.com>
References: <200201030151.RAA03854@birdie.sybase.com> <00aa01c1940f$ac0fee30$08d8ea0c@c1340594a> <p05100301b85a3a6f6dd4@[64.109.212.110]>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Thu, 3 Jan 2002 09:54:02 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Other scripts do have upper/lowercase correspondences, just like the Latin
script does. Users of those scripts are just as likely to want caseless
matching as users of the Latin script (such as you).

For more information, see http://www.unicode.org/unicode/reports/tr21/.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "tedd" <tedd@sperling.com>
To: <idn@ops.ietf.org>
Sent: Thursday, January 03, 2002 09:35
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)


Mark, john, Edmon:

>1. This issue was debated at length some time ago. I suggest that the
people
>arguing for visual confusability as a criterion for matching look at that
>discussion in detail before proceding.

I'm not arguing (in this debate) the "look-a-like" position. In other
words, it makes no difference to me if certain glyph's look identical
in numerous char sets. I am arguing the opposite position -- the
characters in my example don't look a like.

I am arguing the point that the decision "has been made" to map upper
case Greek letters to lower case letters. For proof, look at the
current version of nameprep ( http://www.imc.org/nameprep/  ) and try
running code point 2126 (upper case omega) through it. You will find
that it IS mapped to code point 03A9 (lower case omega).

My question is "Why?" What's the foundation for this determination?
For what good reason is there to conclude that the upper case Omega
should be mapped to a lower case omega?

I see no "A.com" to  "a.com" argument/problem here. Clearly, if
someone registered ?.com and someone else registered w.com there is
significant difference in identification between the two names. Those
two domain names can be completely unique domain names with no
significant resultant problems. Whereas, in the Latin char set, I can
see the reason for making W.com and w.com identical (i.e., mapping W
to w) because there is an UC/LC consideration/distinction in the
language. But, that's not a problem in the Greek char set -- is it...
really?

>(i) From observation, when scripts have two cases, the
>upper-case form is more likely to be highly stylized, and hence
>differentiated from characters in other scripts, than the
>lower-case one.  Hence, if one is going to adopt
>stylization-based (glyph-distinction, if you prefer)
>canonicalization rules, one is better off treating upper case as
>the normal form, rather than lower case.

It looks to me as if someone has already made the determination to
map other languages based upon the Latin char set UC/LC problem
without concern that other languages may not have the UC/LC
distinction and thus be absent of the UC/LC problem. I think the
Greek example I gave above sufficiently demonstrates my observation.

tedd

--
http://sperling.com






From owner-idn@ops.ietf.org  Thu Jan  3 14:16:19 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08661
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 14:16:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MD8s-000K1g-00
	for idn-data@psg.com; Thu, 03 Jan 2002 11:03:06 -0800
Received: from rwcrmhc52.attbi.com ([216.148.227.88])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MD8s-000K1Y-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 11:03:06 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc52.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020103190300.XGSI6450.rwcrmhc52.attbi.com@c1340594a>;
          Thu, 3 Jan 2002 19:03:00 +0000
Message-ID: <003401c19489$83f5d0c0$08d8ea0c@c1340594a>
From: "Mark Davis" <mark.davis@macchiato.com>
To: "Edmon" <edmon@neteka.com>
Cc: <idn@ops.ietf.org>
References:  <003201c19474$16030b60$0601a8c0@neteka.com> <55201632.1010058315@P2> <004701c1947d$6c394540$0601a8c0@neteka.com>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Thu, 3 Jan 2002 11:04:48 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

You do not seem to have read the material I suggested. There was quite a
discussion on this list on why it is hopeless AND counterproductive to try
identify all the characters whose glyphs could be visually indistinguishable
to a user, and create equivalence classes based upon that identification.

Hopeless: For this to be used in IDN, one would have to collect a massive
amount of data; and all at once -- the mappings can't simply change over
time. There are a huge number of questionable cases, where for accuracy one
would have to survey a substantial range of fonts in the common sizes used
on different platforms to determine visual distinguishability. Examples are
quotation dash and the CJK character for "one", the katakana KA and the CJK
character for power, etc. And in many of those cases, one would still have
to make a judgment call, since even if the pixels are always somewhat
different, users may perceive the glyphs as being the same.

Counterproductive: As I noted earlier, the N / V problem arises hundreds of
times -- a lowercase greek nu in common fonts (e.g. Arial Unicode MS) is
visually indistinguishable from a Latin v. That causes N, V, n, v, NU, nu to
be part of the same equivalence class, so a company could not register
NIA.com if VIA.com were already registered.


Although it is certainly "in character" for this list to endlessly (and
pointlessly) repeat earlier discussions, I'd suggest you look at the email
archives on this topic, since this subject has arisen many times. After you
have read them, if you have any new information it might be worth continuing
the discussion.

Mark

P.S. Unfortunately, there appears to be no web interface for viewing the
archive, so it is a bit clumsy to search for particular topics. I think this
topic was discussed at length sometime in 2000, with repeated comments
through 2001.

—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
Sent: Thursday, January 03, 2002 10:39


> QUIT
> QUIT
> Message-ID: <005101c19487$36192d40$0601a8c0@neteka.com>
> From: "Edmon" <edmon@neteka.com>
> To: "Mark Davis" <mark.davis@macchiato.com>
> References: <20020103160357.XKGT27210.rwcrgwc53.attbi.com@c001.snv.cp.net>
<008b01c1947d$03a4a830$08d8ea0c@c1340594a>
> Subject: Re:
> Date: Thu, 3 Jan 2002 13:48:13 -0500
> MIME-Version: 1.0
> Content-Type: text/plain;
> charset="utf-8"
> Content-Transfer-Encoding: 8bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 5.50.4522.1200
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
>
> Hi Mark,
>
> But I am not suggesting any transliteration or transformation.  I am only
> suggesting that some characters which might be "perceived" or "confused"
as
> equivalent/identical be collected together and regarded as "equivalent"
> during the DNS name matching process within the DNS server.  It should not
> hinder the ability to have different characters or representations send
> different data over the wire and to maintain the original information.
>
> Take for example the current DNS, neither uppercase or lowercase is the
> "primary" case, they are considered equal.  Which means that you can have
a
> domain that is DoMaIn.CoM, as well as a domain that is domain.COM, but
> during the matching process, the DNS will declare that they are the same.
> Not that it is mapped to (or declared to be "same as") domain.com or
> DOMAIN.COM, they are simply considered equivalent.  (at least it is what
its
> supposed to do I think)
>
> So, what is the complexity except for coming up with the exact list?  The
> "exact list" I believe should be a living document and be revised over
time,
> but we need to start somewhere.  It should be relatively uncomplicated to
> come up with a list for Latin-Greek-Cyrillic equivalent characters.  In
> fact, I think I dont mind working on a table that contains ones that could
> be "perceived" as equivalent to start with and allow other people to
> scrutinize on each's equivalence in form.  Or do you know if there is such
a
> list already?
>
> Edmon
>
>
>
> ----- Original Message -----
> From: "Mark Davis" <mark.davis@macchiato.com>
> To: <edmon@neteka.com>
> Cc: "Kenneth Whistler" <kenw@sybase.com>
> Sent: Thursday, January 03, 2002 12:00 PM
> Subject: Re:
>
>
> > It is not that simple. I suggest you review the messages on this topic
in
> > the archive for this list, and also read both of the following:
> >
> > http://www.unicode.org/unicode/standard/where/
> > http://www.unicode.org/unicode/reports/tr17/
> >
> > Mark
> > —————
> >
> > Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο
> πάντα — Ὁμήρου Μαργίτῃ
> > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
> >
> > http://www.macchiato.com
> >
> > ----- Original Message -----
> > Sent: Thursday, January 03, 2002 08:03
> >
> >
> > > QUIT
> > > QUIT
> > > Message-ID: <002f01c19471$822bac00$0601a8c0@neteka.com>
> > > From: "Edmon" <edmon@neteka.com>
> > > To: "Mark Davis" <mark.davis@macchiato.com>
> > > References: <200201030151.RAA03854@birdie.sybase.com>
> > <00aa01c1940f$ac0fee30$08d8ea0c@c1340594a>
> > > Subject: Re: Character equivalence mapping (was: Re: [idn] SLC
minutes)
> > > Date: Thu, 3 Jan 2002 11:12:53 -0500
> > > MIME-Version: 1.0
> > > Content-Type: text/plain;
> > > charset="utf-8"
> > > Content-Transfer-Encoding: 7bit
> > > X-Priority: 3
> > > X-MSMail-Priority: Normal
> > > X-Mailer: Microsoft Outlook Express 5.50.4522.1200
> > > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
> > >
> > > Hi Mark
> > >
> > > From: "Mark Davis" <mark.davis@macchiato.com>
> > > > 2. Moreover, stop and think about the implications; using both case
> > > folding
> > > > and visual confusability would have some very unpleasant
consequences.
> > For
> > > > example, it would force the ASCII letters N and V to be in the same
> > > > equivalence class:
> > >
> > > I will argue that <nu> and v have some subtle difference while <ALPHA>
> and
> > > A, <NU> and N,  are truly identical.  Perhaps character equivalence
was
> > not
> > > a good choice of word, lets try Character Identicality.  I think there
> are
> > > some characters that we can truly say that they are "identical" under
> > > scrutiny.  Do you think so?
> > >
> > > Edmon
> > >
> > >
> > >
> >
>
>
>




From owner-idn@ops.ietf.org  Thu Jan  3 15:26:12 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10429
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 15:26:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MEFw-000LkG-00
	for idn-data@psg.com; Thu, 03 Jan 2002 12:14:28 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MEFu-000LkA-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 12:14:27 -0800
Received: from smtp1.sybase.com (sybgate.sybase.com [130.214.220.35])
	by inergen.sybase.com  with ESMTP id MAA18359
	for <idn@ops.ietf.org>; Thu, 3 Jan 2002 12:14:22 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id MAA22662
	for <idn@ops.ietf.org>; Thu, 3 Jan 2002 12:14:24 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id MAA22635;
	Thu, 3 Jan 2002 12:14:22 -0800 (PST)
Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5)
	id MAA08778; Thu, 3 Jan 2002 12:14:22 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id MAA03967;
	Thu, 3 Jan 2002 12:14:21 -0800 (PST)
Date: Thu, 3 Jan 2002 12:14:21 -0800 (PST)
From: Kenneth Whistler <kenw@sybase.com>
Message-Id: <200201032014.MAA03967@birdie.sybase.com>
To: mark.davis@macchiato.com
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Cc: idn@ops.ietf.org
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Mark said:

> Counterproductive: As I noted earlier, the N / V problem arises hundreds of
> times -- a lowercase greek nu in common fonts (e.g. Arial Unicode MS) is
> visually indistinguishable from a Latin v. That causes N, V, n, v, NU, nu to
> be part of the same equivalence class, so a company could not register
> NIA.com if VIA.com were already registered.

And furthermore, to prevent total havoc for existing registrations, you'd
have to check and prevent any such overlapping equivalence classes while
drafting the list of character equivalences in the first place. This would
*force* one to allow visual confusables like v/nu to be distinct -- creating
unaccountable exceptions to the goal of character equivalence mapping from
the start.

By the way, via.org belongs to the Valencia Industrial Association, and
nia.org to the National Insulator Association.

--Ken



From owner-idn@ops.ietf.org  Thu Jan  3 17:26:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12654
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 17:26:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MG7b-000OZp-00
	for idn-data@psg.com; Thu, 03 Jan 2002 14:13:59 -0800
Received: from thorium.singnet.com.sg ([165.21.74.73] helo=thorium.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MG7a-000OZf-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 14:13:59 -0800
Received: from mail pickup service by thorium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 4 Jan 2002 06:06:23 +0800
Received: from mx16.singnet.com.sg ([165.21.74.116]) by thorium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 4 Jan 2002 00:51:18 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx16.singnet.com.sg (8.11.5/8.11.5) with ESMTP id g03GeCL29291
	for <milton8@singnet.com.sg>; Fri, 4 Jan 2002 00:40:12 +0800
Received: by blake.i-email.net (Postfix)
	id 5CC3CA890C; Fri,  4 Jan 2002 00:51:14 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id 8A28DA8901
	for <milton@i-email.net>; Fri,  4 Jan 2002 00:51:11 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MAdP-000GuR-00
	for idn-data@psg.com; Thu, 03 Jan 2002 08:22:27 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16MAdO-000GuK-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 08:22:27 -0800
Message-ID: <003201c19474$16030b60$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: "John C Klensin" <klensin@jck.com>, "Kenneth Whistler" <kenw@sybase.com>
Cc: <idn@ops.ietf.org>
References:  <200201030151.RAA03854@birdie.sybase.com> <4524066.1010007646@localhost>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Thu, 3 Jan 2002 11:31:22 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi John & Ken,

> > The problem of "AB.example" is generally dealt with by
> > context.

But the context of domain names is Internet, and the Internet is
conceptually and practically becoming multilingual, which is why we are
discussing this issue today.  Therefore, the point is that if the context is
multilingual, AB.example needs to be unique regardless of what the
"intended" "language" is, because the "perceived" character is what becomes
the context in itself.  Therefore, the context of a character is the
character itself.  Whether by a Latin-trained-eye or by an
Arabic-trained-eye or a Chinese-trained-eye, some characters are
unmistakably identical.  That is the root of the problem at hand.

> > First of all "example" would be in Greek if I was
> > really dealing with Greek. Second, if I wanted people to enter
> > "ab.whatever" I'd be advertising in *English* to set the
> > expectations. If I wanted people to enter
> > "<alpha><beta>.....", I'd be advertising in *Greek* to set the
> > expectations, and people would be using Greek keyboards and
> > expect to enter Greek.

This is a presumption.  And "localization" by TLD is beyond the
technicalities of trying to make a solid IDN solution.  We should not resort
to the management of TLDs to finish our job..?..

Again, context should be irrelevant because context is not known.
For example (really just an example, there could be other cases)
I dont know greek, but I see an interesting ad that I think might be for a
Greek translation service.
I see the domain A2<beta>.example, (the actual domain was
<ALPHA>2<beta>.example)
I try it as I see it, it goes elsewhere.

> While I think Edmon's notions would make
> that problem worse, rather than better (hence my attempt at a
> reductio ad absurdum argument in my earlier note),

My notion is to keep the DNS stupid and just map all Characters with
"perceived" equivalence during internal matching.  The domain names as they
conceptually exist however should remain user friendly.  In other words,
domain names for humans will contain context and meaning (an "ALPHA" will be
an "ALPHA" not "A"), but domain names as viewed in the DNS (machine) should
be devoid of context.  To bridge these two, a set of equivalent characters
are prepared as a table for the machine so that it can blindly treat them as
identical without contemplating its context.

> I don't
> believe that "resolve by context" is going to be realistic in
> practice --again, in the DNS context-- either.

Very Agreeable.

Edmon


...Just as a final note here, I think Character Equivalence mapping could be
an optional "best practice" type of configuration for zone operators to
provide to their users, however, it would be a good idea to have a
technically sound approach, which is what I am trying to discuss.




From owner-idn@ops.ietf.org  Thu Jan  3 17:51:57 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13004
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 17:51:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MGa1-000PDa-00
	for idn-data@psg.com; Thu, 03 Jan 2002 14:43:21 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16MGa0-000PDU-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 14:43:20 -0800
Message-ID: <007901c194a9$340f8220$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: "Mark Davis" <mark.davis@macchiato.com>
Cc: <idn@ops.ietf.org>
References:  <003201c19474$16030b60$0601a8c0@neteka.com> <55201632.1010058315@P2> <004701c1947d$6c394540$0601a8c0@neteka.com> <003401c19489$83f5d0c0$08d8ea0c@c1340594a>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Thu, 3 Jan 2002 17:51:36 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

First of all, allow me to say that I am not proposing to have Character
Equivalence preparations in the "protocol".
In fact, I intend this topic to be more "operational", and I have mentioned
that this might not be the best list to discuss this, but I did want to
clarify what I said during the SLC meeting as was noted in the minutes
(which was what started this discussion).  Also, since the interested
parties on this topic is likely going to be on this list too.
I apologize for lingering on the discussion, but allow me to say the
following:

I do believe very much that since this issue sparks so much contention, we
should archive the problem and discussions better, perhaps into an
informational document, pointing out that there are a set of codepoints that
may be perceived as equivalent.  This in fact would include issues for
Latin-Greek-Cyrillic (LGC) characters as well as at least JPCHAR, HangulChar
and T/S Chinese.  Becuase we do not have much information on Arabic and the
other General Scripts, that is why I said that this document should be a
living document.  If it becomes apparent that some Character Equivalence
preparation is beneficial for these scripts, then we can ammend the
document.

The document will contain a discussion on the different issues surrounding
LGC and CJK characters in Unicode respectively, as well as a set of tables
that lists out the equivalent characters.

With this document, a zone operator (whether a local zone manager or a TLD
manager) can choose one of three approaches to deal with the issue (and can
choose to implment the mappings and which mappings to use for their own
zone):
1. do nothing
2. multiple registrations
3. consolidate characters before name matching within the name server

It will alarm me if anyone thinks that this is useless because they are real
issues that an implementor should be aware of.

Edmon


----- Original Message -----
From: "Mark Davis" <mark.davis@macchiato.com>
To: "Edmon" <edmon@neteka.com>
Cc: <idn@ops.ietf.org>
Sent: Thursday, January 03, 2002 2:04 PM
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)


> You do not seem to have read the material I suggested. There was quite a
> discussion on this list on why it is hopeless AND counterproductive to try
> identify all the characters whose glyphs could be visually
indistinguishable
> to a user, and create equivalence classes based upon that identification.
>
> Hopeless: For this to be used in IDN, one would have to collect a massive
> amount of data; and all at once -- the mappings can't simply change over
> time. There are a huge number of questionable cases, where for accuracy
one
> would have to survey a substantial range of fonts in the common sizes used
> on different platforms to determine visual distinguishability. Examples
are
> quotation dash and the CJK character for "one", the katakana KA and the
CJK
> character for power, etc. And in many of those cases, one would still have
> to make a judgment call, since even if the pixels are always somewhat
> different, users may perceive the glyphs as being the same.
>
> Counterproductive: As I noted earlier, the N / V problem arises hundreds
of
> times -- a lowercase greek nu in common fonts (e.g. Arial Unicode MS) is
> visually indistinguishable from a Latin v. That causes N, V, n, v, NU, nu
to
> be part of the same equivalence class, so a company could not register
> NIA.com if VIA.com were already registered.
>
>
> Although it is certainly "in character" for this list to endlessly (and
> pointlessly) repeat earlier discussions, I'd suggest you look at the email
> archives on this topic, since this subject has arisen many times. After
you
> have read them, if you have any new information it might be worth
continuing
> the discussion.
>
> Mark
>
> P.S. Unfortunately, there appears to be no web interface for viewing the
> archive, so it is a bit clumsy to search for particular topics. I think
this
> topic was discussed at length sometime in 2000, with repeated comments
> through 2001.
>
> —————
>
> Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο
πάντα — Ὁμήρου Μαργίτῃ
> [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
>
> http://www.macchiato.com
>
> ----- Original Message -----
> Sent: Thursday, January 03, 2002 10:39
>
>
> > QUIT
> > QUIT
> > Message-ID: <005101c19487$36192d40$0601a8c0@neteka.com>
> > From: "Edmon" <edmon@neteka.com>
> > To: "Mark Davis" <mark.davis@macchiato.com>
> > References:
<20020103160357.XKGT27210.rwcrgwc53.attbi.com@c001.snv.cp.net>
> <008b01c1947d$03a4a830$08d8ea0c@c1340594a>
> > Subject: Re:
> > Date: Thu, 3 Jan 2002 13:48:13 -0500
> > MIME-Version: 1.0
> > Content-Type: text/plain;
> > charset="utf-8"
> > Content-Transfer-Encoding: 8bit
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Mailer: Microsoft Outlook Express 5.50.4522.1200
> > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
> >
> > Hi Mark,
> >
> > But I am not suggesting any transliteration or transformation.  I am
only
> > suggesting that some characters which might be "perceived" or "confused"
> as
> > equivalent/identical be collected together and regarded as "equivalent"
> > during the DNS name matching process within the DNS server.  It should
not
> > hinder the ability to have different characters or representations send
> > different data over the wire and to maintain the original information.
> >
> > Take for example the current DNS, neither uppercase or lowercase is the
> > "primary" case, they are considered equal.  Which means that you can
have
> a
> > domain that is DoMaIn.CoM, as well as a domain that is domain.COM, but
> > during the matching process, the DNS will declare that they are the
same.
> > Not that it is mapped to (or declared to be "same as") domain.com or
> > DOMAIN.COM, they are simply considered equivalent.  (at least it is what
> its
> > supposed to do I think)
> >
> > So, what is the complexity except for coming up with the exact list?
The
> > "exact list" I believe should be a living document and be revised over
> time,
> > but we need to start somewhere.  It should be relatively uncomplicated
to
> > come up with a list for Latin-Greek-Cyrillic equivalent characters.  In
> > fact, I think I dont mind working on a table that contains ones that
could
> > be "perceived" as equivalent to start with and allow other people to
> > scrutinize on each's equivalence in form.  Or do you know if there is
such
> a
> > list already?
> >
> > Edmon
> >
> >
> >
> > ----- Original Message -----
> > From: "Mark Davis" <mark.davis@macchiato.com>
> > To: <edmon@neteka.com>
> > Cc: "Kenneth Whistler" <kenw@sybase.com>
> > Sent: Thursday, January 03, 2002 12:00 PM
> > Subject: Re:
> >
> >
> > > It is not that simple. I suggest you review the messages on this topic
> in
> > > the archive for this list, and also read both of the following:
> > >
> > > http://www.unicode.org/unicode/standard/where/
> > > http://www.unicode.org/unicode/reports/tr17/
> > >
> > > Mark
> > > —————
> > >
> > > Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο
> > πάντα — Ὁμήρου Μαργίτῃ
> > > [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
> > >
> > > http://www.macchiato.com
> > >
> > > ----- Original Message -----
> > > Sent: Thursday, January 03, 2002 08:03
> > >
> > >
> > > > QUIT
> > > > QUIT
> > > > Message-ID: <002f01c19471$822bac00$0601a8c0@neteka.com>
> > > > From: "Edmon" <edmon@neteka.com>
> > > > To: "Mark Davis" <mark.davis@macchiato.com>
> > > > References: <200201030151.RAA03854@birdie.sybase.com>
> > > <00aa01c1940f$ac0fee30$08d8ea0c@c1340594a>
> > > > Subject: Re: Character equivalence mapping (was: Re: [idn] SLC
> minutes)
> > > > Date: Thu, 3 Jan 2002 11:12:53 -0500
> > > > MIME-Version: 1.0
> > > > Content-Type: text/plain;
> > > > charset="utf-8"
> > > > Content-Transfer-Encoding: 7bit
> > > > X-Priority: 3
> > > > X-MSMail-Priority: Normal
> > > > X-Mailer: Microsoft Outlook Express 5.50.4522.1200
> > > > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
> > > >
> > > > Hi Mark
> > > >
> > > > From: "Mark Davis" <mark.davis@macchiato.com>
> > > > > 2. Moreover, stop and think about the implications; using both
case
> > > > folding
> > > > > and visual confusability would have some very unpleasant
> consequences.
> > > For
> > > > > example, it would force the ASCII letters N and V to be in the
same
> > > > > equivalence class:
> > > >
> > > > I will argue that <nu> and v have some subtle difference while
<ALPHA>
> > and
> > > > A, <NU> and N,  are truly identical.  Perhaps character equivalence
> was
> > > not
> > > > a good choice of word, lets try Character Identicality.  I think
there
> > are
> > > > some characters that we can truly say that they are "identical"
under
> > > > scrutiny.  Do you think so?
> > > >
> > > > Edmon
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
>




From owner-idn@ops.ietf.org  Thu Jan  3 17:53:08 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13024
	for <idn-archive@lists.ietf.org>; Thu, 3 Jan 2002 17:53:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MGYw-000PCX-00
	for idn-data@psg.com; Thu, 03 Jan 2002 14:42:14 -0800
Received: from hafnium.singnet.com.sg ([165.21.74.90] helo=hafnium.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MGYv-000PCP-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 14:42:14 -0800
Received: from mail pickup service by hafnium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 4 Jan 2002 06:39:32 +0800
Received: from mail pickup service by hafnium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 4 Jan 2002 06:36:12 +0800
Received: from mx15.singnet.com.sg ([165.21.74.115]) by hafnium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 4 Jan 2002 04:28:02 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx15.singnet.com.sg (8.11.5/8.11.5) with ESMTP id g03KOB013758
	for <milton8@singnet.com.sg>; Fri, 4 Jan 2002 04:24:11 +0800
Received: by blake.i-email.net (Postfix)
	id 34D3EA890D; Fri,  4 Jan 2002 04:28:00 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id B874AA8901
	for <milton@i-email.net>; Fri,  4 Jan 2002 04:27:59 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MEFw-000LkG-00
	for idn-data@psg.com; Thu, 03 Jan 2002 12:14:28 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MEFu-000LkA-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 12:14:27 -0800
Received: from smtp1.sybase.com (sybgate.sybase.com [130.214.220.35])
	by inergen.sybase.com  with ESMTP id MAA18359
	for <idn@ops.ietf.org>; Thu, 3 Jan 2002 12:14:22 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id MAA22662
	for <idn@ops.ietf.org>; Thu, 3 Jan 2002 12:14:24 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id MAA22635;
	Thu, 3 Jan 2002 12:14:22 -0800 (PST)
Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5)
	id MAA08778; Thu, 3 Jan 2002 12:14:22 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id MAA03967;
	Thu, 3 Jan 2002 12:14:21 -0800 (PST)
Date: Thu, 3 Jan 2002 12:14:21 -0800 (PST)
From: Kenneth Whistler <kenw@sybase.com>
Message-Id: <200201032014.MAA03967@birdie.sybase.com>
To: mark.davis@macchiato.com
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Cc: idn@ops.ietf.org
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Mark said:

> Counterproductive: As I noted earlier, the N / V problem arises hundreds of
> times -- a lowercase greek nu in common fonts (e.g. Arial Unicode MS) is
> visually indistinguishable from a Latin v. That causes N, V, n, v, NU, nu to
> be part of the same equivalence class, so a company could not register
> NIA.com if VIA.com were already registered.

And furthermore, to prevent total havoc for existing registrations, you'd
have to check and prevent any such overlapping equivalence classes while
drafting the list of character equivalences in the first place. This would
*force* one to allow visual confusables like v/nu to be distinct -- creating
unaccountable exceptions to the goal of character equivalence mapping from
the start.

By the way, via.org belongs to the Valencia Industrial Association, and
nia.org to the National Insulator Association.

--Ken



From owner-idn@ops.ietf.org  Fri Jan  4 00:24:57 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19796
	for <idn-archive@lists.ietf.org>; Fri, 4 Jan 2002 00:24:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MMYe-0007WC-00
	for idn-data@psg.com; Thu, 03 Jan 2002 21:06:20 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MMYd-0007W2-00
	for idn@ops.ietf.org; Thu, 03 Jan 2002 21:06:19 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP
	id 851B3FFC0C; Fri,  4 Jan 2002 13:05:00 +0800 (SGT)
Message-ID: <006a01c194dd$850bc970$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Mark Davis" <mark.davis@macchiato.com>
Cc: <idn@ops.ietf.org>
References:  <003201c19474$16030b60$0601a8c0@neteka.com> <55201632.1010058315@P2> <004701c1947d$6c394540$0601a8c0@neteka.com> <003401c19489$83f5d0c0$08d8ea0c@c1340594a>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Fri, 4 Jan 2002 13:06:02 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

If you mean archive of the IDN list on the web, this is the URL :-)

http://www.imc.org/idn/mail-archive/maillist.html

-James Seng

> P.S. Unfortunately, there appears to be no web interface for viewing
the
> archive, so it is a bit clumsy to search for particular topics. I
think this
> topic was discussed at length sometime in 2000, with repeated comments
> through 2001.





From owner-idn@ops.ietf.org  Fri Jan  4 10:47:56 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06235
	for <idn-archive@lists.ietf.org>; Fri, 4 Jan 2002 10:47:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MWIe-000M1Q-00
	for idn-data@psg.com; Fri, 04 Jan 2002 07:30:28 -0800
Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MWId-000M1I-00
	for idn@ops.ietf.org; Fri, 04 Jan 2002 07:30:27 -0800
Received: from [64.109.212.209] (adsl-64-109-212-209.dsl.lgnnmi.ameritech.net [64.109.212.209])
	by www.wordnic.com (8.9.3/8.9.3) with ESMTP id JAA00860
	for <idn@ops.ietf.org>; Fri, 4 Jan 2002 09:30:16 -0600
Mime-Version: 1.0
X-Sender: tedd1@sperling.com
Message-Id: <p0510030bb85b7afe04f6@[64.109.212.209]>
Date: Fri, 4 Jan 2002 10:30:18 -0500
To: <idn@ops.ietf.org>
From: tedd <tedd@sperling.com>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA06235

Mark:

Alright, if the Greek script is forced into case-less matching, then 
why does it have to be mapped from Upper to Lower Case? I can see 
that mapping the upper case Alpha to the lower case alpha makes sense 
in terms of not confusing the Latin "A" vs Greek "Alpha" issue. But, 
forcing Omega to be mapped to omega only compounds the Latin "w" vs 
Greek "w" issue. Are there any considerations for these types of 
mapping issues, or is it summarily determined UC ->UC in all matters 
regardless?

tedd


>Other scripts do have upper/lowercase correspondences, just like the Latin
>script does. Users of those scripts are just as likely to want caseless
>matching as users of the Latin script (such as you).
>
>For more information, see http://www.unicode.org/unicode/reports/tr21/.
>
>Mark
>-----
>
>P?ll' ?�?stato ?rga, kak?V d' ?�?stato �?nta - ?m?rou Marg?t?
>[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
>
>http://www.macchiato.com
>
>----- Original Message -----
>From: "tedd" <tedd@sperling.com>
>To: <idn@ops.ietf.org>
>Sent: Thursday, January 03, 2002 09:35
>Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
>
>
>Mark, john, Edmon:
>
>>1. This issue was debated at length some time ago. I suggest that the
>people
>>arguing for visual confusability as a criterion for matching look at that
>>discussion in detail before proceding.
>
>I'm not arguing (in this debate) the "look-a-like" position. In other
>words, it makes no difference to me if certain glyph's look identical
>in numerous char sets. I am arguing the opposite position -- the
>characters in my example don't look a like.
>
>I am arguing the point that the decision "has been made" to map upper
>case Greek letters to lower case letters. For proof, look at the
>current version of nameprep ( http://www.imc.org/nameprep/  ) and try
>running code point 2126 (upper case omega) through it. You will find
>that it IS mapped to code point 03A9 (lower case omega).
>
>My question is "Why?" What's the foundation for this determination?
>For what good reason is there to conclude that the upper case Omega
>should be mapped to a lower case omega?
>
>I see no "A.com" to  "a.com" argument/problem here. Clearly, if
>someone registered ?.com and someone else registered w.com there is
>significant difference in identification between the two names. Those
>two domain names can be completely unique domain names with no
>significant resultant problems. Whereas, in the Latin char set, I can
>see the reason for making W.com and w.com identical (i.e., mapping W
>to w) because there is an UC/LC consideration/distinction in the
>language. But, that's not a problem in the Greek char set -- is it...
>really?
>
>>(i) From observation, when scripts have two cases, the
>>upper-case form is more likely to be highly stylized, and hence
>>differentiated from characters in other scripts, than the
>>lower-case one.  Hence, if one is going to adopt
>>stylization-based (glyph-distinction, if you prefer)
>>canonicalization rules, one is better off treating upper case as
>>the normal form, rather than lower case.
>
>It looks to me as if someone has already made the determination to
>map other languages based upon the Latin char set UC/LC problem
>without concern that other languages may not have the UC/LC
>distinction and thus be absent of the UC/LC problem. I think the
>Greek example I gave above sufficiently demonstrates my observation.
>
>tedd
>
>--
>http://sperling.com


-- 
http://sperling.com



From owner-idn@ops.ietf.org  Fri Jan  4 11:54:27 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08425
	for <idn-archive@lists.ietf.org>; Fri, 4 Jan 2002 11:54:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16MXRh-000Ny8-00
	for idn-data@psg.com; Fri, 04 Jan 2002 08:43:53 -0800
Received: from rwcrmhc51.attbi.com ([204.127.198.38])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16MXRg-000Ny2-00
	for idn@ops.ietf.org; Fri, 04 Jan 2002 08:43:52 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020104164352.JODZ20119.rwcrmhc51.attbi.com@c1340594a>;
          Fri, 4 Jan 2002 16:43:52 +0000
Message-ID: <012901c1953f$3f1c6bb0$08d8ea0c@c1340594a>
From: "Mark Davis" <mark.davis@macchiato.com>
To: <idn@ops.ietf.org>, "tedd" <tedd@sperling.com>
References: <p0510030bb85b7afe04f6@[64.109.212.209]>
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
Date: Fri, 4 Jan 2002 08:45:41 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

The reasons lowercase was uniformally chosen for case folding of Latin,
Greek, Cyrillic and Armenian in Unicode are (a) the vast majority of text in
use is in lowercase, and (b) there are a number of lowercase characters that
don't have uppercase forms (but may in the future). Moreover, the uppercase
forms are in general more visually confusable than the lowercase are. Take a
look at:

http://www.unicode.org/charts/PDF/U0370.pdf
http://www.unicode.org/charts/PDF/U0400.pdf
http://www.unicode.org/charts/PDF/U0530.pdf

BTW, there are also some pretty odd looking Latin characters, see:

http://www.unicode.org/charts/PDF/U0180.pdf

Not to mention the IPA characters that are sometimes pressed into service:

http://www.unicode.org/charts/PDF/U0250.pdf


While omega uppercase (Ω) is more distinctive than lowercase (ω), the latter
is not particularly confusable with 'w'; no more than upsilon (υ) is with
'u', or for that matter, uppercase upsilon (Υ) with Y.

(If you have an old emailer that doesn't handle UTF-8 you may not see the
Greek characters in parantheses.)

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "tedd" <tedd@sperling.com>
To: <idn@ops.ietf.org>
Sent: Friday, January 04, 2002 07:30
Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)


Mark:

Alright, if the Greek script is forced into case-less matching, then
why does it have to be mapped from Upper to Lower Case? I can see
that mapping the upper case Alpha to the lower case alpha makes sense
in terms of not confusing the Latin "A" vs Greek "Alpha" issue. But,
forcing Omega to be mapped to omega only compounds the Latin "w" vs
Greek "w" issue. Are there any considerations for these types of
mapping issues, or is it summarily determined UC ->UC in all matters
regardless?

tedd


>Other scripts do have upper/lowercase correspondences, just like the Latin
>script does. Users of those scripts are just as likely to want caseless
>matching as users of the Latin script (such as you).
>
>For more information, see http://www.unicode.org/unicode/reports/tr21/.
>
>Mark
>-----
>
>P?ll' ?¼?stato ?rga, kak?V d' ?¼?stato ¼?nta - ?m?rou Marg?t?
>[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
>
>http://www.macchiato.com
>
>----- Original Message -----
>From: "tedd" <tedd@sperling.com>
>To: <idn@ops.ietf.org>
>Sent: Thursday, January 03, 2002 09:35
>Subject: Re: Character equivalence mapping (was: Re: [idn] SLC minutes)
>
>
>Mark, john, Edmon:
>
>>1. This issue was debated at length some time ago. I suggest that the
>people
>>arguing for visual confusability as a criterion for matching look at that
>>discussion in detail before proceding.
>
>I'm not arguing (in this debate) the "look-a-like" position. In other
>words, it makes no difference to me if certain glyph's look identical
>in numerous char sets. I am arguing the opposite position -- the
>characters in my example don't look a like.
>
>I am arguing the point that the decision "has been made" to map upper
>case Greek letters to lower case letters. For proof, look at the
>current version of nameprep ( http://www.imc.org/nameprep/  ) and try
>running code point 2126 (upper case omega) through it. You will find
>that it IS mapped to code point 03A9 (lower case omega).
>
>My question is "Why?" What's the foundation for this determination?
>For what good reason is there to conclude that the upper case Omega
>should be mapped to a lower case omega?
>
>I see no "A.com" to  "a.com" argument/problem here. Clearly, if
>someone registered ?.com and someone else registered w.com there is
>significant difference in identification between the two names. Those
>two domain names can be completely unique domain names with no
>significant resultant problems. Whereas, in the Latin char set, I can
>see the reason for making W.com and w.com identical (i.e., mapping W
>to w) because there is an UC/LC consideration/distinction in the
>language. But, that's not a problem in the Greek char set -- is it...
>really?
>
>>(i) From observation, when scripts have two cases, the
>>upper-case form is more likely to be highly stylized, and hence
>>differentiated from characters in other scripts, than the
>>lower-case one.  Hence, if one is going to adopt
>>stylization-based (glyph-distinction, if you prefer)
>>canonicalization rules, one is better off treating upper case as
>>the normal form, rather than lower case.
>
>It looks to me as if someone has already made the determination to
>map other languages based upon the Latin char set UC/LC problem
>without concern that other languages may not have the UC/LC
>distinction and thus be absent of the UC/LC problem. I think the
>Greek example I gave above sufficiently demonstrates my observation.
>
>tedd
>
>--
>http://sperling.com


--
http://sperling.com






From owner-idn@ops.ietf.org  Sun Jan  6 18:50:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27562
	for <idn-archive@lists.ietf.org>; Sun, 6 Jan 2002 18:50:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16NMkI-0005oL-00
	for idn-data@psg.com; Sun, 06 Jan 2002 15:30:30 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16NMkH-0005oF-00
	for idn@ops.ietf.org; Sun, 06 Jan 2002 15:30:29 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16NMkG-0002yG-00
	for <idn@ops.ietf.org>; Sun, 06 Jan 2002 15:30:28 -0800
Date: Sun, 6 Jan 2002 23:30:28 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: [idn] AMC-ACE-Z has a name: Punycode
Message-ID: <20020106233028.GD10928@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

AMC-ACE-Z, which has always been a working name, now has a real name:
Punycode.  I just submitted draft-ietf-idn-punycode-00.txt.  It can be
obtained now from:

http://www.cs.berkeley.edu/~amc/idn/

Why "Punycode"?  It rhymes with Unicode and is intended to encode
Unicode strings.  It is "puny" in three senses:  The repertoire of
characters used in the encoded strings is small, the encoded strings are
short, and the implementation is small.

No changes have been made to the algorithm.  Here is a summary of
changes since the previous draft:

  * AMC-ACE-Z has been renamed to Punycode.

  * Usage of the term "ACE" has been made consistent with the latest
    IDNA draft.

  * An incorrect claim regarding the conditions under which the encoded
    string can begin with a hyphen has been corrected.

  * A paragraph has been added to section 6.4 (Alternative methods for
    handling overflow) pointing out that if the Punycode decoder is used
    only inside the ToUnicode operation (see the IDNA draft), then it
    doesn't need to check for overflow.  (It also explains why.)

  * A Disclaimer and License appendix has been added:

    Regarding this entire document or any portion of it (including
    the pseudocode and C code), the author makes no guarantees and
    is not responsible for any damage resulting from its use.  The
    author grants irrevocable permission to anyone to use, modify,
    and distribute it in any way that does not diminish the rights
    of anyone else to use, modify, and distribute it, provided that
    redistributed derivative works do not contain misleading author or
    version information.  Derivative works need not be licensed under
    similar terms.

  * In the sample implementation the mixed-case annotation handling in
    the encoder has changed slightly.  The previous version, when faced
    with ASCII letters inconsistent with their case flags, would ignore
    the case flags and copy the letters verbatim.  The present version
    honors the case flags and forces the letters to the case indicated
    by the flag.  The new behavior is more useful and more intuitive.
    The change has no effect when the input is nameprepped (already
    lowercase) and the case flags are absent (all unset == lowercase).

AMC



From owner-idn@ops.ietf.org  Mon Jan  7 09:38:41 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15532
	for <idn-archive@lists.ietf.org>; Mon, 7 Jan 2002 09:38:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Naeo-000EXh-00
	for idn-data@psg.com; Mon, 07 Jan 2002 06:21:46 -0800
Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Naen-000EXZ-00
	for idn@ops.ietf.org; Mon, 07 Jan 2002 06:21:45 -0800
Received: from [64.109.212.151] (adsl-64-109-212-151.dsl.lgnnmi.ameritech.net [64.109.212.151])
	by www.wordnic.com (8.9.3/8.9.3) with ESMTP id IAA03136
	for <idn@ops.ietf.org>; Mon, 7 Jan 2002 08:21:26 -0600
Mime-Version: 1.0
X-Sender: tedd1@sperling.com
Message-Id: <p05100304b85f55a92444@[64.109.212.151]>
In-Reply-To: <20020106233028.GD10928@nicemice.net>
References: <20020106233028.GD10928@nicemice.net>
Date: Mon, 7 Jan 2002 09:21:28 -0500
To: <idn@ops.ietf.org>
From: tedd <tedd@sperling.com>
Subject: Re: [idn] AMC-ACE-Z has a name: Punycode
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

>AMC-ACE-Z, which has always been a working name, now has a real name:
>Punycode.  I just submitted draft-ietf-idn-punycode-00.txt.  It can be
>obtained now from:
>
>http://www.cs.berkeley.edu/~amc/idn/
>
>Why "Punycode"?  It rhymes with Unicode and is intended to encode
>Unicode strings.  It is "puny" in three senses:  The repertoire of
>characters used in the encoded strings is small, the encoded strings are
>short, and the implementation is small.

Really?

Naming things (i.e., children, cars, algorithms) should be well 
thought out with respect to how they are to be received. For example, 
General Motors introduced the Chevy "Nova" in South America, it was 
apparently unaware that "no va" meant locally "it won't go" and found 
poor sales. Duh.

Is "Punycode" really the name what you want to reflect the end-result 
of this groups work effort? For example:

Puny -- meaning of inferior size, strength, or significance; weak; sickly; ill

The inference certainly doesn't instill a feeling of strength and 
significance regardless of the competence of the algorithm.

Additionally, have you thought about what the industry might make of 
it, nicknames such as:

Funnycode, Ponycode, Pcode

All, of which I would suggest to you does not present the work done 
on this in the best light.

IMO, the inference of a name means something -- and it should be 
considered. Even Microsoft has not been able to overcome the "small 
and limp" inference in some circles. Then again, maybe what others 
think about what this group has done shouldn't be a concern for this 
group? I don't know, that's your call.

On the other hand, it does rhyme with Unicode...

My $0.02

tedd

-- 
http://sperling.com



From owner-idn@ops.ietf.org  Mon Jan  7 14:12:52 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25186
	for <idn-archive@lists.ietf.org>; Mon, 7 Jan 2002 14:12:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Nenb-000IUQ-00
	for idn-data@psg.com; Mon, 07 Jan 2002 10:47:07 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Nena-000IUJ-00
	for idn@ops.ietf.org; Mon, 07 Jan 2002 10:47:06 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Il0302343;
	Mon, 7 Jan 2002 10:47:00 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101002b85f9d18db75@[165.227.249.20]>
In-Reply-To: <p05100304b85f55a92444@[64.109.212.151]>
References: <20020106233028.GD10928@nicemice.net>
 <p05100304b85f55a92444@[64.109.212.151]>
Date: Mon, 7 Jan 2002 10:46:52 -0800
To: tedd <tedd@sperling.com>, <idn@ops.ietf.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] AMC-ACE-Z has a name: Punycode
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

With all due respect, you have not spent much time in the IETF. It is 
a long-standing practice to inject a bit of humor into the naming of 
some of our work items. A quick scan of the IETF Working Group names 
at <http://www.ietf.org/html.charters/wg-dir.html> should give you an 
idea about this. Punycode seems fine.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Mon Jan  7 14:58:05 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26308
	for <idn-archive@lists.ietf.org>; Mon, 7 Jan 2002 14:58:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Nfcn-000JHQ-00
	for idn-data@psg.com; Mon, 07 Jan 2002 11:40:01 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Nfcl-000JHG-00
	for idn@ops.ietf.org; Mon, 07 Jan 2002 11:39:59 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Jdq303560
	for <idn@ops.ietf.org>; Mon, 7 Jan 2002 11:39:53 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101008b85fa9d9d894@[165.227.249.20]>
In-Reply-To: <20020106233028.GD10928@nicemice.net>
References: <20020106233028.GD10928@nicemice.net>
Date: Mon, 7 Jan 2002 11:39:47 -0800
To: IETF idn working group <idn@ops.ietf.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] AMC-ACE-Z has a name: Punycode
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

>AMC-ACE-Z, which has always been a working name, now has a real name:
>Punycode.  I just submitted draft-ietf-idn-punycode-00.txt.  It can be
>obtained now from:
>
>http://www.cs.berkeley.edu/~amc/idn/

Adam, I hope you turned in something with a different format than 
what is on your website. The headers for an Internet Draft need to be 
pretty exact...

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Mon Jan  7 21:07:28 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02969
	for <idn-archive@lists.ietf.org>; Mon, 7 Jan 2002 21:07:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16NlGs-000Nwi-00
	for idn-data@psg.com; Mon, 07 Jan 2002 17:41:46 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16NlGr-000Nwc-00
	for idn@ops.ietf.org; Mon, 07 Jan 2002 17:41:45 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16NlGq-0003YR-00
	for <idn@ops.ietf.org>; Mon, 07 Jan 2002 17:41:44 -0800
Date: Tue, 8 Jan 2002 01:41:44 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: [idn] AMC-ACE-Z has a name: Punycode
Message-ID: <20020108014144.GD13402@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <20020106233028.GD10928@nicemice.net> <p05101008b85fa9d9d894@[165.227.249.20]> <20020106233028.GD10928@nicemice.net> <p05100304b85f55a92444@[64.109.212.151]> <p05101002b85f9d18db75@[165.227.249.20]> <20020106233028.GD10928@nicemice.net> <p05100304b85f55a92444@[64.109.212.151]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p05101008b85fa9d9d894@[165.227.249.20]> <p05101002b85f9d18db75@[165.227.249.20]> <p05100304b85f55a92444@[64.109.212.151]>
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Paul Hoffman / IMC <phoffman@imc.org> wrote:

> Adam, I hope you turned in something with a different format than what
> is on your website.

Yes, I have a script that provides the boilerplate and pagination.

tedd <tedd@sperling.com> wrote:

> Is "Punycode" really the name what you want to reflect the end-result 
> of this groups work effort?

I like the name.

Note that only techies will even hear of Punycode (and Nameprep).  Most
people will speak of ACE.  The IDNA document uses the term ACE all over
the place, but the references to Punycode and Nameprep are buried in the
steps of ToASCII and ToUnicode.  ACE is what you get by applying ToASCII
(which has several steps including Nameprep and Punycode).

> Puny -- meaning of inferior size, strength, or significance; weak;
> sickly; ill

ace: a serve that an opponent fails to touch; a hole in one; a pilot who
has brought down five enemy aircraft; one who excels at something

Feel better?  :)

AMC



From owner-idn@ops.ietf.org  Mon Jan  7 21:36:20 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04347
	for <idn-archive@lists.ietf.org>; Mon, 7 Jan 2002 21:36:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Nlwk-000OVf-00
	for idn-data@psg.com; Mon, 07 Jan 2002 18:25:02 -0800
From: "A. Vine" <andrea.vine@Sun.COM>
Subject: Re: [idn] AMC-ACE-Z has a name: Punycode
To: tedd <tedd@sperling.com>
Cc: idn@ops.ietf.org
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: <E16Nlwk-000OVf-00@psg.com>
Date: Mon, 07 Jan 2002 18:25:02 -0800

tedd wrote:
> 
> Naming things (i.e., children, cars, algorithms) should be well
> thought out with respect to how they are to be received. For example,
> General Motors introduced the Chevy "Nova" in South America, it was
> apparently unaware that "no va" meant locally "it won't go" and found
> poor sales. Duh.

Urban myth. See:

http://www.snopes2.com/business/misxlate/nova.htm

Andrea





From owner-idn@ops.ietf.org  Tue Jan  8 11:05:23 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27179
	for <idn-archive@lists.ietf.org>; Tue, 8 Jan 2002 11:05:23 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16NyVE-0008a4-00
	for idn-data@psg.com; Tue, 08 Jan 2002 07:49:28 -0800
Received: from unknown-raq-customer.dca1.superb.net ([207.228.240.63] helo=www.wordnic.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16NyVD-0008Zy-00
	for idn@ops.ietf.org; Tue, 08 Jan 2002 07:49:27 -0800
Received: from [64.109.212.49] (adsl-64-109-212-49.dsl.lgnnmi.ameritech.net [64.109.212.49])
	by www.wordnic.com (8.9.3/8.9.3) with ESMTP id JAA31089
	for <idn@ops.ietf.org>; Tue, 8 Jan 2002 09:49:21 -0600
Mime-Version: 1.0
X-Sender: tedd1@sperling.com
Message-Id: <p05100308b860c0dd72a5@[64.109.212.49]>
In-Reply-To: <20020108014144.GD13402@nicemice.net>
References: <20020106233028.GD10928@nicemice.net>
 <p05101008b85fa9d9d894@[165.227.249.20]>
 <20020106233028.GD10928@nicemice.net>
 <p05100304b85f55a92444@[64.109.212.151]>
 <p05101002b85f9d18db75@[165.227.249.20]>
 <20020106233028.GD10928@nicemice.net>
 <p05100304b85f55a92444@[64.109.212.151]>
 <20020108014144.GD13402@nicemice.net>
Date: Tue, 8 Jan 2002 10:49:23 -0500
To: idn@ops.ietf.org
From: tedd <tedd@sperling.com>
Subject: Re: [idn] AMC-ACE-Z has a name: Punycode
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

>tedd <tedd@sperling.com> wrote:
>
>>  Is "Punycode" really the name what you want to reflect the end-result
>>  of this groups work effort?
>
>I like the name.

Good -- I'm glad you do.

>Note that only techies will even hear of Punycode (and Nameprep).  Most
>people will speak of ACE.  The IDNA document uses the term ACE all over
>the place, but the references to Punycode and Nameprep are buried in the
>steps of ToASCII and ToUnicode.  ACE is what you get by applying ToASCII
>(which has several steps including Nameprep and Punycode).

ACE is the end result and Nameprep and Punycode, while different, are 
contributory. Okay, so outside of me, only techies will ever hear of 
the details and I'll keep those secret.

>  > Puny -- meaning of inferior size, strength, or significance; weak;
>>  sickly; ill
>
>ace: a serve that an opponent fails to touch; a hole in one; a pilot who
>has brought down five enemy aircraft; one who excels at something
>
>Feel better?  :)

It's not my feelings that matter. If it don't brother you and the 
rest of the idn, then there's no problem. I was just suggesting 
considerations that may reside outside of the idn group. Please 
excuse my business experience, from my perspective -- perception 
matters. If you don't want to capitalize on that, or don't think it's 
an issue, then that's fine. It was only an observation and subsequent 
suggestion from someone outside your circle.

>AMC

tedd
-- 
http://sperling.com



From owner-idn@ops.ietf.org  Fri Jan 11 09:11:10 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15233
	for <idn-archive@lists.ietf.org>; Fri, 11 Jan 2002 09:11:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16P2Ae-0002fX-00
	for idn-data@psg.com; Fri, 11 Jan 2002 05:56:36 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16P2Ad-0002fQ-00
	for idn@ops.ietf.org; Fri, 11 Jan 2002 05:56:35 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14791;
	Fri, 11 Jan 2002 08:56:31 -0500 (EST)
Message-Id: <200201111356.IAA14791@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: idn@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [idn] I-D ACTION:draft-ietf-idn-punycode-00.txt
Date: Fri, 11 Jan 2002 08:56:31 -0500
Sender: owner-idn@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internationalized Domain Name Working Group of the IETF.

	Title		: Punycode version 0.3.3
	Author(s)	: A. Costello
	Filename	: draft-ietf-idn-punycode-00.txt
	Pages		: 
	Date		: 10-Jan-02
	
Punycode is a simple and efficient encoding designed for use with
Internationalized Domain Names [IDN] [IDNA].  It uniquely and
reversibly transforms a Unicode string [UNICODE] into an ASCII
string.  ASCII characters in the Unicode string are represented
literally, and non-ASCII characters are represented by ASCII
characters that are allowed in hostname labels (letters, digits,
and hyphens).  Bootstring is a general algorithm that allows a
string of basic code points to uniquely represent any string of code
points drawn from a larger set.  Punycode is an instance Bootstring
that uses particular parameter values appropriate for IDNA.  This
document specifies Bootstring and the parameter values for Punycode.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idn-punycode-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-idn-punycode-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020110150614.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-idn-punycode-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idn-punycode-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020110150614.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-idn@ops.ietf.org  Mon Jan 14 11:13:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05377
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 11:13:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Q9De-000N4I-00
	for idn-data@psg.com; Mon, 14 Jan 2002 07:40:18 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Q9Dd-000N4C-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 07:40:17 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04608;
	Mon, 14 Jan 2002 10:40:13 -0500 (EST)
Message-Id: <200201141540.KAA04608@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: idn@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [idn] I-D ACTION:draft-ietf-idn-idna-06.txt
Date: Mon, 14 Jan 2002 10:40:13 -0500
Sender: owner-idn@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internationalized Domain Name Working Group of the IETF.

	Title		: Internationalizing Host Names In Applications (IDNA)
	Author(s)	: P. Faltstrom, P. Hoffman, A. Costello
	Filename	: draft-ietf-idn-idna-06.txt
	Pages		: 
	Date		: 11-Jan-02
	
Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire. This document defines
internationalized domain names (IDNs) and a mechanism called IDNA for
handling them in a standard fashion. IDNs use characters drawn from a
large repertoire (Unicode), but IDNA allows the non-ASCII characters to
be represented using the same octets used in so-called hostnames today.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idn-idna-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-idn-idna-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020111152525.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-idn-idna-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idn-idna-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020111152525.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-idn@ops.ietf.org  Mon Jan 14 11:53:12 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06565
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 11:53:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QA58-000OEO-00
	for idn-data@psg.com; Mon, 14 Jan 2002 08:35:34 -0800
Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QA52-000OEG-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 08:35:33 -0800
Received: from mailb.telia.se (localhost [127.0.0.1])
	by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g0EGZ5K17163
	for <idn@ops.ietf.org>; Mon, 14 Jan 2002 17:35:15 +0100 (MET)
Received: from trab.se (terra.malmo.trab.se [131.115.48.22])
	by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g0EGYOg16989
	for <idn@ops.ietf.org>; Mon, 14 Jan 2002 17:34:34 +0100 (MET)
Message-ID: <3C43084A.CEEEE6A5@trab.se>
Date: Mon, 14 Jan 2002 17:33:15 +0100
From: Dan Oscarsson <Dan.Oscarsson@trab.se>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: [idn] IDNA prevents simple development of DNS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

As it now looks like IDNA will be defined as an RFC despite
all the problems it will result in, I have looked at what
it will mean for DNS and for my system.
I will discuss why it will not be usable for me in an other
mail and here just take the problems with DNS.

Of what I can see, IDNA will prevent a simple solution
to DNS using native UCS!

IDNA will force all solutions using native UCS in DNS to
require the client to first test if the server can handle
UCS and the do the real query. This will result in a big overhead
in DNS lookups. While it can sometimes be cached, it cannot always.
In my original ideas I used the IN bit in the header to allow
the client to tell the server that it could handle UCS. It was
also possible to use a flag bit using EDNS. With this flag, the
server could respond correctely to both old and new clients, without
any overhead. If IDNA is used, this is no longer possible. With IDNA
the client must do a query that results in server failure for
older software, because it must know if the server handles
UCS or not before asking the query (is not needed if IDNA is not
used). So you have to do two calls to the DNS server, if older
software. And as many calls go through more than one DNS server,
each step going from new to old server software will result in
two calls.

Is it acceptable that a native internationalisation of DNS
will be much more difficult and have much more overhead because
IDNA is introduced in some applications?


The more I look at IDNA, the less usefull I see it.

   Dan



From owner-idn@ops.ietf.org  Mon Jan 14 12:54:23 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09584
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 12:54:23 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QB8I-00002H-00
	for idn-data@psg.com; Mon, 14 Jan 2002 09:42:54 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QB8H-00001z-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 09:42:53 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id JAA15699;
	Mon, 14 Jan 2002 09:41:48 -0800
Message-Id: <5.1.0.14.2.20020114094031.02770008@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 14 Jan 2002 09:41:42 -0800
To: Dan Oscarsson <Dan.Oscarsson@trab.se>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] IDNA prevents simple development of DNS
Cc: idn@ops.ietf.org
In-Reply-To: <3C43084A.CEEEE6A5@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 05:33 PM 1/14/2002 +0100, Dan Oscarsson wrote:
>IDNA will force all solutions using native UCS in DNS to
>require the client to first test if the server can handle
>UCS

This is quite simply incorrect.

And it has been explained multiple times.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Mon Jan 14 15:14:20 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16855
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 15:14:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QDEO-0003SI-00
	for idn-data@psg.com; Mon, 14 Jan 2002 11:57:20 -0800
Received: from mail-out1.apple.com ([17.254.0.52])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QDEN-0003SC-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 11:57:19 -0800
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g0EJvJ808009
	for <idn@ops.ietf.org>; Mon, 14 Jan 2002 11:57:19 -0800 (PST)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5871443d97118064e159c@mailgate1.apple.com> for <idn@ops.ietf.org>;
 Mon, 14 Jan 2002 11:56:59 -0800
Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113])
	by scv1.apple.com (8.11.3/8.11.3) with SMTP id g0EJvIe04598;
	Mon, 14 Jan 2002 11:57:18 -0800 (PST)
Message-Id: <200201141957.g0EJvIe04598@scv1.apple.com>
Subject: [idn] Determining equivalence in Unicode DNS names
Date: Mon, 14 Jan 2002 11:57:16 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: <idn@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA16855

I am new to this, so please forgive me if the suggestion I am about to 
make has been discussed before.

Some introduction: I work on networking at Apple. Apple cares a lot about 
international text, and consequently international domain names, and 
consequently my management looks to me to give them input about what is 
going on in this area. Hence my need to educate myself about the current 
state of the world in IDN.

It seems to me that one of the great problems of IDN is one that is 
fundamentally unsolvable: an attempt to determine, once and for all time, 
a single global set of rules for deciding if two strings are "equal" or 
"equivalent".

For US ASCII, equivalence is easy: For good or bad, we have decided that 
upper case and lower case letters are equivalent, and that is the end of 
the debate. Resolvers know that upper case and lower case are equivalent, 
servers know it, and caches know it, so they all agree on whether any two 
given names are equivalent. If a resolver asks for "APPLE.COM" and the 
server gives an answer for "apple.com", then the client (and any cache) 
understands that this is an acceptable answer to the question.

The problem as I see it, right now, is that if a client asks for the 
address record for "www.p�psi.com." (with an accent), and it gets back a 
DNS reply with an answer giving the address for "www.pepsi.com." (without 
an accent), then the client will ignore the answer. Even if the client 
does know that "p�psi" is equivalent to "pepsi", a caching resolver in 
between the client and the server may not, and may ignore the answer.

There are two problems here. The first is that I don't think we ever be 
able to agree on a single set of equivalence rules for the whole world. 
The second is that even if we did, we'd have to have a global flag day 
where every client, server and caching resolver was simultaneously 
upgraded to know the new rules.

It seems to me that the solution is to give up on the idea of a single 
global set of rules, and instead let each name server be authoritative 
for the equivalence rules for the zones for which it is authoritative. If 
a client tries to look up "www.p�psi.com.", and the "com" name servers 
have been configured to treat "p�psi" as equivalent to "pepsi", then they 
return the answer for "pepsi.com.", and in the reply they also include a 
(programatically generated) DNAME record which *tells* the client and any 
intervening caching resolvers that these two names are equivalent:

p�psi.com.              IN	     DNAME	  pepsi.com.
pepsi.com.              IN      NS      dnsauth1.sys.gtei.net.
dnsauth1.sys.gtei.net.  IN      A       4.2.49.2

This way we don't need to have a global flag day, because as servers are 
updated to support international domain names, they can "educate" old 
clients as they go, using DNAME. If we find that text equivalence rules 
evolve over time to meet changing needs that's fine too, because the 
servers can be upgraded one at a time as the user's needs demand that. 
Clients and caches don't need to know any of the equivalence rules at 
all; they just need to obey the DNAME mappings that they are told.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org





From owner-idn@ops.ietf.org  Mon Jan 14 16:18:50 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19674
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 16:18:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QEE8-0004ib-00
	for idn-data@psg.com; Mon, 14 Jan 2002 13:01:08 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16QEE6-0004iV-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 13:01:07 -0800
Message-ID: <001701c19d3e$cb540960$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: "Stuart Cheshire" <cheshire@apple.com>, <idn@ops.ietf.org>
References: <200201141957.g0EJvIe04598@scv1.apple.com>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Date: Mon, 14 Jan 2002 16:02:31 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi Stuart,

I think the current argument is "buyer beware" and pepsi will have to make
sure they get all the variances.  You are right that individual
authoritative servers will have to make their own equivalence rules if they
want to.  But your example is even not as extreme as when I mentioned
earlier that <capitalALPHA>.com will look exactly like A.com but currently
they are different domains.  So a zone operator will have to implement some
equivlance rules themselves.

Further to your suggestion, I think the use of DNAME is quite interesting.
In fact it could be used in the future for migration towards a UCS system
perhaps based on EDNS.  The server will have

p�psi.com.                 IN      DNAME   xx--aceofp�psi.com.
xx--aceofp�psi.com.  IN      NS      dnsauth1.sys.gtei.net.
dnsauth1.sys.gtei.net.  IN      A       4.2.49.2

Is this not also a possible way to move toward a UCS system?  with this,
future clients dont need to deploy ACE at all, but will obtain the
information from the server.
Edmon

----- Original Message -----
From: "Stuart Cheshire" <cheshire@apple.com>
It seems to me that the solution is to give up on the idea of a single
global set of rules, and instead let each name server be authoritative
for the equivalence rules for the zones for which it is authoritative. If
a client tries to look up "www.p�psi.com.", and the "com" name servers
have been configured to treat "p�psi" as equivalent to "pepsi", then they
return the answer for "pepsi.com.", and in the reply they also include a
(programatically generated) DNAME record which *tells* the client and any
intervening caching resolvers that these two names are equivalent:

p�psi.com.              IN      DNAME   pepsi.com.
pepsi.com.              IN      NS      dnsauth1.sys.gtei.net.
dnsauth1.sys.gtei.net.  IN      A       4.2.49.2

This way we don't need to have a global flag day, because as servers are
updated to support international domain names, they can "educate" old
clients as they go, using DNAME. If we find that text equivalence rules
evolve over time to meet changing needs that's fine too, because the
servers can be upgraded one at a time as the user's needs demand that.
Clients and caches don't need to know any of the equivalence rules at
all; they just need to obey the DNAME mappings that they are told.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org







From owner-idn@ops.ietf.org  Mon Jan 14 16:37:26 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20583
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 16:37:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QEQE-0004vs-00
	for idn-data@psg.com; Mon, 14 Jan 2002 13:13:38 -0800
To: Stuart Cheshire <cheshire@apple.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Cc: <idn@ops.ietf.org>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: <E16QEQE-0004vs-00@psg.com>
Date: Mon, 14 Jan 2002 13:13:38 -0800

At 11:57 AM 1/14/2002 -0800, Stuart Cheshire wrote:
>It seems to me that one of the great problems of IDN is one that is
>fundamentally unsolvable: an attempt to determine, once and for all
time,
>a single global set of rules for deciding if two strings are "equal" or
>"equivalent".


Is "abc" = "abc"?

Is "aBc" = "AbC"?

Is "abeesee" = "abc"?

These have easy answers, and they depend on well-understood types of
rules
for comparing strings.

The current DNS has rules that make the answers yes, yes, and no,
respectively.  The actual characters used are currently ASCII.  Extend
the
characters to be Unicode, and the same sort of rules can still be used,
albeit with some tuning.

The danger is with trying to solve a broader set of problems, or with
doing
tuning that is more like a major overhaul.

In other words, the task of IDN is entirely solvable, as long as we do
not
define the task to be too broad.

That is, for example, why equivalence between traditional and simplified
Chinese is entirely out of scope for this working group, just as trying
to
define equivalence between arabic and hebrew characters is out of scope.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464






From owner-idn@ops.ietf.org  Mon Jan 14 19:13:22 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26801
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 19:13:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QH2l-0007ZD-00
	for idn-data@psg.com; Mon, 14 Jan 2002 16:01:35 -0800
Received: from mail-out2.apple.com ([17.254.0.51])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QH2k-0007Z7-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 16:01:34 -0800
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g0F01P120583
	for <idn@ops.ietf.org>; Mon, 14 Jan 2002 16:01:32 -0800 (PST)
Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5872240601118164e13a8@mailgate2.apple.com>;
 Mon, 14 Jan 2002 16:01:25 -0800
Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113])
	by scv2.apple.com (8.11.3/8.11.3) with SMTP id g0F01Pw03112;
	Mon, 14 Jan 2002 16:01:25 -0800 (PST)
Message-Id: <200201150001.g0F01Pw03112@scv2.apple.com>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Date: Mon, 14 Jan 2002 16:01:25 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: "Dave Crocker" <dhc@dcrocker.net>
cc: <idn@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26801

>In other words, the task of IDN is entirely solvable, 
>as long as we do not define the task to be too broad.

I can see how my statement could be misinterpreted, so please allow me to 
clarify.

I did not mean to say that IDN cannot succeed. I'm quite sure that IDN 
can and will succeed.

What I meant to say is not solvable, is the task of defining a single set 
of Unicode equivalence rules that is appropriate in every culture in 
every country around the world. It may simply be the case that under UK 
trademark law the names P�psi and Pepsi are deemed to be same, while 
under French trademark law they are deemed to be quite different. (That 
may be a terrible example; if so I apologize, and welcome a better 
example of a case where different cultures have different rules of name 
equivalence.)

Hence my question was whether DNAME might provide an answer, to free IDN 
from the equivalence debate, by allowing equivalence to be determined 
locally on a per-zone basis.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org





From owner-idn@ops.ietf.org  Mon Jan 14 19:30:47 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27166
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 19:30:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QHOe-0007wC-00
	for idn-data@psg.com; Mon, 14 Jan 2002 16:24:12 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QHOd-0007w6-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 16:24:11 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id QAA32561;
	Mon, 14 Jan 2002 16:24:08 -0800
Message-Id: <5.1.0.14.2.20020114161733.01b26530@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 14 Jan 2002 16:19:44 -0800
To: Stuart Cheshire <cheshire@apple.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Cc: <idn@ops.ietf.org>
In-Reply-To: <200201150001.g0F01Pw03112@scv2.apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 04:01 PM 1/14/2002 -0800, Stuart Cheshire wrote:
>What I meant to say is not solvable, is the task of defining a single set
>of Unicode equivalence rules that is appropriate in every culture in
>every country around the world.

Ahh, yes.  Thank you.

And indeed that is one of the reasons such a task is outside the scope of 
this working group.


>Hence my question was whether DNAME might provide an answer, to free IDN
>from the equivalence debate, by allowing equivalence to be determined
>locally on a per-zone basis.

IDN, as a technical effort, ALREADY is free of the debate.

However it is easy to think otherwise:  The fact that some people persist 
in conducting the debate on this mailing list is merely due to their 
intense interest in the topic and their misunderstanding the scope of this 
group.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Mon Jan 14 21:14:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29444
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 21:14:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QIsB-0009HK-00
	for idn-data@psg.com; Mon, 14 Jan 2002 17:58:47 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QIsA-0009HE-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 17:58:46 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id JAA08702;
	Tue, 15 Jan 2002 09:51:27 +0800
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: "Stuart Cheshire" <cheshire@apple.com>, <idn@ops.ietf.org>
Subject: RE: [idn] Determining equivalence in Unicode DNS names
Date: Tue, 15 Jan 2002 10:02:30 +0800
Message-ID: <IHELIFNJKJLDFEMBCENDEEMBCLAA.huangk@alum.sinica.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <200201141957.g0EJvIe04598@scv1.apple.com>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA29444

We have encountered with many equivalence rule discussions.
As you mentioned, if the equivalence rule is simple enough (A=a)
thus the logic can be applied anywhere (service, client, cache, fw..).
If the wg tried to extend rule to a broader domain, that would be difficult
to identify a specific boundary.

Designing a simple equivalence rule in client application is a 
compromise of LDH DNS server.  There is no much technical margin
for designing advanced equivalence rules. Middleware, DNS server 
(UNAME, DNAME) or other naming systems would probably be the remaining 
space for these advanced computations. However, only simple equivalece 
rule got across all demands in application services.


Kenny Huang

> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On 
> Behalf Of Stuart Cheshire
> Sent: Tuesday, January 15, 2002 3:57 AM
> To: idn@ops.ietf.org
> Subject: [idn] Determining equivalence in Unicode DNS names
> 
> 
> I am new to this, so please forgive me if the suggestion I am about to 
> make has been discussed before.
> 
> Some introduction: I work on networking at Apple. Apple cares a lot about 
> international text, and consequently international domain names, and 
> consequently my management looks to me to give them input about what is 
> going on in this area. Hence my need to educate myself about the current 
> state of the world in IDN.
> 
> It seems to me that one of the great problems of IDN is one that is 
> fundamentally unsolvable: an attempt to determine, once and for all time, 
> a single global set of rules for deciding if two strings are "equal" or 
> "equivalent".
> 
> For US ASCII, equivalence is easy: For good or bad, we have decided that 
> upper case and lower case letters are equivalent, and that is the end of 
> the debate. Resolvers know that upper case and lower case are equivalent, 
> servers know it, and caches know it, so they all agree on whether any two 
> given names are equivalent. If a resolver asks for "APPLE.COM" and the 
> server gives an answer for "apple.com", then the client (and any cache) 
> understands that this is an acceptable answer to the question.
> 
> The problem as I see it, right now, is that if a client asks for the 
> address record for "www.p�psi.com." (with an accent), and it gets back a 
> DNS reply with an answer giving the address for "www.pepsi.com." (without 
> an accent), then the client will ignore the answer. Even if the client 
> does know that "p�psi" is equivalent to "pepsi", a caching resolver in 
> between the client and the server may not, and may ignore the answer.
> 
> There are two problems here. The first is that I don't think we ever be 
> able to agree on a single set of equivalence rules for the whole world. 
> The second is that even if we did, we'd have to have a global flag day 
> where every client, server and caching resolver was simultaneously 
> upgraded to know the new rules.
> 
> It seems to me that the solution is to give up on the idea of a single 
> global set of rules, and instead let each name server be authoritative 
> for the equivalence rules for the zones for which it is authoritative. If 
> a client tries to look up "www.p�psi.com.", and the "com" name servers 
> have been configured to treat "p�psi" as equivalent to "pepsi", then they 
> return the answer for "pepsi.com.", and in the reply they also include a 
> (programatically generated) DNAME record which *tells* the client and any 
> intervening caching resolvers that these two names are equivalent:
> 
> p�psi.com.              IN	     DNAME	  pepsi.com.
> pepsi.com.              IN      NS      dnsauth1.sys.gtei.net.
> dnsauth1.sys.gtei.net.  IN      A       4.2.49.2
> 
> This way we don't need to have a global flag day, because as servers are 
> updated to support international domain names, they can "educate" old 
> clients as they go, using DNAME. If we find that text equivalence rules 
> evolve over time to meet changing needs that's fine too, because the 
> servers can be upgraded one at a time as the user's needs demand that. 
> Clients and caches don't need to know any of the equivalence rules at 
> all; they just need to obey the DNAME mappings that they are told.
> 
> Stuart Cheshire <cheshire@apple.com>
>  * Wizard Without Portfolio, Apple Computer
>  * Chairman, IETF ZEROCONF
>  * www.stuartcheshire.org
> 
> 




From owner-idn@ops.ietf.org  Mon Jan 14 22:07:53 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01359
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 22:07:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QJpc-000A73-00
	for idn-data@psg.com; Mon, 14 Jan 2002 19:00:12 -0800
Received: from smtp24.singnet.com.sg ([165.21.101.204])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QJpa-000A6w-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 19:00:10 -0800
Received: from jamessonyvaio (bb159-167.singnet.com.sg [165.21.159.167])
	by smtp24.singnet.com.sg (8.12.1/8.12.1) with SMTP id g0F2xkop001637;
	Tue, 15 Jan 2002 10:59:47 +0800
Message-ID: <048c01c19d70$bd502a10$0c01000a@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Stuart Cheshire" <cheshire@apple.com>, "Dave Crocker" <dhc@dcrocker.net>
Cc: <idn@ops.ietf.org>
References: <200201150001.g0F01Pw03112@scv2.apple.com>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Date: Tue, 15 Jan 2002 10:59:57 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Stuart,

Since you just join the list, you may want to take a look at our website
and the mailing list archives at http://www.i-d-n.net/

The points you raised (and it is valid) have been discussed before which
is partially answered in Nameprep. It is one dead horse we need not whip
again.

The use of DNAME as a solution was also discussed before. It is a
solution that is neither accepted nor rejected by the WG.

-James Seng

----- Original Message -----
From: "Stuart Cheshire" <cheshire@apple.com>
To: "Dave Crocker" <dhc@dcrocker.net>
Cc: <idn@ops.ietf.org>
Sent: Tuesday, January 15, 2002 8:01 AM
Subject: Re: [idn] Determining equivalence in Unicode DNS names


>In other words, the task of IDN is entirely solvable,
>as long as we do not define the task to be too broad.

I can see how my statement could be misinterpreted, so please allow me
to
clarify.

I did not mean to say that IDN cannot succeed. I'm quite sure that IDN
can and will succeed.

What I meant to say is not solvable, is the task of defining a single
set
of Unicode equivalence rules that is appropriate in every culture in
every country around the world. It may simply be the case that under UK
trademark law the names P�psi and Pepsi are deemed to be same, while
under French trademark law they are deemed to be quite different. (That
may be a terrible example; if so I apologize, and welcome a better
example of a case where different cultures have different rules of name
equivalence.)

Hence my question was whether DNAME might provide an answer, to free IDN
from the equivalence debate, by allowing equivalence to be determined
locally on a per-zone basis.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org







From owner-idn@ops.ietf.org  Mon Jan 14 22:32:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02856
	for <idn-archive@lists.ietf.org>; Mon, 14 Jan 2002 22:32:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QK6U-000ALJ-00
	for idn-data@psg.com; Mon, 14 Jan 2002 19:17:38 -0800
Received: from smtp24.singnet.com.sg ([165.21.101.204])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QK6T-000ALD-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 19:17:37 -0800
Received: from jamessonyvaio (bb159-167.singnet.com.sg [165.21.159.167])
	by smtp24.singnet.com.sg (8.12.1/8.12.1) with SMTP id g0F3HIop006040;
	Tue, 15 Jan 2002 11:17:18 +0800
Message-ID: <04fe01c19d73$30395c70$0c01000a@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "James Seng/Personal" <jseng@pobox.org.sg>,
        "Stuart Cheshire" <cheshire@apple.com>,
        "Dave Crocker" <dhc@dcrocker.net>
Cc: <idn@ops.ietf.org>
References: <200201150001.g0F01Pw03112@scv2.apple.com> <048c01c19d70$bd502a10$0c01000a@jamessonyvaio>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Date: Tue, 15 Jan 2002 11:17:39 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

btw, personally, I think the use of DNAME is a reasonable solution for
cases which Nameprep cant handle , e.g. language dependent (Nameprep
handles scripts only) etc

-James Seng

----- Original Message -----
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Stuart Cheshire" <cheshire@apple.com>; "Dave Crocker"
<dhc@dcrocker.net>
Cc: <idn@ops.ietf.org>
Sent: Tuesday, January 15, 2002 10:59 AM
Subject: Re: [idn] Determining equivalence in Unicode DNS names


> Stuart,
>
> Since you just join the list, you may want to take a look at our
website
> and the mailing list archives at http://www.i-d-n.net/
>
> The points you raised (and it is valid) have been discussed before
which
> is partially answered in Nameprep. It is one dead horse we need not
whip
> again.
>
> The use of DNAME as a solution was also discussed before. It is a
> solution that is neither accepted nor rejected by the WG.
>
> -James Seng
>
> ----- Original Message -----
> From: "Stuart Cheshire" <cheshire@apple.com>
> To: "Dave Crocker" <dhc@dcrocker.net>
> Cc: <idn@ops.ietf.org>
> Sent: Tuesday, January 15, 2002 8:01 AM
> Subject: Re: [idn] Determining equivalence in Unicode DNS names
>
>
> >In other words, the task of IDN is entirely solvable,
> >as long as we do not define the task to be too broad.
>
> I can see how my statement could be misinterpreted, so please allow me
> to
> clarify.
>
> I did not mean to say that IDN cannot succeed. I'm quite sure that IDN
> can and will succeed.
>
> What I meant to say is not solvable, is the task of defining a single
> set
> of Unicode equivalence rules that is appropriate in every culture in
> every country around the world. It may simply be the case that under
UK
> trademark law the names P�psi and Pepsi are deemed to be same, while
> under French trademark law they are deemed to be quite different.
(That
> may be a terrible example; if so I apologize, and welcome a better
> example of a case where different cultures have different rules of
name
> equivalence.)
>
> Hence my question was whether DNAME might provide an answer, to free
IDN
> from the equivalence debate, by allowing equivalence to be determined
> locally on a per-zone basis.
>
> Stuart Cheshire <cheshire@apple.com>
>  * Wizard Without Portfolio, Apple Computer
>  * Chairman, IETF ZEROCONF
>  * www.stuartcheshire.org
>
>
>
>
>




From owner-idn@ops.ietf.org  Tue Jan 15 03:04:45 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14951
	for <idn-archive@lists.ietf.org>; Tue, 15 Jan 2002 03:04:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QOF1-000Dv0-00
	for idn-data@psg.com; Mon, 14 Jan 2002 23:42:43 -0800
Received: from mail.telia.se ([131.115.15.109] helo=mailb.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QOF0-000Dut-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 23:42:42 -0800
Received: from mailb.telia.se (localhost [127.0.0.1])
	by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g0F7geK05570
	for <idn@ops.ietf.org>; Tue, 15 Jan 2002 08:42:40 +0100 (MET)
Received: from trab.se (valinor.malmo.trab.se [131.115.48.20])
	by mailb.telia.se (8.11.6/8.11.6) with ESMTP id g0F7gcg05557;
	Tue, 15 Jan 2002 08:42:38 +0100 (MET)
Message-ID: <3C43DCF4.7E7CA15@trab.se>
Date: Tue, 15 Jan 2002 08:40:36 +0100
From: Dan Oscarsson <Dan.Oscarsson@trab.se>
X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: dhc@dcrocker.net, idn@ops.ietf.org
Subject: Re: [idn] IDNA prevents simple development of DNS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


David Crocker wrote:

>At 05:33 PM 1/14/2002 +0100, Dan Oscarsson wrote:
>>IDNA will force all solutions using native UCS in DNS to
>>require the client to first test if the server can handle
>>UCS
>
>This is quite simply incorrect.
>
>And it has been explained multiple times.

Can you prove that? My analysis shows that the test is needed.

    Dan





From owner-idn@ops.ietf.org  Tue Jan 15 03:07:58 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15000
	for <idn-archive@lists.ietf.org>; Tue, 15 Jan 2002 03:07:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QODS-000Dtn-00
	for idn-data@psg.com; Mon, 14 Jan 2002 23:41:06 -0800
Received: from [211.218.145.193] (helo=localhost.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QODR-000Dtg-00
	for idn@ops.ietf.org; Mon, 14 Jan 2002 23:41:05 -0800
Received: (from root@localhost)
	by localhost.localdomain (8.11.0/8.11.0) id g0F7enA21323
	for idn@ops.ietf.org; Tue, 15 Jan 2002 16:40:49 +0900
To: "Stuart Cheshire" <cheshire@apple.com>, "Dave Crocker" <dhc@dcrocker.net>
Cc: idn@ops.ietf.org
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by localhost.localdomain
    (8.11.0/8.11.0) with SMTP id g0F7ela21321; Tue, 15 Jan 2002 16:40:47 +0900
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64
Message-Id: <001d01c19d98$86a67410$ec1bd9d2@temp>
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Tue, 15 Jan 2002 16:44:55 +0900
X-Msmail-Priority: Normal
Subject: Re: [idn] Determining equivalence in Unicode DNS names
References: <200201150001.g0F01Pw03112@scv2.apple.com>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0rMT48UFJFPgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt
LS0tLSAKRnJvbSYjNTg7ICJTdHVhcnQgQ2hlc2hpcmUiIDxjaGVzaGlyZUBh
cHBsZS5jb20+Cj4gCj4gSGVuY2UgbXkgcXVlc3Rpb24gd2FzIHdoZXRoZXIg
RE5BTUUgbWlnaHQgcHJvdmlkZSBhbiBhbnN3ZXIsIHRvIGZyZWUgSUROIAo+
IGZyb20gdGhlIGVxdWl2YWxlbmNlIGRlYmF0ZSwgYnkgYWxsb3dpbmcgZXF1
aXZhbGVuY2UgdG8gYmUgZGV0ZXJtaW5lZCAKPiBsb2NhbGx5IG9uIGEgcGVy
LXpvbmUgYmFzaXMuCj4gCiAKQXBwbGljYXRpb25zIG9mdGVuIHRyeSB0byBt
YXRjaCBsYWJlbHMgd2l0aG91dCBtYWtpbmcgYW55IHF1ZXJpZXMgb24gCmF1
dGhvcml0YXRpdmUgRE5TIHNlcnZlcnMuIGVnKSBjZXJ0aWZpY2F0ZSB2ZXJp
ZmljYXRpb25zLgoKaWUuIFJlZ2lzdHJ5LWRlZmluZWQgZXF1aXZhbGVuY2Ug
aW4gc3VjaCBhIHdheSBjYW5ub3QgYmUgcmVmbGVjdGVkIGluIAphcHBsaWNh
dGlvbnMnIG93biBjb21wYXJpc29ucyBvZiBpRE4gbGFiZWxzLiBUaGF0IHdv
dWxkIGNhdXNlIGNvbmZ1c2lvbnMuCgpIb3dldmVyLCBkaXJlY3Rvcnkvc2Vh
cmNoIGFwcHJvYWNoZXMgaW5jbHVkaW5nIHlvdXIgRE5BTUUgcHJvcG9zYWwg
YXJlIHdvcnRoIAp0byBjb25zaWRlci4gTXkgcGVyc29uYWwgcHJlZmVycmVu
Y2UgaXMgJiM1ODsgICI8TUw+LnRsZCIgYXMga2V5d29yZHMvaGFuZGxlcwpp
biBkaXJlY3Rvcnkvc2VhcmNoIGVuZ2luZXMgb3BlcmF0ZWQgYnkgVExEIHJl
Z2lzdHJpZXMgd2hpY2ggY2FuCmVtcGxveSB0aGVpciBvd24gZXF1aXZhbGVu
Y2UgcnVsZXMgYW5kIHByb3ZpZGUgd2l0aCBhZHZhbmNlZCBmZWF0dXJlcwps
aWtlIGZ1enp5IG1hdGNoZXMgYW5kIGFtYmlndWl0eSByZXNvbHV0aW9ucyBh
bmQgbW9yZSBpbnRlcmFjdGl2aXR5LgoKSW4gY29taW5nIElSTlNTIFdHLCBJ
IHdpc2ggd2UgY291bGQgdGFsayBtb3JlIGFib3V0IGRpcmVjdG9yeSBhcHBy
b2FjaGVzCnRoYXQgd2lsbCBjb21wZXRlIHdpdGggb3IgcmVwbGFjZSBvciBv
YnNvbGV0ZSBJRE4uCgpTb29ib2sgTGVlCgoKCgoKPC9QUkU+Cgo8aW1nIHNy
Yz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZC8xMDExMDgwNjk1
LTM5YzVjOWE1NmZkN2M4MmE0MTM2Mjc1YjlmOWUzYTZhLjQxZTVmZDZmMTk3
ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0
aD0xIGhlaWdodD0xPjxpbWcgc3JjPWh0dHA6Ly9wb3N0ZWwyLnBvc3RlbC5j
by5rci9yZWFkcS8xMDExMDgwNjk1LTM5YzVjOWE1NmZkN2M4MmE0MTM2Mjc1
YjlmOWUzYTZhLjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5j
b25maXJtLnBvc3RlbC50by9pZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0ucG9z
dGVsLnRvIHdpZHRoPTEgaGVpZ2h0PTE+PGltZyBzcmM9aHR0cDovL3Bvc3Rl
bDIucG9zdGVsLmNvLmtyL3JlYWRxLzEwMTEwODA2OTUtMzljNWM5YTU2ZmQ3
YzgyYTQxMzYyNzViOWY5ZTNhNmEuNDFlNWZkNmYxOTdlYmMxMC9pZG5Ab3Bz
LmlldGYub3JnLmNvbmZpcm0ucG9zdGVsLnRvL2lkbkBvcHMuaWV0Zi5vcmcu
Y29uZmlybS5wb3N0ZWwudG8gd2lkdGg9MSBoZWlnaHQ9MT48aW1nIHNyYz1o
dHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZHEvMTAxMTA4MDY5NS0z
OWM1YzlhNTZmZDdjODJhNDEzNjI3NWI5ZjllM2E2YS40MWU1ZmQ2ZjE5N2Vi
YzEwL2lkbkBvcHMuaWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwudG8vaWRuQG9w
cy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0x
PjxpbWcgc3JjPWh0dHA6Ly9wb3N0ZWwyLnBvc3RlbC5jby5rci9yZWFkcS8x
MDExMDgwNjk1LTM5YzVjOWE1NmZkN2M4MmE0MTM2Mjc1YjlmOWUzYTZhLjQx
ZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3Rl
bC50by9pZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0ucG9zdGVsLnRvIHdpZHRo
PTEgaGVpZ2h0PTE+CjwvQk9EWT4KPC9IVE1MPgo=



From owner-idn@ops.ietf.org  Tue Jan 15 04:41:08 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16182
	for <idn-archive@lists.ietf.org>; Tue, 15 Jan 2002 04:41:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QPtB-000FhV-00
	for idn-data@psg.com; Tue, 15 Jan 2002 01:28:17 -0800
Received: from [211.218.145.193] (helo=localhost.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QPt8-000FhP-00
	for idn@ops.ietf.org; Tue, 15 Jan 2002 01:28:16 -0800
Received: (from root@localhost)
	by localhost.localdomain (8.11.0/8.11.0) id g0F9RxM23342
	for idn@ops.ietf.org; Tue, 15 Jan 2002 18:27:59 +0900
To: "Stuart Cheshire"
    <cheshire@apple.com>,
        "Dave Crocker"
    <dhc@dcrocker.net>,
        "Soobok Lee"
    <lsb@postel.co.kr>
Cc: idn@ops.ietf.org
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by localhost.localdomain
    (8.11.0/8.11.0) with SMTP id g0F9Rva23340; Tue, 15 Jan 2002 18:27:57 +0900
Content-Type: multipart/mixed; boundary="----------=_1011086879-23341-0"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Msmail-Priority: Normal
Message-Id: <056d01c19da7$7f70e950$ec1bd9d2@temp>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
References: <200201150001.g0F01Pw03112@scv2.apple.com>
    <001d01c19d98$86a67410$ec1bd9d2@temp>
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Tue, 15 Jan 2002 18:32:05 +0900
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format...

------------=_1011086879-23341-0
Content-Type: text/html; charset=iso-8859-1
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBU
cmFuc2l0aW9uYWwvL0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1
aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1p
c28tODg1OS0xIj4KPE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjYwMC4w
IiBuYW1lPUdFTkVSQVRPUj4KPFNUWUxFPjwvU1RZTEU+CjwvSEVBRD4KPEJP
RFkgYmdDb2xvcj0jZmZmZmZmPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT0m
IzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj4mbmJzcDtzZWxmLWNvbW1lbnQ6PC9G
T05UPjwvU1RST05HPjwvRElWPgo8QkxPQ0tRVU9URSAKc3R5bGU9IlBBRERJ
TkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZU
OiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lO
LVJJR0hUOiAwcHgiPgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0NDQw
NDsmIzQ3NTQ4OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJ
Vj4KICA8RElWIAogIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05U
OiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODs7IGZvbnQtY29sb3I6IGJsYWNrIj48
Qj5Gcm9tOjwvQj4gPEEgCiAgdGl0bGU9bHNiQHBvc3RlbC5jby5rciBocmVm
PSJtYWlsdG86bHNiQHBvc3RlbC5jby5rciI+U29vYm9rIExlZTwvQT4gPC9E
SVY+CiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7
Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWNoZXNoaXJlQGFwcGxlLmNvbSAKICBo
cmVmPSJtYWlsdG86Y2hlc2hpcmVAYXBwbGUuY29tIj5TdHVhcnQgQ2hlc2hp
cmU8L0E+IDsgPEEgCiAgdGl0bGU9ZGhjQGRjcm9ja2VyLm5ldCBocmVmPSJt
YWlsdG86ZGhjQGRjcm9ja2VyLm5ldCI+RGF2ZSBDcm9ja2VyPC9BPiA8L0RJ
Vj4KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsi
PjxCPkNjOjwvQj4gPEEgdGl0bGU9aWRuQG9wcy5pZXRmLm9yZyAKICBocmVm
PSJtYWlsdG86aWRuQG9wcy5pZXRmLm9yZyI+aWRuQG9wcy5pZXRmLm9yZzwv
QT4gPC9ESVY+CiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYj
NDc1NDg7Ij48Qj5TZW50OjwvQj4gVHVlc2RheSwgSmFudWFyeSAxNSwgMjAw
MiA0OjQ0IApQTTwvRElWPgogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0
NDQwNDsmIzQ3NTQ4OyI+PEI+U3ViamVjdDo8L0I+IFJlOiBbaWRuXSBEZXRl
cm1pbmluZyBlcXVpdmFsZW5jZSAKICBpbiBVbmljb2RlIEROUyBuYW1lczwv
RElWPgogIDxESVY+PEJSPjwvRElWPjxGT05UIHNpemU9KzE+PFBSRT4KLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAKRnJvbTogIlN0dWFydCBDaGVz
aGlyZSIgPENIRVNISVJFQEFQUExFLkNPTT4KJmd0OyAKJmd0OyBIZW5jZSBt
eSBxdWVzdGlvbiB3YXMgd2hldGhlciBETkFNRSBtaWdodCBwcm92aWRlIGFu
IGFuc3dlciwgdG8gZnJlZSBJRE4gCiZndDsgZnJvbSB0aGUgZXF1aXZhbGVu
Y2UgZGViYXRlLCBieSBhbGxvd2luZyBlcXVpdmFsZW5jZSB0byBiZSBkZXRl
cm1pbmVkIAomZ3Q7IGxvY2FsbHkgb24gYSBwZXItem9uZSBiYXNpcy4KJmd0
OyAKIApBcHBsaWNhdGlvbnMgb2Z0ZW4gdHJ5IHRvIG1hdGNoIGxhYmVscyB3
aXRob3V0IG1ha2luZyBhbnkgcXVlcmllcyBvbiAKYXV0aG9yaXRhdGl2ZSBE
TlMgc2VydmVycy4gZWcpIGNlcnRpZmljYXRlIHZlcmlmaWNhdGlvbnMuCgpp
ZS4gUmVnaXN0cnktZGVmaW5lZCBlcXVpdmFsZW5jZSBpbiBzdWNoIGEgd2F5
IGNhbm5vdCBiZSByZWZsZWN0ZWQgaW4gCmFwcGxpY2F0aW9ucycgb3duIGNv
bXBhcmlzb25zIG9mIGlETiBsYWJlbHMuIFRoYXQgd291bGQgY2F1c2UgY29u
ZnVzaW9ucy48L1BSRT48L0JMT0NLUVVPVEU+CjxESVY+PFNUUk9ORz48Rk9O
VCBmYWNlPUdhcmFtb25kPioqIG1vcmVvdmVyLCBzb21lIGZvbGtzIGFyZSBj
b25zaWRlcmluZyAKbG9jYWxpemF0aW9uIChbdmVuZG9yK1RMRF0tc3BlY2lm
aWMgcHJlcHJvY2Vzc2luZyk8L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+CjxESVY+
PFNUUk9ORz48Rk9OVCBmYWNlPUdhcmFtb25kPmFuZCBtdWx0aXBsZSByZWdp
c3RyYXRpb25zIGFzIGEgY29tcGVuc2F0aW9uIAombmJzcDtmb3IgaW5jb21w
bGV0ZSBzdHJpbmdwcmVwIGVxdWl2YWxlbmNlJm5ic3A7cnVsZXMuIEJ1dCBz
dWNoIHRyaWNrcyAKPC9GT05UPjwvU1RST05HPjwvRElWPgo8RElWPjxGT05U
IGZhY2U9R2FyYW1vbmQ+PFNUUk9ORz53b3VsZCBhbHNvJm5ic3A7Y2F1c2Ug
c2ltaWxhciBjb25mdXNpb25zIGFuZCAKdGhlcmVmb3JlIHdvdWxkIGh1cnQg
dW5pZm9ybSBpbnRlcnByZXRhdGlvbiBvZiZuYnNwOyBJRE4gaWRlbnRpZmll
cnMmbmJzcDsgCjwvU1RST05HPjwvRk9OVD48L0RJVj4KPERJVj48U1RST05H
PjxGT05UIGZhY2U9R2FyYW1vbmQ+PEZPTlQ+YWNyb3NzIGRpZmZlcmVudCZu
YnNwOyB1c2VyIAplbnZpcm9ubWVudHMvYXBwbGljYXRpb25zLCZuYnNwOyA8
L0ZPTlQ+PEZPTlQ+YXMgJm5ic3A7d2FzIHdhcm5lZCBieSBSRkMyODI1IChB
IAp0YW5nbGVkIHdlYikuPC9GT05UPjwvRk9OVD48L1NUUk9ORz48L0RJVj4K
PERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0zPjwvRk9O
VD4mbmJzcDs8L0RJVj4KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0
ODsgc2l6ZT0zPlNvb2JvayBMZWU8L0ZPTlQ+PC9ESVY+CjxCTE9DS1FVT1RF
IApzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVw
eDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4
IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+PFBSRT4KCkhvd2V2ZXIsIGRp
cmVjdG9yeS9zZWFyY2ggYXBwcm9hY2hlcyBpbmNsdWRpbmcgeW91ciBETkFN
RSBwcm9wb3NhbCBhcmUgd29ydGggCnRvIGNvbnNpZGVyLiBNeSBwZXJzb25h
bCBwcmVmZXJyZW5jZSBpcyA6ICA8U1RST05HPiImbHQ7TUwmZ3Q7PE1MPi50
bGQiPC9TVFJPTkc+IGFzIGtleXdvcmRzL2hhbmRsZXMKaW4gZGlyZWN0b3J5
L3NlYXJjaCBlbmdpbmVzIG9wZXJhdGVkIGJ5IFRMRCByZWdpc3RyaWVzIHdo
aWNoIGNhbgplbXBsb3kgdGhlaXIgb3duIGVxdWl2YWxlbmNlIHJ1bGVzIGFu
ZCBwcm92aWRlIHdpdGggYWR2YW5jZWQgZmVhdHVyZXMKbGlrZSBmdXp6eSBt
YXRjaGVzIGFuZCBhbWJpZ3VpdHkgcmVzb2x1dGlvbnMgYW5kIG1vcmUgaW50
ZXJhY3Rpdml0eS4KCkluIGNvbWluZyBJUk5TUyBXRywgSSB3aXNoIHdlIGNv
dWxkIHRhbGsgbW9yZSBhYm91dCBkaXJlY3RvcnkgYXBwcm9hY2hlcwp0aGF0
IHdpbGwgY29tcGV0ZSB3aXRoIG9yIHJlcGxhY2Ugb3Igb2Jzb2xldGUgSURO
LgoKU29vYm9rIExlZQoKPC9QUkU+PC9GT05UPjwvQkxPQ0tRVU9URT4KCjxp
bWcgc3JjPWh0dHA6Ly9wb3N0ZWwyLnBvc3RlbC5jby5rci9yZWFkLzEwMTEw
ODcxMjUtMzljNWM5YTU2ZmQ3YzgyYTQxMzYyNzViOWY5ZTNhNmEuNDFlNWZk
NmYxOTdlYmMxMC9pZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0ucG9zdGVsLnRv
IHdpZHRoPTEgaGVpZ2h0PTE+PGltZyBzcmM9aHR0cDovL3Bvc3RlbDIucG9z
dGVsLmNvLmtyL3JlYWRxLzEwMTEwODcxMjUtMzljNWM5YTU2ZmQ3YzgyYTQx
MzYyNzViOWY5ZTNhNmEuNDFlNWZkNmYxOTdlYmMxMC9pZG5Ab3BzLmlldGYu
b3JnLmNvbmZpcm0ucG9zdGVsLnRvL2lkbkBvcHMuaWV0Zi5vcmcuY29uZmly
bS5wb3N0ZWwudG8gd2lkdGg9MSBoZWlnaHQ9MT48aW1nIHNyYz1odHRwOi8v
cG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZHEvMTAxMTA4NzEyNS0zOWM1Yzlh
NTZmZDdjODJhNDEzNjI3NWI5ZjllM2E2YS40MWU1ZmQ2ZjE5N2ViYzEwL2lk
bkBvcHMuaWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwudG8vaWRuQG9wcy5pZXRm
Lm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0xPjxpbWcg
c3JjPWh0dHA6Ly9wb3N0ZWwyLnBvc3RlbC5jby5rci9yZWFkcS8xMDExMDg3
MTI1LTM5YzVjOWE1NmZkN2M4MmE0MTM2Mjc1YjlmOWUzYTZhLjQxZTVmZDZm
MTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50by9p
ZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0ucG9zdGVsLnRvIHdpZHRoPTEgaGVp
Z2h0PTE+PGltZyBzcmM9aHR0cDovL3Bvc3RlbDIucG9zdGVsLmNvLmtyL3Jl
YWRxLzEwMTEwODcxMjUtMzljNWM5YTU2ZmQ3YzgyYTQxMzYyNzViOWY5ZTNh
NmEuNDFlNWZkNmYxOTdlYmMxMC9pZG5Ab3BzLmlldGYub3JnLmNvbmZpcm0u
cG9zdGVsLnRvL2lkbkBvcHMuaWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwudG8g
d2lkdGg9MSBoZWlnaHQ9MT48aW1nIHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0
ZWwuY28ua3IvcmVhZHEvMTAxMTA4NzEyNS0zOWM1YzlhNTZmZDdjODJhNDEz
NjI3NWI5ZjllM2E2YS40MWU1ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMuaWV0Zi5v
cmcuY29uZmlybS5wb3N0ZWwudG8vaWRuQG9wcy5pZXRmLm9yZy5jb25maXJt
LnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0xPgo8L0JPRFk+CjwvSFRNTD4K

------------=_1011086879-23341-0--



From owner-idn@ops.ietf.org  Tue Jan 15 06:39:18 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18703
	for <idn-archive@lists.ietf.org>; Tue, 15 Jan 2002 06:39:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QRly-000HDu-00
	for idn-data@psg.com; Tue, 15 Jan 2002 03:28:58 -0800
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QRlx-000HDo-00
	for idn@ops.ietf.org; Tue, 15 Jan 2002 03:28:57 -0800
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17911;
	Tue, 15 Jan 2002 06:28:55 -0500 (EST)
Message-Id: <200201151128.GAA17911@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: idn@ops.ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [idn] I-D ACTION:draft-ietf-idn-nameprep-07.txt
Date: Tue, 15 Jan 2002 06:28:54 -0500
Sender: owner-idn@ops.ietf.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internationalized Domain Name Working Group of the IETF.

	Title		: String Profile for Internationalized Host Names
	Author(s)	: P. Hoffman, M. Blanchet
	Filename	: draft-ietf-idn-nameprep-07.txt
	Pages		: 
	Date		: 14-Jan-02
	
This document describes how to prepare internationalized host name parts
in order to increase the likelihood that name input and name comparison
work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the DNS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-07.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idn-nameprep-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-idn-nameprep-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020114175451.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-idn-nameprep-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idn-nameprep-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020114175451.I-D@ietf.org>

--OtherAccess--

--NextPart--





From owner-idn@ops.ietf.org  Wed Jan 16 01:36:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23395
	for <idn-archive@lists.ietf.org>; Wed, 16 Jan 2002 01:36:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QjLy-0008NV-00
	for idn-data@psg.com; Tue, 15 Jan 2002 22:15:18 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QjLx-0008N3-00
	for idn@ops.ietf.org; Tue, 15 Jan 2002 22:15:17 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP id 7BE21FFC1C
	for <idn@ops.ietf.org>; Wed, 16 Jan 2002 14:14:51 +0800 (SGT)
Message-ID: <021f01c19e55$2601b760$0f01000a@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: <idn@ops.ietf.org>
Subject: [idn] requirements document
Date: Wed, 16 Jan 2002 14:15:03 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

The discussion at SLC regarding requirements document summaried in the
minutes:

  What should we do?
  1. Drop document, no replacement.     -> 12 people
  2. Fix current document.              ->  2 people
  3. New short replacement document.    -> 20 people

  Current document will be dropped, will bring to mailing list whether
  to have a new document that would capture the approach the idn wg is
  taking and what we have learned about the problem.

  * Interested authors should contact co-chairs

Other than 2 other objections to drop the requirements, we have no
further discussion on this. Therefore, I propose that the wg chairs
declare we have rough consensus to drop the requirement doc.

Please provide your feedback as we like to have a closural on this.

Aside, regarding the new (simple and short) document to replace
requirements document, if anyone is working on it or is interested to do
so, please contact Marc and myself. Thanks.

-James Seng




From owner-idn@ops.ietf.org  Wed Jan 16 12:10:22 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14275
	for <idn-archive@lists.ietf.org>; Wed, 16 Jan 2002 12:10:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16QtDb-000Hfb-00
	for idn-data@psg.com; Wed, 16 Jan 2002 08:47:19 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16QtDa-000HfS-00
	for idn@ops.ietf.org; Wed, 16 Jan 2002 08:47:18 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0GGjSH15760;
	Thu, 17 Jan 2002 00:45:29 +0800 (CST)
Message-ID: <001301c19eac$dfdc3a00$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "Stuart Cheshire" <cheshire@apple.com>, "Dave Crocker" <dhc@dcrocker.net>,
        "Soobok Lee" <lsb@postel.co.kr>
Cc: <idn@ops.ietf.org>
References: <200201150001.g0F01Pw03112@scv2.apple.com>    <001d01c19d98$86a67410$ec1bd9d2@temp> <056d01c19da7$7f70e950$ec1bd9d2@temp>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Date: Thu, 17 Jan 2002 00:42:54 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C19EEF.E699DC60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C19EEF.E699DC60
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Soobok Lee:
       Right !  Registry-defined equivalence will not do much help to =
TAG Domain Name in content of web page and mail .  The Localized =
Equivalence of shared CJK UNICODE may  produce more troubles in gTLD =
IDN.=20

L.M.Tseng
    ----- Original Message -----=20
    From: Soobok Lee=20
    To: Stuart Cheshire ; Dave Crocker=20
    Cc: idn@ops.ietf.org=20
    Sent: Tuesday, January 15, 2002 4:44 PM
    Subject: Re: [idn] Determining equivalence in Unicode DNS names


----- Original Message -----=20
From: "Stuart Cheshire"=20
>=20
> Hence my question was whether DNAME might provide an answer, to free =
IDN=20
> from the equivalence debate, by allowing equivalence to be determined=20
> locally on a per-zone basis.
>=20
=20
Applications often try to match labels without making any queries on=20
authoritative DNS servers. eg) certificate verifications.

ie. Registry-defined equivalence in such a way cannot be reflected in=20
applications' own comparisons of iDN labels. That would cause =
confusions.
  ** moreover, some folks are considering localization =
([vendor+TLD]-specific preprocessing)
  and multiple registrations as a compensation  for incomplete =
stringprep equivalence rules. But such tricks=20
  would also cause similar confusions and therefore would hurt uniform =
interpretation of  IDN identifiers =20
  across different  user environments/applications,  as  was warned by =
RFC2825 (A tangled web).

  Soobok Lee

However, directory/search approaches including your DNAME proposal are =
worth=20
to consider. My personal preferrence is :  "<ML>.tld" as =
keywords/handles
in directory/search engines operated by TLD registries which can
employ their own equivalence rules and provide with advanced features
like fuzzy matches and ambiguity resolutions and more interactivity.

In coming IRNSS WG, I wish we could talk more about directory approaches
that will compete with or replace or obsolete IDN.

Soobok Lee


  =20

------=_NextPart_000_0010_01C19EEF.E699DC60
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DMingLiu size=3D2>Hi Soobok Lee:</FONT></DIV>
<DIV><FONT face=3D=E7=B4=B0=E6=98=8E=E9=AB=94 =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Right !&nbsp;=20
Registry-defined equivalence will not do much help to TAG Domain Name in =
content=20
of web page and mail .&nbsp; The&nbsp;Localized Equivalence&nbsp;of =
shared CJK=20
UNICODE&nbsp;may &nbsp;produce more troubles in=20
gTLD&nbsp;IDN.&nbsp;</FONT></DIV>
<DIV><FONT face=3D=E7=B4=B0=E6=98=8E=E9=AB=94 =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D=E7=B4=B0=E6=98=8E=E9=AB=94 =
size=3D2>L.M.Tseng</FONT></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV style=3D"FONT: 10pt =EA=B5=B4=EB=A6=BC">----- Original Message =
----- </DIV>
    <DIV=20
    style=3D"BACKGROUND: #e4e4e4; FONT: 10pt =EA=B5=B4=EB=A6=BC; =
font-color: black"><B>From:</B>=20
    <A title=3Dlsb@postel.co.kr href=3D"mailto:lsb@postel.co.kr">Soobok =
Lee</A>=20
    </DIV>
    <DIV style=3D"FONT: 10pt =EA=B5=B4=EB=A6=BC"><B>To:</B> <A =
title=3Dcheshire@apple.com=20
    href=3D"mailto:cheshire@apple.com">Stuart Cheshire</A> ; <A=20
    title=3Ddhc@dcrocker.net href=3D"mailto:dhc@dcrocker.net">Dave =
Crocker</A>=20
</DIV>
    <DIV style=3D"FONT: 10pt =EA=B5=B4=EB=A6=BC"><B>Cc:</B> <A =
title=3Didn@ops.ietf.org=20
    href=3D"mailto:idn@ops.ietf.org">idn@ops.ietf.org</A> </DIV>
    <DIV style=3D"FONT: 10pt =EA=B5=B4=EB=A6=BC"><B>Sent:</B> Tuesday, =
January 15, 2002 4:44=20
    PM</DIV>
    <DIV style=3D"FONT: 10pt =EA=B5=B4=EB=A6=BC"><B>Subject:</B> Re: =
[idn] Determining equivalence=20
    in Unicode DNS names</DIV>
    <DIV><BR></DIV><FONT size=3D+1><PRE>----- Original Message -----=20
From: "Stuart Cheshire" <CHESHIRE@APPLE.COM>
&gt;=20
&gt; Hence my question was whether DNAME might provide an answer, to =
free IDN=20
&gt; from the equivalence debate, by allowing equivalence to be =
determined=20
&gt; locally on a per-zone basis.
&gt;=20
=20
Applications often try to match labels without making any queries on=20
authoritative DNS servers. eg) certificate verifications.

ie. Registry-defined equivalence in such a way cannot be reflected in=20
applications' own comparisons of iDN labels. That would cause =
confusions.</PRE></BLOCKQUOTE>
  <DIV><STRONG><FONT face=3DGaramond>** moreover, some folks are =
considering=20
  localization ([vendor+TLD]-specific =
preprocessing)</FONT></STRONG></DIV>
  <DIV><STRONG><FONT face=3DGaramond>and multiple registrations as a =
compensation=20
  &nbsp;for incomplete stringprep equivalence&nbsp;rules. But such =
tricks=20
  </FONT></STRONG></DIV>
  <DIV><FONT face=3DGaramond><STRONG>would also&nbsp;cause similar =
confusions and=20
  therefore would hurt uniform interpretation of&nbsp; IDN =
identifiers&nbsp;=20
  </STRONG></FONT></DIV>
  <DIV><STRONG><FONT face=3DGaramond><FONT size=3D+0>across =
different&nbsp; user=20
  environments/applications,&nbsp; </FONT><FONT size=3D+0>as &nbsp;was =
warned by=20
  RFC2825 (A tangled web).</FONT></FONT></STRONG></DIV>
  <DIV><FONT face=3D=EA=B5=B4=EB=A6=BC size=3D3></FONT>&nbsp;</DIV>
  <DIV><FONT face=3D=EA=B5=B4=EB=A6=BC size=3D3>Soobok Lee</FONT></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"><PRE>
However, directory/search approaches including your DNAME proposal are =
worth=20
to consider. My personal preferrence is :  =
<STRONG>"&lt;ML&gt;<ML>.tld"</STRONG> as keywords/handles
in directory/search engines operated by TLD registries which can
employ their own equivalence rules and provide with advanced features
like fuzzy matches and ambiguity resolutions and more interactivity.

In coming IRNSS WG, I wish we could talk more about directory approaches
that will compete with or replace or obsolete IDN.

Soobok Lee

</PRE></FONT></BLOCKQUOTE><IMG height=3D1=20
  =
src=3D"http://postel2.postel.co.kr/read/1011087125-39c5c9a56fd7c82a413627=
5b9f9e3a6a.41e5fd6f197ebc10/idn@ops.ietf.org.confirm.postel.to"=20
  width=3D1><IMG height=3D1=20
  =
src=3D"http://postel2.postel.co.kr/readq/1011087125-39c5c9a56fd7c82a41362=
75b9f9e3a6a.41e5fd6f197ebc10/idn@ops.ietf.org.confirm.postel.to/idn@ops.i=
etf.org.confirm.postel.to"=20
  width=3D1><IMG height=3D1=20
  =
src=3D"http://postel2.postel.co.kr/readq/1011087125-39c5c9a56fd7c82a41362=
75b9f9e3a6a.41e5fd6f197ebc10/idn@ops.ietf.org.confirm.postel.to/idn@ops.i=
etf.org.confirm.postel.to"=20
  width=3D1><IMG height=3D1=20
  =
src=3D"http://postel2.postel.co.kr/readq/1011087125-39c5c9a56fd7c82a41362=
75b9f9e3a6a.41e5fd6f197ebc10/idn@ops.ietf.org.confirm.postel.to/idn@ops.i=
etf.org.confirm.postel.to"=20
  width=3D1><IMG height=3D1=20
  =
src=3D"http://postel2.postel.co.kr/readq/1011087125-39c5c9a56fd7c82a41362=
75b9f9e3a6a.41e5fd6f197ebc10/idn@ops.ietf.org.confirm.postel.to/idn@ops.i=
etf.org.confirm.postel.to"=20
  width=3D1><IMG height=3D1=20
  =
src=3D"http://postel2.postel.co.kr/readq/1011087125-39c5c9a56fd7c82a41362=
75b9f9e3a6a.41e5fd6f197ebc10/idn@ops.ietf.org.confirm.postel.to/idn@ops.i=
etf.org.confirm.postel.to"=20
  width=3D1> </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0010_01C19EEF.E699DC60--




From owner-idn@ops.ietf.org  Wed Jan 16 22:44:25 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28742
	for <idn-archive@lists.ietf.org>; Wed, 16 Jan 2002 22:44:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16R39v-00023R-00
	for idn-data@psg.com; Wed, 16 Jan 2002 19:24:11 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16R39u-00023K-00
	for idn@ops.ietf.org; Wed, 16 Jan 2002 19:24:10 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16R39t-0007vZ-00
	for <idn@ops.ietf.org>; Wed, 16 Jan 2002 19:24:09 -0800
Date: Thu, 17 Jan 2002 03:24:09 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <20020117032409.GA30423@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk


--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

I tried sending the attached message on Monday, but it mysteriously
vanished.  Let's see if it gets through this time.

AMC

--/9DWx/yDrRhgMJTb
Content-Type: message/rfc822
Content-Disposition: inline

Date: Mon, 14 Jan 2002 23:14:24 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <20020114231424.GE22497@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <200201141957.g0EJvIe04598@scv1.apple.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <200201141957.g0EJvIe04598@scv1.apple.com>
User-Agent: Mutt/1.3.24i
Content-Transfer-Encoding: 8bit

Stuart Cheshire <cheshire@apple.com> wrote:

> It seems to me that one of the great problems of IDN is one that is
> fundamentally unsolvable: an attempt to determine, once and for all
> time, a single global set of rules for deciding if two strings are
> "equal" or "equivalent".

You're right that we have no hope of defining a single global set of
rules for equivalence of *strings*.  But we don't need that for IDN.
We merely need a single global set of rules for equivalence of domain
labels.  IDNA defines those rules.

> The problem as I see it, right now, is that if a client asks for the
> address record for "www.p�psi.com." (with an accent), and it gets back
> a DNS reply with an answer giving the address for "www.pepsi.com."
> (without an accent), then the client will ignore the answer.

Indeed, because p�psi and pepsi are two distinct labels.  This is like
today, if a client asks for colour.com, then it will ignore a response
telling the address of color.com.  The server needs to answer the
question that was asked, not some other question that it considers
"close enough".

> If a client tries to look up "www.p�psi.com.", and the "com" name
> servers have been configured to treat "p�psi" as equivalent to
> "pepsi", then they return the answer for "pepsi.com.", and in the
> reply they also include a (programatically generated) DNAME record
> which *tells* the client and any intervening caching resolvers that
> these two names are equivalent:

Assuming DNAME is understood by the caches and clients, you could indeed
do that.  But this does not necessarily yield full equivalence between
pepsi.com and p�psi.com.  In the existing (pre-IDN) model, comparison
of two names for equivalence has never required a DNS lookup.  If
someone has visited pepsi.com and then visits a page containing links to
p�psi.com, will those links be colored correctly?  Probably not.  If an
SSL connection is used, and the certificate uses the name pepsi.com, but
the client used p�psi.com, will the SSL library believe that the server
is authentic?  I doubt it.

AMC

--/9DWx/yDrRhgMJTb--



From owner-idn@ops.ietf.org  Thu Jan 17 02:01:21 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02982
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 02:01:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16R6Gs-0005BS-00
	for idn-data@psg.com; Wed, 16 Jan 2002 22:43:34 -0800
From: "Heinze, Bill" <bill.heinze@tkhr.com>
To: "'idn@ops.ietf.org'" <idn@ops.ietf.org>
Cc: "'Mr. James Seng, Co-Chair, idn Working Group,'"@psg.com
Message-Id: <E16R6Gs-0005BS-00@psg.com>
Date: Wed, 16 Jan 2002 22:43:34 -0800

<jseng@pobox.org.sg>,
"'Mr. Marc Blanchet, Co-Chair, idn Working Group,'"
<Marc.Blanchet@viagenie.qc.ca>,
"'Mr. Erik Nordmark, Internet Area Director,'" <nordmark@eng.sun.com>,
"'Mr. Thomas Narten, Internet Area Director,'" <narten@us.ibm.com>,
"'Mr. John Klensin, Technical Advisor,'" <klensin@jck.com>,
"'Mr. Harald Alverstrand, Technical Advisor,'" <harald@alvestrand.no>,
"'RFC 2026 Submissions to IETF Director,'" <scoya@ietf.org>
Subject: [idn] IETF Notification of Patent Publication for WO 01/90955 A2
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C19EF0.0E3E7B40
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

January 16, 2002

Internet Engineering Task Force                 VIA E-MAIL TO:
idn Working Group Mailing List                  =
<mailto:idn@ops.ietf.org>
idn@ops.ietf.org
=20
Re:  IETF Notification of Patent Publication for
<http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&LG=3Den&DB=3DEPD&PN=3DWO
=
0190955&ID=3DW
O+++0190955A2+I+> WO 01/90955 A2=20
        Our File No. 561401-9010

Dear Subscribers:

In accordance with  <outbind://7/IESG/Section10.txt> Section 10 of the
<outbind://7/rfc/rfc2026.txt> The Internet Standards Process (RFC =
2026), we
are writing on behalf of
<http://l2.espacenet.com/dips/viewer?PN=3DWO0190955&CY=3Dep&LG=3Den&DB=3
D=
EPD> .NU
Domain and its affiliate  <http://www.worldnames.net/> WorldNames,TM =
Inc. to
notify you of the publication of World Intellectual Property =
Organization
International Publication No.
<http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&LG=3Den&DB=3DEPD&PN=3DWO
=
0190955&ID=3DW
O+++0190955A2+I+> WO 01/90955 A2 entitled "Internationalized Domain =
Name
System with Iterative Conversion." A copy of this document is available
=
at
the following website:=20

http://l2.espacenet.com/dips/bnsviewer?CY=3Dep
<http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&LG=3Den&DB=3DEPD&PN=3DWO
=
0190955&ID=3DW
O+++0190955A2+I+> =
&LG=3Den&DB=3DEPD&PN=3DWO0190955&ID=3DWO+++0190955A2+I+=20

This patent application generally relates to a system, method, and =
logic for
managing data, including a database for implementing a key value =
operation,
such as a DNS resource record lookup, with a key having a predetermined
encoding, such as Unicode. Also provided is an iterative converter for
iteratively converting the key from each of multiple encodings to the
predetermined encoding before performing the key value operation with =
each
converted key. The system may also include a validator for verifying =
that a
syntax of each converted key is valid and a normalizer for normalizing =
each
converted key.=20

We believe that many of the technologies being discussed in this =
mailing
list infringe one or more of the 213 claims starting at page 87 of the
attached publication. We would therefore like to propose that you =
review
these claims and contact us immediately with regard to obtaining a =
license
and/or authorized access to WorldNames=E2=84=A2
<http://www.worldnames.net/MLDNS/default.cfm> MLDNS=E2=84=A2 =
multilingual DNS
products and services described at the following hyperlink:

   <http://www.worldnames.net/MLDNS/default.cfm>
http://www.worldnames.net/MLDNS/default.cfm

Please note that failure to promptly obtain the appropriate =
authorization
may subject you and your organization to liability for royalties in the
=
U.S.
as of the date that you receive this letter under
<http://www4.law.cornell.edu/uscode/35/154.html> 35 U.S.C. =
=C2=A7154(d). Once the
application is granted, additional
<http://www.bitlaw.com/source/35usc/281.html> remedies are also =
available
including  <http://www.bitlaw.com/source/35usc/283.html> injunctions,
<http://www.bitlaw.com/source/35usc/284.html> treble damages, and
<http://www.bitlaw.com/source/35usc/285.html> attorney fees. A variety =
of
other  <http://www4.law.cornell.edu/uscode/35/295.html> presumptions =
and
<http://www4.law.cornell.edu/uscode/35/281.html> remedies may also be
available  <http://www.usitc.gov/us337.htm> in the U.S. and abroad.

If you believe that you have a
<http://www.bitlaw.com/source/35usc/282.html> defense to these =
allegations,
such as non-  <http://www4.law.cornell.edu/uscode/35/271.html> =
infringement
or  <http://www4.law.cornell.edu/uscode/35/273.html> prior invention, =
then
please provide us with additional information to refute our allegations
=
and
avoid further involvement with this matter. Similarly, if you believe =
that
any of the attached claims are not
<http://www4.law.cornell.edu/uscode/35/pIIch10.html> patentable, then =
please
bring them to our attention, along with any relevant
<http://www4.law.cornell.edu/uscode/35/102.html> prior art, so that we =
may
submit that information to the appropriate patent offices.

We are looking forward to hearing from you as soon as possible.

Sincerely,

William F. Heinze, Esq.*=20
Thomas, Kayden, Horstemeyer & Risley, L.L.P.=20
100 Galleria Parkway, N.W., Suite 1750=20
Atlanta, GA 30339-5948=20

Tel.:  (770) 933-9500=20
Fax:  (770) 951-0933=20
Profile:   <http://www.tkhr.com/wfh.htm> http://www.tkhr.com/wfh.htm=20

*Admitted to practice in the Commonwealth of Virginia.  Not admitted in
Georgia.=20


cc:   Mr. James Seng, Co-Chair, idn Working Group,
<outbind://7/mail%20to:%20jseng@pobox.org.sg> jseng@pobox.org.sg
        Mr. Marc Blanchet, Co-Chair, idn Working Group,
<outbind://7/Mail%20to:%20Marc.Blanchet@viagenie.qc.ca>
Marc.Blanchet@viagenie.qc.ca
        Mr. Erik Nordmark, Internet Area Director,
<outbind://7/mail%20to:%20nordmark@eng.sun.com> nordmark@eng.sun.com
        Mr. Thomas Narten, Internet Area Director,
<mailto:narten@us.ibm.com> narten@us.ibm.com=20
        Mr. John Klensin, Technical Advisor,  <mailto:klensin@jck.com>
klensin@jck.com
        Mr. Harald Alverstrand, Technical Advisor,
<outbind://7/mail%20to:%20harald@alvestrand.no> harald@alvestrand.no
        RFC 2026 Submissions to IETF Director,
<outbind://7/mail%20to:%20scoya@ietf.org> scoya@ietf.org



=20

------_=_NextPart_001_01C19EF0.0E3E7B40
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUTF-8">


<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P align=3Dleft><FONT face=3DArial>January 16, 2002</FONT></P></DIV>
<DIV align=3Djustify><FONT face=3DArial>Internet Engineering Task =
Force&nbsp;<SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>VIA E-MAIL TO:</FONT></DIV>
<DIV><FONT face=3DArial>idn Working Group Mailing List<SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>=20
</FONT><A href=3D"mailto:idn@ops.ietf.org"><FONT=20
face=3DArial>idn@ops.ietf.org</FONT></A></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV align=3Djustify><FONT face=3DArial>Re:&nbsp;<SPAN =
class=3D340313600-17012002>=20
</SPAN><SPAN class=3D340313600-17012002>IETF </SPAN>Notification of =
Patent=20
Publication for </FONT><A=20
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;D
=
B=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+"><FONT=20
face=3DArial>WO 01/90955 A2</FONT></A><FONT face=3DArial> </FONT></DIV>
<DIV align=3Djustify><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Our=20
File No. 561401-9010</FONT></DIV>
<DIV>
<P align=3Djustify><FONT face=3DArial></FONT></P>
<P align=3Djustify><FONT face=3DArial>Dear Subscribers:</FONT></P>
<P align=3Djustify><FONT face=3DArial></FONT></P>
<P><FONT face=3DArial>In accordance with </FONT><A=20
href=3D"outbind://7/IESG/Section10.txt"><FONT face=3DArial>Section=20
10</FONT></A><FONT face=3DArial> of the </FONT><A=20
href=3D"outbind://7/rfc/rfc2026.txt"><FONT face=3DArial>The Internet =
Standards=20
Process</FONT></A><FONT face=3DArial> (RFC 2026), we are writing on =
behalf of=20
</FONT><A=20
href=3D"http://l2.espacenet.com/dips/viewer?PN=3DWO0190955&amp;CY=3Dep&a
=
mp;LG=3Den&amp;DB=3DEPD"><FONT=20
face=3DArial>.NU Domain</FONT></A><FONT face=3DArial> and its affiliate
=
</FONT><A=20
href=3D"http://www.worldnames.net/"><FONT =
face=3DArial>WorldNames,</FONT></A><FONT=20
face=3DArial><SUP>TM </SUP>Inc. to notify you of the publication of =
World=20
Intellectual Property Organization International Publication No. =
</FONT><A=20
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;D
=
B=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+"><FONT=20
face=3DArial>WO 01/90955 A2</FONT></A><FONT face=3DArial> entitled=20
"Internationalized Domain Name System with Iterative Conversion." A =
copy of this=20
document is available at the&nbsp;<SPAN=20
class=3D340313600-17012002>following&nbsp;website</SPAN><SPAN=20
class=3D340313600-17012002>:</SPAN><SPAN class=3D340313600-17012002>=20
</SPAN></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D340313600-17012002><A=20
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;D
=
B=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+">http://l2.espacen
=
et.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;DB=3DEPD&amp;PN=3DWO019095
=
5&amp;ID=3DWO+++0190955A2+I+</A>&nbsp;</SPAN></FONT></FONT></P>
<P><SPAN class=3D340313600-17012002></SPAN><FONT face=3DArial>Th<SPAN=20
class=3D340313600-17012002>is&nbsp;</SPAN>patent application generally =
relates to=20
a system, method, and logic for managing data, including a database for
=

implementing a key value operation, such as a DNS resource record =
lookup, with a=20
key having a predetermined encoding, such as Unicode. Also provided is =
an=20
iterative converter for iteratively converting the key from each of =
multiple=20
encodings to the predetermined encoding before performing the key value
=

operation with each converted key. The system may also include a =
validator for=20
verifying that a syntax of each converted key is valid and a normalizer
=
for=20
normalizing each converted key. </FONT></P>
<P><FONT face=3DArial></FONT></P>
<P><FONT face=3DArial>We believe that many of the technologies being =
discussed in=20
this mailing list infringe one or more of the 213 claims starting at =
page 87 of=20
the attached publication. We would therefore like to propose that you =
review=20
these claims and contact us immediately with regard to obtaining a =
license=20
and/or authorized access to WorldNames=E2=84=A2 </FONT><A=20
href=3D"http://www.worldnames.net/MLDNS/default.cfm"><FONT =
face=3DArial>MLDNS=E2=84=A2=20
multilingual DNS products and services</FONT></A><FONT face=3DArial> =
described=20
at&nbsp;<SPAN class=3D340313600-17012002>the =
following&nbsp;</SPAN>hyperlink<SPAN=20
class=3D340313600-17012002>:</SPAN></FONT></P>
<P><FONT face=3DArial><SPAN class=3D340313600-17012002></SPAN><FONT=20
size=3D2>&nbsp;</FONT><A =
href=3D"http://www.worldnames.net/MLDNS/default.cfm"><FONT=20
size=3D2>http://www.worldnames.net/MLDNS/default.cfm</FONT></A></FONT></
=
P>
<P><FONT face=3DArial>Please note that failure to promptly obtain the =
appropriate=20
authorization may subject you and your organization to liability for =
royalties=20
in the U.S. as of the date that you receive this letter under </FONT><A
=

href=3D"http://www4.law.cornell.edu/uscode/35/154.html"><FONT =
face=3DArial>35 U.S.C.=20
=C2=A7154(d)</FONT></A><FONT face=3DArial>. Once the application is =
granted, additional=20
</FONT><A href=3D"http://www.bitlaw.com/source/35usc/281.html"><FONT=20
face=3DArial>remedies</FONT></A><FONT face=3DArial> are also available =
including=20
</FONT><A href=3D"http://www.bitlaw.com/source/35usc/283.html"><FONT=20
face=3DArial>injunctions</FONT></A><FONT face=3DArial>, </FONT><A=20
href=3D"http://www.bitlaw.com/source/35usc/284.html"><FONT =
face=3DArial>treble=20
damages</FONT></A><FONT face=3DArial>, and </FONT><A=20
href=3D"http://www.bitlaw.com/source/35usc/285.html"><FONT =
face=3DArial>attorney=20
fees</FONT></A><FONT face=3DArial>. A variety of other </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/295.html"><FONT=20
face=3DArial>presumptions</FONT></A><FONT face=3DArial> and </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/281.html"><FONT=20
face=3DArial>remedies</FONT></A><FONT face=3DArial> may also be =
available </FONT><A=20
href=3D"http://www.usitc.gov/us337.htm"><FONT face=3DArial>in the=20
U.S</FONT></A><FONT face=3DArial>. and abroad.</FONT></P>
<P><FONT face=3DArial>If you believe that you have a </FONT><A=20
href=3D"http://www.bitlaw.com/source/35usc/282.html"><FONT=20
face=3DArial>defense</FONT></A><FONT face=3DArial> to these =
allegations, such as=20
non-</FONT><A =
href=3D"http://www4.law.cornell.edu/uscode/35/271.html"><FONT=20
face=3DArial>infringement</FONT></A><FONT face=3DArial> or </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/273.html"><FONT =
face=3DArial>prior=20
invention</FONT></A><FONT face=3DArial>, then please provide us with =
additional=20
information to refute our allegations and avoid further involvement =
with this=20
matter. Similarly, if you believe that any of the attached claims are =
not=20
</FONT><A =
href=3D"http://www4.law.cornell.edu/uscode/35/pIIch10.html"><FONT=20
face=3DArial>patentable</FONT></A><FONT face=3DArial>, then please =
bring them to our=20
attention, along with any relevant </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/102.html"><FONT =
face=3DArial>prior=20
art</FONT></A><FONT face=3DArial>, so that we may submit that =
information to the=20
appropriate patent offices.</FONT></P>
<P><FONT face=3DArial>We are looking forward to hearing from you as =
soon as=20
possible.</FONT></P>
<P><FONT face=3DArial>Sincerely,</FONT></P>
<P><FONT face=3DArial>William F. Heinze, Esq.* <BR>Thomas, Kayden, =
Horstemeyer=20
&amp; Risley, L.L.P. <BR>100 Galleria Parkway, N.W., Suite 1750 =
<BR>Atlanta, GA=20
30339-5948 </FONT></P>
<P><FONT face=3DArial>Tel.:&nbsp; (770)&nbsp;<SPAN=20
class=3D340313600-17012002>933-9500</SPAN> <BR>Fax:&nbsp; (770) =
951-0933=20
<BR></FONT><FONT face=3DArial>Profile:&nbsp; </FONT><A=20
href=3D"http://www.tkhr.com/wfh.htm" target=3D_blank><FONT=20
face=3DArial>http://www.tkhr.com/wfh.htm</FONT></A><U></U><FONT =
face=3DArial>=20
</FONT></P>
<P><FONT face=3DArial>*Admitted to practice in the Commonwealth of =
Virginia.&nbsp;=20
Not admitted in Georgia. <BR></FONT></P>
<P><FONT face=3DArial></FONT></P></DIV>
<DIV><FONT face=3DArial>cc:&nbsp;<SPAN =
class=3D340313600-17012002>&nbsp; </SPAN>Mr.=20
James Seng, Co-Chair, idn Working Group, </FONT><A=20
href=3D"outbind://7/mail%20to:%20jseng@pobox.org.sg"><FONT=20
face=3DArial>jseng@pobox.org.sg</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Marc Blanchet, Co-Chair, idn Working Group, </FONT><A=20
href=3D"outbind://7/Mail%20to:%20Marc.Blanchet@viagenie.qc.ca"><FONT=20
face=3DArial>Marc.Blanchet@viagenie.qc.ca</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Erik Nordmark, Internet Area Director, </FONT><A=20
href=3D"outbind://7/mail%20to:%20nordmark@eng.sun.com"><FONT=20
face=3DArial>nordmark@eng.sun.com</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Thomas Narten, Internet Area Director, </FONT><A=20
href=3D"mailto:narten@us.ibm.com"><FONT=20
face=3DArial>narten@us.ibm.com</FONT></A><FONT face=3DArial> =
</FONT></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
John Klensin, Technical Advisor, </FONT><A =
href=3D"mailto:klensin@jck.com"><FONT=20
face=3DArial>klensin@jck.com</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Harald Alverstrand, Technical Advisor, </FONT><A=20
href=3D"outbind://7/mail%20to:%20harald@alvestrand.no"><FONT=20
face=3DArial>harald@alvestrand.no</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>RFC=20
2026 Submissions to IETF Director, </FONT><A=20
href=3D"outbind://7/mail%20to:%20scoya@ietf.org"><FONT=20
face=3DArial>scoya@ietf.org</FONT></A></DIV>
<P>
<P><FONT face=3DArial></FONT></P></P><BR>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C19EF0.0E3E7B40--





From owner-idn@ops.ietf.org  Thu Jan 17 02:43:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09718
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 02:43:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16R6n2-0005k9-00
	for idn-data@psg.com; Wed, 16 Jan 2002 23:16:48 -0800
Received: from imo-r02.mx.aol.com ([152.163.225.98])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16R6n1-0005k3-00
	for idn@ops.ietf.org; Wed, 16 Jan 2002 23:16:47 -0800
Received: from DougEwell2@cs.com
	by imo-r02.mx.aol.com (mail_out_v31_r1.25.) id i.47.16a29cf4 (661)
	 for <idn@ops.ietf.org>; Thu, 17 Jan 2002 02:16:43 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <47.16a29cf4.2977d45a@cs.com>
Date: Thu, 17 Jan 2002 02:16:42 EST
Subject: Re: [idn] Determining equivalence in Unicode DNS names
To: idn@ops.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA09718

In a message dated 2002-01-16 19:48:54 Pacific Standard Time, 
idn.amc+0@nicemice.net.RemoveThisWord ("Adam" for short) writes:

>> The problem as I see it, right now, is that if a client asks for the
>> address record for "www.p�psi.com." (with an accent), and it gets back
>> a DNS reply with an answer giving the address for "www.pepsi.com."
>> (without an accent), then the client will ignore the answer.
>
> Indeed, because p�psi and pepsi are two distinct labels.  This is like
> today, if a client asks for colour.com, then it will ignore a response
> telling the address of color.com.  The server needs to answer the
> question that was asked, not some other question that it considers
> "close enough".

For some people, this may not be all that obvious.  We have had discussions 
and read proposals in which it is stated that the relationship between 
"lookalike" characters, like U+0041 and U+0391 and U+0410, or between 
Simplified and Traditional Chinese characters with the same language-specific 
meaning, is no different from the relationship between Latin '"E" and "e".

Presumably there are those who would also see the relationship between "e" 
and "�" in the same way, and would therefore expect "pepsi.com" to be matched 
not only by "PEPSI.COM" but also by "p�psi.com".

There are good and valid reasons for not treating certain classes of 
characters the way Latin case pairs are treated, but ultimately there is 
bound to be a measure of arbitrariness in the system, and people will just 
have to accept the way things are defined.  After all, even traditional Latin 
case pairing gets complicated for languages such as German ("SS" -> "�") and 
Turkish (where "I" and "i" are not a pair).

-Doug Ewell
 Fullerton, California



From owner-idn@ops.ietf.org  Thu Jan 17 03:55:00 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10327
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 03:55:00 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16R7wL-0006x3-00
	for idn-data@psg.com; Thu, 17 Jan 2002 00:30:29 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16R7wK-0006wv-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 00:30:28 -0800
Received: from BBThead.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id AAA16328;
	Thu, 17 Jan 2002 00:30:22 -0800
Message-Id: <5.1.0.14.2.20020117000054.03a04db0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 17 Jan 2002 00:31:16 -0800
To: "Heinze, Bill" <bill.heinze@tkhr.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: [idn] Re: 
Cc: "'idn@ops.ietf.org'" <idn@ops.ietf.org>, george.thomas@tkhr.com,
        jim.kayden@tkhr.com, scott.horstemeyer@tkhr.com, steve.risley@tkhr.com,
        jeff.kuester@tkhr.com, dan.mcclure@tkhr.com, dan.santos@tkhr.com,
        dan.gresham@tkhr.com, scott.culpepper@tkhr.com, mike.tempel@tkhr.com,
        david.risley@tkhr.com
In-Reply-To: <E16R6Gs-0005BS-00@psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dear Bill,

On the off chance that the email to the IETF's IDN list, with your address 
in the From field, was not an attempt by you or someone else to proffer 
some form of humor, a few comments are in order:

When making making claims of technical innovation, especially to a 
technical body, it helps to use the communications technology 
properly.  Your note was nearly incoherent because of serious encoding 
problems with your posting.  Further the web citations your provided were 
quite unusable.  As well, <http://l2.espacenet.com/> appears to be 
inaccessible.

Nonetheless:


At 10:43 PM 1/16/2002 -0800, Heinze, Bill wrote:
>notify you of the publication of World Intellectual Property =
>Organization International Publication No.

A WIPO publication?  How nice.

When did WIPO start issuing patents?


>This patent application generally relates to a system, method, and

Application?  As in, no force of law yet?  How interesting.


>We believe that many of the technologies being discussed in this =
>mailing
>list infringe one or more of the 213 claims starting at page 87 of the

1.  It is a bit unusual to refer to a "technology" as infringing.  Perhaps 
you meant that you believe that some product USING the technology would be 
infringing?  A pity your meaning is unclear.

2.  Patent applications usually begin with an impressively inflated number 
of claims.  For those patents that actually issue, the number of claims 
that survive is typically vastly smaller.  That makes it difficult even to 
guess which portions of your impressive list of claims one should worry about.


>Please note that failure to promptly obtain the appropriate =
>authorization may subject you and your organization to liability for 
>royalties in the

You are threatening legal actions against folks in this standards 
organizations for doing standards work without paying you a license fee?

Either you are jesting or, alas, once again at least being impressively 
unclear.


>William F. Heinze, Esq.

Esquire?  Cute touch, though doesn't it create a challenge for what to use 
upon making partner?


At any rate, please do feel free to distract our discussion list further, 
but perhaps with postings that are more readable in format and clear in 
content.

And in that unfortunate off chance that you were not the originator of the 
note sent under your name, to the person who did:  tsk. tsk.  Why would you 
want to alienate this standards organization to Mr. Heinze, by posting such 
a bothersome note, so badly formulated?

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Jan 17 04:20:43 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10463
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 04:20:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16R8Tv-0007Ur-00
	for idn-data@psg.com; Thu, 17 Jan 2002 01:05:11 -0800
From: "Heinze, Bill" <bill.heinze@tkhr.com>
To: "'idn@ops.ietf.org'" <idn@ops.ietf.org>
Subject: [idn] IETF Notification of Patent Publication for WO 01/90955 A2
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: <E16R8Tv-0007Ur-00@psg.com>
Date: Thu, 17 Jan 2002 01:05:11 -0800

This message is in MIME format. Since your mail reader does not
understand this format, some or all of this message may not be legible.

------_=_NextPart_001_01C19EF0.0E3E7B40
Content-Type: text/plain;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[JS: Re-bounce again without the long cc: list hopefully this would be
readable]

January 16, 2002

Internet Engineering Task Force                 VIA E-MAIL TO:
idn Working Group Mailing List                  =
<mailto:idn@ops.ietf.org>
idn@ops.ietf.org
=20
Re:  IETF Notification of Patent Publication for
<http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&LG=3Den&DB=3DEPD&PN=3DWO
=
0190955&ID=3DW
O+++0190955A2+I+> WO 01/90955 A2=20
        Our File No. 561401-9010

Dear Subscribers:

In accordance with  <outbind://7/IESG/Section10.txt> Section 10 of the
<outbind://7/rfc/rfc2026.txt> The Internet Standards Process (RFC =
2026), we
are writing on behalf of
<http://l2.espacenet.com/dips/viewer?PN=3DWO0190955&CY=3Dep&LG=3Den&DB=3
D=
EPD> .NU
Domain and its affiliate  <http://www.worldnames.net/> WorldNames,TM =
Inc. to
notify you of the publication of World Intellectual Property =
Organization
International Publication No.
<http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&LG=3Den&DB=3DEPD&PN=3DWO
=
0190955&ID=3DW
O+++0190955A2+I+> WO 01/90955 A2 entitled "Internationalized Domain =
Name
System with Iterative Conversion." A copy of this document is available
=
at
the following website:=20

http://l2.espacenet.com/dips/bnsviewer?CY=3Dep
<http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&LG=3Den&DB=3DEPD&PN=3DWO
=
0190955&ID=3DW
O+++0190955A2+I+> =
&LG=3Den&DB=3DEPD&PN=3DWO0190955&ID=3DWO+++0190955A2+I+=20

This patent application generally relates to a system, method, and =
logic for
managing data, including a database for implementing a key value =
operation,
such as a DNS resource record lookup, with a key having a predetermined
encoding, such as Unicode. Also provided is an iterative converter for
iteratively converting the key from each of multiple encodings to the
predetermined encoding before performing the key value operation with =
each
converted key. The system may also include a validator for verifying =
that a
syntax of each converted key is valid and a normalizer for normalizing =
each
converted key.=20

We believe that many of the technologies being discussed in this =
mailing
list infringe one or more of the 213 claims starting at page 87 of the
attached publication. We would therefore like to propose that you =
review
these claims and contact us immediately with regard to obtaining a =
license
and/or authorized access to WorldNames=E2=84=A2
<http://www.worldnames.net/MLDNS/default.cfm> MLDNS=E2=84=A2 =
multilingual DNS
products and services described at the following hyperlink:

   <http://www.worldnames.net/MLDNS/default.cfm>
http://www.worldnames.net/MLDNS/default.cfm

Please note that failure to promptly obtain the appropriate =
authorization
may subject you and your organization to liability for royalties in the
=
U.S.
as of the date that you receive this letter under
<http://www4.law.cornell.edu/uscode/35/154.html> 35 U.S.C. =
=C2=A7154(d). Once the
application is granted, additional
<http://www.bitlaw.com/source/35usc/281.html> remedies are also =
available
including  <http://www.bitlaw.com/source/35usc/283.html> injunctions,
<http://www.bitlaw.com/source/35usc/284.html> treble damages, and
<http://www.bitlaw.com/source/35usc/285.html> attorney fees. A variety =
of
other  <http://www4.law.cornell.edu/uscode/35/295.html> presumptions =
and
<http://www4.law.cornell.edu/uscode/35/281.html> remedies may also be
available  <http://www.usitc.gov/us337.htm> in the U.S. and abroad.

If you believe that you have a
<http://www.bitlaw.com/source/35usc/282.html> defense to these =
allegations,
such as non-  <http://www4.law.cornell.edu/uscode/35/271.html> =
infringement
or  <http://www4.law.cornell.edu/uscode/35/273.html> prior invention, =
then
please provide us with additional information to refute our allegations
=
and
avoid further involvement with this matter. Similarly, if you believe =
that
any of the attached claims are not
<http://www4.law.cornell.edu/uscode/35/pIIch10.html> patentable, then =
please
bring them to our attention, along with any relevant
<http://www4.law.cornell.edu/uscode/35/102.html> prior art, so that we =
may
submit that information to the appropriate patent offices.

We are looking forward to hearing from you as soon as possible.

Sincerely,

William F. Heinze, Esq.*=20
Thomas, Kayden, Horstemeyer & Risley, L.L.P.=20
100 Galleria Parkway, N.W., Suite 1750=20
Atlanta, GA 30339-5948=20

Tel.:  (770) 933-9500=20
Fax:  (770) 951-0933=20
Profile:   <http://www.tkhr.com/wfh.htm> http://www.tkhr.com/wfh.htm=20

*Admitted to practice in the Commonwealth of Virginia.  Not admitted in
Georgia.=20


cc:   Mr. James Seng, Co-Chair, idn Working Group,
<outbind://7/mail%20to:%20jseng@pobox.org.sg> jseng@pobox.org.sg
        Mr. Marc Blanchet, Co-Chair, idn Working Group,
<outbind://7/Mail%20to:%20Marc.Blanchet@viagenie.qc.ca>
Marc.Blanchet@viagenie.qc.ca
        Mr. Erik Nordmark, Internet Area Director,
<outbind://7/mail%20to:%20nordmark@eng.sun.com> nordmark@eng.sun.com
        Mr. Thomas Narten, Internet Area Director,
<mailto:narten@us.ibm.com> narten@us.ibm.com=20
        Mr. John Klensin, Technical Advisor,  <mailto:klensin@jck.com>
klensin@jck.com
        Mr. Harald Alverstrand, Technical Advisor,
<outbind://7/mail%20to:%20harald@alvestrand.no> harald@alvestrand.no
        RFC 2026 Submissions to IETF Director,
<outbind://7/mail%20to:%20scoya@ietf.org> scoya@ietf.org



=20

------_=_NextPart_001_01C19EF0.0E3E7B40
Content-Type: text/html;
charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUTF-8">


<META content=3D"MSHTML 6.00.2712.300" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P align=3Dleft><FONT face=3DArial>January 16, 2002</FONT></P></DIV>
<DIV align=3Djustify><FONT face=3DArial>Internet Engineering Task =
Force&nbsp;<SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>VIA E-MAIL TO:</FONT></DIV>
<DIV><FONT face=3DArial>idn Working Group Mailing List<SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>=20
</FONT><A href=3D"mailto:idn@ops.ietf.org"><FONT=20
face=3DArial>idn@ops.ietf.org</FONT></A></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV align=3Djustify><FONT face=3DArial>Re:&nbsp;<SPAN =
class=3D340313600-17012002>=20
</SPAN><SPAN class=3D340313600-17012002>IETF </SPAN>Notification of =
Patent=20
Publication for </FONT><A=20
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;D
=
B=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+"><FONT=20
face=3DArial>WO 01/90955 A2</FONT></A><FONT face=3DArial> </FONT></DIV>
<DIV align=3Djustify><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Our=20
File No. 561401-9010</FONT></DIV>
<DIV>
<P align=3Djustify><FONT face=3DArial></FONT></P>
<P align=3Djustify><FONT face=3DArial>Dear Subscribers:</FONT></P>
<P align=3Djustify><FONT face=3DArial></FONT></P>
<P><FONT face=3DArial>In accordance with </FONT><A=20
href=3D"outbind://7/IESG/Section10.txt"><FONT face=3DArial>Section=20
10</FONT></A><FONT face=3DArial> of the </FONT><A=20
href=3D"outbind://7/rfc/rfc2026.txt"><FONT face=3DArial>The Internet =
Standards=20
Process</FONT></A><FONT face=3DArial> (RFC 2026), we are writing on =
behalf of=20
</FONT><A=20
href=3D"http://l2.espacenet.com/dips/viewer?PN=3DWO0190955&amp;CY=3Dep&a
=
mp;LG=3Den&amp;DB=3DEPD"><FONT=20
face=3DArial>.NU Domain</FONT></A><FONT face=3DArial> and its affiliate
=
</FONT><A=20
href=3D"http://www.worldnames.net/"><FONT =
face=3DArial>WorldNames,</FONT></A><FONT=20
face=3DArial><SUP>TM </SUP>Inc. to notify you of the publication of =
World=20
Intellectual Property Organization International Publication No. =
</FONT><A=20
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;D
=
B=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+"><FONT=20
face=3DArial>WO 01/90955 A2</FONT></A><FONT face=3DArial> entitled=20
"Internationalized Domain Name System with Iterative Conversion." A =
copy of this=20
document is available at the&nbsp;<SPAN=20
class=3D340313600-17012002>following&nbsp;website</SPAN><SPAN=20
class=3D340313600-17012002>:</SPAN><SPAN class=3D340313600-17012002>=20
</SPAN></FONT></P>
<P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D340313600-17012002><A=20
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;D
=
B=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+">http://l2.espacen
=
et.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;DB=3DEPD&amp;PN=3DWO019095
=
5&amp;ID=3DWO+++0190955A2+I+</A>&nbsp;</SPAN></FONT></FONT></P>
<P><SPAN class=3D340313600-17012002></SPAN><FONT face=3DArial>Th<SPAN=20
class=3D340313600-17012002>is&nbsp;</SPAN>patent application generally =
relates to=20
a system, method, and logic for managing data, including a database for
=

implementing a key value operation, such as a DNS resource record =
lookup, with a=20
key having a predetermined encoding, such as Unicode. Also provided is =
an=20
iterative converter for iteratively converting the key from each of =
multiple=20
encodings to the predetermined encoding before performing the key value
=

operation with each converted key. The system may also include a =
validator for=20
verifying that a syntax of each converted key is valid and a normalizer
=
for=20
normalizing each converted key. </FONT></P>
<P><FONT face=3DArial></FONT></P>
<P><FONT face=3DArial>We believe that many of the technologies being =
discussed in=20
this mailing list infringe one or more of the 213 claims starting at =
page 87 of=20
the attached publication. We would therefore like to propose that you =
review=20
these claims and contact us immediately with regard to obtaining a =
license=20
and/or authorized access to WorldNames=E2=84=A2 </FONT><A=20
href=3D"http://www.worldnames.net/MLDNS/default.cfm"><FONT =
face=3DArial>MLDNS=E2=84=A2=20
multilingual DNS products and services</FONT></A><FONT face=3DArial> =
described=20
at&nbsp;<SPAN class=3D340313600-17012002>the =
following&nbsp;</SPAN>hyperlink<SPAN=20
class=3D340313600-17012002>:</SPAN></FONT></P>
<P><FONT face=3DArial><SPAN class=3D340313600-17012002></SPAN><FONT=20
size=3D2>&nbsp;</FONT><A =
href=3D"http://www.worldnames.net/MLDNS/default.cfm"><FONT=20
size=3D2>http://www.worldnames.net/MLDNS/default.cfm</FONT></A></FONT></
=
P>
<P><FONT face=3DArial>Please note that failure to promptly obtain the =
appropriate=20
authorization may subject you and your organization to liability for =
royalties=20
in the U.S. as of the date that you receive this letter under </FONT><A
=

href=3D"http://www4.law.cornell.edu/uscode/35/154.html"><FONT =
face=3DArial>35 U.S.C.=20
=C2=A7154(d)</FONT></A><FONT face=3DArial>. Once the application is =
granted, additional=20
</FONT><A href=3D"http://www.bitlaw.com/source/35usc/281.html"><FONT=20
face=3DArial>remedies</FONT></A><FONT face=3DArial> are also available =
including=20
</FONT><A href=3D"http://www.bitlaw.com/source/35usc/283.html"><FONT=20
face=3DArial>injunctions</FONT></A><FONT face=3DArial>, </FONT><A=20
href=3D"http://www.bitlaw.com/source/35usc/284.html"><FONT =
face=3DArial>treble=20
damages</FONT></A><FONT face=3DArial>, and </FONT><A=20
href=3D"http://www.bitlaw.com/source/35usc/285.html"><FONT =
face=3DArial>attorney=20
fees</FONT></A><FONT face=3DArial>. A variety of other </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/295.html"><FONT=20
face=3DArial>presumptions</FONT></A><FONT face=3DArial> and </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/281.html"><FONT=20
face=3DArial>remedies</FONT></A><FONT face=3DArial> may also be =
available </FONT><A=20
href=3D"http://www.usitc.gov/us337.htm"><FONT face=3DArial>in the=20
U.S</FONT></A><FONT face=3DArial>. and abroad.</FONT></P>
<P><FONT face=3DArial>If you believe that you have a </FONT><A=20
href=3D"http://www.bitlaw.com/source/35usc/282.html"><FONT=20
face=3DArial>defense</FONT></A><FONT face=3DArial> to these =
allegations, such as=20
non-</FONT><A =
href=3D"http://www4.law.cornell.edu/uscode/35/271.html"><FONT=20
face=3DArial>infringement</FONT></A><FONT face=3DArial> or </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/273.html"><FONT =
face=3DArial>prior=20
invention</FONT></A><FONT face=3DArial>, then please provide us with =
additional=20
information to refute our allegations and avoid further involvement =
with this=20
matter. Similarly, if you believe that any of the attached claims are =
not=20
</FONT><A =
href=3D"http://www4.law.cornell.edu/uscode/35/pIIch10.html"><FONT=20
face=3DArial>patentable</FONT></A><FONT face=3DArial>, then please =
bring them to our=20
attention, along with any relevant </FONT><A=20
href=3D"http://www4.law.cornell.edu/uscode/35/102.html"><FONT =
face=3DArial>prior=20
art</FONT></A><FONT face=3DArial>, so that we may submit that =
information to the=20
appropriate patent offices.</FONT></P>
<P><FONT face=3DArial>We are looking forward to hearing from you as =
soon as=20
possible.</FONT></P>
<P><FONT face=3DArial>Sincerely,</FONT></P>
<P><FONT face=3DArial>William F. Heinze, Esq.* <BR>Thomas, Kayden, =
Horstemeyer=20
&amp; Risley, L.L.P. <BR>100 Galleria Parkway, N.W., Suite 1750 =
<BR>Atlanta, GA=20
30339-5948 </FONT></P>
<P><FONT face=3DArial>Tel.:&nbsp; (770)&nbsp;<SPAN=20
class=3D340313600-17012002>933-9500</SPAN> <BR>Fax:&nbsp; (770) =
951-0933=20
<BR></FONT><FONT face=3DArial>Profile:&nbsp; </FONT><A=20
href=3D"http://www.tkhr.com/wfh.htm" target=3D_blank><FONT=20
face=3DArial>http://www.tkhr.com/wfh.htm</FONT></A><U></U><FONT =
face=3DArial>=20
</FONT></P>
<P><FONT face=3DArial>*Admitted to practice in the Commonwealth of =
Virginia.&nbsp;=20
Not admitted in Georgia. <BR></FONT></P>
<P><FONT face=3DArial></FONT></P></DIV>
<DIV><FONT face=3DArial>cc:&nbsp;<SPAN =
class=3D340313600-17012002>&nbsp; </SPAN>Mr.=20
James Seng, Co-Chair, idn Working Group, </FONT><A=20
href=3D"outbind://7/mail%20to:%20jseng@pobox.org.sg"><FONT=20
face=3DArial>jseng@pobox.org.sg</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Marc Blanchet, Co-Chair, idn Working Group, </FONT><A=20
href=3D"outbind://7/Mail%20to:%20Marc.Blanchet@viagenie.qc.ca"><FONT=20
face=3DArial>Marc.Blanchet@viagenie.qc.ca</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Erik Nordmark, Internet Area Director, </FONT><A=20
href=3D"outbind://7/mail%20to:%20nordmark@eng.sun.com"><FONT=20
face=3DArial>nordmark@eng.sun.com</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Thomas Narten, Internet Area Director, </FONT><A=20
href=3D"mailto:narten@us.ibm.com"><FONT=20
face=3DArial>narten@us.ibm.com</FONT></A><FONT face=3DArial> =
</FONT></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
John Klensin, Technical Advisor, </FONT><A =
href=3D"mailto:klensin@jck.com"><FONT=20
face=3DArial>klensin@jck.com</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
Harald Alverstrand, Technical Advisor, </FONT><A=20
href=3D"outbind://7/mail%20to:%20harald@alvestrand.no"><FONT=20
face=3DArial>harald@alvestrand.no</FONT></A></DIV>
<DIV><FONT face=3DArial><SPAN=20
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>RFC=20
2026 Submissions to IETF Director, </FONT><A=20
href=3D"outbind://7/mail%20to:%20scoya@ietf.org"><FONT=20
face=3DArial>scoya@ietf.org</FONT></A></DIV>
<P>
<P><FONT face=3DArial></FONT></P></P><BR>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C19EF0.0E3E7B40--






From owner-idn@ops.ietf.org  Thu Jan 17 04:26:45 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10512
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 04:26:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16R8Q2-0007RJ-00
	for idn-data@psg.com; Thu, 17 Jan 2002 01:01:10 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16R8Q0-0007Qn-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 01:01:09 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP
	id 342ECFFC17; Thu, 17 Jan 2002 17:00:24 +0800 (SGT)
Message-ID: <003e01c19f35$758ccf50$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Heinze, Bill" <bill.heinze@tkhr.com>, "Dave Crocker" <dhc@dcrocker.net>
Cc: <idn@ops.ietf.org>
References: <5.1.0.14.2.20020117000054.03a04db0@127.0.0.1>
Subject: Re: [idn] Re: 
Date: Thu, 17 Jan 2002 17:00:43 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On the leakage of the MIME format of Bill's mail, it is a problem of my
side. Sorry. For some reasons when I bounce mails with MIME contain thru
majordomo, it tends to screwed up, especially when there is a long list
of headers.

Anyway, I already put Bill onto the auto-approve list since he is not on
the idn list directly.

-James Seng

----- Original Message -----
From: "Dave Crocker" <dhc@dcrocker.net>
To: "Heinze, Bill" <bill.heinze@tkhr.com>
Cc: <idn@ops.ietf.org>; <george.thomas@tkhr.com>; <jim.kayden@tkhr.com>;
<scott.horstemeyer@tkhr.com>; <steve.risley@tkhr.com>;
<jeff.kuester@tkhr.com>; <dan.mcclure@tkhr.com>; <dan.santos@tkhr.com>;
<dan.gresham@tkhr.com>; <scott.culpepper@tkhr.com>;
<mike.tempel@tkhr.com>; <david.risley@tkhr.com>
Sent: Thursday, January 17, 2002 4:31 PM
Subject: [idn] Re:


> Dear Bill,
>
> On the off chance that the email to the IETF's IDN list, with your
address
> in the From field, was not an attempt by you or someone else to
proffer
> some form of humor, a few comments are in order:
>
> When making making claims of technical innovation, especially to a
> technical body, it helps to use the communications technology
> properly.  Your note was nearly incoherent because of serious encoding
> problems with your posting.  Further the web citations your provided
were
> quite unusable.  As well, <http://l2.espacenet.com/> appears to be
> inaccessible.
>
> Nonetheless:
>
>
> At 10:43 PM 1/16/2002 -0800, Heinze, Bill wrote:
> >notify you of the publication of World Intellectual Property =
> >Organization International Publication No.
>
> A WIPO publication?  How nice.
>
> When did WIPO start issuing patents?
>
>
> >This patent application generally relates to a system, method, and
>
> Application?  As in, no force of law yet?  How interesting.
>
>
> >We believe that many of the technologies being discussed in this =
> >mailing
> >list infringe one or more of the 213 claims starting at page 87 of
the
>
> 1.  It is a bit unusual to refer to a "technology" as infringing.
Perhaps
> you meant that you believe that some product USING the technology
would be
> infringing?  A pity your meaning is unclear.
>
> 2.  Patent applications usually begin with an impressively inflated
number
> of claims.  For those patents that actually issue, the number of
claims
> that survive is typically vastly smaller.  That makes it difficult
even to
> guess which portions of your impressive list of claims one should
worry about.
>
>
> >Please note that failure to promptly obtain the appropriate =
> >authorization may subject you and your organization to liability for
> >royalties in the
>
> You are threatening legal actions against folks in this standards
> organizations for doing standards work without paying you a license
fee?
>
> Either you are jesting or, alas, once again at least being
impressively
> unclear.
>
>
> >William F. Heinze, Esq.
>
> Esquire?  Cute touch, though doesn't it create a challenge for what to
use
> upon making partner?
>
>
> At any rate, please do feel free to distract our discussion list
further,
> but perhaps with postings that are more readable in format and clear
in
> content.
>
> And in that unfortunate off chance that you were not the originator of
the
> note sent under your name, to the person who did:  tsk. tsk.  Why
would you
> want to alienate this standards organization to Mr. Heinze, by posting
such
> a bothersome note, so badly formulated?
>
> d/
>
> ----------
> Dave Crocker  <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464
>
>




From owner-idn@ops.ietf.org  Thu Jan 17 04:31:45 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10573
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 04:31:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16R8ZZ-0007bJ-00
	for idn-data@psg.com; Thu, 17 Jan 2002 01:11:01 -0800
Received: from gro.dd.org ([209.198.103.200])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16R8ZY-0007bC-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 01:11:00 -0800
Received: (from tale@localhost)
	by gro.dd.org (8.11.6/8.11.6) id g0H9AtO80221;
	Thu, 17 Jan 2002 04:10:55 -0500 (EST)
	(envelope-from tale@gro.dd.org)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15430.38175.264996.322156@gro.dd.org>
Date: Thu, 17 Jan 2002 04:10:55 -0500
From: tale@nominum.com (David C Lawrence)
To: idn@ops.ietf.org
Subject: Re: [idn] Re: 
In-Reply-To: <5.1.0.14.2.20020117000054.03a04db0@127.0.0.1>
References: <E16R6Gs-0005BS-00@psg.com>
	<5.1.0.14.2.20020117000054.03a04db0@127.0.0.1>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dave Crocker writes:
> As well, <http://l2.espacenet.com/> appears to be inaccessible.

Going to the full URL (after demunging the quoted-printable) works.

It is:
http://l2.espacenet.com/dips/bnsviewer?CY=ep&LG=en&DB=EPD&PN=WO0190955&ID=WO+++0190955A2+I+




From owner-idn@ops.ietf.org  Thu Jan 17 06:25:15 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11844
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 06:25:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RAOO-0009PI-00
	for idn-data@psg.com; Thu, 17 Jan 2002 03:07:36 -0800
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Stuart Cheshire <cheshire@apple.com>, idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <11126403.1011268654@localhost>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Date: Thu, 17 Jan 2002 03:07:36 -0800

--On 2002-01-14 11.57 -0800 Stuart Cheshire <cheshire@apple.com> wrote:

> It seems to me that one of the great problems of IDN is one that is=20
> fundamentally unsolvable: an attempt to determine, once and for all
time, =

> a single global set of rules for deciding if two strings are "equal"
or=20
> "equivalent".

In the DNS system, there is a general rule (as you point out) that the
same
matching rule is to be used for a label regardless of from where the
query
is sent, to what server, and in what domain the label exists.

Reason for this is to prevent confusion, and to secure the in DNS needed
global uniqueness.

Example: If a.com and b.com is considered equal, why should not a.se and
b.se be equal? If a.com and b.com is equal, why is not a.a.com and
b.a.com?

Basically, you ask for context specific matching rules, and that is
something which is impossible to handle in the DNS protocol, because the
client and server can not exchange context. Yes, you point out the only
context that is available, the name of the parent domain. But, how is
the
client able to know what rules exists in a specific domain? Further, is
not
the matching rule more depending on what language the registrant of the
domain and the one querying is using than what parent domain the domain
is
registered in? I would as a swedish-speaking person claim that 'a'
followed
by combining diaeresis be a different character than adiaeresis, while
someone using some other language might think they should be equal. The
same way, I would like having the 'o' with slash and the odiaeresis be
considered the same, while others disagree. All of this because of _my_
culture.

So, this wg decided that we will use one and only one matching rule,
just
like we decided to use only one character set. Both of these (the rule
and
the charset) are created in the Unicode Consortium.

You also talk about "evolving matching rules over time". That is a very
bad
thing.

Let's say that we have registered apple.com and =E4pple.com. They are
considered different. One day the equivalence rule change, and they are
considered being the same. Who is calling Steve Jobs saying that
apple.com
have to give back it's domain name and pick something else? You? ICANN?
The
registry for .com?

    paf






From owner-idn@ops.ietf.org  Thu Jan 17 06:58:12 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12609
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 06:58:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RAyb-0009yS-00
	for idn-data@psg.com; Thu, 17 Jan 2002 03:45:01 -0800
Received: from mx-out.daemonmail.net ([209.75.5.3])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RAya-0009yJ-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 03:45:00 -0800
Received: from mx0.emailqueue.net (localhost.daemonmail.net [127.0.0.1])
	by mx-out.daemonmail.net (8.9.3/8.9.3) with SMTP id DAA18436;
	Thu, 17 Jan 2002 03:44:53 -0800 (PST)
	(envelope-from rosenne@qsm.co.il)
From: rosenne@qsm.co.il
Received: from qsm3 (qsm3 [212.150.100.12])
	by mail.qsm.co.il with ESMTP id Zm405rA2
	Wed, 08 May 1974 04:56:12 -0700 (PDT)
To: "IDN List" <idn@ops.ietf.org>
Cc: "'Heinze, Bill'" <bill.heinze@tkhr.com>
Subject: [idn] RE: IETF Notification of Patent Publication for WO
Date: Thu, 17 Jan 2002 13:44:19 +0200
Message-ID: <001401c19f4c$4fa79c40$eb0110ac@qsm3>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <E16R6Gs-0005BS-00@psg.com>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Since I am just a reader and occasional contributor to this list, with
no official status, I feel free to comment.

I don't believe any patent, valid or not, can be construed to restrain
free speech. I cannot see why we cannot discuss any of these items,
including the validity of the patent claim, whether and how to refute
their claims and whether and how to circumvent or bypass them.

On the face of it, the claims seem ludicrous, but I would like to see
them more clearly. Since the mail as sent is unreadable, I don't want to
be guessing what was meant.

I suggest that Mr. Heinze send his mail again in a readable format, if
he desires to make a note of having sent it to this list.

Jony





From owner-idn@ops.ietf.org  Thu Jan 17 08:24:15 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14487
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 08:24:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RCJE-000BMv-00
	for idn-data@psg.com; Thu, 17 Jan 2002 05:10:24 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RCJD-000BMk-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 05:10:23 -0800
Received: from classic (dhcp380.ripemtg.ripe.net [193.0.5.124])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0HDQga44142;
	Thu, 17 Jan 2002 08:26:42 -0500 (EST)
Date: Thu, 17 Jan 2002 08:13:11 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: IDN List <idn@ops.ietf.org>
cc: "'Heinze, Bill'" <bill.heinze@tkhr.com>
Subject: Re: [idn] RE: IETF Notification of Patent Publication for WO
Message-ID: <35720000.1011273191@classic>
In-Reply-To: <001401c19f4c$4fa79c40$eb0110ac@qsm3>
References:  <001401c19f4c$4fa79c40$eb0110ac@qsm3>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

It would be great if someone could assemble these 131 different pdf files 
in one file. I don't know how to do this, but that would be very useful!

Does the patent holder could do that for us?

Marc.



From owner-idn@ops.ietf.org  Thu Jan 17 09:12:02 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15900
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 09:12:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RCrT-000BuU-00
	for idn-data@psg.com; Thu, 17 Jan 2002 05:45:47 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RCrT-000BuO-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 05:45:47 -0800
Received: from classic (dhcp380.ripemtg.ripe.net [193.0.5.124])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0HE25a44582
	for <idn@ops.ietf.org>; Thu, 17 Jan 2002 09:02:05 -0500 (EST)
Date: Thu, 17 Jan 2002 08:48:34 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: idn@ops.ietf.org
Subject: [idn] script to fetch the patent
Message-ID: <44880000.1011275314@classic>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA15900

Hi,
 I looked at the html source of the patent web site.
 for unix users or cygwin users, here is, with no garantee at all and 
probably full of security virus..;-)), a script to fetch all the pages of 
the patent. Use on your own. (it works for me). Next version would be a 
merger of all pdf files all together (don't know how to do it).

Marc.

---------------
#!/bin/csh
set c=1
while ($c < 132)
wget -O nudomain-patent-p$c.pdf 
"http://l2.espacenet.com/dips/bns.pdf?CY=ep&LG=en&PN=WO0190955&ID=WO+++0190
955A2+I+&PG=$c"
@ c++
end
-------------


------------------------------------------
Marc Blanchet
Viag�nie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------



From owner-idn@ops.ietf.org  Thu Jan 17 10:46:41 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19403
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 10:46:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RETf-000DYQ-00
	for idn-data@psg.com; Thu, 17 Jan 2002 07:29:19 -0800
Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RETd-000DYK-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 07:29:18 -0800
Received: from askvoll.hjemme.alvestrand.no (askvoll.hjemme.alvestrand.no [192.168.1.4])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id AEC2361F4D; Thu, 17 Jan 2002 16:29:11 +0100 (CET)
Date: Thu, 17 Jan 2002 16:29:11 +0100
From: Harald Alvestrand <harald@alvestrand.no>
To: "Heinze, Bill" <bill.heinze@tkhr.com>,
        "'idn@ops.ietf.org'" <idn@ops.ietf.org>
Cc: "'Mr. James Seng, Co-Chair, idn Working Group,'" <jseng@pobox.org.sg>,
        "'Mr. Marc Blanchet, Co-Chair, idn Working Group,'" <Marc.Blanchet@viagenie.qc.ca>,
        "'Mr. Erik Nordmark, Internet Area Director,'" <nordmark@eng.sun.com>,
        "'Mr. Thomas Narten, Internet Area Director,'" <narten@us.ibm.com>,
        "'Mr. John Klensin, Technical Advisor,'" <klensin@jck.com>,
        "'RFC 2026 Submissions to IETF Director,'" <scoya@ietf.org>
Subject: [idn] Re: IETF Notification of Patent Publication for WO 01/90955 A2
Message-ID: <1022890000.1011281348@askvoll.hjemme.alvestrand.no>
In-Reply-To: <F6C05EF93BA2D41193BC00B0D07833466FD31A@TKHR_NT>
References:  <F6C05EF93BA2D41193BC00B0D07833466FD31A@TKHR_NT>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA19403

Thank you for your message.
It will be published on the IETF IPR statements web page.

We have some trouble parsing it, however, since:

- there is no attached document with more than 87 pages
- the URL referred to does not point to a conformant HTTP page
- discussion of technology does not in general require a license;
  the IETF as such does not implement technology.

If you desire comments from the IETF community on the patent claim, pointing
to or enclosing a single document might be a more useful way of sending it.

             Harald Alvestrand, speaking in the IETF officer role

--On onsdag, januar 16, 2002 19:44:01 -0500 "Heinze, Bill" 
<bill.heinze@tkhr.com> wrote:

>
>
> January 16, 2002
> Internet Engineering Task Force                 VIA E-MAIL TO:
> idn Working Group Mailing List                 idn@ops.ietf.org
>
> Re:  IETF Notification of Patent Publication for WO 01/90955 A2
>         Our File No. 561401-9010
>
>
> Dear Subscribers:
>
>
> In accordance with Section 10 of the The Internet Standards Process (RFC
> 2026), we are writing on behalf of .NU Domain and its affiliate
> WorldNames,TM Inc. to notify you of the publication of World Intellectual
> Property Organization International Publication No. WO 01/90955 A2
> entitled "Internationalized Domain Name System with Iterative
> Conversion." A copy of this document is available at the following
> website:
>
> http://l2.espacenet.com/dips/bnsviewer?CY=ep&LG=en&DB=EPD&PN=WO0190955&ID
> =WO+++0190955A2+I+
>
> This patent application generally relates to a system, method, and logic
> for managing data, including a database for implementing a key value
> operation, such as a DNS resource record lookup, with a key having a
> predetermined encoding, such as Unicode. Also provided is an iterative
> converter for iteratively converting the key from each of multiple
> encodings to the predetermined encoding before performing the key value
> operation with each converted key. The system may also include a
> validator for verifying that a syntax of each converted key is valid and
> a normalizer for normalizing each converted key.
>
>
> We believe that many of the technologies being discussed in this mailing
> list infringe one or more of the 213 claims starting at page 87 of the
> attached publication. We would therefore like to propose that you review
> these claims and contact us immediately with regard to obtaining a
> license and/or authorized access to WorldNames™ MLDNS™ multilingual
> DNS products and services described at the following hyperlink:
>
>  http://www.worldnames.net/MLDNS/default.cfm
>
> Please note that failure to promptly obtain the appropriate authorization
> may subject you and your organization to liability for royalties in the
> U.S. as of the date that you receive this letter under 35 U.S.C.
> §154(d). Once the application is granted, additional remedies are also
> available including injunctions, treble damages, and attorney fees. A
> variety of other presumptions and remedies may also be available in the
> U.S. and abroad.
>
> If you believe that you have a defense to these allegations, such as
> non-infringement or prior invention, then please provide us with
> additional information to refute our allegations and avoid further
> involvement with this matter. Similarly, if you believe that any of the
> attached claims are not patentable, then please bring them to our
> attention, along with any relevant prior art, so that we may submit that
> information to the appropriate patent offices.
>
> We are looking forward to hearing from you as soon as possible.
>
> Sincerely,
>
> William F. Heinze, Esq.*
> Thomas, Kayden, Horstemeyer & Risley, L.L.P.
> 100 Galleria Parkway, N.W., Suite 1750
> Atlanta, GA 30339-5948
>
> Tel.:  (770) 933-9500
> Fax:  (770) 951-0933
> Profile:  http://www.tkhr.com/wfh.htm
>
> *Admitted to practice in the Commonwealth of Virginia.  Not admitted in
> Georgia.
>
>
> cc:   Mr. James Seng, Co-Chair, idn Working Group, jseng@pobox.org.sg
>         Mr. Marc Blanchet, Co-Chair, idn Working Group,
> Marc.Blanchet@viagenie.qc.ca          Mr. Erik Nordmark, Internet Area
> Director, nordmark@eng.sun.com          Mr. Thomas Narten, Internet Area
> Director, narten@us.ibm.com          Mr. John Klensin, Technical Advisor,
> klensin@jck.com
>         Mr. Harald Alverstrand, Technical Advisor, harald@alvestrand.no
>         RFC 2026 Submissions to IETF Director, scoya@ietf.org
>
>
>
>
>





From owner-idn@ops.ietf.org  Thu Jan 17 13:37:03 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29583
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 13:37:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RH7Z-000GXj-00
	for idn-data@psg.com; Thu, 17 Jan 2002 10:18:41 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RH7W-000GXE-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 10:18:39 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP
	id E8AB3FFC48; Fri, 18 Jan 2002 02:18:11 +0800 (SGT)
Message-ID: <028101c19f83$61147f70$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Heinze, Bill" <bill.heinze@tkhr.com>, <idn@ops.ietf.org>
Cc: "'Mr. Marc Blanchet, Co-Chair, idn Working Group,'" <Marc.Blanchet@viagenie.qc.ca>,
        "'Mr. Erik Nordmark, Internet Area Director,'" <nordmark@eng.sun.com>,
        "'Mr. Thomas Narten, Internet Area Director,'" <narten@us.ibm.com>,
        "'Mr. John Klensin, Technical Advisor,'" <klensin@jck.com>,
        "'Mr. Harald Alverstrand, Technical Advisor,'" <harald@alvestrand.no>,
        "'RFC 2026 Submissions to IETF Director,'" <scoya@ietf.org>
References: <F6C05EF93BA2D41193BC00B0D07833466FD31A@TKHR_NT>
Subject: [idn] Re: IETF Notification of Patent Publication for WO 01/90955 A2 
Date: Fri, 18 Jan 2002 02:18:30 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_027C_01C19FC6.6BFE8D70"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_027C_01C19FC6.6BFE8D70
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Bill,

I acknowlegded I received this mail as "co-chair for idn wg". I have =
also tried to forward your mail to the idn wg mailing list but somehow =
it is messed up (sorry). I would appreciate if you can resend your mail =
to the idn wg again.

Since Harald had already responded to you on the behalf of IETF so I =
have no further comemnts to add.

Incidently, IETF generally have more engineers and very few lawyers. I =
am not sure if idn wg is in any position to review your patent filing =
claims, a job usually reserved for patent lawyers.=20

-James Seng
  ----- Original Message -----=20
  From: Heinze, Bill=20
  To: 'idn@ops.ietf.org'=20
  Cc: 'Mr. James Seng, Co-Chair, idn Working Group,' ; 'Mr. Marc =
Blanchet, Co-Chair, idn Working Group,' ; 'Mr. Erik Nordmark, Internet =
Area Director,' ; 'Mr. Thomas Narten, Internet Area Director,' ; 'Mr. =
John Klensin, Technical Advisor,' ; 'Mr. Harald Alverstrand, Technical =
Advisor,' ; 'RFC 2026 Submissions to IETF Director,'=20
  Sent: Thursday, January 17, 2002 8:44 AM
  Subject: IETF Notification of Patent Publication for WO 01/90955 A2=20


  January 16, 2002

  Internet Engineering Task Force                 VIA E-MAIL TO:
  idn Working Group Mailing List                 idn@ops.ietf.org

  Re:  IETF Notification of Patent Publication for WO 01/90955 A2=20
          Our File No. 561401-9010

  Dear Subscribers:


  In accordance with Section 10 of the The Internet Standards Process =
(RFC 2026), we are writing on behalf of .NU Domain and its affiliate =
WorldNames,TM Inc. to notify you of the publication of World =
Intellectual Property Organization International Publication No. WO =
01/90955 A2 entitled "Internationalized Domain Name System with =
Iterative Conversion." A copy of this document is available at the =
following website:=20

  =
http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&LG=3Den&DB=3DEPD&PN=3DWO01=
90955&ID=3DWO+++0190955A2+I+=20

  This patent application generally relates to a system, method, and =
logic for managing data, including a database for implementing a key =
value operation, such as a DNS resource record lookup, with a key having =
a predetermined encoding, such as Unicode. Also provided is an iterative =
converter for iteratively converting the key from each of multiple =
encodings to the predetermined encoding before performing the key value =
operation with each converted key. The system may also include a =
validator for verifying that a syntax of each converted key is valid and =
a normalizer for normalizing each converted key.=20


  We believe that many of the technologies being discussed in this =
mailing list infringe one or more of the 213 claims starting at page 87 =
of the attached publication. We would therefore like to propose that you =
review these claims and contact us immediately with regard to obtaining =
a license and/or authorized access to WorldNames=E2=84=A2 MLDNS=E2=84=A2 =
multilingual DNS products and services described at the following =
hyperlink:

   http://www.worldnames.net/MLDNS/default.cfm

  Please note that failure to promptly obtain the appropriate =
authorization may subject you and your organization to liability for =
royalties in the U.S. as of the date that you receive this letter under =
35 U.S.C. =C2=A7154(d). Once the application is granted, additional =
remedies are also available including injunctions, treble damages, and =
attorney fees. A variety of other presumptions and remedies may also be =
available in the U.S. and abroad.

  If you believe that you have a defense to these allegations, such as =
non-infringement or prior invention, then please provide us with =
additional information to refute our allegations and avoid further =
involvement with this matter. Similarly, if you believe that any of the =
attached claims are not patentable, then please bring them to our =
attention, along with any relevant prior art, so that we may submit that =
information to the appropriate patent offices.

  We are looking forward to hearing from you as soon as possible.

  Sincerely,

  William F. Heinze, Esq.*=20
  Thomas, Kayden, Horstemeyer & Risley, L.L.P.=20
  100 Galleria Parkway, N.W., Suite 1750=20
  Atlanta, GA 30339-5948=20

  Tel.:  (770) 933-9500=20
  Fax:  (770) 951-0933=20
  Profile:  http://www.tkhr.com/wfh.htm=20

  *Admitted to practice in the Commonwealth of Virginia.  Not admitted =
in Georgia.=20



  cc:   Mr. James Seng, Co-Chair, idn Working Group, jseng@pobox.org.sg
          Mr. Marc Blanchet, Co-Chair, idn Working Group, =
Marc.Blanchet@viagenie.qc.ca
          Mr. Erik Nordmark, Internet Area Director, =
nordmark@eng.sun.com
          Mr. Thomas Narten, Internet Area Director, narten@us.ibm.com=20
          Mr. John Klensin, Technical Advisor, klensin@jck.com
          Mr. Harald Alverstrand, Technical Advisor, =
harald@alvestrand.no
          RFC 2026 Submissions to IETF Director, scoya@ietf.org







------=_NextPart_000_027C_01C19FC6.6BFE8D70
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUTF-8">
<META content=3D"MSHTML 5.50.4912.300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY dir=3Dltr bgColor=3D#ffffff>
<DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Hi Bill,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>I acknowlegded I received this =
mail as=20
"co-chair for idn wg". I have also tried to forward your mail to the idn =
wg=20
mailing list but somehow it is messed up (sorry). I would appreciate if =
you can=20
resend your mail to the idn wg&nbsp;again.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Since Harald had already =
responded to you=20
on the behalf of IETF so I have no further comemnts to add.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Incidently, IETF generally have =
more=20
engineers and very few lawyers. I am not sure if idn wg is in any =
position to=20
review your patent filing claims, a job usually reserved for patent =
lawyers.=20
</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-James Seng</FONT></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dbill.heinze@tkhr.com =
href=3D"mailto:bill.heinze@tkhr.com">Heinze,=20
  Bill</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Didn@ops.ietf.org =

  href=3D"mailto:'idn@ops.ietf.org'">'idn@ops.ietf.org'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Djseng@pobox.org.sg=20
  href=3D"mailto:jseng@pobox.org.sg">'Mr. James Seng, Co-Chair, idn =
Working=20
  Group,'</A> ; <A title=3DMarc.Blanchet@viagenie.qc.ca=20
  href=3D"mailto:Marc.Blanchet@viagenie.qc.ca">'Mr. Marc Blanchet, =
Co-Chair, idn=20
  Working Group,'</A> ; <A title=3Dnordmark@eng.sun.com=20
  href=3D"mailto:nordmark@eng.sun.com">'Mr. Erik Nordmark, Internet Area =

  Director,'</A> ; <A title=3Dnarten@us.ibm.com=20
  href=3D"mailto:narten@us.ibm.com">'Mr. Thomas Narten, Internet Area=20
  Director,'</A> ; <A title=3Dklensin@jck.com =
href=3D"mailto:klensin@jck.com">'Mr.=20
  John Klensin, Technical Advisor,'</A> ; <A =
title=3Dharald@alvestrand.no=20
  href=3D"mailto:harald@alvestrand.no">'Mr. Harald Alverstrand, =
Technical=20
  Advisor,'</A> ; <A title=3Dscoya@ietf.org =
href=3D"mailto:scoya@ietf.org">'RFC 2026=20
  Submissions to IETF Director,'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, January 17, =
2002 8:44=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> IETF Notification of =
Patent=20
  Publication for WO 01/90955 A2 </DIV>
  <DIV><FONT face=3D"Courier New" size=3D2></FONT><BR></DIV>
  <DIV>
  <P align=3Dleft><FONT face=3DArial>January 16, 2002</FONT></P></DIV>
  <DIV align=3Djustify><FONT face=3DArial>Internet Engineering Task =
Force&nbsp;<SPAN=20
  =
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN>VIA E-MAIL TO:</FONT></DIV>
  <DIV><FONT face=3DArial>idn Working Group Mailing List<SPAN=20
  =
class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>=20
  </FONT><A href=3D"mailto:idn@ops.ietf.org"><FONT=20
  face=3DArial>idn@ops.ietf.org</FONT></A></DIV>
  <DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
  <DIV align=3Djustify><FONT face=3DArial>Re:&nbsp;<SPAN =
class=3D340313600-17012002>=20
  </SPAN><SPAN class=3D340313600-17012002>IETF </SPAN>Notification of =
Patent=20
  Publication for </FONT><A=20
  =
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;DB=
=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+"><FONT=20
  face=3DArial>WO 01/90955 A2</FONT></A><FONT face=3DArial> =
</FONT></DIV>
  <DIV align=3Djustify><FONT face=3DArial><SPAN=20
  class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Our=20
  File No. 561401-9010</FONT></DIV>
  <DIV>
  <P align=3Djustify><FONT face=3DArial></FONT></P>
  <P align=3Djustify><FONT face=3DArial>Dear Subscribers:</FONT></P>
  <P align=3Djustify><FONT face=3DArial></FONT></P>
  <P><FONT face=3DArial>In accordance with </FONT><A=20
  href=3D"outbind://7/IESG/Section10.txt"><FONT face=3DArial>Section=20
  10</FONT></A><FONT face=3DArial> of the </FONT><A=20
  href=3D"outbind://7/rfc/rfc2026.txt"><FONT face=3DArial>The Internet =
Standards=20
  Process</FONT></A><FONT face=3DArial> (RFC 2026), we are writing on =
behalf of=20
  </FONT><A=20
  =
href=3D"http://l2.espacenet.com/dips/viewer?PN=3DWO0190955&amp;CY=3Dep&am=
p;LG=3Den&amp;DB=3DEPD"><FONT=20
  face=3DArial>.NU Domain</FONT></A><FONT face=3DArial> and its =
affiliate </FONT><A=20
  href=3D"http://www.worldnames.net/"><FONT =
face=3DArial>WorldNames,</FONT></A><FONT=20
  face=3DArial><SUP>TM </SUP>Inc. to notify you of the publication of =
World=20
  Intellectual Property Organization International Publication No. =
</FONT><A=20
  =
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;DB=
=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+"><FONT=20
  face=3DArial>WO 01/90955 A2</FONT></A><FONT face=3DArial> entitled=20
  "Internationalized Domain Name System with Iterative Conversion." A =
copy of=20
  this document is available at the&nbsp;<SPAN=20
  class=3D340313600-17012002>following&nbsp;website</SPAN><SPAN=20
  class=3D340313600-17012002>:</SPAN><SPAN class=3D340313600-17012002>=20
  </SPAN></FONT></P>
  <P><FONT face=3DArial><FONT size=3D2><SPAN =
class=3D340313600-17012002><A=20
  =
href=3D"http://l2.espacenet.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;DB=
=3DEPD&amp;PN=3DWO0190955&amp;ID=3DWO+++0190955A2+I+">http://l2.espacenet=
.com/dips/bnsviewer?CY=3Dep&amp;LG=3Den&amp;DB=3DEPD&amp;PN=3DWO0190955&a=
mp;ID=3DWO+++0190955A2+I+</A>&nbsp;</SPAN></FONT></FONT></P>
  <P><SPAN class=3D340313600-17012002></SPAN><FONT face=3DArial>Th<SPAN=20
  class=3D340313600-17012002>is&nbsp;</SPAN>patent application generally =
relates=20
  to a system, method, and logic for managing data, including a database =
for=20
  implementing a key value operation, such as a DNS resource record =
lookup, with=20
  a key having a predetermined encoding, such as Unicode. Also provided =
is an=20
  iterative converter for iteratively converting the key from each of =
multiple=20
  encodings to the predetermined encoding before performing the key =
value=20
  operation with each converted key. The system may also include a =
validator for=20
  verifying that a syntax of each converted key is valid and a =
normalizer for=20
  normalizing each converted key. </FONT></P>
  <P><FONT face=3DArial></FONT></P>
  <P><FONT face=3DArial>We believe that many of the technologies being =
discussed=20
  in this mailing list infringe one or more of the 213 claims starting =
at page=20
  87 of the attached publication. We would therefore like to propose =
that you=20
  review these claims and contact us immediately with regard to =
obtaining a=20
  license and/or authorized access to WorldNames=E2=84=A2 </FONT><A=20
  href=3D"http://www.worldnames.net/MLDNS/default.cfm"><FONT =
face=3DArial>MLDNS=E2=84=A2=20
  multilingual DNS products and services</FONT></A><FONT face=3DArial> =
described=20
  at&nbsp;<SPAN class=3D340313600-17012002>the=20
  following&nbsp;</SPAN>hyperlink<SPAN=20
  class=3D340313600-17012002>:</SPAN></FONT></P>
  <P><FONT face=3DArial><SPAN class=3D340313600-17012002></SPAN><FONT=20
  size=3D2>&nbsp;</FONT><A=20
  href=3D"http://www.worldnames.net/MLDNS/default.cfm"><FONT=20
  =
size=3D2>http://www.worldnames.net/MLDNS/default.cfm</FONT></A></FONT></P=
>
  <P><FONT face=3DArial>Please note that failure to promptly obtain the=20
  appropriate authorization may subject you and your organization to =
liability=20
  for royalties in the U.S. as of the date that you receive this letter =
under=20
  </FONT><A =
href=3D"http://www4.law.cornell.edu/uscode/35/154.html"><FONT=20
  face=3DArial>35 U.S.C. =C2=A7154(d)</FONT></A><FONT face=3DArial>. =
Once the application=20
  is granted, additional </FONT><A=20
  href=3D"http://www.bitlaw.com/source/35usc/281.html"><FONT=20
  face=3DArial>remedies</FONT></A><FONT face=3DArial> are also available =
including=20
  </FONT><A href=3D"http://www.bitlaw.com/source/35usc/283.html"><FONT=20
  face=3DArial>injunctions</FONT></A><FONT face=3DArial>, </FONT><A=20
  href=3D"http://www.bitlaw.com/source/35usc/284.html"><FONT =
face=3DArial>treble=20
  damages</FONT></A><FONT face=3DArial>, and </FONT><A=20
  href=3D"http://www.bitlaw.com/source/35usc/285.html"><FONT =
face=3DArial>attorney=20
  fees</FONT></A><FONT face=3DArial>. A variety of other </FONT><A=20
  href=3D"http://www4.law.cornell.edu/uscode/35/295.html"><FONT=20
  face=3DArial>presumptions</FONT></A><FONT face=3DArial> and </FONT><A=20
  href=3D"http://www4.law.cornell.edu/uscode/35/281.html"><FONT=20
  face=3DArial>remedies</FONT></A><FONT face=3DArial> may also be =
available=20
  </FONT><A href=3D"http://www.usitc.gov/us337.htm"><FONT =
face=3DArial>in the=20
  U.S</FONT></A><FONT face=3DArial>. and abroad.</FONT></P>
  <P><FONT face=3DArial>If you believe that you have a </FONT><A=20
  href=3D"http://www.bitlaw.com/source/35usc/282.html"><FONT=20
  face=3DArial>defense</FONT></A><FONT face=3DArial> to these =
allegations, such as=20
  non-</FONT><A =
href=3D"http://www4.law.cornell.edu/uscode/35/271.html"><FONT=20
  face=3DArial>infringement</FONT></A><FONT face=3DArial> or </FONT><A=20
  href=3D"http://www4.law.cornell.edu/uscode/35/273.html"><FONT =
face=3DArial>prior=20
  invention</FONT></A><FONT face=3DArial>, then please provide us with =
additional=20
  information to refute our allegations and avoid further involvement =
with this=20
  matter. Similarly, if you believe that any of the attached claims are =
not=20
  </FONT><A =
href=3D"http://www4.law.cornell.edu/uscode/35/pIIch10.html"><FONT=20
  face=3DArial>patentable</FONT></A><FONT face=3DArial>, then please =
bring them to=20
  our attention, along with any relevant </FONT><A=20
  href=3D"http://www4.law.cornell.edu/uscode/35/102.html"><FONT =
face=3DArial>prior=20
  art</FONT></A><FONT face=3DArial>, so that we may submit that =
information to the=20
  appropriate patent offices.</FONT></P>
  <P><FONT face=3DArial>We are looking forward to hearing from you as =
soon as=20
  possible.</FONT></P>
  <P><FONT face=3DArial>Sincerely,</FONT></P>
  <P><FONT face=3DArial>William F. Heinze, Esq.* <BR>Thomas, Kayden, =
Horstemeyer=20
  &amp; Risley, L.L.P. <BR>100 Galleria Parkway, N.W., Suite 1750 =
<BR>Atlanta,=20
  GA 30339-5948 </FONT></P>
  <P><FONT face=3DArial>Tel.:&nbsp; (770)&nbsp;<SPAN=20
  class=3D340313600-17012002>933-9500</SPAN> <BR>Fax:&nbsp; (770) =
951-0933=20
  <BR></FONT><FONT face=3DArial>Profile:&nbsp; </FONT><A target=3D_blank =

  href=3D"http://www.tkhr.com/wfh.htm"><FONT=20
  face=3DArial>http://www.tkhr.com/wfh.htm</FONT></A><U></U><FONT =
face=3DArial>=20
  </FONT></P>
  <P><FONT face=3DArial>*Admitted to practice in the Commonwealth of=20
  Virginia.&nbsp; Not admitted in Georgia. <BR></FONT></P>
  <P><FONT face=3DArial></FONT></P></DIV>
  <DIV><FONT face=3DArial>cc:&nbsp;<SPAN =
class=3D340313600-17012002>&nbsp;=20
  </SPAN>Mr. James Seng, Co-Chair, idn Working Group, </FONT><A=20
  href=3D"outbind://7/mail%20to:%20jseng@pobox.org.sg"><FONT=20
  face=3DArial>jseng@pobox.org.sg</FONT></A></DIV>
  <DIV><FONT face=3DArial><SPAN=20
  class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
  Marc Blanchet, Co-Chair, idn Working Group, </FONT><A=20
  href=3D"outbind://7/Mail%20to:%20Marc.Blanchet@viagenie.qc.ca"><FONT=20
  face=3DArial>Marc.Blanchet@viagenie.qc.ca</FONT></A></DIV>
  <DIV><FONT face=3DArial><SPAN=20
  class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
  Erik Nordmark, Internet Area Director, </FONT><A=20
  href=3D"outbind://7/mail%20to:%20nordmark@eng.sun.com"><FONT=20
  face=3DArial>nordmark@eng.sun.com</FONT></A></DIV>
  <DIV><FONT face=3DArial><SPAN=20
  class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
  Thomas Narten, Internet Area Director, </FONT><A=20
  href=3D"mailto:narten@us.ibm.com"><FONT=20
  face=3DArial>narten@us.ibm.com</FONT></A><FONT face=3DArial> =
</FONT></DIV>
  <DIV><FONT face=3DArial><SPAN=20
  class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
  John Klensin, Technical Advisor, </FONT><A =
href=3D"mailto:klensin@jck.com"><FONT=20
  face=3DArial>klensin@jck.com</FONT></A></DIV>
  <DIV><FONT face=3DArial><SPAN=20
  class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>Mr.=20
  Harald Alverstrand, Technical Advisor, </FONT><A=20
  href=3D"outbind://7/mail%20to:%20harald@alvestrand.no"><FONT=20
  face=3DArial>harald@alvestrand.no</FONT></A></DIV>
  <DIV><FONT face=3DArial><SPAN=20
  class=3D340313600-17012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>RFC=20
  2026 Submissions to IETF Director, </FONT><A=20
  href=3D"outbind://7/mail%20to:%20scoya@ietf.org"><FONT=20
  face=3DArial>scoya@ietf.org</FONT></A></DIV>
  <P>
  <P><FONT face=3DArial></FONT></P>
  <P></P><BR>
  <DIV><FONT face=3D"Courier New"=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_027C_01C19FC6.6BFE8D70--




From owner-idn@ops.ietf.org  Thu Jan 17 13:53:18 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00238
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 13:53:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RHR6-000GxH-00
	for idn-data@psg.com; Thu, 17 Jan 2002 10:38:52 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RHR5-000GxA-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 10:38:51 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA03106;
	Thu, 17 Jan 2002 10:34:50 -0800
Message-Id: <5.1.0.14.2.20020117103139.01bd1a88@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 17 Jan 2002 10:34:35 -0800
To: "James Seng/Personal" <jseng@pobox.org.sg>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Re: IETF Notification of Patent Publication for WO
  01/90955 A2 
Cc: "Heinze, Bill" <bill.heinze@tkhr.com>, <idn@ops.ietf.org>,
        "'Mr. Marc Blanchet, Co-Chair, idn Working Group,'" <Marc.Blanchet@viagenie.qc.ca>,
        "'Mr. Erik Nordmark, Internet Area Director,'" <nordmark@eng.sun.com>,
        "'Mr. Thomas Narten, Internet Area Director,'" <narten@us.ibm.com>,
        "'Mr. John Klensin, Technical Advisor,'" <klensin@jck.com>,
        "'Mr. Harald Alverstrand, Technical Advisor,'" <harald@alvestrand.no>,
        "'RFC 2026 Submissions to IETF Director,'" <scoya@ietf.org>
In-Reply-To: <028101c19f83$61147f70$dd00a8c0@jamessonyvaio>
References: <F6C05EF93BA2D41193BC00B0D07833466FD31A@TKHR_NT>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

<html>
At 02:18 AM 1/18/2002 +0800, James Seng/Personal wrote:<br>
<blockquote type=cite class=cite cite><font face="Courier New, Courier" size=2>Incidently,
IETF generally have more engineers and very few lawyers. I am not sure if
idn wg is in any position to review your patent filing claims, a job
usually reserved for patent lawyers. </font></blockquote><br>
James,<br><br>
1.&nbsp; Unfortunately, quite a few IETF engineers have had to deal with
patent issues in recent years.&nbsp; This means that they/we are in a
position to do expert review of the technical aspects of a filing.&nbsp;
Often that leads to distracting discussions in which we fall into the
trap of forgetting that we are not attorneys, but it still can provide
useful review of a filing's technology.<br><br>
2.&nbsp; An IETF working group has an obligation to pay attention to
claims that are asserted over IETF work.<br><br>
d/<br><br>
<x-sigsep><p></x-sigsep>
<font face="Courier New, Courier" size=2>----------<br>
Dave Crocker&nbsp;
&lt;<a href="mailto:dcrocker@brandenburg.com" eudora="autourl">mailto:dcrocker@brandenburg.com</a>&gt;<br>
Brandenburg InternetWorking&nbsp;
&lt;<a href="http://www.brandenburg.com/" eudora="autourl">http://www.brandenburg.com</a>&gt;<br>
tel +1.408.246.8253;&nbsp; fax +1.408.273.6464<br>
</font></html>




From owner-idn@ops.ietf.org  Thu Jan 17 14:35:32 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02500
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 14:35:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RI7A-000HuF-00
	for idn-data@psg.com; Thu, 17 Jan 2002 11:22:20 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RI7A-000Hu9-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 11:22:20 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA04903;
	Thu, 17 Jan 2002 11:21:13 -0800
Message-Id: <5.1.0.14.2.20020117111008.01b8bbe0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 17 Jan 2002 11:11:48 -0800
To: Dan Oscarsson <Dan.Oscarsson@trab.se>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] IDNA prevents simple development of DNS
Cc: idn@ops.ietf.org
In-Reply-To: <3C43DCF4.7E7CA15@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 08:40 AM 1/15/2002 +0100, Dan Oscarsson wrote:
>David Crocker wrote:
> >At 05:33 PM 1/14/2002 +0100, Dan Oscarsson wrote:
> >>IDNA will force all solutions using native UCS in DNS to
> >>require the client to first test if the server can handle
> >>UCS
> >
> >This is quite simply incorrect.
> >And it has been explained multiple times.
>
>Can you prove that?

for anyone not convinced already, then probably there is little that will 
convince them.

>My analysis shows that the test is needed.

Please disclose the algorithm that you believe is required.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Jan 17 18:24:55 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15394
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 18:24:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RLiW-000MBz-00
	for idn-data@psg.com; Thu, 17 Jan 2002 15:13:08 -0800
Received: from [209.195.13.114] (helo=tkhr_nt.tkhr.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RLiU-000MBs-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 15:13:07 -0800
Received: by TKHR_NT with Internet Mail Service (5.5.2650.21)
	id <C9XJ7V2H>; Thu, 17 Jan 2002 18:04:02 -0500
Message-ID: <F6C05EF93BA2D41193BC00B0D07833466FD339@TKHR_NT>
From: "Heinze, Bill" <bill.heinze@tkhr.com>
To: "'idn@ops.ietf.org'" <idn@ops.ietf.org>
Cc: "'Mr. James Seng, Co-Chair, idn Working Group,'" <jseng@pobox.org.sg>,
        "'Mr. Marc Blanchet, Co-Chair, idn Working Group,'"
	 <Marc.Blanchet@viagenie.qc.ca>,
        "'Mr. Erik Nordmark, Internet Area Director,'" <nordmark@eng.sun.com>,
        "'Mr. Thomas Narten, Internet Area Director,'" <narten@us.ibm.com>,
        "'Mr. John Klensin, Technical Advisor,'" <klensin@jck.com>,
        "'Mr. Harald Alverstrand, Technical Advisor,'" <harald@alvestrand.no>,
        "'RFC 2026 Submissions to IETF Director,'" <scoya@ietf.org>
Subject: [idn] IETF Notification of Patent Publication for WO 01/90955 A2  
Date: Thu, 17 Jan 2002 18:03:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="UTF-8"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

January 17, 2002

Internet Engineering Task Force				VIA E-MAIL TO:
idn Working Group Mailing List				idn@ops.ietf.org


	Re:	IETF Notification of Patent Publication for WO 01/90955 A2  
		Our File No. 561401-9010

Dear Subscribers:

	Please accept my apologies for the poor formatting of my previous
message.  I was not aware that the hyperlinks would create so many problems
for various recipients.  Here is a second copy that should be easier to read
and includes a link to a concatenated copy of the patent.  	

	In accordance with Section 10 of the Internet Standards Process (RFC
2026), I am writing on behalf of .NU Domain and its affiliate WorldNames,
Inc. to notify you of the publication of World Intellectual Property
Organization International Publication No. WO 01/90955 A2 entitled
"Internationalized Domain Name System with Iterative Conversion."  A copy of
this document is available at the following website:

ftp://ftp.tkhr.com/WO0190955A2.pdf

	This patent application generally relates to a system, method, and
logic for managing data, including a database for implementing a key value
operation, such as a DNS resource record lookup, with a key having a
predetermined encoding, such as Unicode. Also provided is an iterative
converter for iteratively converting the key from each of multiple encodings
to the predetermined encoding before performing the key value operation with
each converted key.  The system may also include a validator for verifying
that a syntax of each converted key is valid and a normalizer for
normalizing each converted key. 
 
	We believe that many of the technologies being discussed in this
mailing list infringe one or more of the claims starting at page 87 of the
attached publication.  We would therefore like to propose that you review
these claims and contact us immediately with regard to obtaining a license
and/or authorized access to WorldNames "MLDNS" multilingual DNS products and
services described at the following website:

http://www.worldnames.net/MLDNS/default.cfm  

	Please note that failure to promptly obtain the appropriate
authorization may subject you and your organization to liability for
royalties in the U.S. as of the date that you receive this letter under 35
U.S.C. Section 154(d).  Once the application is granted, additional remedies
are also available including injunctions, treble damages, and attorney fees.
A variety of other presumptions and remedies may also be available in the
U.S. and abroad.

	If you believe that you have a defense to these allegations, such as
non-infringement or prior invention, then please provide us with additional
information to refute our allegations and avoid further involvement with
this matter.  Similarly, if you believe that any of the attached claims are
not patentable, then please bring them to our attention, along with any
relevant prior art, so that we may submit that information to the
appropriate patent offices.

	We are looking forward to hearing from you.

Sincerely,

William F. Heinze, Esq.* 
Thomas, Kayden, Horstemeyer & Risley, L.L.P. 
100 Galleria Parkway, N.W., Suite 1750 
Atlanta, GA 30339-5948 
Tel.:  (770) 933-9500 
Fax:  (770) 951-0933 
Profile:  http://www.tkhr.com/wfh.htm 

*Admitted to practice in the Commonwealth of Virginia.  Not admitted in
Georgia. 

cc:  	Mr. James Seng, Co-Chair, idn Working Group, jseng@pobox.org.sg
	Mr. Marc Blanchet, Co-Chair, idn Working Group,
Marc.Blanchet@viagenie.qc.ca
	Mr. Erik Nordmark, Internet Area Director, nordmark@eng.sun.com
	Mr. Thomas Narten, Internet Area Director, narten@us.ibm.com 
	Mr. John Klensin, Technical Advisor, klensin@jck.com
	Mr. Harald Alverstrand, Technical Advisor, harald@alvestrand.no
	RFC 2026 Submissions to IETF Director, scoya@ietf.org



From owner-idn@ops.ietf.org  Thu Jan 17 23:51:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22589
	for <idn-archive@lists.ietf.org>; Thu, 17 Jan 2002 23:51:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RQm2-0001V5-00
	for idn-data@psg.com; Thu, 17 Jan 2002 20:37:06 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RQm1-0001Uz-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 20:37:05 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Thu, 17 Jan 2002 20:52:28 -0800
Message-ID: <002601c19fdb$2d3e5b00$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" <ben@cc-www.com>
To: "Heinze, Bill" <bill.heinze@tkhr.com>, <idn@ops.ietf.org>
Cc: "'Mr. James Seng, Co-Chair, idn Working Group,'" <jseng@pobox.org.sg>,
        "'Mr. Marc Blanchet, Co-Chair, idn Working Group,'" <Marc.Blanchet@viagenie.qc.ca>,
        "'Mr. Erik Nordmark, Internet Area Director,'" <nordmark@eng.sun.com>,
        "'Mr. Thomas Narten, Internet Area Director,'" <narten@us.ibm.com>,
        "'Mr. John Klensin, Technical Advisor,'" <klensin@jck.com>,
        "'Mr. Harald Alverstrand, Technical Advisor,'" <harald@alvestrand.no>,
        "'RFC 2026 Submissions to IETF Director,'" <scoya@ietf.org>
References: <F6C05EF93BA2D41193BC00B0D07833466FD339@TKHR_NT>
Subject: Re: [idn] IETF Notification of Patent Publication for WO 01/90955 A2  
Date: Thu, 17 Jan 2002 23:47:01 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Bill,

> We believe that many of the technologies being discussed in this
> mailing list infringe one or more of the claims starting at page 87
of the
> attached publication.  We would therefore like to propose that you
review
> these claims and contact us immediately with regard to obtaining a
license
> and/or authorized access to WorldNames "MLDNS" multilingual DNS
products and
> services described at the following website:
>

I am no lawyer, so perhaps you can assist me ...

I filed a patent application a while ago with almost nothing but just
a title and a very simple/general description on how to
internationalize domain names.  The Canada system is not as stringent
as U.S. and allows patent applications to be filed with almost no
substance and allows one to add things (ie. claims) later on... or
even file a second application and claim the priority date of the
first application.  Because of this I still have *not* submitted the
claims portion of my patent application.

Now that I can see that this WG has finally come to agree on the
technologies that will be submitted for approval, can you help me
write the claims portion of my patent so that I *too* can have the
technologies being discussed in this mailing list infringe on my
patent?

Thanks
Ben






From owner-idn@ops.ietf.org  Fri Jan 18 02:06:58 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02539
	for <idn-archive@lists.ietf.org>; Fri, 18 Jan 2002 02:06:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RSsl-0003Sp-00
	for idn-data@psg.com; Thu, 17 Jan 2002 22:52:11 -0800
Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RSsk-0003Sj-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 22:52:10 -0800
Received: from askvoll.hjemme.alvestrand.no (askvoll.hjemme.alvestrand.no [192.168.1.4])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id 0D0E961F4D; Fri, 18 Jan 2002 07:52:09 +0100 (CET)
Date: Fri, 18 Jan 2002 07:52:08 +0100
From: Harald Alvestrand <harald@alvestrand.no>
To: Stuart Cheshire <cheshire@apple.com>, idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <1425610000.1011336725@askvoll.hjemme.alvestrand.no>
In-Reply-To: <200201141957.g0EJvIe04598@scv1.apple.com>
References:  <200201141957.g0EJvIe04598@scv1.apple.com>
X-Mailer: Mulberry/2.1.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA02539

Stuart,

draft-vrang-idn-cname-00.txt describes such a scheme in some detail.
It also tries to create a "canonical" collection of the problems you are 
likely to encounter with such a scheme.

I'd like to see comments on disadvantages that were missed :-)

Note: DNAME is, at the moment, not a popular record in the DNS.
It creates MANY interesting problems; currently, most DNS people seem to be 
in favour of declaring it useless for standards-track protocols.

                         Harald


--On mandag, januar 14, 2002 11:57:16 -0800 Stuart Cheshire 
<cheshire@apple.com> wrote:

> It seems to me that the solution is to give up on the idea of a single
> global set of rules, and instead let each name server be authoritative
> for the equivalence rules for the zones for which it is authoritative. If
> a client tries to look up "www.p�psi.com.", and the "com" name servers
> have been configured to treat "p�psi" as equivalent to "pepsi", then they
> return the answer for "pepsi.com.", and in the reply they also include a
> (programatically generated) DNAME record which *tells* the client and any
> intervening caching resolvers that these two names are equivalent:





From owner-idn@ops.ietf.org  Fri Jan 18 02:19:33 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02762
	for <idn-archive@lists.ietf.org>; Fri, 18 Jan 2002 02:19:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RTB9-0003jz-00
	for idn-data@psg.com; Thu, 17 Jan 2002 23:11:11 -0800
Received: from shell.nominum.com ([128.177.192.160])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RTB8-0003jt-00
	for idn@ops.ietf.org; Thu, 17 Jan 2002 23:11:10 -0800
Received: from [10.0.1.6] (shell.nominum.com [128.177.192.160])
	by shell.nominum.com (Postfix) with ESMTP
	id ACFFD3190C; Thu, 17 Jan 2002 23:11:09 -0800 (PST)
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 17 Jan 2002 23:11:08 -0800
Subject: Re: [idn] Determining equivalence in Unicode DNS names
From: David Conrad <david.conrad@nominum.com>
To: Harald Alvestrand <harald@alvestrand.no>,
        Stuart Cheshire <cheshire@apple.com>,
        Internationalized Domain Names <idn@ops.ietf.org>
Message-ID: <B86D0A8C.317D%david.conrad@nominum.com>
In-Reply-To: <1425610000.1011336725@askvoll.hjemme.alvestrand.no>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

On 1/17/02 10:52 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:
> Note: DNAME is, at the moment, not a popular record in the DNS.
> It creates MANY interesting problems; currently, most DNS people seem to be
> in favour of declaring it useless for standards-track protocols.

Oh?  Where have these discussions been occuring?

Tnx,
-drc




From owner-idn@ops.ietf.org  Fri Jan 18 04:41:44 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04961
	for <idn-archive@lists.ietf.org>; Fri, 18 Jan 2002 04:41:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RVKk-0005oB-00
	for idn-data@psg.com; Fri, 18 Jan 2002 01:29:14 -0800
Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RVKj-0005o5-00
	for idn@ops.ietf.org; Fri, 18 Jan 2002 01:29:13 -0800
Received: from [192.168.1.31] (eikenes.alvestrand.no [217.13.28.203])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id 4338761F4D; Fri, 18 Jan 2002 10:29:12 +0100 (CET)
Date: Fri, 18 Jan 2002 10:28:22 +0100
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: David Conrad <david.conrad@nominum.com>,
        Stuart Cheshire <cheshire@apple.com>,
        Internationalized Domain Names <idn@ops.ietf.org>
Subject: DNAME (Re: [idn] Determining equivalence in Unicode DNS names)
Message-ID: <61757512.1011349702@localhost>
In-Reply-To: <B86D0A8C.317D%david.conrad@nominum.com>
References:  <B86D0A8C.317D%david.conrad@nominum.com>
X-Mailer: Mulberry/2.1.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



--On 17. januar 2002 23:11 -0800 David Conrad <david.conrad@nominum.com> 
wrote:

> On 1/17/02 10:52 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:
>> Note: DNAME is, at the moment, not a popular record in the DNS.
>> It creates MANY interesting problems; currently, most DNS people seem to
>> be in favour of declaring it useless for standards-track protocols.
>
> Oh?  Where have these discussions been occuring?

that is what I have understood from DNSEXT and the NGTRANS WG.
The NGTRANS/DNSEXT discussions in London concluded that DNAME was not 
needed for introducing IPv6, but that DNAME might have other uses, so 
NGTRANS should not speak about whether it should be on standards track or 
not - just that v6 does not need it.

DNAME has been mentioned in a total of 15 messages (out of 1005) on DNSEXT 
since I changed mailers this summer; it hasn't been a very active topic 
recently.

But you are probably better able to speak authoritatively about its status 
than I am.....

                  Harald



From owner-idn@ops.ietf.org  Fri Jan 18 05:36:39 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05815
	for <idn-archive@lists.ietf.org>; Fri, 18 Jan 2002 05:36:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RWBA-0006dm-00
	for idn-data@psg.com; Fri, 18 Jan 2002 02:23:24 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RWB8-0006dU-00
	for idn@ops.ietf.org; Fri, 18 Jan 2002 02:23:23 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP
	id 18AC1FFC23; Fri, 18 Jan 2002 18:22:51 +0800 (SGT)
Message-ID: <036001c1a00a$251f2600$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Dave Crocker" <dhc@dcrocker.net>
Cc: "Heinze, Bill" <bill.heinze@tkhr.com>, <idn@ops.ietf.org>
References: <F6C05EF93BA2D41193BC00B0D07833466FD31A@TKHR_NT> <5.1.0.14.2.20020117103139.01bd1a88@127.0.0.1>
Subject: Re: [idn] Re: IETF Notification of Patent Publication for WO  01/90955 A2 
Date: Fri, 18 Jan 2002 18:23:12 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> 1.  Unfortunately, quite a few IETF engineers have had to deal with
> patent issues in recent years.  This means that they/we are in a
> position to do expert review of the technical aspects of a filing.
> Often that leads to distracting discussions in which we fall into
> the trap of forgetting that we are not attorneys, but it still can
> provide useful review of a filing's technology.

Yes. But that does not mean we (idn wg) try to play the role of patent
lawyers.

> 2.  An IETF working group has an obligation to pay attention to claims
> that are asserted over IETF work.

Definately.

The group should discuss the claims of the patents wrt to the work we
are doing. As you said, the wg have an obligation to determine if the
technology we moving forward is infringing on some potential patents. We
may then decide if we want to move forward with it or work around it or
whatever.

But the group is not responsible nor have a charter goal to assist
someone to assert the validity of their patent filing, a job best left
for patents lawyers.

If any of the individual in the group wish to assist Bill Heinze in
finding prior arts or assert validity of his patent filing, they are
free to do so in their own capacity.

Note: patent application are automatically published a year from filing,
regardless of the status of the application. From Bill's mail, it is
clear that a patent have been filed but it is not clear if their patent
have been granted.

-James Seng




From owner-idn@ops.ietf.org  Fri Jan 18 06:08:50 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06297
	for <idn-archive@lists.ietf.org>; Fri, 18 Jan 2002 06:08:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RWjd-0007Br-00
	for idn-data@psg.com; Fri, 18 Jan 2002 02:59:01 -0800
Received: from [211.218.145.193] (helo=localhost.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16RWjc-0007Bi-00
	for idn@ops.ietf.org; Fri, 18 Jan 2002 02:59:00 -0800
Received: (from root@localhost)
	by postel2 (8.11.0/8.11.0) id g0IAwj203997
	for idn@ops.ietf.org; Fri, 18 Jan 2002 19:58:45 +0900
To: idn@ops.ietf.org
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by localhost.localdomain
    (8.11.0/8.11.0) with SMTP id g0IAvea03995 for <idn@ops.ietf.org>;
    Fri, 18 Jan 2002 19:57:40 +0900
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64
X-Msmail-Priority: Normal
Message-Id: <075701c1a00e$f5dd9390$ec1bd9d2@temp>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
References: <200201141957.g0EJvIe04598@scv1.apple.com>
    <1425610000.1011336725@askvoll.hjemme.alvestrand.no>
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Fri, 18 Jan 2002 19:57:44 +0900
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0rMT48UFJFPgpIYXJhbGQsCgogIEkgc2VlIGluIHRoZSBv
bi10aGUtZmx5IENOQU1FIFJSIGRyYWZ0IFtwYWdlIDRdLAogICAgIChodHRw
JiM1ODsvL3NlYXJjaC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt
dnJhbmctaWRuLWNuYW1lLTAwLnR4dCkKCiJUaGUgbWV0aG9kIHdpbGwgY2F1
c2UgY29uZnVzaW9uIHdpdGggSFRUUC8xLjEgbmFtZWQgdmlydHVhbCBob3N0
cyBhbmQKb3RoZXIgc2VydmljZXMgd2hlcmUgdGhlIHNlcnZlciB3aXNoZXMg
dG8ga25vdyB3aGljaCBuYW1lIHRoZSBjbGllbnQgaXMKdHJ5aW5nIHRvIHVz
ZSBmb3IgaGltOyB1bmxlc3MgdGhlIHNlcnZlciBleGVjdXRlcyB0aGUgbWFw
cGluZyBhbGdvcml0aG0KaGltc2VsZiwgdGhlIG5hbWUgdGhhdCB0aGUgY2xp
ZW50IGhhbmRzIHRvIHRoZSBzZXJ2ZXIgd2lsbCBub3QgbWF0Y2gKYW55IG5h
bWUgdGhhdCB0aGUgc2VydmVyIGtub3dzIGZvciBpdHNlbGYuICIKCiAgICBU
byBuYW1lIHRoZSAib3RoZXIgc2VydmljZXMiIGV4cGxpY2l0bHksIGluY2x1
ZGluZyBwdXJlIHN0YW5kYWxvbmUgY2xpZW50IGFwcGxpY2F0aW9ucywKICAg
ICAgICAgICAgIGVtYWlsL2hvc3RuYW1lIHNlYXJjaCBmYWlsdXJlcyBpbiBs
b2NhbCBhZGRyZXNzYm9vay9sZGFwIGRpcmVjdG9yeS9sZWdhY3kgREIsCiAg
ICAgICAgICAgICBjZXJ0aWZpY2F0ZSB2ZXJpZmljYXRpb25zIGZhaWx1cmVz
IGluIEhUVFBTICYgU01JTUUgZnJvbSBicm93c2VyL21haWwgY2xpZW50cywK
ICAgICAgICAgICAgIEphdmEgYXBwbGV0IHNlY3VyaXR5IG1lY2hhbmlzbSBm
YWlsdXJlLAogICAgICAgICAgICAgb3RoZXIgaG9zdG5hbWUgYmFzZWQgc2Vj
dXJpdHkgbWVjaGFuaXN1bSBmYWlsdXJlCiAgICAgICAgICAgICBjb25zaXN0
ZW50IGJyb3dzZXIgY29va2llIGhhbmRsaW5nIGZhaWx1cmUgYmV0d2VlbiBz
ZXNzaW9ucywKICAgICAgICAgICAgIHZpcnR1YWwgbWFpbCBob3N0aW5nIGZh
aWx1cmVzLAogICAgICAgICAgICAgYW5kIG1hbnkgSUROLWF3YXJlL25vbmF3
YXJlIGluLWhvdXNlIGFwcGxpY2F0aW9ucyBmYWlsdXJlIHdoaWNoIGRvIGhv
c3RuYW1lIGNvbXBhcmlzb25zCgogICAgICBtYW55IG9mIHRoZW0gbWF5IGJl
IG5vdGljZWFibGUgb3IgbWF5ICpOT1QqIG5vdGljZWFibGUgdG8gb3BlcmF0
ZXJzIG9yIGVuZCB1c2VycyEKICAgICAgSnVzdCBmYWlsLCBwcm92aWRpbmcg
bm8gY2x1ZXMhCiAgICAgIFNpbWlsYXIgcHJvYmxlbXMgb2NjdXIgaW4gdHJl
YXRpbmcgdW5hc3NpZ25lZCBjb2RlIHBvaW50cy4KCgogIEFwcG9yYWNoZXMg
dXNpbmcgRE5BTUUgUlIgb3IgQSBSUiAoc28gcG9wdWxhciAibXVsdGlwbGUg
cmVnaXN0cmF0aW9ucyIpIGFuZCBsb2NhbGl6YXRpb25zCiAgICBhbHNvIHNo
YXJlIHRoZSBzYW1lIGRpc2FkdmFudGFnZXMuIHZlcnkgY29zdGx5IHRyaWNr
cyB0aGF0IG1ha2UgdHJvdWJsZXMuCgogIFRoZXNlIGFwcHJvYWNoZXMgY2Fu
bm90IHNvbHZlIFRTQ09OViBwcm9ibGVtICBhbmQKICAgTGF0aW4vR3JlZWsv
Q3lyaWxsaWMvQ2hlcm9rZWUgbG9va2FsaWtlIHByb2JsZW1zLCByYXRoZXIs
IG1ha2UgdGhlbSBtb3JlIGNvbXBsaWNhdGVkLgoKICBJRE4gaXMgbm90IHN1
aXRhYmxlIGZvciBtaXNzaW9uIGNyaXRpY2FsIGludGVybmV0IGlkZW50aWZp
ZXIgc3lzdGVtLgogIHJhdGhlcixpIGZlZWwgaXQgaXMgbGlrZSBhIHRveS4K
ClNvb2JvayBMZWUKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCkZy
b20mIzU4OyAiSGFyYWxkIEFsdmVzdHJhbmQiIDxoYXJhbGRAYWx2ZXN0cmFu
ZC5ubz4KVG8mIzU4OyAiU3R1YXJ0IENoZXNoaXJlIiA8Y2hlc2hpcmVAYXBw
bGUuY29tPjsgPGlkbkBvcHMuaWV0Zi5vcmc+ClNlbnQmIzU4OyBGcmlkYXks
IEphbnVhcnkgMTgsIDIwMDIgMyYjNTg7NTIgUE0KU3ViamVjdCYjNTg7IFJl
JiM1ODsgW2lkbl0gRGV0ZXJtaW5pbmcgZXF1aXZhbGVuY2UgaW4gVW5pY29k
ZSBETlMgbmFtZXMKCgo+IFN0dWFydCwKPgo+IGRyYWZ0LXZyYW5nLWlkbi1j
bmFtZS0wMC50eHQgZGVzY3JpYmVzIHN1Y2ggYSBzY2hlbWUgaW4gc29tZSBk
ZXRhaWwuCj4gSXQgYWxzbyB0cmllcyB0byBjcmVhdGUgYSAiY2Fub25pY2Fs
IiBjb2xsZWN0aW9uIG9mIHRoZSBwcm9ibGVtcyB5b3UgYXJlCj4gbGlrZWx5
IHRvIGVuY291bnRlciB3aXRoIHN1Y2ggYSBzY2hlbWUuCj4KPiBJJ2QgbGlr
ZSB0byBzZWUgY29tbWVudHMgb24gZGlzYWR2YW50YWdlcyB0aGF0IHdlcmUg
bWlzc2VkICYjNTg7LSkKPgo+IE5vdGUmIzU4OyBETkFNRSBpcywgYXQgdGhl
IG1vbWVudCwgbm90IGEgcG9wdWxhciByZWNvcmQgaW4gdGhlIEROUy4KPiBJ
dCBjcmVhdGVzIE1BTlkgaW50ZXJlc3RpbmcgcHJvYmxlbXM7IGN1cnJlbnRs
eSwgbW9zdCBETlMgcGVvcGxlIHNlZW0gdG8gYmUKPiBpbiBmYXZvdXIgb2Yg
ZGVjbGFyaW5nIGl0IHVzZWxlc3MgZm9yIHN0YW5kYXJkcy10cmFjayBwcm90
b2NvbHMuCj4KPiAgICAgICAgICAgICAgICAgICAgICAgICAgSGFyYWxkCj4K
Pgo+IC0tT24gbWFuZGFnLCBqYW51YXIgMTQsIDIwMDIgMTEmIzU4OzU3JiM1
ODsxNiAtMDgwMCBTdHVhcnQgQ2hlc2hpcmUKPiA8Y2hlc2hpcmVAYXBwbGUu
Y29tPiB3cm90ZSYjNTg7Cj4KPiA+IEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhl
IHNvbHV0aW9uIGlzIHRvIGdpdmUgdXAgb24gdGhlIGlkZWEgb2YgYSBzaW5n
bGUKPiA+IGdsb2JhbCBzZXQgb2YgcnVsZXMsIGFuZCBpbnN0ZWFkIGxldCBl
YWNoIG5hbWUgc2VydmVyIGJlIGF1dGhvcml0YXRpdmUKPiA+IGZvciB0aGUg
ZXF1aXZhbGVuY2UgcnVsZXMgZm9yIHRoZSB6b25lcyBmb3Igd2hpY2ggaXQg
aXMgYXV0aG9yaXRhdGl2ZS4gSWYKPiA+IGEgY2xpZW50IHRyaWVzIHRvIGxv
b2sgdXAgInd3dy5w6XBzaS5jb20uIiwgYW5kIHRoZSAiY29tIiBuYW1lIHNl
cnZlcnMKPiA+IGhhdmUgYmVlbiBjb25maWd1cmVkIHRvIHRyZWF0ICJw6XBz
aSIgYXMgZXF1aXZhbGVudCB0byAicGVwc2kiLCB0aGVuIHRoZXkKPiA+IHJl
dHVybiB0aGUgYW5zd2VyIGZvciAicGVwc2kuY29tLiIsIGFuZCBpbiB0aGUg
cmVwbHkgdGhleSBhbHNvIGluY2x1ZGUgYQo+ID4gKHByb2dyYW1hdGljYWxs
eSBnZW5lcmF0ZWQpIEROQU1FIHJlY29yZCB3aGljaCAqdGVsbHMqIHRoZSBj
bGllbnQgYW5kIGFueQo+ID4gaW50ZXJ2ZW5pbmcgY2FjaGluZyByZXNvbHZl
cnMgdGhhdCB0aGVzZSB0d28gbmFtZXMgYXJlIGVxdWl2YWxlbnQmIzU4Owo+
Cj4KCjwvUFJFPgoKPGltZyBzcmM9aHR0cDovL3Bvc3RlbDIucG9zdGVsLmNv
LmtyL3JlYWQvMTAxMTM1MTQ2NC0zOWM1YzlhNTZmZDdjODJhNDEzNjI3NWI5
ZjllM2E2YS40MWU1ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMuaWV0Zi5vcmcuY29u
ZmlybS5wb3N0ZWwudG8gd2lkdGg9MSBoZWlnaHQ9MT48aW1nIHNyYz1odHRw
Oi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZHEvMTAxMTM1MTQ2NC0zOWM1
YzlhNTZmZDdjODJhNDEzNjI3NWI5ZjllM2E2YS40MWU1ZmQ2ZjE5N2ViYzEw
L2lkbkBvcHMuaWV0Zi5vcmcuY29uZmlybS5wb3N0ZWwudG8vaWRuQG9wcy5p
ZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0xPgo8
L0JPRFk+CjwvSFRNTD4K



From owner-idn@ops.ietf.org  Sat Jan 19 05:47:44 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17900
	for <idn-archive@lists.ietf.org>; Sat, 19 Jan 2002 05:47:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16RsjL-000AA3-00
	for idn-data@psg.com; Sat, 19 Jan 2002 02:28:11 -0800
Date: Fri, 18 Jan 2002 17:56:10 -0500
From: "Jorge Contreras" <jorge.contreras@haledorr.com>
Organization: Hale and Dorr LLP
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD HaleandDorr  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Heinze Bill" <bill.heinze@tkhr.com>
Cc: Michael Diener <michael.diener@haledorr.com>,
        Scott Bradner <sob@harvard.edu>, idn@ops.ietf.org,
        Harald Alvestrand <harald@Alvestrand.no>
Subject: [idn] WIPO PCT Publication No. WO 01/90955 A2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: <E16RsjL-000AA3-00@psg.com>
Content-Transfer-Encoding: 7bit

Dear Mr. Heinze:

  Thank you for bringing WIPO PCT Publication No. WO 01/90955 A2
entitled "Internationalized Domain Name System with Iterative
Conversion" (the "Publication") to the attention of the IETF idn Working
Group.

  As you know, all contributors to IETF working groups are required to
disclose the existence of any proprietary or intellectual property
rights in their contributions that are reasonably and personally known
to them.  Your identification of the Publication will be noted as such a

disclosure on behalf of your clients .Nu Domain and WorldNames.

  We express no opinion with respect to your assertion that many of the
technologies being discussed on the idn mailing list infringe the claims

of the Publication.  As you know, the IETF is an international standards
organization which does not itself develop, make, use, sell, or import
products or services.  However, if you believe that the products or
services of any entity infringe the claims of the Publication, then you
may wish to contact them separately.

  I believe that no further response to your communication is required.
However, please do not hesitate to contact me if you would like to
discuss this matter further.  I have copied the idn list on this message
at the request of my client.

  Sincerely yours,
  Jorge L. Contreras






From owner-idn@ops.ietf.org  Sat Jan 19 21:44:04 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26099
	for <idn-archive@lists.ietf.org>; Sat, 19 Jan 2002 21:44:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16S7er-0002a3-00
	for idn-data@psg.com; Sat, 19 Jan 2002 18:24:33 -0800
Received: from twnic.net.tw ([211.72.210.250])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16S7eq-0002Zx-00
	for idn@ops.ietf.org; Sat, 19 Jan 2002 18:24:33 -0800
Received: from gix ([140.112.24.30])
	by twnic.net.tw (8.9.3/8.9.3) with SMTP id KAA22862
	for <idn@ops.ietf.org>; Sun, 20 Jan 2002 10:24:17 +0800
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: "IETF-IDN" <idn@ops.ietf.org>
Subject: [idn] Prohibit CDN code points
Date: Sun, 20 Jan 2002 10:29:03 +0800
Message-ID: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA26099

Dear IETF members

It seems that the CDN architecture proposal I presented in the IETF 
52nd meeting didn't capture significant consensus from the people 
of the Working Group. Some may claim that the proposed 
architecture may result in  "a partial solution to a partial problem", 
or "delay of IDN development",...,etc. If there is no support in the 
the proposal, the Chinese domain name issue remains an unresolved 
issue. If the Working  Group feels the problem is too complicate to 
be solved,  I have to  propose the final architecture as the following:
 
   ---------------------------------------------
   |             NamePrep                             |
   ---------------------------------------------
                             |  
   ----------------------------------------------------------------
   |    Prohibit code points :                                            |
   |    (4E00-9FAF)     Unified Ideographs                     |
   |    (3400-4DBF)   Unified Ideographs Extension A   |
   -----------------------------------------------------------------
                             |
   ---------------------------------------------
   |             Punycode                          |
   ---------------------------------------------
  
It implies there will be no Chinese domain name services until there 
is other solution proposed and agreed by the Working Group. 
I feel sorry to Chinese community, but by temporarily excluding the 
Chinese domain name service, the Working Group can ensure that 
the IDN progress is not hindered by CDN development. 
  
Best Regards
   
Kenny Huang




From owner-idn@ops.ietf.org  Sat Jan 19 21:58:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26302
	for <idn-archive@lists.ietf.org>; Sat, 19 Jan 2002 21:58:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16S819-0002qr-00
	for idn-data@psg.com; Sat, 19 Jan 2002 18:47:35 -0800
Received: from cichlid.adsl.duke.edu ([152.16.64.203])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16S818-0002ql-00
	for idn@ops.ietf.org; Sat, 19 Jan 2002 18:47:34 -0800
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g0K2kP807040;
	Sat, 19 Jan 2002 21:46:25 -0500
Message-Id: <200201200246.g0K2kP807040@cichlid.adsl.duke.edu>
To: "Jorge Contreras" <jorge.contreras@haledorr.com>
cc: "Heinze Bill" <bill.heinze@tkhr.com>,
        Michael Diener <michael.diener@haledorr.com>,
        Scott Bradner <sob@harvard.edu>, idn@ops.ietf.org,
        Harald Alvestrand <harald@Alvestrand.no>
Subject: Re: [idn] WIPO PCT Publication No. WO 01/90955 A2 
In-Reply-To: Message from "Jorge Contreras" <jorge.contreras@haledorr.com> 
   of "Fri, 18 Jan 2002 17:56:10 EST." <E16RsjL-000AA3-00@psg.com> 
Date: Sat, 19 Jan 2002 21:46:24 -0500
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Jorge Contreras" <jorge.contreras@haledorr.com> writes:

> I have copied the idn list on this message at the request of my
> client.

For those that don't know, Jorge is an attorney who provides advice to
the IETF. His response was prompted by a request from the IESG.

Thomas



From owner-idn@ops.ietf.org  Sun Jan 20 06:56:26 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09297
	for <idn-archive@lists.ietf.org>; Sun, 20 Jan 2002 06:56:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SGIT-0008hc-00
	for idn-data@psg.com; Sun, 20 Jan 2002 03:38:01 -0800
Received: from nat.alvestrand.no ([217.13.28.204] helo=eikenes.alvestrand.no)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SGIS-0008hL-00
	for idn@ops.ietf.org; Sun, 20 Jan 2002 03:38:00 -0800
Received: from [192.168.1.31] (eikenes.alvestrand.no [217.13.28.203])
	by eikenes.alvestrand.no (Postfix) with ESMTP
	id 9176961F4A; Sun, 20 Jan 2002 12:37:53 +0100 (CET)
Date: Sat, 19 Jan 2002 15:43:28 +0100
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: idn@ops.ietf.org
Cc: Jorge Contreras <jorge.contreras@haledorr.com>
Subject: Re: [idn] WIPO PCT Publication No. WO 01/90955 A2
Message-ID: <167057966.1011455008@localhost>
In-Reply-To: <E16RsjL-000AA3-00@psg.com>
References:  <E16RsjL-000AA3-00@psg.com>
X-Mailer: Mulberry/2.1.2 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

for those who don't know - Jorge Contreras is the lawyer who does pro bono 
legal review of various aspects of the IETF process.

BTW, I have also verified that a PCT publication is not a patent - it is a 
way of simplifying the work of multiple national or regional patent 
applications by doing part of the work in one place.

It's nice to know that this info has been public for 8 months.

                 Harald

--On 18. januar 2002 17:56 -0500 Jorge Contreras 
<jorge.contreras@haledorr.com> wrote:

> Dear Mr. Heinze:
>
>   Thank you for bringing WIPO PCT Publication No. WO 01/90955 A2
> entitled "Internationalized Domain Name System with Iterative
> Conversion" (the "Publication") to the attention of the IETF idn Working
> Group.




From owner-idn@ops.ietf.org  Sun Jan 20 12:33:40 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13834
	for <idn-archive@lists.ietf.org>; Sun, 20 Jan 2002 12:33:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SLc0-000Cw4-00
	for idn-data@psg.com; Sun, 20 Jan 2002 09:18:32 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SLbz-000Cvy-00
	for idn@ops.ietf.org; Sun, 20 Jan 2002 09:18:31 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g0KHHp326603;
	Sun, 20 Jan 2002 09:17:51 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101204b870ab94166d@[165.227.249.20]>
In-Reply-To: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
Date: Sun, 20 Jan 2002 09:17:47 -0800
To: "Kenny Huang" <huangk@alum.sinica.edu>, "IETF-IDN" <idn@ops.ietf.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] Prohibit CDN code points
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 10:29 AM +0800 1/20/02, Kenny Huang wrote:
>It implies there will be no Chinese domain name services until there
>is other solution proposed and agreed by the Working Group.

The WG should note that this proposal prohibits Japanese and Korean 
names as well.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Sun Jan 20 12:34:58 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13886
	for <idn-archive@lists.ietf.org>; Sun, 20 Jan 2002 12:34:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SLdZ-000CxM-00
	for idn-data@psg.com; Sun, 20 Jan 2002 09:20:09 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SLdZ-000CxF-00
	for idn@ops.ietf.org; Sun, 20 Jan 2002 09:20:09 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Sun, 20 Jan 2002 09:35:50 -0800
Message-ID: <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" <ben@cc-www.com>
To: "Kenny Huang" <huangk@alum.sinica.edu>, "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
Subject: Re: [idn] Prohibit CDN code points
Date: Sun, 20 Jan 2002 12:30:01 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Kenny,

>I feel sorry to Chinese community, but by temporarily excluding the
>Chinese domain name service, the Working Group can ensure that
>the IDN progress is not hindered by CDN development.

Although it may seem like a good suggestion at first, is that option
realistically possible?

My knowledge in Japanese and Korean is very limitted, but from what I
have learned from the past discussions in this WG... it is that CJK
share many of the same code points.  Is it possible to let the
Japanese and Korean domains names go forward and prohibit Chinese
domain names?

Thanks,
Ben





From owner-idn@ops.ietf.org  Sun Jan 20 13:05:59 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14357
	for <idn-archive@lists.ietf.org>; Sun, 20 Jan 2002 13:05:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SMGJ-000Db4-00
	for idn-data@psg.com; Sun, 20 Jan 2002 10:00:11 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SMGI-000Day-00
	for idn@ops.ietf.org; Sun, 20 Jan 2002 10:00:10 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g0KI04327417;
	Sun, 20 Jan 2002 10:00:04 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101200b870b1d08c87@[165.227.249.20]>
In-Reply-To: 
 <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
Date: Sun, 20 Jan 2002 10:00:00 -0800
To: "ben" <ben@cc-www.com>, "Kenny Huang" <huangk@alum.sinica.edu>,
        "IETF-IDN" <idn@ops.ietf.org>
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] Prohibit CDN code points
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 12:30 PM -0500 1/20/02, ben wrote:
>Is it possible to let the
>Japanese and Korean domains names go forward and prohibit Chinese
>domain names?

No, and that one of the main problems that the CDN community faces. 
In the ISO/IEC 10646 repertoire (which is the same as the Unicode 
repertoire), it is impossible to differentiate between Chinese 
characters and Korean characters and Japanese characters. Thus, any 
proposal to remove the characters for one language removes them for 
all.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Mon Jan 21 02:57:04 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02364
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 02:57:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SZ4r-0001iG-00
	for idn-data@psg.com; Sun, 20 Jan 2002 23:41:13 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SZ4q-0001i6-00
	for idn@ops.ietf.org; Sun, 20 Jan 2002 23:41:12 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd4qpz9jiqcQ/CbmmWSRH61Tg==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GRNNUAJ5; Mon, 21 Jan 2002 02:39:43 EST
To: paf@cisco.com
Cc: cheshire@apple.com, idn@ops.ietf.org, liana.ydisg@juno.com
Date: Sun, 20 Jan 2002 23:01:01 -0800
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <20020120.234743.-324529.3.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye <liana.ydisg@juno.com>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

 
> So, this wg decided that we will use one and only one matching rule,
> just  like we decided to use only one character set. Both of these 
> (the rule and the charset) are created in the Unicode Consortium.

The decision of use one and only one matching rule is 
at false, because of there is no ONE rule can deal with 
hundreds of different scripts no matter how strong it 
appears that you defend the stand.  

The charset appears in the form of a table, which gives 
us a better view of these chars and we have a base 
to work with. But when you try to use only ONE rule to 
deal with all of the chars, the rule has to be bias for 
only one type of script, currently Latin.  If we let this 
pass from this IDN wg, then all of us here are arguing
for nothing, as the "Prohibit CDN code points" is the 
only way out suggested by Kenny Huang.   

Isn't the time for the WG to wake up from the "one rule 
for all" scope?

The only way out is to use multiple rules to treat multiple 
scripts, where each rule is identified by a tag. 

Liana




From owner-idn@ops.ietf.org  Mon Jan 21 03:30:36 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02690
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 03:30:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SZca-0002Pp-00
	for idn-data@psg.com; Mon, 21 Jan 2002 00:16:04 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SZcY-0002Pj-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 00:16:03 -0800
Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA29507;
	Mon, 21 Jan 2002 09:15:15 +0100 (MET)
Date: Mon, 21 Jan 2002 09:14:11 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: liana Ye <liana.ydisg@juno.com>
cc: cheshire@apple.com, idn@ops.ietf.org, liana.ydisg@juno.com
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <2341274.1011604451@localhost>
In-Reply-To: <20020120.234743.-324529.3.liana.ydisg@juno.com>
References:  <20020120.234743.-324529.3.liana.ydisg@juno.com>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-20 23.01 -0800 liana Ye <liana.ydisg@juno.com> wrote:

> The decision of use one and only one matching rule is 
> at false, because of there is no ONE rule can deal with 
> hundreds of different scripts no matter how strong it 
> appears that you defend the stand.  

The DNS uses only one rule for matching. One charset and one matching rule.

What you think about is something different than DNS, and that is discussed
in other forum than this working group.

   paf




From owner-idn@ops.ietf.org  Mon Jan 21 10:23:27 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12243
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 10:23:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SfyG-00093H-00
	for idn-data@psg.com; Mon, 21 Jan 2002 07:02:52 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SfyF-000939-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 07:02:51 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0LF1Q416787;
	Mon, 21 Jan 2002 23:01:26 +0800 (CST)
Message-ID: <001601c1a28c$208fca20$4007738c@q.j.tw>
From: =?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "ben" <ben@cc-www.com>, "Kenny Huang" <huangk@alum.sinica.edu>,
        "IETF-IDN" <idn@ops.ietf.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]>
Subject: Re: [idn] Prohibit CDN code points
Date: Mon, 21 Jan 2002 22:58:42 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

It is possible if  we assume the ccTLD implied the language used .  So, they
can be treated with different way based on the ccTLD name implied language.
Now,  only gTLD has this problems.  If  only ASCII ".com" is used, it can
not identify which language is used in hostname part. But if  ML-gTLD is
available , the ML(com) can be classfied by the implied language characters
in ML(com). Especially , ML(gTLD) is very small  and can be predefined .

L.M.Tseng
----- Original Message -----
From: "Paul Hoffman / IMC" <phoffman@imc.org>
To: "ben" <ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>;
"IETF-IDN" <idn@ops.ietf.org>
Sent: Monday, January 21, 2002 2:00 AM
Subject: Re: [idn] Prohibit CDN code points


> At 12:30 PM -0500 1/20/02, ben wrote:
> >Is it possible to let the
> >Japanese and Korean domains names go forward and prohibit Chinese
> >domain names?
>
> No, and that one of the main problems that the CDN community faces.
> In the ISO/IEC 10646 repertoire (which is the same as the Unicode
> repertoire), it is impossible to differentiate between Chinese
> characters and Korean characters and Japanese characters. Thus, any
> proposal to remove the characters for one language removes them for
> all.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>




From owner-idn@ops.ietf.org  Mon Jan 21 10:58:19 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13572
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 10:58:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Sgic-0009wy-00
	for idn-data@psg.com; Mon, 21 Jan 2002 07:50:46 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Sgib-0009ws-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 07:50:45 -0800
Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA26772;
	Mon, 21 Jan 2002 16:49:31 +0100 (MET)
Date: Mon, 21 Jan 2002 16:45:51 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: "=?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?=" <tsenglm@cc.ncu.edu.tw>,
        ben <ben@cc-www.com>, Kenny Huang <huangk@alum.sinica.edu>,
        IETF-IDN <idn@ops.ietf.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <3070662.1011631551@localhost>
In-Reply-To: <001601c1a28c$208fca20$4007738c@q.j.tw>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
 <p05101200b870b1d08c87@[165.227.249.20]>
 <001601c1a28c$208fca20$4007738c@q.j.tw>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-21 22.58 +0800
"=?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<tsenglm@cc.ncu.edu.tw> wrote:

> It is possible if  we assume the ccTLD implied the language used .

What language are they to use in Canada? Sweden?

   paf




From owner-idn@ops.ietf.org  Mon Jan 21 11:06:38 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14079
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 11:06:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Sgp2-000A6x-00
	for idn-data@psg.com; Mon, 21 Jan 2002 07:57:24 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Sgp1-000A6r-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 07:57:23 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0LFup403523;
	Mon, 21 Jan 2002 23:56:51 +0800 (CST)
Message-ID: <000501c1a293$dc346cc0$4007738c@q.j.tw>
From: =?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "ben" <ben@cc-www.com>, "Kenny Huang" <huangk@alum.sinica.edu>,
        "IETF-IDN" <idn@ops.ietf.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <3070662.1011631551@localhost>
Subject: Re: [idn] Prohibit CDN code points
Date: Mon, 21 Jan 2002 23:54:06 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Patrik Fältström:
         Some ccTLD is like ".com" ,  in that country/region thare are many
language used , so they can use ML(ccTLD)
to mean what language is predefined implicitly.

L.M.Tseng
----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>; "ben"
<ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>; "IETF-IDN"
<idn@ops.ietf.org>; "Paul Hoffman / IMC" <phoffman@imc.org>
Sent: Monday, January 21, 2002 11:45 PM
Subject: Re: [idn] Prohibit CDN code points


> --On 2002-01-21 22.58 +0800
> "=?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
> <tsenglm@cc.ncu.edu.tw> wrote:
>
> > It is possible if  we assume the ccTLD implied the language used .
>
> What language are they to use in Canada? Sweden?
>
>    paf
>




From owner-idn@ops.ietf.org  Mon Jan 21 11:06:40 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14091
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 11:06:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SgsL-000ACf-00
	for idn-data@psg.com; Mon, 21 Jan 2002 08:00:49 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SgsK-000ACZ-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 08:00:48 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Mon, 21 Jan 2002 08:16:21 -0800
Message-ID: <000701c1a296$270c5bc0$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" <ben@cc-www.com>
To: =?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>,
        "Kenny Huang" <huangk@alum.sinica.edu>, "IETF-IDN" <idn@ops.ietf.org>,
        "Paul Hoffman / IMC" <phoffman@imc.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw>
Subject: Re: [idn] Prohibit CDN code points
Date: Mon, 21 Jan 2002 11:10:30 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi Tseng / Paul,

I like Tseng's idea for a new type of ML-gTLD very very very very very
much!  :-)

Unfortunately, I don't think it answers the problem Paul and I brought
up- which is what to do about the *current situation* with the gTLD
that has registered domains in Chinese, Japanese, Korean (even a
mixture of them) if infact we want to prohibit CDNs and let the other
IDNs move forward.

Thanks,
Ben



----- Original Message -----
From: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>
To: "ben" <ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>;
"IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman / IMC" <phoffman@imc.org>
Sent: Monday, January 21, 2002 9:58 AM
Subject: Re: [idn] Prohibit CDN code points


> It is possible if  we assume the ccTLD implied the language used .
So, they
> can be treated with different way based on the ccTLD name implied
language.
> Now,  only gTLD has this problems.  If  only ASCII ".com" is used,
it can
> not identify which language is used in hostname part. But if
ML-gTLD is
> available , the ML(com) can be classfied by the implied language
characters
> in ML(com). Especially , ML(gTLD) is very small  and can be
predefined .
>
> L.M.Tseng
> ----- Original Message -----
> From: "Paul Hoffman / IMC" <phoffman@imc.org>
> To: "ben" <ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>;
> "IETF-IDN" <idn@ops.ietf.org>
> Sent: Monday, January 21, 2002 2:00 AM
> Subject: Re: [idn] Prohibit CDN code points
>
>
> > At 12:30 PM -0500 1/20/02, ben wrote:
> > >Is it possible to let the
> > >Japanese and Korean domains names go forward and prohibit Chinese
> > >domain names?
> >
> > No, and that one of the main problems that the CDN community
faces.
> > In the ISO/IEC 10646 repertoire (which is the same as the Unicode
> > repertoire), it is impossible to differentiate between Chinese
> > characters and Korean characters and Japanese characters. Thus,
any
> > proposal to remove the characters for one language removes them
for
> > all.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >
>
>




From owner-idn@ops.ietf.org  Mon Jan 21 11:20:25 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14898
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 11:20:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Sh3n-000AUq-00
	for idn-data@psg.com; Mon, 21 Jan 2002 08:12:39 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Sh3n-000AUk-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 08:12:39 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Mon, 21 Jan 2002 08:27:49 -0800
Message-ID: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" <ben@cc-www.com>
To: "cc-www.com \(Ben\)" <ben@cc-www.com>,
        =?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>,
        "Kenny Huang" <huangk@alum.sinica.edu>, "IETF-IDN" <idn@ops.ietf.org>,
        "Paul Hoffman / IMC" <phoffman@imc.org>
Subject: Re: [idn] Prohibit CDN code points
Date: Mon, 21 Jan 2002 11:21:59 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi Tseng,

Actually... now that I read your suggestion more carefully, are you
suggesting to change Verisign's current ASCII(.com) to ML(.com)?
Hmmmm... what a strange suggestion.

Thanks,
Ben

----- Original Message -----
From: "cc-www.com (Ben)" <ben@cc-www.com>
To: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>; "Kenny Huang"
<huangk@alum.sinica.edu>; "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman
/ IMC" <phoffman@imc.org>
Sent: Monday, January 21, 2002 11:10 AM
Subject: Re: [idn] Prohibit CDN code points


> Hi Tseng / Paul,
>
> I like Tseng's idea for a new type of ML-gTLD very very very very
very
> much!  :-)
>
> Unfortunately, I don't think it answers the problem Paul and I
brought
> up- which is what to do about the *current situation* with the gTLD
> that has registered domains in Chinese, Japanese, Korean (even a
> mixture of them) if infact we want to prohibit CDNs and let the
other
> IDNs move forward.
>
> Thanks,
> Ben
>
>
>
> ----- Original Message -----
> From: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>
> To: "ben" <ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>;
> "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman / IMC"
<phoffman@imc.org>
> Sent: Monday, January 21, 2002 9:58 AM
> Subject: Re: [idn] Prohibit CDN code points
>
>
> > It is possible if  we assume the ccTLD implied the language used .
> So, they
> > can be treated with different way based on the ccTLD name implied
> language.
> > Now,  only gTLD has this problems.  If  only ASCII ".com" is used,
> it can
> > not identify which language is used in hostname part. But if
> ML-gTLD is
> > available , the ML(com) can be classfied by the implied language
> characters
> > in ML(com). Especially , ML(gTLD) is very small  and can be
> predefined .
> >
> > L.M.Tseng
> > ----- Original Message -----
> > From: "Paul Hoffman / IMC" <phoffman@imc.org>
> > To: "ben" <ben@cc-www.com>; "Kenny Huang"
<huangk@alum.sinica.edu>;
> > "IETF-IDN" <idn@ops.ietf.org>
> > Sent: Monday, January 21, 2002 2:00 AM
> > Subject: Re: [idn] Prohibit CDN code points
> >
> >
> > > At 12:30 PM -0500 1/20/02, ben wrote:
> > > >Is it possible to let the
> > > >Japanese and Korean domains names go forward and prohibit
Chinese
> > > >domain names?
> > >
> > > No, and that one of the main problems that the CDN community
> faces.
> > > In the ISO/IEC 10646 repertoire (which is the same as the
Unicode
> > > repertoire), it is impossible to differentiate between Chinese
> > > characters and Korean characters and Japanese characters. Thus,
> any
> > > proposal to remove the characters for one language removes them
> for
> > > all.
> > >
> > > --Paul Hoffman, Director
> > > --Internet Mail Consortium
> > >
> >
> >
>




From owner-idn@ops.ietf.org  Mon Jan 21 11:47:38 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16265
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 11:47:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ShQw-000Ayd-00
	for idn-data@psg.com; Mon, 21 Jan 2002 08:36:34 -0800
Received: from med14.ndl.net.nu ([216.133.64.14] helo=mail.nic.nu)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ShQv-000AyX-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 08:36:33 -0800
Received: from bill.mail.nic.nu ([24.218.220.124]) by mail.nic.nu
          (Post.Office MTA v3.5.3 release 223 ID# 0-61576U100L100S0V35)
          with SMTP id nu; Mon, 21 Jan 2002 11:36:28 -0500
Message-Id: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu>
X-Sender: bill@mail.nic.nu
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 21 Jan 2002 11:37:14 -0500
To: "ben" <ben@cc-www.com>, <tsenglm@cc.ncu.edu.tw>,
        "Kenny Huang" <huangk@alum.sinica.edu>, "IETF-IDN" <idn@ops.ietf.org>
From: bill@mail.nic.nu (J. William Semich)
Subject: Re: [idn] Prohibit CDN code points
In-Reply-To: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA16265

I interpret Mr. Tseng's suggestion differently - that any <ml>.kr could 
indicate Korean, any <ml>.cn could indicate Chinese (or whatever) and any 
<ml>. jp could indicate Japanese. I think that's what he means by "we 
assume the ccTLD implied the language used."  Additionally, <ml>.kr.com 
could indicate Korean, etc.

Bill Semich

At 11:21 AM 1/21/02 -0500, ben wrote:
>Hi Tseng,
>
>Actually... now that I read your suggestion more carefully, are you
>suggesting to change Verisign's current ASCII(.com) to ML(.com)?
>Hmmmm... what a strange suggestion.
>
>Thanks,
>Ben
>
>----- Original Message -----
>From: "cc-www.com (Ben)" <ben@cc-www.com>
>To: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>; "Kenny Huang"
><huangk@alum.sinica.edu>; "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman
>/ IMC" <phoffman@imc.org>
>Sent: Monday, January 21, 2002 11:10 AM
>Subject: Re: [idn] Prohibit CDN code points
>
>
> > Hi Tseng / Paul,
> >
> > I like Tseng's idea for a new type of ML-gTLD very very very very
>very
> > much!  :-)
> >
> > Unfortunately, I don't think it answers the problem Paul and I
>brought
> > up- which is what to do about the *current situation* with the gTLD
> > that has registered domains in Chinese, Japanese, Korean (even a
> > mixture of them) if infact we want to prohibit CDNs and let the
>other
> > IDNs move forward.
> >
> > Thanks,
> > Ben
> >
> >
> >
> > ----- Original Message -----
> > From: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>
> > To: "ben" <ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>;
> > "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman / IMC"
><phoffman@imc.org>
> > Sent: Monday, January 21, 2002 9:58 AM
> > Subject: Re: [idn] Prohibit CDN code points
> >
> >
> > > It is possible if  we assume the ccTLD implied the language used .
> > So, they
> > > can be treated with different way based on the ccTLD name implied
> > language.
> > > Now,  only gTLD has this problems.  If  only ASCII ".com" is used,
> > it can
> > > not identify which language is used in hostname part. But if
> > ML-gTLD is
> > > available , the ML(com) can be classfied by the implied language
> > characters
> > > in ML(com). Especially , ML(gTLD) is very small  and can be
> > predefined .
> > >
> > > L.M.Tseng
> > > ----- Original Message -----
> > > From: "Paul Hoffman / IMC" <phoffman@imc.org>
> > > To: "ben" <ben@cc-www.com>; "Kenny Huang"
><huangk@alum.sinica.edu>;
> > > "IETF-IDN" <idn@ops.ietf.org>
> > > Sent: Monday, January 21, 2002 2:00 AM
> > > Subject: Re: [idn] Prohibit CDN code points
> > >
> > >
> > > > At 12:30 PM -0500 1/20/02, ben wrote:
> > > > >Is it possible to let the
> > > > >Japanese and Korean domains names go forward and prohibit
>Chinese
> > > > >domain names?
> > > >
> > > > No, and that one of the main problems that the CDN community
> > faces.
> > > > In the ISO/IEC 10646 repertoire (which is the same as the
>Unicode
> > > > repertoire), it is impossible to differentiate between Chinese
> > > > characters and Korean characters and Japanese characters. Thus,
> > any
> > > > proposal to remove the characters for one language removes them
> > for
> > > > all.
> > > >
> > > > --Paul Hoffman, Director
> > > > --Internet Mail Consortium
> > > >
> > >
> > >
> >




From owner-idn@ops.ietf.org  Mon Jan 21 11:50:56 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16447
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 11:50:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ShVh-000B4Y-00
	for idn-data@psg.com; Mon, 21 Jan 2002 08:41:29 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ShVg-000B4J-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 08:41:28 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0LGfB415647;
	Tue, 22 Jan 2002 00:41:11 +0800 (CST)
Message-ID: <001c01c1a29a$0d94bf80$4007738c@q.j.tw>
From: =?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "ben" <ben@cc-www.com>, "Kenny Huang" <huangk@alum.sinica.edu>,
        "IETF-IDN" <idn@ops.ietf.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
References: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers.com>
Subject: Re: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 00:38:26 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

I  just  describe the possible  methods even it is very strange.  For  CJK
code point switch off  temporary , another approach may be that we can let
code point of Hangel and Kana
go forward but let ideograph part (Han character) delayed , so Korean and
Japan can use their own pure national language to reduce the troubles come
from delay.

L.M.Tseng
----- Original Message -----
From: "ben" <ben@cc-www.com>
To: "cc-www.com (Ben)" <ben@cc-www.com>; "tsenglm@計網中心.中大.tw"
<tsenglm@cc.ncu.edu.tw>; "Kenny Huang" <huangk@alum.sinica.edu>; "IETF-IDN"
<idn@ops.ietf.org>; "Paul Hoffman / IMC" <phoffman@imc.org>
Sent: Tuesday, January 22, 2002 12:21 AM
Subject: Re: [idn] Prohibit CDN code points


> Hi Tseng,
>
> Actually... now that I read your suggestion more carefully, are you
> suggesting to change Verisign's current ASCII(.com) to ML(.com)?
> Hmmmm... what a strange suggestion.
>
> Thanks,
> Ben
>
> ----- Original Message -----
> From: "cc-www.com (Ben)" <ben@cc-www.com>
> To: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>; "Kenny Huang"
> <huangk@alum.sinica.edu>; "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman
> / IMC" <phoffman@imc.org>
> Sent: Monday, January 21, 2002 11:10 AM
> Subject: Re: [idn] Prohibit CDN code points
>
>
> > Hi Tseng / Paul,
> >
> > I like Tseng's idea for a new type of ML-gTLD very very very very
> very
> > much!  :-)
> >
> > Unfortunately, I don't think it answers the problem Paul and I
> brought
> > up- which is what to do about the *current situation* with the gTLD
> > that has registered domains in Chinese, Japanese, Korean (even a
> > mixture of them) if infact we want to prohibit CDNs and let the
> other
> > IDNs move forward.
> >
> > Thanks,
> > Ben
> >
> >
> >
> > ----- Original Message -----
> > From: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>
> > To: "ben" <ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>;
> > "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman / IMC"
> <phoffman@imc.org>
> > Sent: Monday, January 21, 2002 9:58 AM
> > Subject: Re: [idn] Prohibit CDN code points
> >
> >
> > > It is possible if  we assume the ccTLD implied the language used .
> > So, they
> > > can be treated with different way based on the ccTLD name implied
> > language.
> > > Now,  only gTLD has this problems.  If  only ASCII ".com" is used,
> > it can
> > > not identify which language is used in hostname part. But if
> > ML-gTLD is
> > > available , the ML(com) can be classfied by the implied language
> > characters
> > > in ML(com). Especially , ML(gTLD) is very small  and can be
> > predefined .
> > >
> > > L.M.Tseng
> > > ----- Original Message -----
> > > From: "Paul Hoffman / IMC" <phoffman@imc.org>
> > > To: "ben" <ben@cc-www.com>; "Kenny Huang"
> <huangk@alum.sinica.edu>;
> > > "IETF-IDN" <idn@ops.ietf.org>
> > > Sent: Monday, January 21, 2002 2:00 AM
> > > Subject: Re: [idn] Prohibit CDN code points
> > >
> > >
> > > > At 12:30 PM -0500 1/20/02, ben wrote:
> > > > >Is it possible to let the
> > > > >Japanese and Korean domains names go forward and prohibit
> Chinese
> > > > >domain names?
> > > >
> > > > No, and that one of the main problems that the CDN community
> > faces.
> > > > In the ISO/IEC 10646 repertoire (which is the same as the
> Unicode
> > > > repertoire), it is impossible to differentiate between Chinese
> > > > characters and Korean characters and Japanese characters. Thus,
> > any
> > > > proposal to remove the characters for one language removes them
> > for
> > > > all.
> > > >
> > > > --Paul Hoffman, Director
> > > > --Internet Mail Consortium
> > > >
> > >
> > >
> >
>
>




From owner-idn@ops.ietf.org  Mon Jan 21 11:59:59 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16856
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 11:59:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Shds-000BJe-00
	for idn-data@psg.com; Mon, 21 Jan 2002 08:49:56 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Shdr-000BJO-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 08:49:55 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0LGnj417272;
	Tue, 22 Jan 2002 00:49:45 +0800 (CST)
Message-ID: <002301c1a29b$3f8e3740$4007738c@q.j.tw>
From: =?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "ben" <ben@cc-www.com>, "Kenny Huang" <huangk@alum.sinica.edu>,
        "IETF-IDN" <idn@ops.ietf.org>, "J. William Semich" <bill@mail.nic.nu>
References: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu>
Subject: Re: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 00:47:00 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi !  Bill :
        Both of them are all possible ways ,  <ML>.Lang.com use the lanage
explicitly.
L.M.Tseng
----- Original Message -----
From: "J. William Semich" <bill@mail.nic.nu>
To: "ben" <ben@cc-www.com>; <tsenglm@cc.ncu.edu.tw>; "Kenny Huang"
<huangk@alum.sinica.edu>; "IETF-IDN" <idn@ops.ietf.org>
Sent: Tuesday, January 22, 2002 12:37 AM
Subject: Re: [idn] Prohibit CDN code points


> I interpret Mr. Tseng's suggestion differently - that any <ml>.kr could
> indicate Korean, any <ml>.cn could indicate Chinese (or whatever) and any
> <ml>. jp could indicate Japanese. I think that's what he means by "we
> assume the ccTLD implied the language used."  Additionally, <ml>.kr.com
> could indicate Korean, etc.
>
> Bill Semich
>
> At 11:21 AM 1/21/02 -0500, ben wrote:
> >Hi Tseng,
> >
> >Actually... now that I read your suggestion more carefully, are you
> >suggesting to change Verisign's current ASCII(.com) to ML(.com)?
> >Hmmmm... what a strange suggestion.
> >
> >Thanks,
> >Ben
> >
> >----- Original Message -----
> >From: "cc-www.com (Ben)" <ben@cc-www.com>
> >To: "tsenglm@è¨^網中å¿f.中大.tw" <tsenglm@cc.ncu.edu.tw>; "Kenny
Huang"
> ><huangk@alum.sinica.edu>; "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman
> >/ IMC" <phoffman@imc.org>
> >Sent: Monday, January 21, 2002 11:10 AM
> >Subject: Re: [idn] Prohibit CDN code points
> >
> >
> > > Hi Tseng / Paul,
> > >
> > > I like Tseng's idea for a new type of ML-gTLD very very very very
> >very
> > > much!  :-)
> > >
> > > Unfortunately, I don't think it answers the problem Paul and I
> >brought
> > > up- which is what to do about the *current situation* with the gTLD
> > > that has registered domains in Chinese, Japanese, Korean (even a
> > > mixture of them) if infact we want to prohibit CDNs and let the
> >other
> > > IDNs move forward.
> > >
> > > Thanks,
> > > Ben
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "tsenglm@è¨^網中å¿f.中大.tw" <tsenglm@cc.ncu.edu.tw>
> > > To: "ben" <ben@cc-www.com>; "Kenny Huang" <huangk@alum.sinica.edu>;
> > > "IETF-IDN" <idn@ops.ietf.org>; "Paul Hoffman / IMC"
> ><phoffman@imc.org>
> > > Sent: Monday, January 21, 2002 9:58 AM
> > > Subject: Re: [idn] Prohibit CDN code points
> > >
> > >
> > > > It is possible if  we assume the ccTLD implied the language used .
> > > So, they
> > > > can be treated with different way based on the ccTLD name implied
> > > language.
> > > > Now,  only gTLD has this problems.  If  only ASCII ".com" is used,
> > > it can
> > > > not identify which language is used in hostname part. But if
> > > ML-gTLD is
> > > > available , the ML(com) can be classfied by the implied language
> > > characters
> > > > in ML(com). Especially , ML(gTLD) is very small  and can be
> > > predefined .
> > > >
> > > > L.M.Tseng
> > > > ----- Original Message -----
> > > > From: "Paul Hoffman / IMC" <phoffman@imc.org>
> > > > To: "ben" <ben@cc-www.com>; "Kenny Huang"
> ><huangk@alum.sinica.edu>;
> > > > "IETF-IDN" <idn@ops.ietf.org>
> > > > Sent: Monday, January 21, 2002 2:00 AM
> > > > Subject: Re: [idn] Prohibit CDN code points
> > > >
> > > >
> > > > > At 12:30 PM -0500 1/20/02, ben wrote:
> > > > > >Is it possible to let the
> > > > > >Japanese and Korean domains names go forward and prohibit
> >Chinese
> > > > > >domain names?
> > > > >
> > > > > No, and that one of the main problems that the CDN community
> > > faces.
> > > > > In the ISO/IEC 10646 repertoire (which is the same as the
> >Unicode
> > > > > repertoire), it is impossible to differentiate between Chinese
> > > > > characters and Korean characters and Japanese characters. Thus,
> > > any
> > > > > proposal to remove the characters for one language removes them
> > > for
> > > > > all.
> > > > >
> > > > > --Paul Hoffman, Director
> > > > > --Internet Mail Consortium
> > > > >
> > > >
> > > >
> > >
>




From owner-idn@ops.ietf.org  Mon Jan 21 12:36:45 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17882
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 12:36:44 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SiAl-000C6i-00
	for idn-data@psg.com; Mon, 21 Jan 2002 09:23:55 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SiAk-000C6c-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 09:23:54 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Mon, 21 Jan 2002 09:38:33 -0800
Message-ID: <001d01c1a2a1$a6a12ea0$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" <ben@cc-www.com>
To: <tsenglm@cc.ncu.edu.tw>, "Kenny Huang" <huangk@alum.sinica.edu>,
        "IETF-IDN" <idn@ops.ietf.org>, "J. William Semich" <bill@mail.nic.nu>
References: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu>
Subject: Re: [idn] Prohibit CDN code points
Date: Mon, 21 Jan 2002 12:32:23 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Bill,

>I think that's what he means by "we
>assume the ccTLD implied the language used."  Additionally,
<ml>.kr.com
>could indicate Korean, etc.

If I am correct, Verisign's contract with ICANN disallows them from
registering 2LD... therefore labelling a domain with the language it
is in (such as <ml>.kr.com, etc.) is *not* an option for them.

So the question still remains... what to do about the current gTLD
registrations if infact we want to prohibit CDNs.

Thanks,
Ben







From owner-idn@ops.ietf.org  Mon Jan 21 13:23:19 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19324
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 13:23:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Sixq-000DC9-00
	for idn-data@psg.com; Mon, 21 Jan 2002 10:14:38 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Sixp-000DBq-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 10:14:37 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LIEY313224
	for <idn@ops.ietf.org>; Mon, 21 Jan 2002 10:14:34 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101208b87207de162e@[165.227.249.20]>
In-Reply-To: 
 <001d01c1a2a1$a6a12ea0$cd462b18@mtag.phub.net.cable.rogers.com>
References: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu>
 <001d01c1a2a1$a6a12ea0$cd462b18@mtag.phub.net.cable.rogers.com>
Date: Mon, 21 Jan 2002 10:14:30 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] Prohibit CDN code points
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 12:32 PM -0500 1/21/02, ben wrote:
>So the question still remains... what to do about the current gTLD
>registrations if infact we want to prohibit CDNs.

There is certainly more than one question if we want to prohibit CDNs.

- What do companies who are not in a ccTLD do if they want to use 
Chinese names in their domain names? For example, it would make sense 
for a company that has a Chinese subsidiary to want to use that name 
in a domain name under their primary name, such as 
<Chinese-name>.company-name.com.

- Looking one level up, if ICANN decides to allow internationalized 
TLDs (as many of us hope they will), will Japan and Korea be forced 
to use unnatural spellings of their names? For how long?

- There are tens of millions of Chinese people who do not live in 
China or Taiwan. Should those people be forced to register only in 
.tw or .cn in order to use their personal or company names?

- What do Japanese and Koreans do if rendering their names 
phonetically is inexact? For example, homonyms are quite common in 
Japanese (I don't know about Korean), and the current proposal 
restricts people and companies to fighting to be first to register a 
phonetic homonym when there would be no fight for them using Han.

There are certainly many other questions that this proposal (for 
which there is no Internet Draft, by the way) brings up.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Mon Jan 21 16:26:07 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25011
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 16:26:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SlXq-000GgP-00
	for idn-data@psg.com; Mon, 21 Jan 2002 12:59:58 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SlXq-000GgJ-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 12:59:58 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Mon, 21 Jan 2002 13:15:37 -0800
Message-ID: <002f01c1a2bf$f84af600$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" <ben@cc-www.com>
To: <idn@ops.ietf.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
References: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu> <001d01c1a2a1$a6a12ea0$cd462b18@mtag.phub.net.cable.rogers.com> <p05101208b87207de162e@[165.227.249.20]>
Subject: Re: [idn] Prohibit CDN code points
Date: Mon, 21 Jan 2002 16:09:52 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> There are certainly many other questions that this proposal (for
> which there is no Internet Draft, by the way) brings up.
>

I know we are not suppose to discuss things which has no I-D... so let
me just sneak in one final comment...

Although I have said that Tseng's suggestions (converting the current
registrations of ASCII-.com to ML-.com and converting ASCII-ccTLD to
ML-ccTLD, etc.) are strange (for reasons that are not important), I
must say his suggestions certainly has my vote.  I have always believe
that all the IDN problems we currently face can easily be solved with
ML-TLD (aka <idn>.<idn>).

Thanks,
Ben





From owner-idn@ops.ietf.org  Mon Jan 21 18:34:56 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28156
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 18:34:55 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Snpw-000Jpa-00
	for idn-data@psg.com; Mon, 21 Jan 2002 15:26:48 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Snpv-000JpT-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 15:26:47 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0LNQd402747;
	Tue, 22 Jan 2002 07:26:40 +0800 (CST)
Message-ID: <003e01c1a2d2$afcd8c40$4007738c@q.j.tw>
From: =?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: <idn@ops.ietf.org>, "Paul Hoffman / IMC" <phoffman@imc.org>
References: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu> <001d01c1a2a1$a6a12ea0$cd462b18@mtag.phub.net.cable.rogers.com> <p05101208b87207de162e@[165.227.249.20]>
Subject: Re: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 07:23:50 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi ! Paul  & all :
              If we switch-off  the code point of  ideograph  temporary
then the others can go forward and let CDN society has enough time to
discuss and to solve the TC/SC problems to switch-on quickly . The delay
influence the current gTLD registration will be  minimum.  If  the ML(.com)
are opened it can help to supply more path to solve language conflictions in
different country/region , so the solution can be get and selected if more
path existed.

L.M.Tseng
----- Original Message -----
From: "Paul Hoffman / IMC" <phoffman@imc.org>
To: <idn@ops.ietf.org>
Sent: Tuesday, January 22, 2002 2:14 AM
Subject: Re: [idn] Prohibit CDN code points


> At 12:32 PM -0500 1/21/02, ben wrote:
> >So the question still remains... what to do about the current gTLD
> >registrations if infact we want to prohibit CDNs.
>
> There is certainly more than one question if we want to prohibit CDNs.
>
> - What do companies who are not in a ccTLD do if they want to use
> Chinese names in their domain names? For example, it would make sense
> for a company that has a Chinese subsidiary to want to use that name
> in a domain name under their primary name, such as
> <Chinese-name>.company-name.com.
>
> - Looking one level up, if ICANN decides to allow internationalized
> TLDs (as many of us hope they will), will Japan and Korea be forced
> to use unnatural spellings of their names? For how long?
>
> - There are tens of millions of Chinese people who do not live in
> China or Taiwan. Should those people be forced to register only in
> .tw or .cn in order to use their personal or company names?
>
> - What do Japanese and Koreans do if rendering their names
> phonetically is inexact? For example, homonyms are quite common in
> Japanese (I don't know about Korean), and the current proposal
> restricts people and companies to fighting to be first to register a
> phonetic homonym when there would be no fight for them using Han.
>
> There are certainly many other questions that this proposal (for
> which there is no Internet Draft, by the way) brings up.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>




From owner-idn@ops.ietf.org  Mon Jan 21 19:46:12 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29052
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 19:46:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Sowo-000LNi-00
	for idn-data@psg.com; Mon, 21 Jan 2002 16:37:58 -0800
Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Sown-000LNc-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 16:37:57 -0800
Received: from m5.gw.fujitsu.co.jp by fgwmail5.fujitsu.co.jp (8.9.3/3.7W-MX0112-Fujitsu Gateway)
	id JAA16054 for <idn@ops.ietf.org>; Tue, 22 Jan 2002 09:37:55 +0900 (JST)
	(envelope-from seki@jp.fujitsu.com)
Received: from poi.sysrap.cs.fujitsu.co.jp by m5.gw.fujitsu.co.jp (8.9.3/3.7W-0112-Fujitsu Domain Master)
	id JAA02099 for <idn@ops.ietf.org>; Tue, 22 Jan 2002 09:37:54 +0900
	(envelope-from seki@jp.fujitsu.com)
Received: from roan (dhcp107.sysrap.cs.fujitsu.co.jp [10.35.109.107])
	by poi.sysrap.cs.fujitsu.co.jp (Postfix) with SMTP id C17731EC3
	for <idn@ops.ietf.org>; Tue, 22 Jan 2002 09:37:53 +0900 (JST)
Message-ID: <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp>
From: "Masahiro Sekiguchi" <seki@jp.fujitsu.com>
To: "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw>
Subject: Re: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 09:37:53 +0900
Organization: Fujitsu Limited
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> It is possible if  we assume the ccTLD implied the language used .  So, they
> can be treated with different way based on the ccTLD name implied language.

No, assuming _language_ by ccTLD is a bad idea.

We only need to assume each ccTLD implies a well-defined
set of rules of mapping/matching domain names.

One of the difficulty IDN WG is facing is one universal
set of such rules appropriate all-over-the-world.  By reducing
applicable area of each set of rules smaller, it will be far
more easier to find the rules.

My scenario is as follows:

(1) IDN WG defines a basic set of rules with several options.
    One of the options can be: enable/disable SC/TC mapping,
    for example.

(2) Each TLD registry defines and propergates a concrete
    set of selections among those options, to be used
    for the domain names under the TLD.

    For example, .cn domain can say "SC/TC mapping must be 
    enabled for .cn" if it considers that decision serves the
    .cn domain name users best.  If another domain, say .us,
    finds contrary, it can say "SC/TC must be disabled for .us".

(3) The set of selected options for each TLD must be somehow
    notified to all DNS clients.  IDN WG must develop a
    reasonable way to allow it.  One possibility is to use
    DNS query against the TLD for a special RR.  (This is
    just an example idea.)


(4) DNS clients implements NAMEPREP module as a "parameterized"
    algorithm.  The parameters here is the set of selected
    options.

Note that the intention of this optional (or parameterized)
approach is to make negotiation/compromise easier.  If a ccTLD
considers almost all users of that particular ccTLD uses
same language, the ccTLD can use a set of options optimized for
taht language.  If it finds its users use relatively small 
number of languages, the ccTLD can compromise to find a set 
of rules suitable for those small number of languages.  In case
a ccTLD finds its user communities are so broad, it can choose
a set of neutral options that is *not* best for anybody but is
not harmful either.

The point is: assuming "a ccTLD is tied to a language" is
infeasible, but "to a set of processing rules" looks OK.

    




From owner-idn@ops.ietf.org  Mon Jan 21 22:39:03 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02748
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 22:39:03 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SrYT-000OhU-00
	for idn-data@psg.com; Mon, 21 Jan 2002 19:25:01 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SrYS-000OhL-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 19:25:00 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id LAA03840;
	Tue, 22 Jan 2002 11:18:20 +0800
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: "Paul Hoffman / IMC" <phoffman@imc.org>, <idn@ops.ietf.org>
Subject: RE: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 11:29:31 +0800
Message-ID: <IHELIFNJKJLDFEMBCENDOEBBCMAA.huangk@alum.sinica.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <p05101208b87207de162e@[165.227.249.20]>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA02748



> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On 
> Behalf Of Paul Hoffman / IMC
> Sent: Tuesday, January 22, 2002 2:15 AM
> To: idn@ops.ietf.org
> Subject: Re: [idn] Prohibit CDN code points
> 
> 
> At 12:32 PM -0500 1/21/02, ben wrote:
> >So the question still remains... what to do about the current gTLD
> >registrations if infact we want to prohibit CDNs.
> 
> There is certainly more than one question if we want to prohibit CDNs.
> 
> - What do companies who are not in a ccTLD do if they want to use 
> Chinese names in their domain names? For example, it would make sense 
> for a company that has a Chinese subsidiary to want to use that name 
> in a domain name under their primary name, such as 
> <Chinese-name>.company-name.com.
> 

That's the case we perceived from the very beginning, that's why we keep emphasizing
this issue many times even come with various proposals. Unfortunately this issue
wasn't captured group consensus. This issue was categorized as a localization issue,
or application behavious issue. Finally, we were forced to set up other mechanism to
deal with CDN standardization process. (maybe IRNSS, or other layers).

> - Looking one level up, if ICANN decides to allow internationalized 
> TLDs (as many of us hope they will), will Japan and Korea be forced 
> to use unnatural spellings of their names? For how long?
> 
> - There are tens of millions of Chinese people who do not live in 
> China or Taiwan. Should those people be forced to register only in 
> .tw or .cn in order to use their personal or company names?
> 

Once CDN standards are completed, these will be distributed to global
Internet community.  ccTLD and gTLD can make their own decision. However,
since it's claimed CDN issue can be solved in registration policies, ccTLD
deployed proprietary CDN solutions is foreseeable.

> - What do Japanese and Koreans do if rendering their names 
> phonetically is inexact? For example, homonyms are quite common in 
> Japanese (I don't know about Korean), and the current proposal 
> restricts people and companies to fighting to be first to register a 
> phonetic homonym when there would be no fight for them using Han.
> 

reverse this question, what do Chinese do if rendering their names
visually is inexact  ?  How we compare the degree of severity ? 


Kenny Huang





From owner-idn@ops.ietf.org  Mon Jan 21 23:07:12 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03180
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 23:07:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ss2V-000PJC-00
	for idn-data@psg.com; Mon, 21 Jan 2002 19:56:03 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Ss2U-000PJ2-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 19:56:02 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16Ss2I-000PFQ-00; Tue, 22 Jan 2002 03:55:50 +0000
Date: Mon, 21 Jan 2002 22:55:34 -0500
From: John C Klensin <klensin@jck.com>
To: liana Ye <liana.ydisg@juno.com>, paf@cisco.com
cc: cheshire@apple.com, idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <48034955.1011653734@localhost>
In-Reply-To: <20020120.234743.-324529.3.liana.ydisg@juno.com>
References:  <20020120.234743.-324529.3.liana.ydisg@juno.com>
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: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Liana (and others),

Let's try to review how we have gotten here, since I partially
disagree with Patrik (the disagreement leads, however, to the
same conclusion, only more strongly).

--On Sunday, 20 January, 2002 23:01 -0800 liana Ye
<liana.ydisg@juno.com> wrote:

>> So, this wg decided that we will use one and only one
>> matching rule, just  like we decided to use only one
>> character set. Both of these  (the rule and the charset) are
>> created in the Unicode Consortium.

Actually, I don't believe this is correct --or that the language
isn't precise enough-- so let me try to restate it.  The fact
that there is only one matching rule is a consequence of the
design of the DNS: largely because of the binary nature of the
underlying  architecture, the only matching rule that is
possible involves a bit-wise comparison on each octet in turn.
Unless the labels are assumed to be "binary" (i.e., the
case-mapping rule does not apply) that bit-wise comparison is
made under a mask that collapses ASCII upper-case characters
onto their lower-case counterparts.

Now, we can map or transform all sorts of things together before
they get injected into the actual DNS.  But, as far as the DNS
is concerned, there is only one mapping rule, or two if "binary
labels" are handled differently from "character labels", but
that is it.

Are there ways around this?  Of course there are.  The WG has
looked at many of them and given up on them long ago.  For
example:

(i) One could introduce a completely new set of query types for
labels that might contain non-ASCII strings, and apply a
different matching rule for them.  Unfortunately, this would be
hugely complex -- we are having quite enough problems with the
three address-type records/queries we have today -- and might
take forever to deploy.

(ii) One could introduce a single new label and query type whose
sole purpose was to provide a new form of alias -- like CNAME
only with Unicode (encoded somehow) in the label.  The WG looked
at variants on that theme early on and decided to not pursue
them.  In hindsight, the approach essentially implies "within
DNS layering" and has all of the disadvantages of an "above DNS"
layering scheme and few of the advantages.

(iii) One could adopt the "new class" model, using that class to
impose a somewhat different set of matching rules by redefining
the query types.  That was, you will recall, proposed and
rejected (or, more accurately, ignored), I think mostly because
people were concerned about the length of time it would take to
deploy.

(iv) One could try to use EDNS to specify alternate mapping
rules or conventions.  Again, the problem is deployment,
aggravated by some rather complex issues involving caching and
secondary servers.  And, again, the WG considered some set of
options in this group and couldn't get consensus around moving
forward with them.

One thing that all of these --except, possibly, the last-- have
in common is that, while they were permit a _different_ matching
rule, none of them permit per-language or per-script rules.  You
still get only one (or two).

> The decision of use one and only one matching rule is 
> at false, because of there is no ONE rule can deal with 
> hundreds of different scripts no matter how strong it 
> appears that you defend the stand.  

The rule doesn't deal with scripts at all.  It doesn't deal with
languages either.  It deals only with strings of bits and deals
with them in a mathematically simplistic way.

> The charset appears in the form of a table, which gives 
> us a better view of these chars and we have a base 
> to work with. But when you try to use only ONE rule to 
> deal with all of the chars, the rule has to be bias for 
> only one type of script, currently Latin.

No.  The only "bias" is the ability to use a bit masking
algorithm for ASCII upper-lower case matching.  There are severe
and complex problems in dealing with the range of Latin scripts.

>  If we let this 
> pass from this IDN wg, then all of us here are arguing
> for nothing, as the "Prohibit CDN code points" is the 
> only way out suggested by Kenny Huang.   
 
> Isn't the time for the WG to wake up from the "one rule 
> for all" scope?
> 
> The only way out is to use multiple rules to treat multiple 
> scripts, where each rule is identified by a tag. 

And where are you going to put the tags?  Again, the WG has been
around this question many times.  There isn't a logical place to
put the tags unless one further shortens the fraction of the
label-length-space available for user-visible information.
There are difficult problems in doing the tagging from a user
interface basis.  Language (or even "script") tagging would
prohibit many combinations of characters for which there is
clear demand, and the WG has been reluctant or unwilling to
start making the policy decisions that "one label, one script"
implies.  

The bottom line is that, if you really think you know how to do
this, we are anxiously awaiting the Internet Draft.  But it
needs to cover all of those complex cases with mixed-language
labels and scripts that can't be neatly mapped onto languages
and vice versa.

My own belief is that many of these things require, not a
complex set of binary matching rules, but enough of a notion of
distance functions to talk, not about "matching" but about
similarities and differences.  Cyrillic, Greek, and Latin "A"
look similar, and are "sort of" the same letter (same origins,
overlapping pronounciations), but don't "match".  Greek
lower-case omega "looks somewhat like" Latin "w", but it isn't
the same letter (even "sort of").  Really getting TC<->SC
mappings right may require context, distance/probability
functions, or both (the latter if there isn't enough context).
We can posit doing those things in other sorts of systems, but
not in the DNS, even with a broader set of matching rules.

Now, I know you don't like that answer, and that saddens me.
But wishing, and even unhappiness, won't change the mathematics
that underlie DNS matching.

     john





From owner-idn@ops.ietf.org  Mon Jan 21 23:26:09 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03388
	for <idn-archive@lists.ietf.org>; Mon, 21 Jan 2002 23:26:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SsMC-000Pjx-00
	for idn-data@psg.com; Mon, 21 Jan 2002 20:16:24 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SsMB-000Pjr-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 20:16:23 -0800
Received: from iis.sinica.edu.tw (dhcp053 [140.109.21.60])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g0M4Bej23071;
	Tue, 22 Jan 2002 12:11:40 +0800 (CST)
Message-ID: <3C4CE804.88F70F55@iis.sinica.edu.tw>
Date: Tue, 22 Jan 2002 12:18:12 +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: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= <tsenglm@cc.ncu.edu.tw>
CC: idn@ops.ietf.org, Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] Prohibit CDN code points
References: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu> <001d01c1a2a1$a6a12ea0$cd462b18@mtag.phub.net.cable.rogers.com> <p05101208b87207de162e@[165.227.249.20]> <003e01c1a2d2$afcd8c40$4007738c@q.j.tw>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


���Ѯv�A

�ڭ��٬O�o�`�N Paul �ݪ����D�A�]�N�O�b�^�� domain���U�إߤ���domain,
�Ҧp ����.harvard.edu�C�ѩ�ʥF���ǥ]�t�L�̦b��������ϥΪ̪�����A
cDNC�ܮe���Q�L�̫a�H�ƥ~���W�C

�bIETF�����ҤU�A�ڭ̴��Ѫ������٬O�n�o��L�̪��@�ѡC

�ة�

tsenglm@�p������.���j.tw �g�J�G

> Hi ! Paul  & all :
>               If we switch-off  the code point of  ideograph  temporary
> then the others can go forward and let CDN society has enough time to
> discuss and to solve the TC/SC problems to switch-on quickly . The delay
> influence the current gTLD registration will be  minimum.  If  the ML(.com)
> are opened it can help to supply more path to solve language conflictions in
> different country/region , so the solution can be get and selected if more
> path existed.
>
> L.M.Tseng
> ----- Original Message -----
> From: "Paul Hoffman / IMC" <phoffman@imc.org>
> To: <idn@ops.ietf.org>
> Sent: Tuesday, January 22, 2002 2:14 AM
> Subject: Re: [idn] Prohibit CDN code points
>
> > At 12:32 PM -0500 1/21/02, ben wrote:
> > >So the question still remains... what to do about the current gTLD
> > >registrations if infact we want to prohibit CDNs.
> >
> > There is certainly more than one question if we want to prohibit CDNs.
> >
> > - What do companies who are not in a ccTLD do if they want to use
> > Chinese names in their domain names? For example, it would make sense
> > for a company that has a Chinese subsidiary to want to use that name
> > in a domain name under their primary name, such as
> > <Chinese-name>.company-name.com.
> >
> > - Looking one level up, if ICANN decides to allow internationalized
> > TLDs (as many of us hope they will), will Japan and Korea be forced
> > to use unnatural spellings of their names? For how long?
> >
> > - There are tens of millions of Chinese people who do not live in
> > China or Taiwan. Should those people be forced to register only in
> > .tw or .cn in order to use their personal or company names?
> >
> > - What do Japanese and Koreans do if rendering their names
> > phonetically is inexact? For example, homonyms are quite common in
> > Japanese (I don't know about Korean), and the current proposal
> > restricts people and companies to fighting to be first to register a
> > phonetic homonym when there would be no fight for them using Han.
> >
> > There are certainly many other questions that this proposal (for
> > which there is no Internet Draft, by the way) brings up.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> >




From owner-idn@ops.ietf.org  Tue Jan 22 02:10:33 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13018
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 02:10:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Suut-0002pM-00
	for idn-data@psg.com; Mon, 21 Jan 2002 23:00:23 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Suus-0002pF-00
	for idn@ops.ietf.org; Mon, 21 Jan 2002 23:00:23 -0800
Received: from [0.0.0.0] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA13483;
	Tue, 22 Jan 2002 08:00:11 +0100 (MET)
Date: Tue, 22 Jan 2002 07:59:21 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Masahiro Sekiguchi <seki@jp.fujitsu.com>, IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <4607243.1011686361@localhost>
In-Reply-To: <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
 <p05101200b870b1d08c87@[165.227.249.20]>
 <001601c1a28c$208fca20$4007738c@q.j.tw>
 <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-22 09.37 +0900 Masahiro Sekiguchi <seki@jp.fujitsu.com> wrote:

>     For example, .cn domain can say "SC/TC mapping must be 
>     enabled for .cn" if it considers that decision serves the
>     .cn domain name users best.  If another domain, say .us,
>     finds contrary, it can say "SC/TC must be disabled for .us".

This will not work because _all_ DNS servers in the world need to be able
to fulfil matchings according to the rules the .cn TLD decides. That in
turn means that all DNS servers need to have matching rules which is the
sum of _all_ rules _all_ TLD's define (and subdomains to TLDs etc, because
of course I want a special matching rule for my subdomain of .com!).

This in turn leads by definition to one to me very complex matching
algorithm which is context dependent and not one for each domain in the
world.

Noone have come up with such an algorithm.

And, one thing DNS likes is when one label have the same matching algorithm
regardless of what "neighbour" labels are in the DNS packet. Leaving this
strategy and have different matching rules for the same octets depending on
context is a _very_ big change to all existing DNS implementations.

Don't go there.

   paf




From owner-idn@ops.ietf.org  Tue Jan 22 04:50:47 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14650
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 04:50:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SxLM-0005SV-00
	for idn-data@psg.com; Tue, 22 Jan 2002 01:35:52 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SxLJ-0005Rk-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 01:35:50 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0M9Yb429282;
	Tue, 22 Jan 2002 17:34:37 +0800 (CST)
Message-ID: <002f01c1a327$9ad84000$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp> <4607243.1011686361@localhost>
Subject: Re: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 17:31:41 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "Masahiro Sekiguchi" <seki@jp.fujitsu.com>; "IETF-IDN"
<idn@ops.ietf.org>
Sent: Tuesday, January 22, 2002 2:59 PM
Subject: Re: [idn] Prohibit CDN code points


> --On 2002-01-22 09.37 +0900 Masahiro Sekiguchi <seki@jp.fujitsu.com>
wrote:
>
> >     For example, .cn domain can say "SC/TC mapping must be
> >     enabled for .cn" if it considers that decision serves the
> >     .cn domain name users best.  If another domain, say .us,
> >     finds contrary, it can say "SC/TC must be disabled for .us".
>
> This will not work because _all_ DNS servers in the world need to be able
> to fulfil matchings according to the rules the .cn TLD decides. That in
> turn means that all DNS servers need to have matching rules which is the
> sum of _all_ rules _all_ TLD's define (and subdomains to TLDs etc, because
> of course I want a special matching rule for my subdomain of .com!).
>
        I  think  "the matching rule of server" and "the SC/TC mapping must
be enable foe .cn " in client 's side before IDNA/nameprep  is different
approach.
        The switch in client based on ccTLD is the similar function of
nameprep( mapping , normalization and prohibit).
TC/SC character equivalence mapping is similar to  the mapping of  UNICODE
Alphabet  map  it to its counterpart of ASCII  alpnabet .  The switch will
control the TC/SC equivalence mapping is enabled and the result can be
passed and processed by  nameprep then send to Punny code encoder or not.
       If  TC/SC script should be indicated which one of  it correctly in
the .cn Domain , a  signal information per script can be associated with the
equivalence mapped code and they are passed to Punny code encoder to encode
it with case anotation for non-basic-code-point  part.
       The LDH DNS server still use one simple matching rule for any domain.
> This in turn leads by definition to one to me very complex matching
> algorithm which is context dependent and not one for each domain in the
> world.
>
> Noone have come up with such an algorithm.
>
> And, one thing DNS likes is when one label have the same matching
algorithm
> regardless of what "neighbour" labels are in the DNS packet. Leaving this
> strategy and have different matching rules for the same octets depending
on
> context is a _very_ big change to all existing DNS implementations.
>
> Don't go there.
>
>    paf
>
>




From owner-idn@ops.ietf.org  Tue Jan 22 07:24:33 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16227
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 07:24:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Szpc-0007b5-00
	for idn-data@psg.com; Tue, 22 Jan 2002 04:15:16 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Szpb-0007az-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 04:15:15 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd41Q26RRJTeYGM7LO/dyrnCw==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GRRQYLKR; Tue, 22 Jan 2002 07:14:45 EST
To: paf@cisco.com
Cc: idn@ops.ietf.org
Date: Tue, 22 Jan 2002 02:34:21 -0800
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <20020122.042244.-309131.5.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-1,3-30
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye <liana.ydisg@juno.com>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



On Mon, 21 Jan 2002 09:14:11 +0100 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
<paf@cisco.com> writes:
> --On 2002-01-20 23.01 -0800 liana Ye <liana.ydisg@juno.com> wrote:
> 
> > The decision of use one and only one matching rule is 
> > at false, because of there is no ONE rule can deal with 
> > hundreds of different scripts no matter how strong it 
> > appears that you defend the stand.  
> 
> The DNS uses only one rule for matching. One charset and one 
> matching rule.
> 
> What you think about is something different than DNS, and that is 
> discussed
> in other forum than this working group.
> 
>    paf
> 

Which forum do you mean?  

The IDN currently is one rule - [nameprep].  One charset UCS.
The DNS is one matching rule and one charset ASCII.

Liana







From owner-idn@ops.ietf.org  Tue Jan 22 07:29:08 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16309
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 07:29:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16SzrH-0007ce-00
	for idn-data@psg.com; Tue, 22 Jan 2002 04:16:59 -0800
Received: from m2.boston.juno.com ([64.136.24.65])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16SzrG-0007cY-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 04:16:58 -0800
Received: from cookie.juno.com by cookie.juno.com for <"h3psgxK7wwe0kgb98qASH2VCdP/qtkd41Q26RRJTeYF7sPTqEFOkTw==">
Received: (from liana.ydisg@juno.com)
 by m2.boston.juno.com (jqueuemail) id GRRQYLM6; Tue, 22 Jan 2002 07:14:45 EST
To: klensin@jck.com
Cc: liana.ydisg@juno.com, paf@cisco.com, cheshire@apple.com, idn@ops.ietf.org
Date: Tue, 22 Jan 2002 04:18:20 -0800
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <20020122.042244.-309131.7.liana.ydisg@juno.com>
X-Mailer: Juno 4.0.5
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Juno-Line-Breaks: 0-1,3-174
X-Juno-Att: 0
X-Juno-RefParts: 0
From: liana Ye <liana.ydisg@juno.com>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



On Mon, 21 Jan 2002 22:55:34 -0500 John C Klensin <klensin@jck.com>
writes:
> Liana (and others),
> 
> Let's try to review how we have gotten here, since I partially
> disagree with Patrik (the disagreement leads, however, to the
> same conclusion, only more strongly).
> 
> --On Sunday, 20 January, 2002 23:01 -0800 liana Ye
> <liana.ydisg@juno.com> wrote:
> 
> >> So, this wg decided that we will use one and only one
> >> matching rule, just  like we decided to use only one
> >> character set. Both of these  (the rule and the charset) are
> >> created in the Unicode Consortium.
> 
> Actually, I don't believe this is correct --or that the language
> isn't precise enough-- so let me try to restate it.  The fact
> that there is only one matching rule is a consequence of the
> design of the DNS: largely because of the binary nature of the
> underlying  architecture, the only matching rule that is
> possible involves a bit-wise comparison on each octet in turn.
> Unless the labels are assumed to be "binary" (i.e., the
> case-mapping rule does not apply) that bit-wise comparison is
> made under a mask that collapses ASCII upper-case characters
> onto their lower-case counterparts.
> 

Agree, and this provides the stability of DNS system in the past
years.


> Now, we can map or transform all sorts of things together before
> they get injected into the actual DNS.  But, as far as the DNS
> is concerned, there is only one mapping rule, or two if "binary
> labels" are handled differently from "character labels", but
> that is it.
> 

I am not suggest anyother way, and the  "character labels" are
proposed to be handled the same way with current one 
matching rule in DNS, - NOT two rules.

> Are there ways around this?  Of course there are.  The WG has
> looked at many of them and given up on them long ago.  For
> example:
> 
> (i) One could introduce a completely new set of query types for
> labels that might contain non-ASCII strings, and apply a
> different matching rule for them.  Unfortunately, this would be
> hugely complex -- we are having quite enough problems with the
> three address-type records/queries we have today -- and might
> take forever to deploy.
> 
> (ii) One could introduce a single new label and query type whose
> sole purpose was to provide a new form of alias -- like CNAME
> only with Unicode (encoded somehow) in the label.  The WG looked
> at variants on that theme early on and decided to not pursue
> them.  In hindsight, the approach essentially implies "within
> DNS layering" and has all of the disadvantages of an "above DNS"
> layering scheme and few of the advantages.
> 
> (iii) One could adopt the "new class" model, using that class to
> impose a somewhat different set of matching rules by redefining
> the query types.  That was, you will recall, proposed and
> rejected (or, more accurately, ignored), I think mostly because
> people were concerned about the length of time it would take to
> deploy.
>
> (iv) One could try to use EDNS to specify alternate mapping
> rules or conventions.  Again, the problem is deployment,
> aggravated by some rather complex issues involving caching and
> secondary servers.  And, again, the WG considered some set of
> options in this group and couldn't get consensus around moving
> forward with them.
> 
> One thing that all of these --except, possibly, the last-- have
> in common is that, while they were permit a _different_ matching
> rule, none of them permit per-language or per-script rules.  You
> still get only one (or two).
> 
> > The decision of use one and only one matching rule is 
> > at false, because of there is no ONE rule can deal with 
> > hundreds of different scripts no matter how strong it 
> > appears that you defend the stand.  
> 
> The rule doesn't deal with scripts at all.  It doesn't deal with
> languages either.  It deals only with strings of bits and deals
> with them in a mathematically simplistic way.
> 
> > The charset appears in the form of a table, which gives 
> > us a better view of these chars and we have a base 
> > to work with. But when you try to use only ONE rule to 
> > deal with all of the chars, the rule has to be bias for 
> > only one type of script, currently Latin.
> 
> No.  The only "bias" is the ability to use a bit masking
> algorithm for ASCII upper-lower case matching.  There are severe
> and complex problems in dealing with the range of Latin scripts.
> 
> >  If we let this 
> > pass from this IDN wg, then all of us here are arguing
> > for nothing, as the "Prohibit CDN code points" is the 
> > only way out suggested by Kenny Huang.   
>  
> > Isn't the time for the WG to wake up from the "one rule 
> > for all" scope?
> > 
> > The only way out is to use multiple rules to treat multiple 
> > scripts, where each rule is identified by a tag. 
> 
> And where are you going to put the tags?  Again, the WG has been
> around this question many times.  There isn't a logical place to
> put the tags unless one further shortens the fraction of the
> label-length-space available for user-visible information.

The tag should be transparent to the user, and yes, should be
a part of the user-visible label.

> There are difficult problems in doing the tagging from a user
> interface basis.  Language (or even "script") tagging would
> prohibit many combinations of characters for which there is
> clear demand, and the WG has been reluctant or unwilling to
> start making the policy decisions that "one label, one script"
> implies.  
> 

Uncontroled mix of character scripts is dangerous as the 
discussion on the list already shown.  There must be some
types of control of which scripts can be combined which are 
not making sense. "one label, one script" is not accurate 
description of the tagging method.  I rather call it 
"one label, one language", ie. ja- means japanese using 
kana and Kanji two scripts; kr- means korean using 
Hangul and Hanja scripts; vi- means Vietnamese using 
Latin and Han scripts. If some group wants Latin and 
Greek mix, and there is such a language tag in [ISO639], 
then we can provide that.  Like Chinese, Latin or  Armenia 
can be  "one label, one script". Since Latin, Chinese and  
Arabic are used by multiple languages already. 

> The bottom line is that, if you really think you know how to do
> this, we are anxiously awaiting the Internet Draft.  But it
> needs to cover all of those complex cases with mixed-language
> labels and scripts that can't be neatly mapped onto languages
> and vice versa.

If there are enough interest in the idea, I will summit the next
version of idn-map today.

> My own belief is that many of these things require, not a
> complex set of binary matching rules, but enough of a notion of
> distance functions to talk, not about "matching" but about
> similarities and differences.  Cyrillic, Greek, and Latin "A"
> look similar, and are "sort of" the same letter (same origins,
> overlapping pronounciations), but don't "match".  Greek
> lower-case omega "looks somewhat like" Latin "w", but it isn't
> the same letter (even "sort of").  Really getting TC<->SC
> mappings right may require context, distance/probability
> functions, or both (the latter if there isn't enough context).
> We can posit doing those things in other sorts of systems, but
> not in the DNS, even with a broader set of matching rules.
> 
> Now, I know you don't like that answer, and that saddens me.
> But wishing, and even unhappiness, won't change the mathematics
> that underlie DNS matching.
> 
>      john

That is precise the reason we need multiple rules in IDN, so 
that we can keep one rule one charset in DNS.  

Liana



From owner-idn@ops.ietf.org  Tue Jan 22 10:31:51 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26605
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 10:31:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T2XI-000AJI-00
	for idn-data@psg.com; Tue, 22 Jan 2002 07:08:32 -0800
Received: from imo-r03.mx.aol.com ([152.163.225.99])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T2XH-000AJC-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 07:08:31 -0800
Received: from DougEwell2@cs.com
	by imo-r03.mx.aol.com (mail_out_v31_r1.25.) id i.186.22609fe (3700);
	Tue, 22 Jan 2002 10:08:09 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <186.22609fe.297eda63@cs.com>
Date: Tue, 22 Jan 2002 10:08:19 EST
Subject: Re: [idn] Prohibit CDN code points
To: idn@ops.ietf.org
CC: tsenglm@cc.ncu.edu.tw, paf@cisco.com, seki@jp.fujitsu.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-01-22 1:56:56 Pacific Standard Time, 
tsenglm@cc.ncu.edu.tw writes:

> TC/SC character equivalence mapping is similar to  the mapping of  UNICODE
> Alphabet  map  it to its counterpart of ASCII  alpnabet .

No, it isn't.  Stop saying that.

ASCII uppercase/lowercase mapping is straightforward and unambiguous, and can 
be done one character at a time with NO lexical analysis (at least for 99% of 
all languages that use it; Turkish and Azeri do have exceptions).

TC/SC is NOT one-to-one for all characters.  It is for many, but nowhere near 
99% or 95%.  If you implement any sort of TC/SC mapping you MUST figure out 
how to handle the many-to-one and one-to-many cases, and this is where we 
have all been balking.  Users will not understand or accept that "only some" 
of the TC and SC characters are mapped to each other.

-Doug Ewell
 Fullerton, California



From owner-idn@ops.ietf.org  Tue Jan 22 10:36:33 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26857
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 10:36:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T2eV-000ARU-00
	for idn-data@psg.com; Tue, 22 Jan 2002 07:15:59 -0800
Received: from mail1.ics.ntts.co.jp ([202.32.24.45])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T2eU-000ARM-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 07:15:59 -0800
Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0)
	id AAA26492; Wed, 23 Jan 2002 00:15:52 +0900 (JST)
Received: from daemon.inl.ntts.co.jp
	by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id g0MFFp102420
	for <idn@ops.ietf.org>; Wed, 23 Jan 2002 00:15:51 +0900 (JST)
	(envelope-from yone@po.ntts.co.jp)
Received: (qmail 96536 invoked by alias); 23 Jan 2002 00:15:52 +0900
Received: (qmail 96520 invoked from network); 23 Jan 2002 00:15:51 +0900
Received: from daemon.inl.ntts.co.jp (HELO localhost)
  by daemon.inl.ntts.co.jp with SMTP; 23 Jan 2002 00:15:51 +0900
To: idn@ops.ietf.org
Subject: Re: [idn] Prohibit CDN code points
In-Reply-To: <001c01c1a29a$0d94bf80$4007738c@q.j.tw>
References: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers.com>
	<001c01c1a29a$0d94bf80$4007738c@q.j.tw>
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20020123001542Y.yone@po.ntts.co.jp>
Date: Wed, 23 Jan 2002 00:15:42 +0900 (JST)
From: Yoshiro YONEYA <yone@po.ntts.co.jp>
X-Dispatcher: imput version 20000228(IM140)
Lines: 19
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Prof Tseng,

From: <tsenglm@cc.ncu.edu.tw>
Subject: Re: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 00:38:26 +0800

> I  just  describe the possible  methods even it is very strange.  For  CJK
> code point switch off  temporary , another approach may be that we can let
> code point of Hangel and Kana
> go forward but let ideograph part (Han character) delayed , so Korean and
> Japan can use their own pure national language to reduce the troubles come
> from delay.

As you know, CJK stands for Chinese, Japanese and Korean.  So even
though your suggestion makes sense for Chinese, it is non-sense for
Japanese.

-- 
Yoshiro YONEYA <yone@po.ntts.co.jp>



From owner-idn@ops.ietf.org  Tue Jan 22 10:54:52 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27493
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 10:54:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T33M-000AvE-00
	for idn-data@psg.com; Tue, 22 Jan 2002 07:41:40 -0800
Received: from spitfire.law.miami.edu ([129.171.187.10])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T33L-000Av7-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 07:41:39 -0800
Received: from spitfire.law.miami.edu (localhost [127.0.0.1])
	by spitfire.law.miami.edu (Postfix) with ESMTP
	id 4F7665C3AE2; Tue, 22 Jan 2002 10:41:39 -0500 (EST)
Received: by spitfire.law.miami.edu (Postfix, from userid 1113)
	id 094905C3AE2; Tue, 22 Jan 2002 10:41:38 -0500 (EST)
Received: from localhost (localhost [127.0.0.1])
	by spitfire.law.miami.edu (Postfix) with ESMTP
	id EB6AA5D3A87; Tue, 22 Jan 2002 10:41:38 -0500 (EST)
Date: Tue, 22 Jan 2002 10:41:37 -0500 (EST)
From: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
To: John C Klensin <klensin@jck.com>
Cc: idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
In-Reply-To: <48034955.1011653734@localhost>
Message-ID: <Pine.LNX.4.10.10201221032440.998-100000@spitfire.law.miami.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Perhaps this is the decision -- if conscious decision it was? -- that it
is time to revisit?

I recognize this is not a small or necessarily easy change to make, but
after following this debate for some time, I'm increasingly persuaded that
it does seem to provide the best long-run solution...and doesn't affect
backwards-compatibility either, does it?

On Mon, 21 Jan 2002, John C Klensin wrote:
[...]
> 
> (iii) One could adopt the "new class" model, using that class to
> impose a somewhat different set of matching rules by redefining
> the query types.  That was, you will recall, proposed and
> rejected (or, more accurately, ignored), I think mostly because
> people were concerned about the length of time it would take to
> deploy.
-- 
		Please visit http://www.icannwatch.org
A. Michael Froomkin   |    Professor of Law    |   froomkin@law.tm
U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA
+1 (305) 284-4285  |  +1 (305) 284-6506 (fax)  |  http://www.law.tm
                        -->It's warm here.<--




From owner-idn@ops.ietf.org  Tue Jan 22 11:14:52 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28497
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 11:14:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T3SE-000BMK-00
	for idn-data@psg.com; Tue, 22 Jan 2002 08:07:22 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T3SD-000BME-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 08:07:21 -0800
Received: from iis.sinica.edu.tw (i2ot3 [140.109.21.155])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g0MG22j21178;
	Wed, 23 Jan 2002 00:02:02 +0800 (CST)
Message-ID: <3C4D8E83.5F32BCE7@iis.sinica.edu.tw>
Date: Wed, 23 Jan 2002 00:08:35 +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: Yoshiro YONEYA <yone@po.ntts.co.jp>
CC: idn@ops.ietf.org
Subject: Re: [idn] Prohibit CDN code points
References: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers.com>
		<001c01c1a29a$0d94bf80$4007738c@q.j.tw> <20020123001542Y.yone@po.ntts.co.jp>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


On the other hand, IDN WG is pushing for a standard which introduces a large
amount
of ambiguity into domain names. It does not make sense to users in CJK. This is
especially true for users in China and Taiwan.

-- Janming

Yoshiro YONEYA �g�J�G

> Prof Tseng,
>
> From: <tsenglm@cc.ncu.edu.tw>
> Subject: Re: [idn] Prohibit CDN code points
> Date: Tue, 22 Jan 2002 00:38:26 +0800
>
> > I  just  describe the possible  methods even it is very strange.  For  CJK
> > code point switch off  temporary , another approach may be that we can let
> > code point of Hangel and Kana
> > go forward but let ideograph part (Han character) delayed , so Korean and
> > Japan can use their own pure national language to reduce the troubles come
> > from delay.
>
> As you know, CJK stands for Chinese, Japanese and Korean.  So even
> though your suggestion makes sense for Chinese, it is non-sense for
> Japanese.
>
> --
> Yoshiro YONEYA <yone@po.ntts.co.jp>




From owner-idn@ops.ietf.org  Tue Jan 22 11:17:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28679
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 11:17:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T3Wc-000BSX-00
	for idn-data@psg.com; Tue, 22 Jan 2002 08:11:54 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T3Wb-000BSR-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 08:11:53 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA29592;
	Tue, 22 Jan 2002 08:11:03 -0800
Message-Id: <5.1.0.14.2.20020122080031.03482f28@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 22 Jan 2002 08:06:45 -0800
To: bill@mail.nic.nu (J. William Semich)
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Prohibit CDN code points
Cc: "ben" <ben@cc-www.com>, <tsenglm@cc.ncu.edu.tw>,
        "Kenny Huang" <huangk@alum.sinica.edu>, "IETF-IDN" <idn@ops.ietf.org>
In-Reply-To: <5.1.0.14.2.20020121113103.04aa0af0@mail.nic.nu>
References: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 11:37 AM 1/21/2002 -0500, J. William Semich wrote:
>I interpret Mr. Tseng's suggestion differently - that any <ml>.kr could 
>indicate Korean, any <ml>.cn could indicate Chinese (or whatever) and any 
><ml>. jp could indicate Japanese. I think that's what he means by "we 
>assume the ccTLD implied the language used."  Additionally, <ml>.kr.com 
>could indicate Korean, etc.

Bill,

Thank you for the clarification.

As to the proposal itself, and the discussion about it:

Unfortunately, the suggestion to tie character-set interpretation to 
particular TLDs has several basic flaws.  First, it creates considerable 
complexity in the global DNS software.  Second, it makes the incorrect 
assumption that we can know exactly what choices to make.

Chinese in Japan will not be served well by the assumption that all 
characters under .jp are japanese.  Japanese in China will not be served 
well...  And so on.  Both Japanese and Chinese are badly served by this 
rule in Korea, of course.

It also attempts no solution for characters under gTLDs.

In general, threads like the current one are examples of a failure to 
appreciate the complexity of creating special conditions and rules for 
Internet protocols.  Such idiosyncrasies in protocols make them much more 
difficult to implement correctly and usually destroy their ability to scale 
well.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 22 11:38:10 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29271
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 11:38:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T3jv-000Bmo-00
	for idn-data@psg.com; Tue, 22 Jan 2002 08:25:39 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T3ju-000Bmi-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 08:25:38 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA30167;
	Tue, 22 Jan 2002 08:25:31 -0800
Message-Id: <5.1.0.14.2.20020122082331.033e8ff0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 22 Jan 2002 08:24:13 -0800
To: hoho <hoho@iis.sinica.edu.tw>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Prohibit CDN code points
Cc: Yoshiro YONEYA <yone@po.ntts.co.jp>, idn@ops.ietf.org
In-Reply-To: <3C4D8E83.5F32BCE7@iis.sinica.edu.tw>
References: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers.com>
 <001c01c1a29a$0d94bf80$4007738c@q.j.tw>
 <20020123001542Y.yone@po.ntts.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 12:08 AM 1/23/2002 +0800, hoho wrote:
>On the other hand, IDN WG is pushing for a standard which introduces a large
>amount of ambiguity into domain names. It does not make sense to users in 
>CJK. This is
>especially true for users in China and Taiwan.

Sorry, no.  It introduces no ambiguity at all.

Please feel free to provide a technical analysis that demonstrates such 
ambiguity.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 22 11:38:59 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29301
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 11:38:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T3h4-000Bhm-00
	for idn-data@psg.com; Tue, 22 Jan 2002 08:22:42 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T3h4-000BhQ-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 08:22:42 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA29998
	for <idn@ops.ietf.org>; Tue, 22 Jan 2002 08:22:41 -0800
Message-Id: <5.1.0.14.2.20020122081640.01bdf948@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 22 Jan 2002 08:21:58 -0800
To: idn@ops.ietf.org
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
In-Reply-To: <48034955.1011653734@localhost>
References: <20020120.234743.-324529.3.liana.ydisg@juno.com>
 <20020120.234743.-324529.3.liana.ydisg@juno.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 10:55 PM 1/21/2002 -0500, John C Klensin wrote:
>Now, I know you don't like that answer, and that saddens me.
>But wishing, and even unhappiness, won't change the mathematics
>that underlie DNS matching.


Folks,

I encourage you to read all of John's note very carefully and more than once.

Many participants in this working group desire to solve some very real and 
very serious problems.  However many of those problems are outside of the 
scope of this working group AND there is no technical solution that will 
work for the Internet.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 22 12:14:46 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01017
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 12:14:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T4HB-000CRY-00
	for idn-data@psg.com; Tue, 22 Jan 2002 09:00:01 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T4HA-000CRK-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 09:00:00 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0MGxT428965;
	Wed, 23 Jan 2002 00:59:30 +0800 (CST)
Message-ID: <002301c1a365$b92c5800$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: <DougEwell2@cs.com>, <idn@ops.ietf.org>
Cc: <paf@cisco.com>, <seki@jp.fujitsu.com>
References: <186.22609fe.297eda63@cs.com>
Subject: Re: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 00:56:20 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: <DougEwell2@cs.com>
To: <idn@ops.ietf.org>
Cc: <tsenglm@cc.ncu.edu.tw>; <paf@cisco.com>; <seki@jp.fujitsu.com>
Sent: Tuesday, January 22, 2002 11:08 PM
Subject: Re: [idn] Prohibit CDN code points


> In a message dated 2002-01-22 1:56:56 Pacific Standard Time,
> tsenglm@cc.ncu.edu.tw writes:
>
> > TC/SC character equivalence mapping is similar to  the mapping of
UNICODE
> > Alphabet  map  it to its counterpart of ASCII  alpnabet .
>
> No, it isn't.  Stop saying that.
>
> ASCII uppercase/lowercase mapping is straightforward and unambiguous, and
can
> be done one character at a time with NO lexical analysis (at least for 99%
of
> all languages that use it; Turkish and Azeri do have exceptions).
>
> TC/SC is NOT one-to-one for all characters.  It is for many, but nowhere
near
> 99% or 95%.  If you implement any sort of TC/SC mapping you MUST figure
out
> how to handle the many-to-one and one-to-many cases, and this is where we
> have all been balking.  Users will not understand or accept that "only
some"
> of the TC and SC characters are mapped to each other.
               Using TC/SC in a name identifier is not the same as a
bi-directional translation of  literature.
Today there are many TC/SC translater that only based on character
conversion are used very well in NEWS/BBS. As an identifier comparision ,
one way mapping for both then do comparision  is very simple.  It is like
the case insentive comparision of ASCII string.
               IDN name system need not use a complete literature translater
for such a similar language character TC/SC.

L.M.Tseng
>
> -Doug Ewell
>  Fullerton, California
>




From owner-idn@ops.ietf.org  Tue Jan 22 12:16:21 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01231
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 12:16:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T4Pf-000Ccf-00
	for idn-data@psg.com; Tue, 22 Jan 2002 09:08:47 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T4Pe-000CcR-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 09:08:46 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0MH8i400926;
	Wed, 23 Jan 2002 01:08:44 +0800 (CST)
Message-ID: <003b01c1a367$02bec420$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: <idn@ops.ietf.org>, "Yoshiro YONEYA" <yone@po.ntts.co.jp>
References: <002001c1a297$c2243a00$cd462b18@mtag.phub.net.cable.rogers.com><001c01c1a29a$0d94bf80$4007738c@q.j.tw> <20020123001542Y.yone@po.ntts.co.jp>
Subject: Re: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 01:05:36 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear  Yoneya :
          If  it is non-sense to you , it can be neglected from you .  I do
not like hurt to each others. I just hope to reduce the troubles.

L.M.Tseng
----- Original Message -----
From: "Yoshiro YONEYA" <yone@po.ntts.co.jp>
To: <idn@ops.ietf.org>
Sent: Tuesday, January 22, 2002 11:15 PM
Subject: Re: [idn] Prohibit CDN code points


> Prof Tseng,
>
> From: <tsenglm@cc.ncu.edu.tw>
> Subject: Re: [idn] Prohibit CDN code points
> Date: Tue, 22 Jan 2002 00:38:26 +0800
>
> > I  just  describe the possible  methods even it is very strange.  For
CJK
> > code point switch off  temporary , another approach may be that we can
let
> > code point of Hangel and Kana
> > go forward but let ideograph part (Han character) delayed , so Korean
and
> > Japan can use their own pure national language to reduce the troubles
come
> > from delay.
>
> As you know, CJK stands for Chinese, Japanese and Korean.  So even
> though your suggestion makes sense for Chinese, it is non-sense for
> Japanese.
>
> --
> Yoshiro YONEYA <yone@po.ntts.co.jp>
>




From owner-idn@ops.ietf.org  Tue Jan 22 16:27:16 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11203
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 16:27:16 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T8Ba-000HK2-00
	for idn-data@psg.com; Tue, 22 Jan 2002 13:10:30 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T8BZ-000HJv-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 13:10:29 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16T8BX-0000vb-00; Tue, 22 Jan 2002 21:10:27 +0000
Date: Tue, 22 Jan 2002 16:10:11 -0500
From: John C Klensin <klensin@jck.com>
To: "Michael Froomkin - U.Miami School of Law" <froomkin@law.miami.edu>
cc: idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <10241513.1011715811@localhost>
In-Reply-To: <Pine.LNX.4.10.10201221032440.998-100000@spitfire.law.miami.edu>
References:  <Pine.LNX.4.10.10201221032440.998-100000@spitfire.law
 .miami.edu>
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: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On Tuesday, 22 January, 2002 10:41 -0500 "Michael Froomkin -
U.Miami School of Law" <froomkin@law.miami.edu> wrote:

> Perhaps this is the decision -- if conscious decision it was?
> -- that it is time to revisit?
> 
> I recognize this is not a small or necessarily easy change to
> make, but after following this debate for some time, I'm
> increasingly persuaded that it does seem to provide the best
> long-run solution...and doesn't affect backwards-compatibility
> either, does it?

Well, I made the "new class" proposal for a reason, and I still
believe in the reasoning (which you have more or less summarized
above).  The argument against it, to me, is the number of
problems it _doesn't_ solve.  While we could make some changes
in matching/ equivalence models via a new Class, it isn't going
to solve problems with near-matches that might be considered
matching and might not.  It isn't going to solve problems that
really require different actions for different languages.  It
isn't going to solve problems for people who really want phrases
and not invented words.  It isn't going to resolve the insane
problem of which "Joe's Pizza" is entitled to exclusive,
worldwide, use of "joespizza.com".  And it isn't going to solve
a very large number of other problems.  Consequently, whatever
we do, we are going to need other systems --whether "above DNS"
layering or otherwise-- to deal with those issues.

In that context, let's horribly oversimplify things and assume
that we can make a three-way choice as far as the DNS is
concerned.

	(i) We can do some fairly fancy mapping and exclusions,
	then encode IDNs into the DNS.  IDNA (including
	nameprep) is clearly an instance of this; all of the
	other proposals are seeming to me to be nearly
	isomorphic to it as far as the major issues and
	capabilities are concerned.
	
	(ii) We can do the new class stuff, cleaning up some of
	the compatibility and matching issues, but making only a
	marginal improvement over IDNA in the grand scheme of
	things.
	
	(iii) We can prohibit _all_ encoding of non-LDH
	characters in the DNS, relying entirely on the layered
	stuff to do the internationalization job.

Now, to me, the questions then become whether IDNA (or the first
option more broadly) is likely to cause enough damage to push us
toward the second or third.  And, if the answer is "yes",
whether the advantages of the hard-to-deploy second alternative
make it more attractive than the third one.

I don't know.  But my instincts right now --reinforced by the
lack of interest in, and willingness of people to work on, "new
class"-- are that the real choice lies between the first and
third of those options.    And, of course, for whatever it is
worth, "postpone/prohibit CDN" is, I think, just a special case
of the third option: while the problems with Chinese are
somewhat different, I'm convinced that we have somewhat parallel
equivalence or look-alike problems with almost any language or
script we might focus on.

    john


----

> On Mon, 21 Jan 2002, John C Klensin wrote:
> [...]
>> 
>> (iii) One could adopt the "new class" model, using that class
>> to impose a somewhat different set of matching rules by
>> redefining the query types.  That was, you will recall,
>> proposed and rejected (or, more accurately, ignored), I think
>> mostly because people were concerned about the length of time
>> it would take to deploy.
> -- 




From owner-idn@ops.ietf.org  Tue Jan 22 17:55:46 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13858
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 17:55:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T9fX-000JS0-00
	for idn-data@psg.com; Tue, 22 Jan 2002 14:45:31 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T9fX-000JRt-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 14:45:31 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16T9fQ-00014R-00; Tue, 22 Jan 2002 22:45:24 +0000
Date: Tue, 22 Jan 2002 17:45:08 -0500
From: John C Klensin <klensin@jck.com>
To: Dave Crocker <dhc@dcrocker.net>
cc: idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <15938774.1011721508@localhost>
In-Reply-To: <5.1.0.14.2.20020122081640.01bdf948@127.0.0.1>
References:  <5.1.0.14.2.20020122081640.01bdf948@127.0.0.1>
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: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On Tuesday, 22 January, 2002 08:21 -0800 Dave Crocker
<dhc@dcrocker.net> wrote:

> At 10:55 PM 1/21/2002 -0500, John C Klensin wrote:
>> Now, I know you don't like that answer, and that saddens me.
>> But wishing, and even unhappiness, won't change the
>> mathematics that underlie DNS matching.
> 
> Folks,
> 
> I encourage you to read all of John's note very carefully and
> more than once.
> 
> Many participants in this working group desire to solve some
> very real and very serious problems.  However many of those
> problems are outside of the scope of this working group AND
> there is no technical solution that will work for the Internet.

I would have said "no technical solution within the context of
the DNS, or at least within Class=IN, that will work for the
Internet".   But I assume and hope that we agree about that.

    john




From owner-idn@ops.ietf.org  Tue Jan 22 18:08:19 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14090
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 18:08:18 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16T9ud-000Jo4-00
	for idn-data@psg.com; Tue, 22 Jan 2002 15:01:07 -0800
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16T9uc-000Jnx-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 15:01:06 -0800
Received: from [209.187.148.217] (helo=P2)
	by bs.jck.com with esmtp (Exim 3.22 #1)
	id 16T9ua-000160-00; Tue, 22 Jan 2002 23:01:04 +0000
Date: Tue, 22 Jan 2002 18:00:48 -0500
From: John C Klensin <klensin@jck.com>
To: Dave Crocker <dhc@dcrocker.net>
cc: IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <16879118.1011722448@localhost>
In-Reply-To: <5.1.0.14.2.20020122080031.03482f28@127.0.0.1>
References:  <5.1.0.14.2.20020122080031.03482f28@127.0.0.1>
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: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On Tuesday, 22 January, 2002 08:06 -0800 Dave Crocker
<dhc@dcrocker.net> wrote:

> In general, threads like the current one are examples of a
> failure to appreciate the complexity of creating special
> conditions and rules for Internet protocols.  Such
> idiosyncrasies in protocols make them much more difficult to
> implement correctly and usually destroy their ability to scale
> well.

Now it is my turn.  While Dave and I have a history of
disagreeing about many things, I appreciate his kind words about
my analysis of the equivalency problem.   And the above
summarizes, much better than I have been able to do, one of the
key problems we face in trying to make language-specific,
country-specific, or script-specific rules.  

The DNS, especially as represented by contemporary
implementations, is a fairly complex bit of protocol work.
Given that complexity, the code base, and some history of
fragile or incorrect setup of various domains, it is a
testimonial to the quality of the design that it works at all,
and does so without frequent major disruptions.  It is very hard
to imagine that we could change the protocols and implementation
to support a potentially-large collection of "if the TLD is X,
then..." and "if the TLD is Y and the SLD is Z" rules while
preserving the current level of robustness.   And, while adding
a Class would help isolate the current DNS from the problems
this would cause, it wouldn't make the ultimate complexity, or
risk, any lower.

We've heard a number of suggestions on this list by people who
have preceeded their remarks with words like "I am not an
implementor, but...".  This is the point --and the robustness
and scaling issues that Dave identifies are the key-- at which
looking at the problem and not at the protocol infrastructure
becomes a problem.  And so, I would strongly encourage those who
are suggesting "equivalence", or language-specific, or
script-specific systems to be sure they have recently read and
understood the basic DNS protocol standards and, preferably,
taken a careful look at the code for BIND or some equivalent
implementation.

     john
 



From owner-idn@ops.ietf.org  Tue Jan 22 20:07:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16125
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 20:07:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TBhP-000MDm-00
	for idn-data@psg.com; Tue, 22 Jan 2002 16:55:35 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TBhO-000MDg-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 16:55:34 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0N0tJ420000;
	Wed, 23 Jan 2002 08:55:19 +0800 (CST)
Message-ID: <002201c1a3a8$2c139a80$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "John C Klensin" <klensin@jck.com>, "Dave Crocker" <dhc@dcrocker.net>
Cc: "IETF-IDN" <idn@ops.ietf.org>
References:  <5.1.0.14.2.20020122080031.03482f28@127.0.0.1> <16879118.1011722448@localhost>
Subject: Re: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 08:52:01 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear John, Dave and all:
                  There are some basic different points in this thread , If
we can classify them then we may  lead to the same conclusions.
1. TC/SC is not a global issue and not only a local issue.  That is say,
TC/SC is related to chinese language locally but the TC/SC characters in
UNICODE is related to CJK area.  There are two additional attributes, (
TC/SC-name, lang, area).
2.The requirement of preserving of TC/SC scripts information in DNS zone
file and client's display for manager and users is necessary, but it do not
necessary to preserve in the level 1 lookup and comparing phase of  LDH-DNS
query.  That is say , the basic DNS capability and anotationalized Puny Code
encoder/decoder of  IDNA are enough.
3.The searching/mapping from (TC/SC-name,lang,area) --->
string-with-some-signalized-UNICODE--character  --->
anotational-Puny-coded-ACE-string  can be  a client side solution  with
multi-layer-module or alternative-class approach .  But a client side
solution to do this mapping from (TC/SC-name, lang,area) -->
string-with-signalized-UNICODE-character  is just like the issue in IRNSS.
From multiple attributed record mapping to a signalized-UNICODE-string can
be describe by the rule :  If  (TLD == area && source-native-language
==lang) then f1 else f2.   The rule is in the higher level , it is a
localization or area related issue. It is not operated on LDH-DNS server.
4. Now, we need to know does it is possible and existed some interface to do
nameprep of IDNA to let the mapping can do correctly :
string-with-signalized-UNICODE-character --->
anotational-Puny-coded-ACE-string
5. A lower/upper case mixed LDH-domain name never change and increase burden
to current LDH-DNS.
6. At the time to define how to process of multiple attributed record
mapping into a string-of-signalized-UNICODE-characters , we need to know the
interface existed and  TC/SC IDN will not be mis-used in current IDNA
architecture.

L.M.Tseng
----- Original Message -----
From: "John C Klensin" <klensin@jck.com>
To: "Dave Crocker" <dhc@dcrocker.net>
Cc: "IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 7:00 AM
Subject: Re: [idn] Prohibit CDN code points


> --On Tuesday, 22 January, 2002 08:06 -0800 Dave Crocker
> <dhc@dcrocker.net> wrote:
>
> > In general, threads like the current one are examples of a
> > failure to appreciate the complexity of creating special
> > conditions and rules for Internet protocols.  Such
> > idiosyncrasies in protocols make them much more difficult to
> > implement correctly and usually destroy their ability to scale
> > well.
>
> Now it is my turn.  While Dave and I have a history of
> disagreeing about many things, I appreciate his kind words about
> my analysis of the equivalency problem.   And the above
> summarizes, much better than I have been able to do, one of the
> key problems we face in trying to make language-specific,
> country-specific, or script-specific rules.
>
> The DNS, especially as represented by contemporary
> implementations, is a fairly complex bit of protocol work.
> Given that complexity, the code base, and some history of
> fragile or incorrect setup of various domains, it is a
> testimonial to the quality of the design that it works at all,
> and does so without frequent major disruptions.  It is very hard
> to imagine that we could change the protocols and implementation
> to support a potentially-large collection of "if  TLD isthe X,
> isrules  Y and then..." and "if the TLD the SLD is Z" while
> preserving the current level of robustness.   And, while adding
> a Class would help isolate the current DNS from the problems
> this would cause, it wouldn't make the ultimate complexity, or
> risk, any lower.
>
> We've heard a number of suggestions on this list by people who
> have preceeded their remarks with words like "I am not an
> implementor, but...".  This is the point --and the robustness
> and scaling issues that Dave identifies are the key-- at which
> looking at the problem and not at the protocol infrastructure
> becomes a problem.  And so, I would strongly encourage those who
> are suggesting "equivalence", or language-specific, or
> script-specific systems to be sure they have recently read and
> understood the basic DNS protocol standards and, preferably,
> taken a careful look at the code for BIND or some equivalent
> implementation.
>
>      john
>
>




From owner-idn@ops.ietf.org  Tue Jan 22 22:46:24 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20655
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 22:46:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TE4c-000Oy4-00
	for idn-data@psg.com; Tue, 22 Jan 2002 19:27:42 -0800
Received: from mail1.ics.ntts.co.jp ([202.32.24.45])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TE4b-000Oxx-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 19:27:42 -0800
Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0)
	id MAA21380; Wed, 23 Jan 2002 12:27:36 +0900 (JST)
Received: from daemon.inl.ntts.co.jp
	by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id g0N3RZP25507
	for <idn@ops.ietf.org>; Wed, 23 Jan 2002 12:27:35 +0900 (JST)
	(envelope-from yone@po.ntts.co.jp)
Received: (qmail 14527 invoked by alias); 23 Jan 2002 12:27:35 +0900
Received: (qmail 14512 invoked from network); 23 Jan 2002 12:27:34 +0900
Received: from daemon.inl.ntts.co.jp (HELO localhost)
  by daemon.inl.ntts.co.jp with SMTP; 23 Jan 2002 12:27:34 +0900
To: idn@ops.ietf.org
Subject: Re: [idn] Prohibit CDN code points
In-Reply-To: <003b01c1a367$02bec420$4007738c@q.j.tw>
References: <001c01c1a29a$0d94bf80$4007738c@q.j.tw>
	<20020123001542Y.yone@po.ntts.co.jp>
	<003b01c1a367$02bec420$4007738c@q.j.tw>
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20020123122720I.yone@po.ntts.co.jp>
Date: Wed, 23 Jan 2002 12:27:20 +0900 (JST)
From: Yoshiro YONEYA <yone@po.ntts.co.jp>
X-Dispatcher: imput version 20000228(IM140)
Lines: 15
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Prof Tseng,

From: <tsenglm@cc.ncu.edu.tw>
Subject: Re: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 01:05:36 +0800

>           If  it is non-sense to you , it can be neglected from you .  I do
> not like hurt to each others. I just hope to reduce the troubles.

Do you mean your suggestion can be neglected from who think it is
non-sense?  Consensus of the IDN WG is, considering language aspect is
out of scope.

-- 
Yoshiro YONEYA <yone@nic.ad.jp>



From owner-idn@ops.ietf.org  Tue Jan 22 23:08:32 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20873
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 23:08:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TEUz-000PRQ-00
	for idn-data@psg.com; Tue, 22 Jan 2002 19:54:57 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TEUx-000PRK-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 19:54:56 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16TEUx-0003kg-00
	for <idn@ops.ietf.org>; Tue, 22 Jan 2002 19:54:55 -0800
Date: Wed, 23 Jan 2002 03:54:55 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF-IDN <idn@ops.ietf.org>
Subject: [idn] prohibit simplified code points
Message-ID: <20020123035454.GG12577@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <5.1.0.14.2.20020122080031.03482f28@127.0.0.1> <16879118.1011722448@localhost> <002201c1a3a8$2c139a80$4007738c@q.j.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002201c1a3a8$2c139a80$4007738c@q.j.tw>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Someone proposed prohibiting Han code points until the Chinese community
decides what to do about the traditional/simplified matching issue.
Obviously that would be very onerous on the Japanese and Korean
communities.

A similar idea, though, would be to prohibit only the simplified Han
code points until the Chinese community decides what to do about the
traditional/simplified matching issue.  This would not affect other
languages, right?  (If I'm wrong, then disregard this message.)

Let me say up front that I don't advocate this idea.  I think IDN is too
low a layer for this sort of matching, and I advocate IDNA as-is.  But
if there is great opposition to IDNA, prohibiting simplified Han code
points for the time being might be an acceptable compromise.

It would leave the door open for a future version of IDNA that maps
some simplified characters to traditional characters and allows the
other simplified characters (the ones that have no one-to-one mapping)
to stand as they are.  Mixed-case annotations could be used to indicate
which traditional characters want to be mapped back to their simplified
counterparts, but this T->S mapping would be enabled only if the IDNA
prefix contained both an uppercase and lowercase letter, to reduce the
chance that T->S mapping is accidentally performed when not intended
(like on Japanese names).

The door would also be left open for a future version of IDNA that
simply removes the prohibition on simplified Han code points, resulting
in the same IDNA that's now on the table.

AMC



From owner-idn@ops.ietf.org  Tue Jan 22 23:44:00 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21792
	for <idn-archive@lists.ietf.org>; Tue, 22 Jan 2002 23:43:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TF9n-0000C0-00
	for idn-data@psg.com; Tue, 22 Jan 2002 20:37:07 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TF9m-0000Bp-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 20:37:06 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g0N4bbb02278
	for idn@ops.ietf.org; Wed, 23 Jan 2002 13:37:37 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Wed, 23 Jan 2002 13:37:37 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] prohibit simplified code points
Message-ID: <20020123043736.GD2071@spsoft.co.kr>
References: <5.1.0.14.2.20020122080031.03482f28@127.0.0.1> <16879118.1011722448@localhost> <002201c1a3a8$2c139a80$4007738c@q.j.tw> <20020123035454.GG12577@nicemice.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <20020123035454.GG12577@nicemice.net>
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Wed, Jan 23, 2002 at 03:54:55AM +0000, Adam M. Costello wrote:
> (snip)  Mixed-case annotations could be used to indicate
> which traditional characters want to be mapped back to their simplified
> counterparts, but this T->S mapping would be enabled only if the IDNA
> prefix contained both an uppercase and lowercase letter, to reduce the
> chance that T->S mapping is accidentally performed when not intended
> (like on Japanese names).

Dear Adam M. Costello,

Are you proposing that "mixed case notation" shoule be a mandatory
feature of Punycode when used in IDNA ? If it is true, it sounds
very interesting.

My best regards

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Wed Jan 23 00:21:09 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22333
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 00:21:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TFiA-0000nX-00
	for idn-data@psg.com; Tue, 22 Jan 2002 21:12:38 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TFi9-0000nN-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 21:12:37 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16TFi5-0003xf-00
	for <idn@ops.ietf.org>; Tue, 22 Jan 2002 21:12:33 -0800
Date: Wed, 23 Jan 2002 05:12:33 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] prohibit simplified code points
Message-ID: <20020123051233.GH12577@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <5.1.0.14.2.20020122080031.03482f28@127.0.0.1> <16879118.1011722448@localhost> <002201c1a3a8$2c139a80$4007738c@q.j.tw> <20020123035454.GG12577@nicemice.net> <20020123043736.GD2071@spsoft.co.kr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020123043736.GD2071@spsoft.co.kr>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> Are you proposing that "mixed case notation" shoule be a mandatory
> feature of Punycode when used in IDNA ?

No.  The S->T mapping would be required in nameprep, but mixed-case
annotation would remain an optional feature of Punycode, and T->S
mapping would be an optional feature when displaying ACE names.  When
converting an ACE to Unicode for display, software that supports T->S
mapping could do it for the entire domain name (if the user requests
it) or for individual characters using mixed-case annotation (if it is
supported).

Software that doesn't support T->S mapping would simply display
the Unicode as-is, which means the user would see only traditional
characters (and simplified characters that have no one-to-one mapping).

Chinese users would tend to demand software support for T->S mapping.
Other users would tend not to care.

I think this proposal technically works, but I think it's probably too
much trouble for an incomplete solution (only one-to-one T-S matching is
handled).  A complete solution (for many languages, not just Chinese)
would have to be done at a higher layer.

AMC



From owner-idn@ops.ietf.org  Wed Jan 23 01:13:54 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23162
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 01:13:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TGWX-0001gm-00
	for idn-data@psg.com; Tue, 22 Jan 2002 22:04:41 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TGWW-0001gg-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 22:04:40 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id NAA08805;
	Wed, 23 Jan 2002 13:57:33 +0800
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: "Yoshiro YONEYA" <yone@po.ntts.co.jp>, <idn@ops.ietf.org>
Subject: RE: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 14:08:44 +0800
Message-ID: <IHELIFNJKJLDFEMBCENDEECDCMAA.huangk@alum.sinica.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20020123122720I.yone@po.ntts.co.jp>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA23162

> Do you mean your suggestion can be neglected from who think it is
> non-sense?  Consensus of the IDN WG is, considering language aspect is
> out of scope.
> 

Language and terminology issue shall be discussed at other layers 
(e.g., IRNSS wg). The issue (prohibit code points) I raised because it is
impartible with future development in other wg. Therefore I suggest
prohibiting these controversial code points until things are in progress.

We don't have to change the whole infrastructure all at once. Especially
not many of us realize what side effect (business, operation, ..,etc) the CJK 
community will encounter.  

People working here have many impressive engineering experience.
Do we pay enough attention to realize user requirements ?  If we don't have
clear user requirements, what sort of system will eventually be delivered ?
Please correct me if any of you do have clear and complete user requirements 
from user community.


Best Regards


Kenny Huang




From owner-idn@ops.ietf.org  Wed Jan 23 02:22:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02591
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 02:22:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16THbs-0002or-00
	for idn-data@psg.com; Tue, 22 Jan 2002 23:14:16 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16THbr-0002ol-00
	for idn@ops.ietf.org; Tue, 22 Jan 2002 23:14:15 -0800
Message-ID: <006301c1a386$83d4efc0$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp> <4607243.1011686361@localhost>
Subject: Re: [idn] Prohibit CDN code points
Date: Tue, 22 Jan 2002 15:51:04 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi Patrik,

Additional and optional character equivalence preparation by zone is
possible.

----- Original Message -----
From: "Patrik F�ltstr�m" <paf@cisco.com>
> >     For example, .cn domain can say "SC/TC mapping must be
> >     enabled for .cn" if it considers that decision serves the
> >     .cn domain name users best.  If another domain, say .us,
> >     finds contrary, it can say "SC/TC must be disabled for .us".
>
> This will not work because _all_ DNS servers in the world need to be able
> to fulfil matchings according to the rules the .cn TLD decides. That in

This is not true. As long as the .cn DNS does the matching internally and
provide a consistent response, why would "all" servers in the world need to
be able to fulfil the matchings?  If you are arguing how the application
then use the information to connect to the destination server, thats another
issue.  But by zone rules are possible.

> And, one thing DNS likes is when one label have the same matching
algorithm
> regardless of what "neighbour" labels are in the DNS packet. Leaving this
> strategy and have different matching rules for the same octets depending
on
> context is a _very_ big change to all existing DNS implementations.

I agree with you on this.  But I dont think what is being discussed is
"neighbour-label" dependent matching rules, instead it is the ability for
zone operators to decide which options they could pick and choose from to do
internal matching.  And I think it is agreeable that it makes sense to have
a standardized list of options for operators to choose to implement.

Edmon




From owner-idn@ops.ietf.org  Wed Jan 23 03:40:52 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03865
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 03:40:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TIeH-00047z-00
	for idn-data@psg.com; Wed, 23 Jan 2002 00:20:49 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TIeG-00047s-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 00:20:48 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id QAA09458;
	Wed, 23 Jan 2002 16:13:51 +0800
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: <DougEwell2@cs.com>, <idn@ops.ietf.org>
Cc: <tsenglm@cc.ncu.edu.tw>, <paf@cisco.com>, <seki@jp.fujitsu.com>
Subject: RE: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 16:25:00 +0800
Message-ID: <IHELIFNJKJLDFEMBCENDEECHCMAA.huangk@alum.sinica.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <186.22609fe.297eda63@cs.com>
Importance: Normal
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA03865



> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On 
> Behalf Of DougEwell2@cs.com
> Sent: Tuesday, January 22, 2002 11:08 PM
> To: idn@ops.ietf.org
> Cc: tsenglm@cc.ncu.edu.tw; paf@cisco.com; seki@jp.fujitsu.com
> Subject: Re: [idn] Prohibit CDN code points
> 
> 
> In a message dated 2002-01-22 1:56:56 Pacific Standard Time, 
> tsenglm@cc.ncu.edu.tw writes:
> 
> > TC/SC character equivalence mapping is similar to  the mapping 
> of  UNICODE
> > Alphabet  map  it to its counterpart of ASCII  alpnabet .
> 
> No, it isn't.  Stop saying that.
> 
> ASCII uppercase/lowercase mapping is straightforward and 
> unambiguous, and can 
> be done one character at a time with NO lexical analysis (at 
> least for 99% of 
> all languages that use it; Turkish and Azeri do have exceptions).
> 
> TC/SC is NOT one-to-one for all characters.  It is for many, but 
> nowhere near 
> 99% or 95%.  If you implement any sort of TC/SC mapping you MUST 
> figure out 
> how to handle the many-to-one and one-to-many cases, and this is where we 
> have all been balking.  Users will not understand or accept that 
> "only some" 
> of the TC and SC characters are mapped to each other.

Theoretically, 1-1 TC/SC mapping, ASCII uppercase/lowercase mapping or
any table mapping are all belong to the same computing algorithm. From computer
science point of view, they are the same algorithm.

Your question should address to the souce of the table (1-1 only), not to the 
computing algorithm.

Kenny Huang





From owner-idn@ops.ietf.org  Wed Jan 23 03:56:50 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04082
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 03:56:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TIwl-0004T8-00
	for idn-data@psg.com; Wed, 23 Jan 2002 00:39:55 -0800
Received: from bartok.sidn.nl ([193.176.144.164])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TIwk-0004T2-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 00:39:55 -0800
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1])
	by bartok.sidn.nl (8.11.6/8.11.6) with ESMTP id g0N8dHi27877;
	Wed, 23 Jan 2002 09:39:18 +0100 (CET)
	(envelope-from jaap@bartok.sidn.nl)
Message-Id: <200201230839.g0N8dHi27877@bartok.sidn.nl>
To: "Edmon" <edmon@neteka.com>
cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points 
In-reply-to: Your message of Tue, 22 Jan 2002 15:51:04 -0500.
             <006301c1a386$83d4efc0$0601a8c0@neteka.com> 
Date: Wed, 23 Jan 2002 09:39:17 +0100
From: Jaap Akkerhuis <jaap@sidn.nl>
Sender: owner-idn@ops.ietf.org
Precedence: bulk


    Hi Patrik,
    
    Additional and optional character equivalence preparation by zone is
    possible.

But very undesirable. It will be very had to explain why the matching
is different in different zones. And I predict that when there are
conflicts about the names and they are caused by these different
matching rules, the lawyers will care less about the explanation.

Don't go this road!

	jaap



From owner-idn@ops.ietf.org  Wed Jan 23 05:05:51 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04757
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 05:05:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TK6E-0007Nj-00
	for idn-data@psg.com; Wed, 23 Jan 2002 01:53:46 -0800
Received: from twnic.net.tw ([211.72.210.250])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TK6D-0007Na-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 01:53:45 -0800
Received: from twnic.net.tw (pc160.twnic.net.tw [211.72.211.160])
	by twnic.net.tw (8.9.3/8.9.3) with ESMTP id RAA32292;
	Wed, 23 Jan 2002 17:53:25 +0800
Message-ID: <3C4E8931.6080908@twnic.net.tw>
Date: Wed, 23 Jan 2002 17:58:09 +0800
From: Erin Chen <erin@twnic.net.tw>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Paul Hoffman / IMC <phoffman@imc.org>
CC: Kenny Huang <huangk@alum.sinica.edu>, IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <p05101204b870ab94166d@[165.227.249.20]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Paul,

In the other word,  if  do not prohibits CJK code points,
the standard also shall hurt CDN requirements.

So, We have no choice but to prohibit CJK code points temperarily.
Untill the proper or better rule comes out which will not let CJK hurt 
each other..

Erin Chen

Paul Hoffman / IMC wrote:

> At 10:29 AM +0800 1/20/02, Kenny Huang wrote:
>
>> It implies there will be no Chinese domain name services until there
>> is other solution proposed and agreed by the Working Group.
>
>
> The WG should note that this proposal prohibits Japanese and Korean 
> names as well.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium






From owner-idn@ops.ietf.org  Wed Jan 23 05:22:01 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04912
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 05:22:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TKL0-0007gj-00
	for idn-data@psg.com; Wed, 23 Jan 2002 02:09:02 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TKKz-0007gC-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 02:09:01 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA16288;
	Wed, 23 Jan 2002 11:08:52 +0100 (MET)
Date: Wed, 23 Jan 2002 11:08:19 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Edmon <edmon@neteka.com>, Masahiro Sekiguchi <seki@jp.fujitsu.com>,
        IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <1334484.1011784099@localhost>
In-Reply-To: <006301c1a386$83d4efc0$0601a8c0@neteka.com>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
 <p05101200b870b1d08c87@[165.227.249.20]>
 <001601c1a28c$208fca20$4007738c@q.j.tw>
 <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp>
 <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-22 15.51 -0500 Edmon <edmon@neteka.com> wrote:

> This is not true. As long as the .cn DNS does the matching internally and
> provide a consistent response, why would "all" servers in the world need
> to be able to fulfil the matchings?  If you are arguing how the
> application then use the information to connect to the destination
> server, thats another issue.  But by zone rules are possible.

No, because you will have a caching DNS server which also have to be able
to do matchings for things in the .cn TLD. This means that any caching DNS
server have to have the complete set of rules used in all zones in the DNS.

   paf




From owner-idn@ops.ietf.org  Wed Jan 23 06:59:10 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05921
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 06:59:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TLsa-0009Rl-00
	for idn-data@psg.com; Wed, 23 Jan 2002 03:47:48 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TLsZ-0009Rf-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 03:47:47 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA02224;
	Wed, 23 Jan 2002 12:46:25 +0100 (MET)
Date: Wed, 23 Jan 2002 12:43:19 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Erin Chen <erin@twnic.net.tw>, "Paul Hoffman / IMC" <phoffman@imc.org>
cc: Kenny Huang <huangk@alum.sinica.edu>, IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <1676461.1011789799@localhost>
In-Reply-To: <3C4E8931.6080908@twnic.net.tw>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-23 17.58 +0800 Erin Chen <erin@twnic.net.tw> wrote:

> In the other word,  if  do not prohibits CJK code points,
> the standard also shall hurt CDN requirements.
> 
> So, We have no choice but to prohibit CJK code points temperarily.
> Untill the proper or better rule comes out which will not let CJK hurt
> each other..

The problem with CJK codepoints and the SC/TC problems everyone talks about
is the unification which is done in the Unicode character set.

Just because in Unicode, the same character have the same codepoint
regardless of the language for CJK codepoints, there is no way to compare
two codepoints and say that they sometimes are different and sometimes not.

The Unicode tables are approved by the Unicode Consortium and ISO, and we
can not in the IETF "undo" that unification procedure.

This is the reason why we rely on other standard organizations to do "the
right thing". They have defined that when only comparing two characters, a
given codepoint in a normalized Unicode string is to be equal (or not
equal) with according to the matching rules Unicode are defining.

This means further that if one enter a string in Unicode, one will _NOT_
know whether SC or TC was used.


So, given this unification which _already_is_a_done_deal_, the matching
algorithms which are more "clever" have to have metadata part from the
query string itself, such as language, culture, original script used etc.

We can _not_ do these context-sensitive matchings in the DNS for reasons
which have been stated on this mailing list for the last year, over and
over and over again.

Instead, the IETF have started (in the Applications Area) look into a
lookup system which _can_ handle context-sensitive matchings.

So, given Unicode as character set, context-sensitive matchings have to be
done where one can pass around a context and not only a query string.

And this is NOT the DNS.

    paf




From owner-idn@ops.ietf.org  Wed Jan 23 07:03:33 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05973
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 07:03:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TLzy-0009bE-00
	for idn-data@psg.com; Wed, 23 Jan 2002 03:55:26 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TLzs-0009b7-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 03:55:21 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0NBsF417503;
	Wed, 23 Jan 2002 19:54:15 +0800 (CST)
Message-ID: <00c901c1a404$3258f640$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "Edmon" <edmon@neteka.com>, "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp> <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com> <1334484.1011784099@localhost>
Subject: Re: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 19:50:42 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "Edmon" <edmon@neteka.com>; "Masahiro Sekiguchi" <seki@jp.fujitsu.com>;
"IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 6:08 PM
Subject: Re: [idn] Prohibit CDN code points


> --On 2002-01-22 15.51 -0500 Edmon <edmon@neteka.com> wrote:
>
> > This is not true. As long as the .cn DNS does the matching internally
and
> > provide a consistent response, why would "all" servers in the world need
> > to be able to fulfil the matchings?  If you are arguing how the
> > application then use the information to connect to the destination
> > server, thats another issue.  But by zone rules are possible.
>
> No, because you will have a caching DNS server which also have to be able
> to do matchings for things in the .cn TLD. This means that any caching DNS
> server have to have the complete set of rules used in all zones in the
DNS.
>

         It is right, cache DNS will cause some problems. But the caching
DNS need not only to have the complete set of rules used in authorized zone
DNS . If  the caching DNS use the matching rule with the capability of
differentiation  more than authorized zone server, it will work too.
         It is one of the possible solution in some particular condition but
this is not the current issue of this thread.
L.M.Tseng






From owner-idn@ops.ietf.org  Wed Jan 23 07:38:39 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06344
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 07:38:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TMXb-000AJ7-00
	for idn-data@psg.com; Wed, 23 Jan 2002 04:30:11 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TMXa-000AJ1-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 04:30:10 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id NAA09681;
	Wed, 23 Jan 2002 13:29:12 +0100 (MET)
Date: Wed, 23 Jan 2002 13:28:09 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: "=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?=" <tsenglm@cc.ncu.edu.tw>,
        Edmon <edmon@neteka.com>, Masahiro Sekiguchi <seki@jp.fujitsu.com>,
        IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <1837891.1011792489@localhost>
In-Reply-To: <00c901c1a404$3258f640$4007738c@q.j.tw>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
 <p05101200b870b1d08c87@[165.227.249.20]>
 <001601c1a28c$208fca20$4007738c@q.j.tw>
 <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp>
 <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com>
 <1334484.1011784099@localhost> <00c901c1a404$3258f640$4007738c@q.j.tw>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-23 19.50 +0800
"=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<tsenglm@cc.ncu.edu.tw> wrote:

>          It is right, cache DNS will cause some problems. But the caching
> DNS need not only to have the complete set of rules used in authorized
> zone DNS . If  the caching DNS use the matching rule with the capability
> of differentiation  more than authorized zone server, it will work too.

No, that is wrong. The caching server need to know the matching rules, or,
you might do matching in the cache which should not be done because of a
local rule in the domain.

   paf




From owner-idn@ops.ietf.org  Wed Jan 23 07:54:07 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06538
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 07:54:06 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TMoU-000AgZ-00
	for idn-data@psg.com; Wed, 23 Jan 2002 04:47:38 -0800
Received: from [211.254.82.194] (helo=spsoft.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TMoT-000AgT-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 04:47:38 -0800
Received: (from newcat@localhost)
	by spsoft.co.kr (8.10.0/8.10.0) id g0NClXq10148
	for idn@ops.ietf.org; Wed, 23 Jan 2002 21:47:33 +0900
Date: Wed, 23 Jan 2002 21:47:33 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <20020123214733.A9627@spsoft.co.kr>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw> <1676461.1011789799@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <1676461.1011789799@localhost>
User-Agent: Mutt/1.3.23i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Wed, Jan 23, 2002 at 12:43:19PM +0100, Patrik F?ltstr?m wrote:
> Just because in Unicode, the same character have the same codepoint
> regardless of the language for CJK codepoints, there is no way to compare
> two codepoints and say that they sometimes are different and sometimes not.
> 
> The Unicode tables are approved by the Unicode Consortium and ISO, and we
> can not in the IETF "undo" that unification procedure.
> 
> This is the reason why we rely on other standard organizations to do "the
> right thing". They have defined that when only comparing two characters, a
> given codepoint in a normalized Unicode string is to be equal (or not
> equal) with according to the matching rules Unicode are defining.
> 
> This means further that if one enter a string in Unicode, one will _NOT_
> know whether SC or TC was used.

Dear Patrik Faltstrom,

Your last statement does not exactly describe TC/SC issue. Following may
explain TC/SC issue better;

"If one enter a string in Unicode, one may or may not know whether TC or
SC was used. It depends both on his language in mind when entering that 
string and on his knowledge about characters."

Dear all members,

What about having additional prefix(es) for extension like TC/SC issue ? 
For example, az-- for normal IDNA and bz-- for chinese-extension IDNA 
and so forth. It may serve as an context information or language tag.

Regards

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Wed Jan 23 08:05:14 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07080
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 08:05:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TMy5-000Ax0-00
	for idn-data@psg.com; Wed, 23 Jan 2002 04:57:33 -0800
Received: from [211.254.82.194] (helo=spsoft.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TMy4-000Awt-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 04:57:32 -0800
Received: (from newcat@localhost)
	by spsoft.co.kr (8.10.0/8.10.0) id g0NCvSU10196
	for idn@ops.ietf.org; Wed, 23 Jan 2002 21:57:28 +0900
Date: Wed, 23 Jan 2002 21:57:28 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <20020123215728.B9627@spsoft.co.kr>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp> <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com> <1334484.1011784099@localhost> <00c901c1a404$3258f640$4007738c@q.j.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <00c901c1a404$3258f640$4007738c@q.j.tw>
User-Agent: Mutt/1.3.23i
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Tseng,

Please correct me if I am wrong. As far as I know, you are not going to 
add more rules to DNS server. Instead, some IDNA implementations may have 
more features to comply with CDN requirement. But, this specific thread
is about whether it is good or not to make DNS server having language 
depending features. So, your answers on this specific thread made me
be totally confused.

My best regards

On Wed, Jan 23, 2002 at 07:50:42PM +0800, tsenglm@ͪ������.����.tw wrote:
> 
> ----- Original Message -----
> From: "Patrik F??ltstr??m" <paf@cisco.com>
> To: "Edmon" <edmon@neteka.com>; "Masahiro Sekiguchi" <seki@jp.fujitsu.com>;
> "IETF-IDN" <idn@ops.ietf.org>
> Sent: Wednesday, January 23, 2002 6:08 PM
> Subject: Re: [idn] Prohibit CDN code points
> 
> 
> > --On 2002-01-22 15.51 -0500 Edmon <edmon@neteka.com> wrote:
> >
> > > This is not true. As long as the .cn DNS does the matching internally
> and
> > > provide a consistent response, why would "all" servers in the world need
> > > to be able to fulfil the matchings?  If you are arguing how the
> > > application then use the information to connect to the destination
> > > server, thats another issue.  But by zone rules are possible.
> >
> > No, because you will have a caching DNS server which also have to be able
> > to do matchings for things in the .cn TLD. This means that any caching DNS
> > server have to have the complete set of rules used in all zones in the
> DNS.
> >
> 
>          It is right, cache DNS will cause some problems. But the caching
> DNS need not only to have the complete set of rules used in authorized zone
> DNS . If  the caching DNS use the matching rule with the capability of
> differentiation  more than authorized zone server, it will work too.
>          It is one of the possible solution in some particular condition but
> this is not the current issue of this thread.
> L.M.Tseng
> 
> 
> 

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Wed Jan 23 08:31:40 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07755
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 08:31:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TNJU-000BQc-00
	for idn-data@psg.com; Wed, 23 Jan 2002 05:19:40 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TNJT-000BQW-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 05:19:39 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA20600;
	Wed, 23 Jan 2002 14:19:28 +0100 (MET)
Date: Wed, 23 Jan 2002 14:18:01 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: YangWoo Ko <newcat@spsoft.co.kr>, IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <2017401.1011795481@localhost>
In-Reply-To: <20020123214733.A9627@spsoft.co.kr>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw>
 <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-23 21.47 +0900 YangWoo Ko <newcat@spsoft.co.kr> wrote:

> Your last statement does not exactly describe TC/SC issue. Following may
> explain TC/SC issue better;
> 
> "If one enter a string in Unicode, one may or may not know whether TC or
> SC was used. It depends both on his language in mind when entering that 
> string and on his knowledge about characters."

Correct.

> Dear all members,
> 
> What about having additional prefix(es) for extension like TC/SC issue ? 
> For example, az-- for normal IDNA and bz-- for chinese-extension IDNA 
> and so forth. It may serve as an context information or language tag.

How do you match between one string which uses az--<foo>.com and
bz--<foo>.com where "<foo>" stands for the term "foo" but encoded?

And, yes, you can do this, but as i have pointed out before, this means
every server needs to know about all matching algorithms.

I.e. if you open the box of "problems" with Unicode, you will find that the
SC/TC problem is only one of them. Only one. I guess we have some 20-30
other problems which are similar to the SC/TC, i.e. problems because of
unification or non-unification in Unicode.

So, you will see an explosion of matching rules.

Reason we see this about SC/TC is that that happen to be the problem space
we discuss at the moment. We could aswell discuss the problems with
adiaeresis in the countries and languages which uses it.

My conclusion is the same, every server need to have knowledge about how to
handle all encodings.

   paf




From owner-idn@ops.ietf.org  Wed Jan 23 09:36:57 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10439
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 09:36:56 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TOKZ-000Cvo-00
	for idn-data@psg.com; Wed, 23 Jan 2002 06:24:51 -0800
Received: from [211.254.82.194] (helo=spsoft.co.kr)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TOKY-000Cvi-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 06:24:50 -0800
Received: (from newcat@localhost)
	by spsoft.co.kr (8.10.0/8.10.0) id g0NEOjS10809
	for idn@ops.ietf.org; Wed, 23 Jan 2002 23:24:45 +0900
Date: Wed, 23 Jan 2002 23:24:45 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <20020123232445.C9627@spsoft.co.kr>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw> <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr> <2017401.1011795481@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <2017401.1011795481@localhost>
User-Agent: Mutt/1.3.23i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Wed, Jan 23, 2002 at 02:18:01PM +0100, Patrik F?ltstr?m wrote:
> > Dear all members,
> > 
> > What about having additional prefix(es) for extension like TC/SC issue ? 
> > For example, az-- for normal IDNA and bz-- for chinese-extension IDNA 
> > and so forth. It may serve as an context information or language tag.
> 
> And, yes, you can do this, but as i have pointed out before, this means
> every server needs to know about all matching algorithms.

I am talking about IDNA. With IDNA, we do not add matching algorithm
to any server. Some client may try "az--" and it fails, it may try 
"bz--" with TC/SC feature-enabled preprocessing, while others only 
try "az--". I know this may look quite ugly. But, current IDN proposal 
seems premature in terms of internationalization at least from the Chinese 
people's point of view.

Allowing Unicode be used where only ASCII was used before is not enough 
for internationalization. We should prepare an enough room in which
localization can be done while complying with internationalized standards.

> I.e. if you open the box of "problems" with Unicode, you will find that the
> SC/TC problem is only one of them. Only one. 

Yes, I totally agree.

> I guess we have some 20-30
> other problems which are similar to the SC/TC, i.e. problems because of
> unification or non-unification in Unicode.

Why are we going to hide and ignore problems even though we know they are
there ?

> My conclusion is the same, every server need to have knowledge about how to
> handle all encodings.

My conclusion is the same with yours.

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Wed Jan 23 11:07:49 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13960
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 11:07:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TPfw-000Esr-00
	for idn-data@psg.com; Wed, 23 Jan 2002 07:51:00 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TPfv-000Esl-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 07:51:00 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA20919;
	Wed, 23 Jan 2002 16:50:47 +0100 (MET)
Date: Wed, 23 Jan 2002 16:49:10 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: YangWoo Ko <newcat@spsoft.co.kr>, IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <2561536.1011804550@localhost>
In-Reply-To: <20020123232445.C9627@spsoft.co.kr>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw>
 <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr>
 <2017401.1011795481@localhost> <20020123232445.C9627@spsoft.co.kr>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-23 23.24 +0900 YangWoo Ko <newcat@spsoft.co.kr> wrote:

> I am talking about IDNA. With IDNA, we do not add matching algorithm
> to any server. Some client may try "az--" and it fails, it may try 
> "bz--" with TC/SC feature-enabled preprocessing, while others only 
> try "az--". I know this may look quite ugly. But, current IDN proposal 
> seems premature in terms of internationalization at least from the
> Chinese  people's point of view.

The problem occur when you use a language like for example Swedish. I can
type something in Swedish, and it should match something in Norwegian. It
might also match something in German, and English. What about "color" and
"colour" matching when you use US-english and UK-englisg?

So, my resolver library encode in some IDNA-like fashion the query in all
of the languages above, and then try them one at a time until a match is
found.

I call that guessing, and not something the DNS is made for, very efficient
in doing and something we in the IETF repeatedly have said "No" to many
times.

Just because the DNS is a lookup system where a client calculate a key,
that key is sent to the mesh of servers, and a result is returned.

The alternative would be to have the servers understand that UK-Enlish and
US-English is "almost" the same, and they are able to match ab-<color> with
bc-<colour>. Should ab-<colour> match bc-<colour>? If not, then ab-<color>
is the same as bc-<colour> which in turn is different from ab-<colour>.
This means we will/can get a registrant which register ab-<colour> and one
which register bc-<colour> but noone at that time register ab-<color>
because bc-<colour> is already taken, and we require global uniqueness.

I.e. if you _want_ to go down this path, you should look at the RFC's about
definition of lanaguge codes, and think about how you should do something
which can handle those languages. Then, hopefully, you will be convinced
that this is not a path that can be followed.

Multiple lookup in DNS is not something that will be accepted, and multiple
matching algorithms will not work either.

> Allowing Unicode be used where only ASCII was used before is not enough 
> for internationalization. We should prepare an enough room in which
> localization can be done while complying with internationalized standards.

You have to differ between localization and internationalization. It is
wellknown that IDN is _not_ about localization.

>> I.e. if you open the box of "problems" with Unicode, you will find that
>> the SC/TC problem is only one of them. Only one. 
> 
> Yes, I totally agree.
> 
>> I guess we have some 20-30
>> other problems which are similar to the SC/TC, i.e. problems because of
>> unification or non-unification in Unicode.
> 
> Why are we going to hide and ignore problems even though we know they are
> there ?

Because you can not solve them using Unicode and non-context-matchings
which is what we do in DNS.

>> My conclusion is the same, every server need to have knowledge about how
>> to handle all encodings.
> 
> My conclusion is the same with yours.

Good.

  paf




From owner-idn@ops.ietf.org  Wed Jan 23 11:09:19 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14038
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 11:09:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TPl0-000Ez9-00
	for idn-data@psg.com; Wed, 23 Jan 2002 07:56:14 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TPkz-000Ez3-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 07:56:13 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA13338;
	Wed, 23 Jan 2002 07:55:54 -0800
Message-Id: <5.1.0.14.2.20020123074339.032c9de0@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 23 Jan 2002 07:47:12 -0800
To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= <paf@cisco.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Prohibit CDN code points
Cc: Erin Chen <erin@twnic.net.tw>, "Paul Hoffman / IMC" <phoffman@imc.org>,
        Kenny Huang <huangk@alum.sinica.edu>, IETF-IDN <idn@ops.ietf.org>
In-Reply-To: <1676461.1011789799@localhost>
References: <3C4E8931.6080908@twnic.net.tw>
 <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <p05101204b870ab94166d@[165.227.249.20]>
 <3C4E8931.6080908@twnic.net.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA14038

At 12:43 PM 1/23/2002 +0100, Patrik F�ltstr�m wrote:
>The Unicode tables are approved by the Unicode Consortium and ISO, and we
>can not in the IETF "undo" that unification procedure.

A variation to the cliche "if the only tool you have is a hammer, then 
everything starts looking like a nail" applies to this working group:  If 
the only venue you have is an IETF working group, then everything starts 
looking as if it is within scope of the working group.

As Patrik has once again reminded everyone, this entire discussion is 
entirely outside the scope of this working group.  We can choose to use 
Unicode or not, but we cannot "fix" it.

The task of this working group is to find a way for the DNS to use 
character strings that are more diverse than ASCII.  As has been often 
explained, character strings are not the same as words.  Comparing strings 
is different from comparing words.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Wed Jan 23 11:21:33 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14677
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 11:21:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TPxx-000FGb-00
	for idn-data@psg.com; Wed, 23 Jan 2002 08:09:37 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TPxu-000FGS-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 08:09:35 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0NG8j424104;
	Thu, 24 Jan 2002 00:08:45 +0800 (CST)
Message-ID: <001e01c1a427$b9c28f60$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "YangWoo Ko" <newcat@spsoft.co.kr>, "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp> <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com> <1334484.1011784099@localhost> <00c901c1a404$3258f640$4007738c@q.j.tw> <20020123215728.B9627@spsoft.co.kr>
Subject: Re: [idn] Prohibit CDN code points
Date: Thu, 24 Jan 2002 00:05:01 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Ko:
        You are right. In current discussion , my proposal is not interested
in DNS server approach. I talk it , because some people worry about the
prohibitation of CDN code points in IDNA will let some area can not work.
So, I give some solutions to let them can be done by area/language TLD
dependent name solving to reduce the troubles of CDN delay.
        The second reason is that some client has the caching feature, but
the caching client actually need not only just the same matching rule as
authorized zone DNS if we assume  this client will query the authorized zone
DNS at first or refresh time. I think this description can help to remove
some misunderstanding of current BIND DNS cache. For example:
1.Assume authorized zone server is case insensitive and the record:
bq--xyz   A  1.2.3.4

2.Assume client is case sensitive in matching  records in local cache. These
query will be get and copied result from authorized server.
bq--xYz   A  1.2.3.4
bq--XYZ   A  1.2.3.4
bq--xyz   A  1.2.3.4

  That means if caching client has capability of differentiating than zone
server will still work.
  To force the query information to lower case and store it in local client
is not so necessary to a case insensitive DNS server.
That is my point about IDNA nameprep.

L.M.Tseng
----- Original Message -----
From: "YangWoo Ko" <newcat@spsoft.co.kr>
To: "IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 8:57 PM
Subject: Re: [idn] Prohibit CDN code points


> Dear Tseng,
>
> Please correct me if I am wrong. As far as I know, you are not going to
> add more rules to DNS server. Instead, some IDNA implementations may have
> more features to comply with CDN requirement. But, this specific thread
> is about whether it is good or not to make DNS server having language
> depending features. So, your answers on this specific thread made me
> be totally confused.
>
> My best regards
>
> On Wed, Jan 23, 2002 at 07:50:42PM +0800, tsenglm@計網中心.中大.tw wrote:
> >
> > ----- Original Message -----
> > From: "Patrik F??ltstr??m" <paf@cisco.com>
> > To: "Edmon" <edmon@neteka.com>; "Masahiro Sekiguchi"
<seki@jp.fujitsu.com>;
> > "IETF-IDN" <idn@ops.ietf.org>
> > Sent: Wednesday, January 23, 2002 6:08 PM
> > Subject: Re: [idn] Prohibit CDN code points
> >
> >
> > > --On 2002-01-22 15.51 -0500 Edmon <edmon@neteka.com> wrote:
> > >
> > > > This is not true. As long as the .cn DNS does the matching
internally
> > and
> > > > provide a consistent response, why would "all" servers in the world
need
> > > > to be able to fulfil the matchings?  If you are arguing how the
> > > > application then use the information to connect to the destination
> > > > server, thats another issue.  But by zone rules are possible.
> > >
> > > No, because you will have a caching DNS server which also have to be
able
> > > to do matchings for things in the .cn TLD. This means that any caching
DNS
> > > server have to have the complete set of rules used in all zones in the
> > DNS.
> > >
> >
> >          It is right, cache DNS will cause some problems. But the
caching
> > DNS need not only to have the complete set of rules used in authorized
zone
> > DNS . If  the caching DNS use the matching rule with the capability of
> > differentiation  more than authorized zone server, it will work too.
> >          It is one of the possible solution in some particular condition
but
> > this is not the current issue of this thread.
> > L.M.Tseng
> >
> >
> >
>
> --
> /*------------------------------------------------
> YangWoo Ko : newcat@spsoft.co.kr
> We Invent Enterprise Software Solutions
> and Make You Secure & Powerful.
> ------------------------------------------------*/
>




From owner-idn@ops.ietf.org  Wed Jan 23 11:27:46 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14949
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 11:27:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TQ9R-000FY7-00
	for idn-data@psg.com; Wed, 23 Jan 2002 08:21:29 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TQ9Q-000FY1-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 08:21:29 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA26973;
	Wed, 23 Jan 2002 17:21:15 +0100 (MET)
Date: Wed, 23 Jan 2002 17:19:37 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: "Mark Davis (jtcsv)" <mark.davis@jtcsv.com>,
        YangWoo Ko <newcat@spsoft.co.kr>, IETF-IDN <idn@ops.ietf.org>,
        Kenneth Whistler <kenw@sybase.com>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <2671163.1011806377@localhost>
In-Reply-To: <006701c1a422$8b1cfa60$08d8ea0c@c1340594a>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw>
 <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr>
 <2017401.1011795481@localhost> <006701c1a422$8b1cfa60$08d8ea0c@c1340594a>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-23 07.27 -0800 "Mark Davis (jtcsv)" <mark.davis@jtcsv.com>
wrote:

> The TC/SC problem can be dealt with by means of the registration of a
> small number of additional names. Little different in kind from
> registering both theatre.com and theater.com, or aarborg.com and
> a<ring>rborg.com. While theoretically someone could have 5-character name
> with 32 combinations of TC/SC, in practice nobody has proven this to be a
> real problem, or even provided any evidence whatsoever that clients will
> in fact be confused.

Exactly!

Thanks Mark for bringing this up again.

I forgot to point this out.

  paf




From owner-idn@ops.ietf.org  Wed Jan 23 11:36:27 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15362
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 11:36:26 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TQCG-000Fcu-00
	for idn-data@psg.com; Wed, 23 Jan 2002 08:24:24 -0800
Received: from imo-m06.mx.aol.com ([64.12.136.161])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TQCF-000Fcn-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 08:24:23 -0800
Received: from DougEwell2@cs.com
	by imo-m06.mx.aol.com (mail_out_v31_r1.25.) id i.c5.1cd8c61e (3699);
	Wed, 23 Jan 2002 11:23:39 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <c5.1cd8c61e.29803d8b@cs.com>
Date: Wed, 23 Jan 2002 11:23:39 EST
Subject: Re: [idn] Prohibit CDN code points
To: idn@ops.ietf.org
CC: huangk@alum.sinica.edu, tsenglm@cc.ncu.edu.tw, paf@cisco.com,
        seki@jp.fujitsu.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-01-23 0:21:08 Pacific Standard Time, 
huangk@alum.sinica.edu writes:

> Theoretically, 1-1 TC/SC mapping, ASCII uppercase/lowercase mapping or
> any table mapping are all belong to the same computing algorithm. From 
> computer science point of view, they are the same algorithm.

Every Latin uppercase letter maps unambiguously to a single Latin lowercase 
letter, regardless of context or meaning.  My understanding was that this is 
not true for every TC/SC character.  If it is, then please accept my 
apologies, but you will also have to convince the rest of the list.

> Your question should address to the souce of the table (1-1 only), not to 
> the computing algorithm.

If everything is 1-to-1 between TC and SC, the algorithm is trivial.  I was 
talking about the algorithm that would be necessary to do TC/SC conversion in 
the case of 1-to-many or many-to-1 conversions.  But, since you say there are 
none, I guess we can proceed with implementing the tables.

-Doug Ewell
 Fullerton, California



From owner-idn@ops.ietf.org  Wed Jan 23 11:42:21 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15722
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 11:42:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TQKt-000Fqm-00
	for idn-data@psg.com; Wed, 23 Jan 2002 08:33:19 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TQKr-000FqX-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 08:33:18 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0NGX9428749;
	Thu, 24 Jan 2002 00:33:09 +0800 (CST)
Message-ID: <002d01c1a42b$20fd3a60$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "YangWoo Ko" <newcat@spsoft.co.kr>, "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw> <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr> <2017401.1011795481@localhost> <20020123232445.C9627@spsoft.co.kr>
Subject: Re: [idn] Prohibit CDN code points
Date: Thu, 24 Jan 2002 00:29:27 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "YangWoo Ko" <newcat@spsoft.co.kr>
To: "IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 10:24 PM
Subject: Re: [idn] Prohibit CDN code points
...
>
> I am talking about IDNA. With IDNA, we do not add matching algorithm
> to any server. Some client may try "az--" and it fails, it may try
> "bz--" with TC/SC feature-enabled preprocessing, while others only
> try "az--". I know this may look quite ugly. But, current IDN proposal
> seems premature in terms of internationalization at least from the Chinese
> people's point of view.
>
> Allowing Unicode be used where only ASCII was used before is not enough
> for internationalization. We should prepare an enough room in which
> localization can be done while complying with internationalized standards.
>
          I  totally agree with these , whether the UNICODE is unified or
not , it is not the issue in this thread, we want to know where is the
interface or room in IDNA and through which  the localization results and
information  can be passed.

L.M.Tseng




From owner-idn@ops.ietf.org  Wed Jan 23 12:02:15 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16420
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 12:02:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TQgY-000GNT-00
	for idn-data@psg.com; Wed, 23 Jan 2002 08:55:42 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TQgX-000GNM-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 08:55:41 -0800
Received: from iis.sinica.edu.tw (i2ot1 [140.109.21.153])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g0NGnCj14390;
	Thu, 24 Jan 2002 00:49:13 +0800 (CST)
Message-ID: <3C4EEAF7.1E2D57DB@iis.sinica.edu.tw>
Date: Thu, 24 Jan 2002 00:55:19 +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: Patrik =?big5?B?RuRsdHN0cvZt?= <paf@cisco.com>,
        Erin Chen 
	<erin@twnic.net.tw>, Paul Hoffman / IMC <phoffman@imc.org>,
        Kenny Huang 
	<huangk@alum.sinica.edu>, IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
References: <3C4E8931.6080908@twnic.net.tw>
	 <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
	 <p05101204b870ab94166d@[165.227.249.20]>
	 <3C4E8931.6080908@twnic.net.tw> <5.1.0.14.2.20020123074339.032c9de0@127.0.0.1>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Yes, Unicode is the source of problems for IDNs with Han characters. But, did
anyone
ask IDN WG to undo anything? Why is it a problem here?

If you propose not to adopt Unicode as part of IDNA as an alternative of doing
nothing
to help people using Han characters. We appreciate that.

-- Janming

Dave Crocker �g�J�G

> At 12:43 PM 1/23/2002 +0100, Patrik F�ltstr�m wrote:
> >The Unicode tables are approved by the Unicode Consortium and ISO, and we
> >can not in the IETF "undo" that unification procedure.
>
> A variation to the cliche "if the only tool you have is a hammer, then
> everything starts looking like a nail" applies to this working group:  If
> the only venue you have is an IETF working group, then everything starts
> looking as if it is within scope of the working group.
>
> As Patrik has once again reminded everyone, this entire discussion is
> entirely outside the scope of this working group.  We can choose to use
> Unicode or not, but we cannot "fix" it.
>
> The task of this working group is to find a way for the DNS to use
> character strings that are more diverse than ASCII.  As has been often
> explained, character strings are not the same as words.  Comparing strings
> is different from comparing words.
>
> d/
>
> ----------
> Dave Crocker  <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Wed Jan 23 12:05:32 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16498
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 12:05:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TQjP-000GT8-00
	for idn-data@psg.com; Wed, 23 Jan 2002 08:58:39 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TQjO-000GSu-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 08:58:38 -0800
Received: from iis.sinica.edu.tw (i2ot1 [140.109.21.153])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g0NGrcj15911;
	Thu, 24 Jan 2002 00:53:38 +0800 (CST)
Message-ID: <3C4EEBFF.C8F75801@iis.sinica.edu.tw>
Date: Thu, 24 Jan 2002 00:59:43 +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: Patrik =?big5?B?RuRsdHN0cvZt?= <paf@cisco.com>
CC: YangWoo Ko <newcat@spsoft.co.kr>, IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
	 <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw>
	 <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr>
	 <2017401.1011795481@localhost> <20020123232445.C9627@spsoft.co.kr> <2561536.1011804550@localhost>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


There is a big difference between "IDNA did not solve all our problems" and
"IDNA
creates problem for our community".

-- Janming

Patrik F�ltstr�m �g�J�G

> --On 2002-01-23 23.24 +0900 YangWoo Ko <newcat@spsoft.co.kr> wrote:
>
> > I am talking about IDNA. With IDNA, we do not add matching algorithm
> > to any server. Some client may try "az--" and it fails, it may try
> > "bz--" with TC/SC feature-enabled preprocessing, while others only
> > try "az--". I know this may look quite ugly. But, current IDN proposal
> > seems premature in terms of internationalization at least from the
> > Chinese  people's point of view.
>
> The problem occur when you use a language like for example Swedish. I can
> type something in Swedish, and it should match something in Norwegian. It
> might also match something in German, and English. What about "color" and
> "colour" matching when you use US-english and UK-englisg?
>
> So, my resolver library encode in some IDNA-like fashion the query in all
> of the languages above, and then try them one at a time until a match is
> found.
>
> I call that guessing, and not something the DNS is made for, very efficient
> in doing and something we in the IETF repeatedly have said "No" to many
> times.
>
> Just because the DNS is a lookup system where a client calculate a key,
> that key is sent to the mesh of servers, and a result is returned.
>
> The alternative would be to have the servers understand that UK-Enlish and
> US-English is "almost" the same, and they are able to match ab-<color> with
> bc-<colour>. Should ab-<colour> match bc-<colour>? If not, then ab-<color>
> is the same as bc-<colour> which in turn is different from ab-<colour>.
> This means we will/can get a registrant which register ab-<colour> and one
> which register bc-<colour> but noone at that time register ab-<color>
> because bc-<colour> is already taken, and we require global uniqueness.
>
> I.e. if you _want_ to go down this path, you should look at the RFC's about
> definition of lanaguge codes, and think about how you should do something
> which can handle those languages. Then, hopefully, you will be convinced
> that this is not a path that can be followed.
>
> Multiple lookup in DNS is not something that will be accepted, and multiple
> matching algorithms will not work either.
>
> > Allowing Unicode be used where only ASCII was used before is not enough
> > for internationalization. We should prepare an enough room in which
> > localization can be done while complying with internationalized standards.
>
> You have to differ between localization and internationalization. It is
> wellknown that IDN is _not_ about localization.
>
> >> I.e. if you open the box of "problems" with Unicode, you will find that
> >> the SC/TC problem is only one of them. Only one.
> >
> > Yes, I totally agree.
> >
> >> I guess we have some 20-30
> >> other problems which are similar to the SC/TC, i.e. problems because of
> >> unification or non-unification in Unicode.
> >
> > Why are we going to hide and ignore problems even though we know they are
> > there ?
>
> Because you can not solve them using Unicode and non-context-matchings
> which is what we do in DNS.
>
> >> My conclusion is the same, every server need to have knowledge about how
> >> to handle all encodings.
> >
> > My conclusion is the same with yours.
>
> Good.
>
>   paf




From owner-idn@ops.ietf.org  Wed Jan 23 12:39:28 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17775
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 12:39:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TREc-000HEb-00
	for idn-data@psg.com; Wed, 23 Jan 2002 09:30:54 -0800
Received: from mail1.ics.ntts.co.jp ([202.32.24.45])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TREb-000HEU-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 09:30:53 -0800
Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0)
	id CAA27655; Thu, 24 Jan 2002 02:30:50 +0900 (JST)
Received: from daemon.inl.ntts.co.jp
	by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id g0NHUnM08784
	for <idn@ops.ietf.org>; Thu, 24 Jan 2002 02:30:49 +0900 (JST)
	(envelope-from yone@po.ntts.co.jp)
Received: (qmail 37496 invoked by alias); 24 Jan 2002 02:30:49 +0900
Received: (qmail 37474 invoked from network); 24 Jan 2002 02:30:48 +0900
Received: from daemon.inl.ntts.co.jp (HELO localhost)
  by daemon.inl.ntts.co.jp with SMTP; 24 Jan 2002 02:30:48 +0900
To: hoho@iis.sinica.edu.tw
Cc: idn@ops.ietf.org
Subject: Re: [idn] Prohibit CDN code points
In-Reply-To: <3C4EEAF7.1E2D57DB@iis.sinica.edu.tw>
References: <3C4E8931.6080908@twnic.net.tw>
	<5.1.0.14.2.20020123074339.032c9de0@127.0.0.1>
	<3C4EEAF7.1E2D57DB@iis.sinica.edu.tw>
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.1 (AOI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20020124023039J.yone@po.ntts.co.jp>
Date: Thu, 24 Jan 2002 02:30:39 +0900 (JST)
From: Yoshiro YONEYA <yone@po.ntts.co.jp>
X-Dispatcher: imput version 20000228(IM140)
Lines: 15
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

hoho,

From: hoho <hoho@iis.sinica.edu.tw>
Subject: Re: [idn] Prohibit CDN code points
Date: Thu, 24 Jan 2002 00:55:19 +0800

> Yes, Unicode is the source of problems for IDNs with Han characters. But, did
> anyone
> ask IDN WG to undo anything? Why is it a problem here?

You should read recent 4-6 months' mail archive of this mailing list.
Unicode is only one universal standard we can refer.

-- 
Yoshiro YONEYA <yone@po.ntts.co.jp>



From owner-idn@ops.ietf.org  Wed Jan 23 13:30:18 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19533
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 13:30:16 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TRwx-000ICX-00
	for idn-data@psg.com; Wed, 23 Jan 2002 10:16:43 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16TRww-000ICR-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 10:16:42 -0800
Message-ID: <002a01c1a43a$918a4160$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp> <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com> <1334484.1011784099@localhost>
Subject: [idn] Optional & Additional Character Equivalence Preparations by Zone
Date: Wed, 23 Jan 2002 13:19:55 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

----- Original Message -----
From: "Patrik F�ltstr�m" <paf@cisco.com>
> > This is not true. As long as the .cn DNS does the matching internally
and
> > provide a consistent response, why would "all" servers in the world need
> > to be able to fulfil the matchings?  If you are arguing how the
>
> No, because you will have a caching DNS server which also have to be able
> to do matchings for things in the .cn TLD. This means that any caching DNS
> server have to have the complete set of rules used in all zones in the
DNS.

But caching servers only cache the result of a query.
for example a domain request
<A><A'>.example
the .example ns would internally match it with
<a><a>.example
and reply with a positive response.
the caching server will therefore cache
<A><A'>.example
with the response.
If you are asking what happens if another request comes:
<a><A'>.example
then the answer is simple, it will consult the .example server again,
then it will cahce
<a><A'>.example
with the response.
So, I dont see why all the servers in the world needs to be able to handle
all additional matching rules.

Edmon




From owner-idn@ops.ietf.org  Wed Jan 23 13:34:53 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19688
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 13:34:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TS0X-000IGY-00
	for idn-data@psg.com; Wed, 23 Jan 2002 10:20:25 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16TS0V-000IGR-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 10:20:23 -0800
Message-ID: <003801c1a43b$138b3340$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: "Jaap Akkerhuis" <jaap@sidn.nl>
Cc: "=?big5?B?UGF0cmlrIEbkbHRzdHL2bQ==?=" <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <200201230839.g0N8dHi27877@bartok.sidn.nl>
Subject: Re: [idn] Prohibit CDN code points 
Date: Wed, 23 Jan 2002 13:23:36 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jaap,
But I dont think this is the real issue.  What I hear is that people want to
have an option to implement it and they want a set of standardized options.
I believe our job is to create the standardized set of options and allow
implementors to pick and choose.  If you think it is advisable to caution
the implementors of these options, that is another issue.
Edmon


----- Original Message -----
From: "Jaap Akkerhuis" <jaap@sidn.nl>
>     Hi Patrik,
>
>     Additional and optional character equivalence preparation by zone is
>     possible.
>
> But very undesirable. It will be very had to explain why the matching
> is different in different zones. And I predict that when there are
> conflicts about the names and they are caused by these different
> matching rules, the lawyers will care less about the explanation.
>
> Don't go this road!
>
> jaap
>




From owner-idn@ops.ietf.org  Wed Jan 23 13:43:08 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20081
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 13:43:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TSBo-000IYb-00
	for idn-data@psg.com; Wed, 23 Jan 2002 10:32:04 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16TSBn-000IYS-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 10:32:03 -0800
Message-ID: <006801c1a43c$b87430e0$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: <DougEwell2@cs.com>, <idn@ops.ietf.org>
Cc: <huangk@alum.sinica.edu>, <tsenglm@cc.ncu.edu.tw>, <paf@cisco.com>,
        <seki@jp.fujitsu.com>
References: <c5.1cd8c61e.29803d8b@cs.com>
Subject: Re: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 13:35:20 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: <DougEwell2@cs.com>
> If everything is 1-to-1 between TC and SC, the algorithm is trivial.  I
was
> talking about the algorithm that would be necessary to do TC/SC conversion
in
> the case of 1-to-many or many-to-1 conversions.  But, since you say there
are
> none, I guess we can proceed with implementing the tables.
>
It is possible to implement a 1-to-many or many-to-1 conversion.
All it is required is that all "equivalent" characters be matched as
"equivalent" in the authoritative DNS.
For example, a simple rule that says:
A = a = A' = a'  (note that there need not be a "primary" character)
This represents a 1-to-many or many-to-1 situation.
So, if a domain comes in:
aA'.example
it will be matched the same is if a domain:
Aa'.example
comes in.
This is just the matching rule within the DNS server and does not have to
affect any of the IDNA process.
That is, the user wil still see and know and react to whatever they typed in
and believed to be accessing.
It does not take anything away from being able to use multilingual
characters in the DNS.

Edmon





From owner-idn@ops.ietf.org  Wed Jan 23 13:57:25 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20581
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 13:57:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TSMh-000IpX-00
	for idn-data@psg.com; Wed, 23 Jan 2002 10:43:19 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TSMh-000IpR-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 10:43:19 -0800
Received: from BBThead.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id KAA19865;
	Wed, 23 Jan 2002 10:34:30 -0800
Message-Id: <5.1.0.14.2.20020123095614.03c7de98@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 23 Jan 2002 10:35:35 -0800
To: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Prohibit CDN code points
Cc: "YangWoo Ko" <newcat@spsoft.co.kr>, "IETF-IDN" <idn@ops.ietf.org>
In-Reply-To: <002d01c1a42b$20fd3a60$4007738c@q.j.tw>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <p05101204b870ab94166d@[165.227.249.20]>
 <3C4E8931.6080908@twnic.net.tw>
 <1676461.1011789799@localhost>
 <20020123214733.A9627@spsoft.co.kr>
 <2017401.1011795481@localhost>
 <20020123232445.C9627@spsoft.co.kr>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 12:29 AM 1/24/2002 +0800, 
=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= wrote:
>           I  totally agree with these , whether the UNICODE is unified or
>not , it is not the issue in this thread, we want to know where is the
>interface or room in IDNA and through which  the localization results and
>information  can be passed.

A standard that is focused on international interoperability cannot be the 
place for localization.

So, the place for what you are seeking is outside IDNA.  In terms of 
architecture, it is at a layer above IDNA.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Wed Jan 23 15:26:29 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23998
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 15:26:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TTpo-000KyI-00
	for idn-data@psg.com; Wed, 23 Jan 2002 12:17:28 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TTpn-000KyC-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 12:17:27 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id VAA01597;
	Wed, 23 Jan 2002 21:17:18 +0100 (MET)
Date: Wed, 23 Jan 2002 21:10:32 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Edmon <edmon@neteka.com>, Masahiro Sekiguchi <seki@jp.fujitsu.com>,
        IETF-IDN <idn@ops.ietf.org>
Subject: [idn] Re: Optional & Additional Character Equivalence Preparations by
 Zone
Message-ID: <3502503.1011820232@localhost>
In-Reply-To: <002a01c1a43a$918a4160$0601a8c0@neteka.com>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com>
 <p05101200b870b1d08c87@[165.227.249.20]>
 <001601c1a28c$208fca20$4007738c@q.j.tw>
 <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp>
 <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com>
 <1334484.1011784099@localhost> <002a01c1a43a$918a4160$0601a8c0@neteka.com>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-23 13.19 -0500 Edmon <edmon@neteka.com> wrote:

> But caching servers only cache the result of a query.
> for example a domain request
> <A><A'>.example
> the .example ns would internally match it with
> <a><a>.example
> and reply with a positive response.
> the caching server will therefore cache
> <A><A'>.example
> with the response.
> If you are asking what happens if another request comes:
> <a><A'>.example
> then the answer is simple, it will consult the .example server again,
> then it will cahce
> <a><A'>.example
> with the response.
> So, I dont see why all the servers in the world needs to be able to handle
> all additional matching rules.

It's not that easy. The result coming back is called an RR-Set, which means
all records which have the same owner. The responses are always treated in
groups of RR-Sets.

Now, given that we have one RR-Set which has different content on an
authoritative server from a caching server, read your favourite RFC's about
DNS Security.

Just don't go there.

     paf




From owner-idn@ops.ietf.org  Wed Jan 23 15:55:32 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25087
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 15:55:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TUIg-000Ldw-00
	for idn-data@psg.com; Wed, 23 Jan 2002 12:47:18 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16TUIf-000Ldq-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 12:47:17 -0800
Message-ID: <00c601c1a44f$936f4880$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]> <001601c1a28c$208fca20$4007738c@q.j.tw> <005701c1a2dd$07d9c930$6b6d230a@sysrap.cs.fujitsu.co.jp> <4607243.1011686361@localhost> <006301c1a386$83d4efc0$0601a8c0@neteka.com> <1334484.1011784099@localhost> <002a01c1a43a$918a4160$0601a8c0@neteka.com> <3502503.1011820232@localhost>
Subject: Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone
Date: Wed, 23 Jan 2002 15:50:13 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

So, at the end of the day, we point back to DNS Sec which creates the
problem.
I understand and know that there are potential problems but there are
possible solutions as well.  I think there are still a number of outstanding
issues in DNS Sec anyway.  So if this does create a potential issue,
shouldnt we raise the issue instead of shy away from it just because?  Is
this a positive engineering design practice?
Therefore, please dont say that it is not possible and advertise it as such
just like that.  It is possible but we just need to also take care of the
DNS Sec potential issues.
One of the possibility obviously is signing on the fly (perhaps less
advisable), the other the use of opt-in (still in progress... problematic
domains will have to opt-out), and thirdly to have sig rrs for all
permutations (readily possible).  There are more possibilities I believe, we
just need to document them for the implementor to choose from or advise one
particular method.  Afterall, I think it is important that we have a
standardized set of options to deal with the problem at hand (which is
perceived character equivalancy) and it should be within the DNS, but not
necessarily affecting the overall protocol.
With by Zone optional charprep mechanisms, we can achieve this.
Edmon


----- Original Message -----
From: "Patrik F�ltstr�m" <paf@cisco.com>
To: "Edmon" <edmon@neteka.com>; "Masahiro Sekiguchi" <seki@jp.fujitsu.com>;
"IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 3:10 PM
Subject: [idn] Re: Optional & Additional Character Equivalence Preparations
by Zone


> --On 2002-01-23 13.19 -0500 Edmon <edmon@neteka.com> wrote:
>
> > But caching servers only cache the result of a query.
> > for example a domain request
> > <A><A'>.example
> > the .example ns would internally match it with
> > <a><a>.example
> > and reply with a positive response.
> > the caching server will therefore cache
> > <A><A'>.example
> > with the response.
> > If you are asking what happens if another request comes:
> > <a><A'>.example
> > then the answer is simple, it will consult the .example server again,
> > then it will cahce
> > <a><A'>.example
> > with the response.
> > So, I dont see why all the servers in the world needs to be able to
handle
> > all additional matching rules.
>
> It's not that easy. The result coming back is called an RR-Set, which
means
> all records which have the same owner. The responses are always treated in
> groups of RR-Sets.
>
> Now, given that we have one RR-Set which has different content on an
> authoritative server from a caching server, read your favourite RFC's
about
> DNS Security.
>
> Just don't go there.
>
>      paf
>
>




From owner-idn@ops.ietf.org  Wed Jan 23 21:38:26 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02530
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 21:38:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TZUk-0002oN-00
	for idn-data@psg.com; Wed, 23 Jan 2002 18:20:06 -0800
Received: from twnic.net.tw ([211.72.210.250])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TZUj-0002oH-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 18:20:05 -0800
Received: from twnic.net.tw (pc160.twnic.net.tw [211.72.211.160])
	by twnic.net.tw (8.9.3/8.9.3) with ESMTP id KAA27686;
	Thu, 24 Jan 2002 10:19:57 +0800
Message-ID: <3C4F706C.7030601@twnic.net.tw>
Date: Thu, 24 Jan 2002 10:24:44 +0800
From: Erin Chen <erin@twnic.net.tw>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Paul Hoffman / IMC <phoffman@imc.org>
CC: ben <ben@cc-www.com>, Kenny Huang <huangk@alum.sinica.edu>,
        IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <001701c1a1d8$17e0c960$cd462b18@mtag.phub.net.cable.rogers.com> <p05101200b870b1d08c87@[165.227.249.20]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Paul,

Yes, You point out the key point. The problem is caused by  Unicode 
ambiguity.

Because of Unicode ambiguity, many critical problems will comes out:
the registration dispute of 2^n, the delegation/resolution inconsistent, 
the naming
uncertainty.

CDN requirements are extremely required in CDN users daily live.
All of the problems caused by Unicode ambiguity shell hurt CDN.

Erin Chen

Paul Hoffman / IMC wrote:

> At 12:30 PM -0500 1/20/02, ben wrote:
>
>> Is it possible to let the
>> Japanese and Korean domains names go forward and prohibit Chinese
>> domain names?
>
>
> No, and that one of the main problems that the CDN community faces. In 
> the ISO/IEC 10646 repertoire (which is the same as the Unicode 
> repertoire), it is impossible to differentiate between Chinese 
> characters and Korean characters and Japanese characters. Thus, any 
> proposal to remove the characters for one language removes them for all.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium






From owner-idn@ops.ietf.org  Wed Jan 23 21:53:15 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02685
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 21:53:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TZtB-0003MD-00
	for idn-data@psg.com; Wed, 23 Jan 2002 18:45:21 -0800
Received: from mail.iis.sinica.edu.tw ([140.109.20.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TZtA-0003M7-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 18:45:20 -0800
Received: from iis.sinica.edu.tw (dhcp053 [140.109.21.60])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with ESMTP id g0O2e8j01434;
	Thu, 24 Jan 2002 10:40:09 +0800 (CST)
Message-ID: <3C4F7595.160A999@iis.sinica.edu.tw>
Date: Thu, 24 Jan 2002 10:46:46 +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: Yoshiro YONEYA <yone@po.ntts.co.jp>
CC: idn@ops.ietf.org
Subject: Re: [idn] Prohibit CDN code points
References: <3C4E8931.6080908@twnic.net.tw>
		<5.1.0.14.2.20020123074339.032c9de0@127.0.0.1>
		<3C4EEAF7.1E2D57DB@iis.sinica.edu.tw> <20020124023039J.yone@po.ntts.co.jp>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


Unicode has its own purpose. As their design goal, did Unicode take domain
name considerations into account?

Unicode has their uniqueness and impacts in many application. We are reminding
the WG that it is abusing Unicode by using it as the basis of domain name
delegation and resolution.

For those who claim to use Unicode as it is, hope you don't mind to wait until
Unicode
Consortium solves naming ambiguity problems associated with the IDNA proposals.

Please do not pretend that victims of IDNA do not exist.

-- Janming

Yoshiro YONEYA �g�J�G

> hoho,
>
> From: hoho <hoho@iis.sinica.edu.tw>
> Subject: Re: [idn] Prohibit CDN code points
> Date: Thu, 24 Jan 2002 00:55:19 +0800
>
> > Yes, Unicode is the source of problems for IDNs with Han characters. But, did
> > anyone
> > ask IDN WG to undo anything? Why is it a problem here?
>
> You should read recent 4-6 months' mail archive of this mailing list.
> Unicode is only one universal standard we can refer.
>
> --
> Yoshiro YONEYA <yone@po.ntts.co.jp>




From owner-idn@ops.ietf.org  Wed Jan 23 22:11:48 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03006
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 22:11:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Ta9J-0003jY-00
	for idn-data@psg.com; Wed, 23 Jan 2002 19:02:01 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Ta9I-0003jQ-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 19:02:00 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g0O32Pg01188
	for idn@ops.ietf.org; Thu, 24 Jan 2002 12:02:25 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Thu, 24 Jan 2002 12:02:25 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: IETF-IDN <idn@ops.ietf.org>
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <20020124030223.GA952@spsoft.co.kr>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw> <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr> <2017401.1011795481@localhost> <20020123232445.C9627@spsoft.co.kr> <5.1.0.14.2.20020123095614.03c7de98@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20020123095614.03c7de98@127.0.0.1>
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dear Dave Crocker,

Thank you for your answer.

On Wed, Jan 23, 2002 at 10:35:35AM -0800, Dave Crocker wrote:
> A standard that is focused on international interoperability cannot be the 
> place for localization.
> 
> So, the place for what you are seeking is outside IDNA.  In terms of 
> architecture, it is at a layer above IDNA.

Your argument is totally correct. But, as far as TC/SC issue is concerned,
we are not dealing with 0 or 1 issue. Please, let me quote from Paul 
Hoffman's I-D draft-hoffman-i18n-terms-04.txt.

      ... The better internationalized an application is,
      the easier it is to localize it ...

I want to rephrase it;

      ... The poorer internationalized an application is,
      the harder (or even impossible) it is to localization it ...

As I have not yet surveyed TC/SC issue enough to make a solid conclusion, it
seems to me that we are going to come up with very poorly internationalized
standard.

My best regards

> d/
> 
> ----------
> Dave Crocker  <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Wed Jan 23 22:17:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03088
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 22:17:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TaI9-0003wF-00
	for idn-data@psg.com; Wed, 23 Jan 2002 19:11:09 -0800
Received: from inergen.sybase.com ([192.138.151.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TaI8-0003w9-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 19:11:08 -0800
Received: from smtp1.sybase.com (sybgate.sybase.com [130.214.220.35])
	by inergen.sybase.com  with ESMTP id TAA21098
	for <idn@ops.ietf.org>; Wed, 23 Jan 2002 19:10:52 -0800 (PST)
Received: from smtp1.sybase.com (localhost [127.0.0.1])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000/11/20) with ESMTP id TAA00551
	for <idn@ops.ietf.org>; Wed, 23 Jan 2002 19:11:06 -0800 (PST)
Received: from olympus.sybase.com (olympus.sybase.com [130.214.160.74])
	by smtp1.sybase.com (Pro-8.9.3/Pro-8.9.3/sendmail 8.9.3 smtp1 2000-11-20) with ESMTP id TAA00520;
	Wed, 23 Jan 2002 19:11:04 -0800 (PST)
Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5)
	id TAA09650; Wed, 23 Jan 2002 19:11:04 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id TAA04475;
	Wed, 23 Jan 2002 19:11:03 -0800 (PST)
Date: Wed, 23 Jan 2002 19:11:03 -0800 (PST)
From: Kenneth Whistler <kenw@sybase.com>
Message-Id: <200201240311.TAA04475@birdie.sybase.com>
To: erin@twnic.net.tw
Subject: Re: [idn] Prohibit CDN code points
Cc: idn@ops.ietf.org
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


> Yes, You point out the key point. The problem is caused by  Unicode 
> ambiguity.

This is utter nonsense.

The characters are the same because they come from the same source --
China -- and got borrowed historically by neighboring cultures in
Japan, Korea, and Vietnam, to write different languages. This is
no different (except in scale) from Latin characters getting borrowed
around for the alphabets of different languages, including Chinese(!).

If I write in Chinese, zhong1guo2ke1xue2yuan4 "Chinese Academy of
Sciences", a Japanese can read it right off, *in Japanese* as
chuugokukagakuin. Why? Because it is the *same* 5 characters, used
for two different languages. Unicode has nothing to do with it.
This was true before Unicode existed, and is true now.

> 
> Because of Unicode ambiguity, many critical problems will comes out:
> the registration dispute of 2^n, the delegation/resolution inconsistent, 
> the naming
> uncertainty.

The simplified versus traditional Chinese character issue is
something brought to the world by Chinese politics, and by
independent standardization and character encoding work that
gave us GB 2312 and Big 5 (and CNS, etc.).

Once again, Unicode really has nothing to do with this, other
than to make the nature of the problem clearer, perhaps.

But dream on, if you think you can resolve the problems of
Chinese naming by pursuing an avenue of distinct
national character sets and character encodings for each
political jurisdiction.

Furthermore, the national standardization groups in East Asia
are busy adopting each others characters into their national
standards -- *then* what do you do? GB 18030 is already a
mandated Chinese national standard, and it contains all the
Han characters from 10646, including all the Japanese-only
and Korean-only ones. Everybody has to support GB 18030
in China now, and it has all the traditional forms and all
the simplified forms in it, as well. That is the political
and technical reality.

> 
> CDN requirements are extremely required in CDN users daily live.
> All of the problems caused by Unicode ambiguity shell hurt CDN.

Sorry, this just won't cut it. It isn't Unicode ambiguity
that is at issue. It is the complex problems of having to
deal with two competing Chinese orthographies in a globalizing
world that includes Japanese and Koreans using the same
characters that is causing the pain. Trying to scapegoat
the Unicode Standard for the difficulties of IT globalization
in East Asia is just silly.
 
--Ken

> Erin Chen
> 
> Paul Hoffman / IMC wrote:
> 
> > At 12:30 PM -0500 1/20/02, ben wrote:
> >
> >> Is it possible to let the
> >> Japanese and Korean domains names go forward and prohibit Chinese
> >> domain names?
> >
> >
> > No, and that one of the main problems that the CDN community faces. In 
> > the ISO/IEC 10646 repertoire (which is the same as the Unicode 
> > repertoire), it is impossible to differentiate between Chinese 
> > characters and Korean characters and Japanese characters. Thus, any 
> > proposal to remove the characters for one language removes them for all.
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium



From owner-idn@ops.ietf.org  Wed Jan 23 22:50:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04729
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 22:50:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TamW-0004eW-00
	for idn-data@psg.com; Wed, 23 Jan 2002 19:42:32 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TamV-0004eQ-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 19:42:31 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g0O3h2C01243
	for idn@ops.ietf.org; Thu, 24 Jan 2002 12:43:02 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Thu, 24 Jan 2002 12:43:02 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: idn@ops.ietf.org
Subject: Re: [idn] Prohibit CDN code points
Message-ID: <20020124034302.GB952@spsoft.co.kr>
References: <200201240311.TAA04475@birdie.sybase.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <200201240311.TAA04475@birdie.sybase.com>
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Wed, Jan 23, 2002 at 07:11:03PM -0800, Kenneth Whistler wrote:
> The simplified versus traditional Chinese character issue is
> something brought to the world by Chinese politics, and by
> independent standardization and character encoding work that
> gave us GB 2312 and Big 5 (and CNS, etc.).

As I am not fairly well aware of standardization history of Chinese 
character code in China, please correct me if I am wrong.

Simplification of chinese character was done for cultural and educational 
purpose. And GB and Big5 is just a refelction of national policy (or
standard) into informational technology world. There is no political issue 
at all here.

Standardization process in a specific country is usually done by that 
country independently. That is quite natural. I have never heard that 
while defining ASCII, US people consulted with other countries.

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Wed Jan 23 23:52:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06181
	for <idn-archive@lists.ietf.org>; Wed, 23 Jan 2002 23:52:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TblP-000625-00
	for idn-data@psg.com; Wed, 23 Jan 2002 20:45:27 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TblO-00061z-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 20:45:26 -0800
Received: from BBThead.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id UAA09254;
	Wed, 23 Jan 2002 20:45:24 -0800
Message-Id: <5.1.0.14.2.20020123203947.024914f8@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 23 Jan 2002 20:40:13 -0800
To: YangWoo Ko <newcat@spsoft.co.kr>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Prohibit CDN code points
Cc: IETF-IDN <idn@ops.ietf.org>
In-Reply-To: <20020124030223.GA952@spsoft.co.kr>
References: <5.1.0.14.2.20020123095614.03c7de98@127.0.0.1>
 <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu>
 <p05101204b870ab94166d@[165.227.249.20]>
 <3C4E8931.6080908@twnic.net.tw>
 <1676461.1011789799@localhost>
 <20020123214733.A9627@spsoft.co.kr>
 <2017401.1011795481@localhost>
 <20020123232445.C9627@spsoft.co.kr>
 <5.1.0.14.2.20020123095614.03c7de98@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 12:02 PM 1/24/2002 +0900, YangWoo Ko wrote:
>As I have not yet surveyed TC/SC issue enough to make a solid conclusion, it
>seems to me that we are going to come up with very poorly internationalized
>standard.

Forgive me, but you are confusing "application" with "protocol".

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Jan 24 00:12:49 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06552
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 00:12:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Tc1r-0006QD-00
	for idn-data@psg.com; Wed, 23 Jan 2002 21:02:27 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Tc1q-0006Q7-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 21:02:26 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16Tc1p-0000z7-00
	for <idn@ops.ietf.org>; Wed, 23 Jan 2002 21:02:25 -0800
Date: Thu, 24 Jan 2002 05:02:25 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: [idn] internal DNS server behavior is irrelevant
Message-ID: <20020124050224.GE31151@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

We can stop discussing what authoritative DNS servers do internally when
deciding how to answer a query, because it's completely irrelevant.
An authoritative DNS server is already able to use whatever arbitrary
method it likes to decide how to answer queries (because it is the
authority--its answers define the namespace), and the proposed IDNA does
nothing to change that.

The only relevant issue is how *other* machines (DNS caching servers and
end hosts) decide whether two names are the same.  This is the algorithm
that is used to decide whether a query can be answered from the cache,
or whether a link has already been visited, or whether the name used
to contact a web server matches the SSL certificate presented by that
server.  Because this matching algorithm is performed locally (without
doing a DNS lookup) it must be well-known and standard.

Having authoritative name servers do extended matching internally can
confuse applications (because they effectively create alternate names
for servers that the servers themselves might not recognize--think
virtual web hosts).  Getting around this problem would apparently
entail extending the application servers inside the zone to understand
the additional matching.  Each zone can decide whether it's worth the
trouble to go down that road.  But that is all orthogonal to IDNA.

To reiterate:  We can stop discussing localized matching rules, because
IDNA does nothing to encourage or prevent them.  The relevant issue is
the single well-known matching rule.  Can we go ahead with the one in
IDNA, or do we need to prohibit simplified code points while the TC/SC
issue is settled (I hope not)?

AMC



From owner-idn@ops.ietf.org  Thu Jan 24 00:25:23 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06769
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 00:25:23 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TcEm-0006lv-00
	for idn-data@psg.com; Wed, 23 Jan 2002 21:15:48 -0800
Received: from [203.207.0.132] (helo=mail.asiainfra.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TcEk-0006ln-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 21:15:47 -0800
Received: from gix ([203.207.0.121])
	by mail.asiainfra.com (8.9.3/8.9.3) with SMTP id NAA13460
	for <idn@ops.ietf.org>; Thu, 24 Jan 2002 13:09:24 +0800
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: "IETF idn working group" <idn@ops.ietf.org>
Subject: RE: [idn] internal DNS server behavior is irrelevant
Date: Thu, 24 Jan 2002 13:20:36 +0800
Message-ID: <IHELIFNJKJLDFEMBCENDEEDJCMAA.huangk@alum.sinica.edu>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <20020124050224.GE31151@nicemice.net>
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA06769


I support AMC's suggestion. Please stop the irrelevant discussion until
any new draft submitted.


Kenny Huang

> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On 
> Behalf Of Adam M. Costello
> Sent: Thursday, January 24, 2002 1:02 PM
> To: IETF idn working group
> Subject: [idn] internal DNS server behavior is irrelevant
> 
> 
> We can stop discussing what authoritative DNS servers do internally when
> deciding how to answer a query, because it's completely irrelevant.
> An authoritative DNS server is already able to use whatever arbitrary
> method it likes to decide how to answer queries (because it is the
> authority--its answers define the namespace), and the proposed IDNA does
> nothing to change that.
> 
> The only relevant issue is how *other* machines (DNS caching servers and
> end hosts) decide whether two names are the same.  This is the algorithm
> that is used to decide whether a query can be answered from the cache,
> or whether a link has already been visited, or whether the name used
> to contact a web server matches the SSL certificate presented by that
> server.  Because this matching algorithm is performed locally (without
> doing a DNS lookup) it must be well-known and standard.
> 
> Having authoritative name servers do extended matching internally can
> confuse applications (because they effectively create alternate names
> for servers that the servers themselves might not recognize--think
> virtual web hosts).  Getting around this problem would apparently
> entail extending the application servers inside the zone to understand
> the additional matching.  Each zone can decide whether it's worth the
> trouble to go down that road.  But that is all orthogonal to IDNA.
> 
> To reiterate:  We can stop discussing localized matching rules, because
> IDNA does nothing to encourage or prevent them.  The relevant issue is
> the single well-known matching rule.  Can we go ahead with the one in
> IDNA, or do we need to prohibit simplified code points while the TC/SC
> issue is settled (I hope not)?
> 
> AMC




From owner-idn@ops.ietf.org  Thu Jan 24 01:38:14 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07999
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 01:38:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TdLS-0008O3-00
	for idn-data@psg.com; Wed, 23 Jan 2002 22:26:46 -0800
Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TdLR-0008Ns-00
	for idn@ops.ietf.org; Wed, 23 Jan 2002 22:26:46 -0800
Received: from zetnet.co.uk (man-s163.dialup.zetnet.co.uk [194.247.45.34])
        by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g0O6Qbb21435
        for <idn@ops.ietf.org>; Thu, 24 Jan 2002 06:26:38 GMT
Message-ID: <3C4E488E.AAEB8AF9@zetnet.co.uk>
Date: Wed, 23 Jan 2002 05:22:22 +0000
From: David Hopwood <david.hopwood@zetnet.co.uk>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: Re: [idn] Prohibit CDN code points
References: <c5.1cd8c61e.29803d8b@cs.com> <006801c1a43c$b87430e0$0601a8c0@neteka.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----

Edmon wrote:
> From: <DougEwell2@cs.com>
> > If everything is 1-to-1 between TC and SC, the algorithm is trivial.
> > I was talking about the algorithm that would be necessary to do TC/SC
> > conversion in the case of 1-to-many or many-to-1 conversions.  But,
> > since you say there are none, I guess we can proceed with implementing
> > the tables.
>
> It is possible to implement a 1-to-many or many-to-1 conversion.
> All it is required is that all "equivalent" characters be matched as
> "equivalent" in the authoritative DNS.

This doesn't work for the same reason that folding look-alike characters
doesn't work: you would need to put characters into equivalence classes
according to the transitive closure of the SC->TC and TC->SC mappings, and
that ends up putting completely unrelated characters in the same class.

I.e. start with a single character. Add all its TC/SC variants. For each
of those variants, add all their TC/SC variants, and so on, recursively.
For all I know you may end up with all Han characters in the same
equivalence class; perhaps not, but you certainly end up with very large
classes.

If TC/SC folding is done, it can only be done for the 1-1 subset of
mappings, and any variations in the algorithm must be based only on the
name itself, without making use of any other context (such as language,
etc.) I'm not qualified to judge whether it is useful to do TC/SC
folding under these contraints, but I suggest that those who advocate
it concentrate on that question, rather than making proposals that aren't
implementable.

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPE42MDkCAxeYt5gVAQG8iAgAqZtwQXJD1L80QdOi0t9dOhX2/cF90CKe
pF4CmdBsA9C2mOcRmzQPTXDt7aIApFkE1A2N9TP+avo38J4fqZF/qPVKb/ZSU6uk
JgZodaeyiyyOhc7p2MZ5+MR/3/EwWbrAXgpWkpG8JbbnLNKQ8asR81bPdCq0L0gK
a3Ifie1IHnHJcefWOzuBTHhfPcUkFLDhaJ/8YnAUjzDTaQDOohg7HgSNw6JBUoaO
/bgrPGRQBl9svrvQvVSSw4L4a0LJlQwikWUG7QVyH9W0mYbqO5E3xwJgKIh3qJn+
W2jN0LSjVYXmHamrTQXw2lcHKMxcSoyFLpLS0BgJOtkkTAUyjBG5CA==
=MiLW
-----END PGP SIGNATURE-----



From owner-idn@ops.ietf.org  Thu Jan 24 05:58:10 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19345
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 05:58:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16ThJj-000EA1-00
	for idn-data@psg.com; Thu, 24 Jan 2002 02:41:15 -0800
Received: from mercury.sun.com ([192.9.25.1])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16ThJi-000E9v-00
	for idn@ops.ietf.org; Thu, 24 Jan 2002 02:41:14 -0800
Received: from bebop.France.Sun.COM ([129.157.179.15])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA15696;
	Thu, 24 Jan 2002 02:41:09 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0OAf7F29422;
	Thu, 24 Jan 2002 11:41:07 +0100 (MET)
Date: Thu, 24 Jan 2002 11:37:47 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone
To: Edmon <edmon@neteka.com>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Masahiro Sekiguchi <seki@jp.fujitsu.com>, IETF-IDN <idn@ops.ietf.org>
In-Reply-To: "Your message with ID" <00c601c1a44f$936f4880$0601a8c0@neteka.com>
Message-ID: <Roam.SIMC.2.0.6.1011868667.10127.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


> One of the possibility obviously is signing on the fly (perhaps less
> advisable), the other the use of opt-in (still in progress... problematic
> domains will have to opt-out), and thirdly to have sig rrs for all
> permutations (readily possible).

Edmon,

If the DNS servers don't care about potential DoS attacks and having on-line
keys then signing on the fly could work. But that is a huge "if".
The DoS attack is that anybody can send DNS queries to have the DNS server
spend all its CPU generating signatures on the fly.
Sure sounds like a bad design from a security and robustness perspective.

I don't understand what "opt-in" has to do with IDN. Could you please explain?

Your third idea (SIG RRs for all permutations) has a natural follow-on:
If you have enough memory/storage for the large SIG RRs for all permutations
then the additional memory/storage for the underlying RRs for all permutations
will be very small. So in practise this sounds like creating all permutations
in the zone file e.g. at registration time.
That (or just a subset of all permutations picked at registration time) has the
benefit of not requiring any changes to the DNS server software.

   Erik





From owner-idn@ops.ietf.org  Thu Jan 24 07:51:58 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20474
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 07:51:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Tj8m-000GbG-00
	for idn-data@psg.com; Thu, 24 Jan 2002 04:38:04 -0800
From: "Mark Davis \(jtcsv\)" <mark.davis@jtcsv.com>
To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "YangWoo Ko" <newcat@spsoft.co.kr>, "IETF-IDN" <idn@ops.ietf.org>,
        "Kenneth Whistler" <kenw@sybase.com>
Subject: Re: [idn] Prohibit CDN code points
Date: Wed, 23 Jan 2002 07:27:59 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Message-Id: <E16Tj8m-000GbG-00@psg.com>
Content-Transfer-Encoding: 8bit

There are, of course, problems in Unicode; unavoidable with a project
that
complex. Some were introduced for compatibility with the host of legacy
code
pages in the world (by our count in ICU, well over 700 unique code pages
in
current use), others could have been avoided had we known what we know
now.

Unification is not one of them, however. It is not so much a feature of
Unicode as a feature of human writing. We could have chosen to deunify
every
language's character; even every dialect's. A Swedish 'a' would be
different
than a French 'a', different than an English 'a', even different than a
Yorkshire 'a' or a New York 'a'. After all, that would allow one to
detect
different languages, and sort or match differently based upon that. For
that
matter, we could have chosen to deunify fonts and styles; bold 'u' from
italic, Helvetica from Times New Roman.

But what a huge mess it would be. Rather than a relatively small number
of
confusible characters, we would have essentially all confusible
characters.
Applications would have to deal with a tremendous increase in the number
of
characters, drastically increasing the memory storage for the necessary
character properties, and there would be an incredible number of
problems
for users because of the visual confusion of so many characters. Much
too
high a price, on balance, rather than dealing with matching issues in a
simpler representation.

The TC/SC problem can be dealt with by means of the registration of a
small
number of additional names. Little different in kind from registering
both
theatre.com and theater.com, or aarborg.com and a<ring>rborg.com. While
theoretically someone could have 5-character name with 32 combinations
of
TC/SC, in practice nobody has proven this to be a real problem, or even
provided any evidence whatsoever that clients will in fact be confused.

Mark
—————

� όλλ’ � πίστατο ἔργα, κακῶς δ’ �
πίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "YangWoo Ko" <newcat@spsoft.co.kr>; "IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 05:18
Subject: Re: [idn] Prohibit CDN code points


> --On 2002-01-23 21.47 +0900 YangWoo Ko <newcat@spsoft.co.kr> wrote:
>
> > Your last statement does not exactly describe TC/SC issue. Following
may
> > explain TC/SC issue better;
> >
> > "If one enter a string in Unicode, one may or may not know whether
TC or
> > SC was used. It depends both on his language in mind when entering
that
> > string and on his knowledge about characters."
>
> Correct.
>
> > Dear all members,
> >
> > What about having additional prefix(es) for extension like TC/SC
issue ?
> > For example, az-- for normal IDNA and bz-- for chinese-extension
IDNA
> > and so forth. It may serve as an context information or language
tag.
>
> How do you match between one string which uses az--<foo>.com and
> bz--<foo>.com where "<foo>" stands for the term "foo" but encoded?
>
> And, yes, you can do this, but as i have pointed out before, this
means
> every server needs to know about all matching algorithms.
>
> I.e. if you open the box of "problems" with Unicode, you will find
that
the
> SC/TC problem is only one of them. Only one. I guess we have some
20-30
> other problems which are similar to the SC/TC, i.e. problems because
of
> unification or non-unification in Unicode.
>
> So, you will see an explosion of matching rules.
>
> Reason we see this about SC/TC is that that happen to be the problem
space
> we discuss at the moment. We could aswell discuss the problems with
> adiaeresis in the countries and languages which uses it.
>
> My conclusion is the same, every server need to have knowledge about
how
to
> handle all encodings.
>
>    paf
>
>
>






From owner-idn@ops.ietf.org  Thu Jan 24 08:26:15 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20918
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 08:26:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Tjnm-000Hah-00
	for idn-data@psg.com; Thu, 24 Jan 2002 05:20:26 -0800
Received: from smtp12.singnet.com.sg ([165.21.6.32])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Tjnl-000Hab-00
	for idn@ops.ietf.org; Thu, 24 Jan 2002 05:20:25 -0800
Received: from jamessonyvaio (bb154-84.singnet.com.sg [165.21.154.84])
	by smtp12.singnet.com.sg (8.12.1/8.12.1) with SMTP id g0ODKNoO012623
	for <idn@ops.ietf.org>; Thu, 24 Jan 2002 21:20:23 +0800
Message-ID: <01a001c1a4d9$ee9141c0$1901000a@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: <idn@ops.ietf.org>
References: <c5.1cd8c61e.29803d8b@cs.com> <006801c1a43c$b87430e0$0601a8c0@neteka.com> <3C4E488E.AAEB8AF9@zetnet.co.uk>
Subject: Thread on - Re: [idn] Prohibit CDN code points
Date: Thu, 24 Jan 2002 21:20:45 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear all,

I was offline for 2 days and just finished reading 60+ message on this
thread alone.

While it is very interesting, I would like to remind everyone that in
order to make working group progress, we should focus our discussion on
"core interest".

The "core interest" of the group after SLC:

Requirements of Internationalized Domain Names
(draft-ietf-idn-requirements)
Internationalizing Host Names In Applications (IDNA)
(draft-ietf-idn-idna)
Preparation of Internationalized Host Names (draft-ietf-idn-nameprep)
Proposal for a determining process of ACE identifier
(draft-ietf-idn-aceid)
AMC-ACE-Z version 0.2.1(draft-costello-idn-amc-ace-z) renamed as
    Punycode version 0.3.3 (draft-ietf-idn-punycode-00)

Therefore, it would be better if we bring all discussion outside core
interest offline. We should focus on our current action item, namely:

1. Decision on Requirements Document

   Since there is no further feedback on the issues of dropping the
   requirements, then we should drop it from the pool.

   There is also no volunteer for the replacement doc so we will put
   the idea on hold until we find one.

2. WG Last Call for IDNA, Nameprep, AMC-ACE-Z (aka punycode)

   We should be doing it anytime now, hopefully within this week.

-James Seng




From owner-idn@ops.ietf.org  Thu Jan 24 12:28:41 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28496
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 12:28:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TnSx-000NqB-00
	for idn-data@psg.com; Thu, 24 Jan 2002 09:15:11 -0800
Received: from [66.48.4.181] (helo=neteka.com)
	by psg.com with smtp (Exim 3.33 #1)
	id 16TnSw-000Nq5-00
	for idn@ops.ietf.org; Thu, 24 Jan 2002 09:15:10 -0800
Message-ID: <005001c1a4f2$402fcd40$0601a8c0@neteka.com>
From: "Edmon" <edmon@neteka.com>
To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <Roam.SIMC.2.0.6.1011868667.10127.nordmark@bebop.france>
Subject: Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone
Date: Thu, 24 Jan 2002 11:14:46 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
> If the DNS servers don't care about potential DoS attacks and having
on-line
> keys then signing on the fly could work. But that is a huge "if".
> The DoS attack is that anybody can send DNS queries to have the DNS server
> spend all its CPU generating signatures on the fly.
> Sure sounds like a bad design from a security and robustness perspective.
>
Which is why I said it is not advisable.  But it is a possibility.

> I don't understand what "opt-in" has to do with IDN. Could you please
explain?

Multilingual names that have character equivalency issues will have to
opt-out of DNSSEC.

> Your third idea (SIG RRs for all permutations) has a natural follow-on:
> If you have enough memory/storage for the large SIG RRs for all
permutations
> then the additional memory/storage for the underlying RRs for all
permutations
> will be very small. So in practise this sounds like creating all
permutations
> in the zone file e.g. at registration time.
> That (or just a subset of all permutations picked at registration time)
has the
> benefit of not requiring any changes to the DNS server software.

Erik, honestly, I dont have the exact "best" solution yet.  My point is that
there are "possibilities" and we should not rule the entire thing out just
because it might be a bit difficult.  I really want to stop talking about
this subject on this list, but it seems to me very irresponsible, especially
considering that I am an implementor of this technology that I would have to
tell my customers that:
A.example  is NOT the same as A.example
How can I do that?  Any normal person in this world would not accept this,
yet I am creating a system that force them to accept that.  I could step
back and say, "o well, buyers beware", but it just doesnt seem right.  Do
you think it is right?

Edmon




From owner-idn@ops.ietf.org  Thu Jan 24 21:04:11 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11877
	for <idn-archive@lists.ietf.org>; Thu, 24 Jan 2002 21:04:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16TvTI-000Aqv-00
	for idn-data@psg.com; Thu, 24 Jan 2002 17:48:04 -0800
Received: from smtp12.singnet.com.sg ([165.21.6.32])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16TvTG-000Aqo-00
	for idn@ops.ietf.org; Thu, 24 Jan 2002 17:48:02 -0800
Received: from jamessonyvaio (bb154-84.singnet.com.sg [165.21.154.84])
	by smtp12.singnet.com.sg (8.12.1/8.12.1) with SMTP id g0P1lioO031954;
	Fri, 25 Jan 2002 09:47:44 +0800
Message-ID: <049501c1a542$57c0eb10$1901000a@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Edmon" <edmon@neteka.com>, "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
Cc: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <Roam.SIMC.2.0.6.1011868667.10127.nordmark@bebop.france> <005001c1a4f2$402fcd40$0601a8c0@neteka.com>
Subject: Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone
Date: Fri, 25 Jan 2002 09:48:09 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

For the same reasons as the thread on CDN, (ie, not of core interest),
this thread is also out of scope so please bring it offline.  I already
give you my comments offline.

Thanks!

-James Seng

----- Original Message -----
From: "Edmon" <edmon@neteka.com>
To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
Cc: "Patrik F�ltstr�m" <paf@cisco.com>; "Masahiro Sekiguchi"
<seki@jp.fujitsu.com>; "IETF-IDN" <idn@ops.ietf.org>
Sent: Friday, January 25, 2002 12:14 AM
Subject: Re: [idn] Re: Optional & Additional Character Equivalence
Preparations by Zone


> ----- Original Message -----
> From: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
> > If the DNS servers don't care about potential DoS attacks and having
> on-line
> > keys then signing on the fly could work. But that is a huge "if".
> > The DoS attack is that anybody can send DNS queries to have the DNS
server
> > spend all its CPU generating signatures on the fly.
> > Sure sounds like a bad design from a security and robustness
perspective.
> >
> Which is why I said it is not advisable.  But it is a possibility.
>
> > I don't understand what "opt-in" has to do with IDN. Could you
please
> explain?
>
> Multilingual names that have character equivalency issues will have to
> opt-out of DNSSEC.
>
> > Your third idea (SIG RRs for all permutations) has a natural
follow-on:
> > If you have enough memory/storage for the large SIG RRs for all
> permutations
> > then the additional memory/storage for the underlying RRs for all
> permutations
> > will be very small. So in practise this sounds like creating all
> permutations
> > in the zone file e.g. at registration time.
> > That (or just a subset of all permutations picked at registration
time)
> has the
> > benefit of not requiring any changes to the DNS server software.
>
> Erik, honestly, I dont have the exact "best" solution yet.  My point
is that
> there are "possibilities" and we should not rule the entire thing out
just
> because it might be a bit difficult.  I really want to stop talking
about
> this subject on this list, but it seems to me very irresponsible,
especially
> considering that I am an implementor of this technology that I would
have to
> tell my customers that:
> A.example  is NOT the same as A.example
> How can I do that?  Any normal person in this world would not accept
this,
> yet I am creating a system that force them to accept that.  I could
step
> back and say, "o well, buyers beware", but it just doesnt seem right.
Do
> you think it is right?
>
> Edmon
>
>




From owner-idn@ops.ietf.org  Fri Jan 25 08:12:48 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01311
	for <idn-archive@lists.ietf.org>; Fri, 25 Jan 2002 08:12:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16U5vL-000OWX-00
	for idn-data@psg.com; Fri, 25 Jan 2002 04:57:43 -0800
Received: from patan.sun.com ([192.18.98.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16U5vK-000OWR-00
	for idn@ops.ietf.org; Fri, 25 Jan 2002 04:57:42 -0800
Received: from bebop.France.Sun.COM ([129.157.179.15])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14133;
	Fri, 25 Jan 2002 05:57:35 -0700 (MST)
Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0PCvTF27233;
	Fri, 25 Jan 2002 13:57:29 +0100 (MET)
Date: Fri, 25 Jan 2002 13:54:03 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone
To: Edmon <edmon@neteka.com>
Cc: Erik Nordmark <Erik.Nordmark@eng.sun.com>,
        =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>,
        Masahiro Sekiguchi <seki@jp.fujitsu.com>, IETF-IDN <idn@ops.ietf.org>
In-Reply-To: "Your message with ID" <005001c1a4f2$402fcd40$0601a8c0@neteka.com>
Message-ID: <Roam.SIMC.2.0.6.1011963243.19966.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


> Multilingual names that have character equivalency issues will have to
> opt-out of DNSSEC.

That shounds like a non-starter.
We need to figure out how to provide better Internationalization of
IETF protocols and we need to make the Internet more secure.
Forcing users to choose between either IDN or secure doesn't accomplish
this.


> Erik, honestly, I dont have the exact "best" solution yet.  My point is that
> there are "possibilities" and we should not rule the entire thing out just
> because it might be a bit difficult.

I think we've talked about this on the list for two years. Lots of folks
have said "I have an idea" and further exploration on the list or in I-Ds
have determined that when taking the details into account the idea
doesn't fit with the constraints imposed by the DNS and the applications.

So the problem isn't that it is a bit difficult, but that it can't be made
to work given the constraints.
That doesn't make the problem less important - but it means that it doesn't
fit into the DNS. Hence the work on layer 2 where more context can be
taking into account when searching for names.

>  I really want to stop talking about
> this subject on this list, but it seems to me very irresponsible, especially
> considering that I am an implementor of this technology that I would have to
> tell my customers that:
> A.example  is NOT the same as A.example
> How can I do that?  Any normal person in this world would not accept this,
> yet I am creating a system that force them to accept that.  I could step
> back and say, "o well, buyers beware", but it just doesnt seem right.  Do
> you think it is right?

Isn't much different than MICROSOFT.COM and MICR0S0FT.COM (digit 0 vs. O).

But I think the problem is important. 
But I've come to the conclusion that solving the problem either requires
 - replacing the DNS with something else that can do approximate matching, or
 - building a system on top of the DNS.

I think the vast majority, no matter how important they think the problem is,
don't want to take the risk to the current operational Internet of
a whole-sale replacement of the DNS.
Leaves the layered approach as the only reasonable choice.

  Erik




From owner-idn@ops.ietf.org  Fri Jan 25 10:09:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04585
	for <idn-archive@lists.ietf.org>; Fri, 25 Jan 2002 10:09:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16U7oO-0000lf-00
	for idn-data@psg.com; Fri, 25 Jan 2002 06:58:40 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16U7oN-0000lH-00
	for idn@ops.ietf.org; Fri, 25 Jan 2002 06:58:39 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0PEvg400726;
	Fri, 25 Jan 2002 22:57:42 +0800 (CST)
Message-ID: <000801c1a5b0$498589c0$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>, "Edmon" <edmon@neteka.com>
Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>,
        =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "Masahiro Sekiguchi" <seki@jp.fujitsu.com>,
        "IETF-IDN" <idn@ops.ietf.org>
References: <Roam.SIMC.2.0.6.1011963243.19966.nordmark@bebop.france>
Subject: Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone
Date: Fri, 25 Jan 2002 22:55:08 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear  Edmon & Erik:
          Sorry ,  I jump into your discussion. But this is first time,  I
feel there are some honest engineer want to dig the true problem  and not
only announce it is a forbidden area.
----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>
To: "Edmon" <edmon@neteka.com>
Cc: "Erik Nordmark" <Erik.Nordmark@eng.sun.com>; "Patrik Fältström"
<paf@cisco.com>; "Masahiro Sekiguchi" <seki@jp.fujitsu.com>; "IETF-IDN"
<idn@ops.ietf.org>
Sent: Friday, January 25, 2002 8:54 PM
Subject: Re: [idn] Re: Optional & Additional Character Equivalence
Preparations by Zone


>
> > Multilingual names that have character equivalency issues will have to
> > opt-out of DNSSEC.
>
> That shounds like a non-starter.
> We need to figure out how to provide better Internationalization of
> IETF protocols and we need to make the Internet more secure.
> Forcing users to choose between either IDN or secure doesn't accomplish
> this.
>
              In my personal experimental implementation test and analysis.
I  can make sure current UTF-8 DNS can be modified to work as a ML-DNS with
character equivalency  capability and all of them should to  form a core
tree.  If  these server are work as core server without working as a cache
to non-character-equivalency DNS server, the problems of  mis-cache-data and
authorized tree relation check  can be avoid.


>
> > Erik, honestly, I dont have the exact "best" solution yet.  My point is
that
> > there are "possibilities" and we should not rule the entire thing out
just
> > because it might be a bit difficult.
>
> I think we've talked about this on the list for two years. Lots of folks
> have said "I have an idea" and further exploration on the list or in I-Ds
> have determined that when taking the details into account the idea
> doesn't fit with the constraints imposed by the DNS and the applications.
>
> So the problem isn't that it is a bit difficult, but that it can't be made
> to work given the constraints.
> That doesn't make the problem less important - but it means that it
doesn't
> fit into the DNS. Hence the work on layer 2 where more context can be
> taking into account when searching for names.
>
             A  core ML-UTF8-DNS tree is another Layer 2 server with more
character equivalent capability than current edge UTF-8 DNS server. But this
approach  will not follow the layer relation . Actually,  more lower layer
should more capability of  equivalence to form a common base . The  current
IDNA  nameprep  do not follow this rule ,  so it will force LDH-DNS can not
be work as a server with more capability  of  character equivalence . Even
Puny code have support this feature based on ASCII case insensitive
comparision of  LDH-DNS server.

> >  I really want to stop talking about
> > this subject on this list, but it seems to me very irresponsible,
especially
> > considering that I am an implementor of this technology that I would
have to
> > tell my customers that:
> > A.example  is NOT the same as A.example
> > How can I do that?  Any normal person in this world would not accept
this,
> > yet I am creating a system that force them to accept that.  I could step
> > back and say, "o well, buyers beware", but it just doesnt seem right.
Do
> > you think it is right?
>
> Isn't much different than MICROSOFT.COM and MICR0S0FT.COM (digit 0 vs. O).
> But I think the problem is important.
> But I've come to the conclusion that solving the problem either requires
>  - replacing the DNS with something else that can do approximate matching,
or
>  - building a system on top of the DNS.

         If  it is out of control , it is no different with  TLD string be
append with an additional domain name in client .
As I  know ,  If  on top of current DNS is need , taking ML-DNS approach as
the layer2 server is more save than other server.

Best regards,

L.M.Tseng




From owner-idn@ops.ietf.org  Fri Jan 25 22:04:28 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21310
	for <idn-archive@lists.ietf.org>; Fri, 25 Jan 2002 22:04:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UInM-000DPq-00
	for idn-data@psg.com; Fri, 25 Jan 2002 18:42:20 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UInL-000DPk-00
	for idn@ops.ietf.org; Fri, 25 Jan 2002 18:42:19 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0Q2gC418597;
	Sat, 26 Jan 2002 10:42:13 +0800 (CST)
Message-ID: <001701c1a612$b0d5ac60$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "James Seng/Personal" <jseng@pobox.org.sg>, <idn@ops.ietf.org>
References: <c5.1cd8c61e.29803d8b@cs.com> <006801c1a43c$b87430e0$0601a8c0@neteka.com> <3C4E488E.AAEB8AF9@zetnet.co.uk> <01a001c1a4d9$ee9141c0$1901000a@jamessonyvaio>
Subject: Re: Thread on - Re: [idn] Prohibit CDN code points
Date: Sat, 26 Jan 2002 10:39:32 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear All:
In the draft ,
http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt
define the single Unicode code point as follow:

Unicode [UNICODE] is a coded character set containing tens of thousands
of characters. A single Unicode code point is denoted by "U+" followed
by four to six hexadecimal digits, while a range of Unicode code points
is denoted by two hexadecimal numbers separated by "..", with no
prefixes.

My question are:
Q1:   U+hhhh  can be represented as u+hhhh  or not ?
Q2:   Here U+HHHH  is not a hostname , does it MUST be forced to lower
u+hhhh or not  in nameprep ?
Q3:  Puny code  draft  accept  U+hhhh  or  u+hhhh  to let the final encoded
ASCII character (last character of corresponding  encoded code point)  with
case upper or lower.

I   hope draft authors can help to clarify these interconnection point .

L.M.Tseng
----- Original Message -----
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: <idn@ops.ietf.org>
Sent: Thursday, January 24, 2002 9:20 PM
Subject: Thread on - Re: [idn] Prohibit CDN code points


> Dear all,
>
> I was offline for 2 days and just finished reading 60+ message on this
> thread alone.
>
> While it is very interesting, I would like to remind everyone that in
> order to make working group progress, we should focus our discussion on
> "core interest".
>
> The "core interest" of the group after SLC:
>
> Requirements of Internationalized Domain Names
> (draft-ietf-idn-requirements)
> Internationalizing Host Names In Applications (IDNA)
> (draft-ietf-idn-idna)
> Preparation of Internationalized Host Names (draft-ietf-idn-nameprep)
> Proposal for a determining process of ACE identifier
> (draft-ietf-idn-aceid)
> AMC-ACE-Z version 0.2.1(draft-costello-idn-amc-ace-z) renamed as
>     Punycode version 0.3.3 (draft-ietf-idn-punycode-00)
>
> Therefore, it would be better if we bring all discussion outside core
> interest offline. We should focus on our current action item, namely:
>
> 1. Decision on Requirements Document
>
>    Since there is no further feedback on the issues of dropping the
>    requirements, then we should drop it from the pool.
>
>    There is also no volunteer for the replacement doc so we will put
>    the idea on hold until we find one.
>
> 2. WG Last Call for IDNA, Nameprep, AMC-ACE-Z (aka punycode)
>
>    We should be doing it anytime now, hopefully within this week.
>
> -James Seng
>
>




From owner-idn@ops.ietf.org  Fri Jan 25 23:17:43 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22969
	for <idn-archive@lists.ietf.org>; Fri, 25 Jan 2002 23:17:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UK7e-000Erd-00
	for idn-data@psg.com; Fri, 25 Jan 2002 20:07:22 -0800
Received: from fm200.sybase.com ([192.138.151.122])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UK7d-000ErX-00
	for idn@ops.ietf.org; Fri, 25 Jan 2002 20:07:21 -0800
Received: from smtp2.sybase.com (sybgate2.sybase.com [10.22.97.85])
	by fm200.sybase.com  with ESMTP id UAA10952;
	Fri, 25 Jan 2002 20:07:24 -0800 (PST)
Received: from olympus.sybase.com (localhost [127.0.0.1])
	by smtp2.sybase.com  with ESMTP id UAA14394;
	Fri, 25 Jan 2002 20:07:20 -0800 (PST)
Received: from birdie.sybase.com by olympus.sybase.com (8.8.8+Sun/SMI-SVR4/SybEC3.5)
	id UAA02569; Fri, 25 Jan 2002 20:06:23 -0800 (PST)
Received: (from kenw@localhost)
	by birdie.sybase.com (8.8.8+Sun/8.8.8) id UAA04911;
	Fri, 25 Jan 2002 20:07:18 -0800 (PST)
Date: Fri, 25 Jan 2002 20:07:18 -0800 (PST)
From: Kenneth Whistler <kenw@sybase.com>
Message-Id: <200201260407.UAA04911@birdie.sybase.com>
To: tsenglm@cc.ncu.edu.tw
Subject: Re: Thread on - Re: [idn] Prohibit CDN code points
Cc: idn@ops.ietf.org
X-Sun-Charset: US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

L.M.Tseng asked:

> Dear All:
> In the draft ,
> http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt
> define the single Unicode code point as follow:
> 
> Unicode [UNICODE] is a coded character set containing tens of thousands
> of characters. A single Unicode code point is denoted by "U+" followed
> by four to six hexadecimal digits, while a range of Unicode code points
> is denoted by two hexadecimal numbers separated by "..", with no
> prefixes.

Patrick, Paul, or Adam may offer further clarification, but this is
basically a Unicode nomenclatural issue.

The string "U+006A" is a denotation for the Unicode code point (in
the overall range of possible values 0..10FFFF), as well as the
character encoded at that code point, namely LATIN SMALL LETTER J.

The case doesn't matter, although the Unicode Standard most
often uses uppercase. So some people would also use "U+006a" or 
"u+006a" for the same Unicode code point.

> 
> My question are:
> Q1:   U+hhhh  can be represented as u+hhhh  or not ?

Yes. And you can also just leave off
the U+ altogether where it is clear you are referring to
Unicode characters, i.e. "hhhh", so for the LATIN SMALL LETTER J,
just "006A" or "006a".

> Q2:   Here U+HHHH  is not a hostname , does it MUST be forced to lower
> u+hhhh or not  in nameprep ?

I think you are mixing things up. If you put a Unicode character
into a hostname, you don't literally put the string "U+006A" (or
whatever) into the hostname, you put the Unicode encoded representation,
in whatever form of Unicode you are using, into the hostname.

Thus, if my hostname was "jam", in Unicode UTF-8, that would be
just 0x6A 0x61 0x6D, since the Unicode values for ASCII characters
like "j" are the same as ASCII in UTF-8.

If my hostname was the Chinese word for 'banana', just to pick
a random example, that consists of two characters (pinyin: xiang1jiao1).
The Unicode values for those characters are U+9999 U+8549. If you
have a Unicode string, that would just be two 16-bit numbers,
0x9999 followed by 0x8549, if using Unicode UTF-16, or the
following byte sequence if using Unicode UTF-8: 0xE9 0xA6 0x99 
0xE8 0x95 0x89.

> Q3:  Puny code  draft  accept  U+hhhh  or  u+hhhh  to let the final encoded
> ASCII character (last character of corresponding  encoded code point)  with
> case upper or lower.

If I am interpreting things correctly, Punycode is defined on the 
Unicode code points, and certainly not on
the short identifier strings for the Unicode code points.
So for the Chinese 'banana' example, you'd be encoding two
code point integers (39321 = 0x9999, followed by 34121 = 0x8549),
*not* the string of integers corresponding to the ASCII
string "U+9999U+8549".

Of course, somebody might want to try having a hostname or
domain name of "U+9999U+8549", but that is a 12 character ASCII
string, and is not the same thing at all as the two-character
Unicode string for the Chinese word for 'banana'.

--Ken

> 
> I   hope draft authors can help to clarify these interconnection point .
> 
> L.M.Tseng



From owner-idn@ops.ietf.org  Fri Jan 25 23:26:14 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23012
	for <idn-archive@lists.ietf.org>; Fri, 25 Jan 2002 23:26:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UKFi-000F1H-00
	for idn-data@psg.com; Fri, 25 Jan 2002 20:15:42 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UKFh-000F0x-00
	for idn@ops.ietf.org; Fri, 25 Jan 2002 20:15:41 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16UKFd-0005mk-00
	for <idn@ops.ietf.org>; Fri, 25 Jan 2002 20:15:37 -0800
Date: Sat, 26 Jan 2002 04:15:37 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: Thread on - Re: [idn] Prohibit CDN code points
Message-ID: <20020126041536.GC19927@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <c5.1cd8c61e.29803d8b@cs.com> <006801c1a43c$b87430e0$0601a8c0@neteka.com> <3C4E488E.AAEB8AF9@zetnet.co.uk> <01a001c1a4d9$ee9141c0$1901000a@jamessonyvaio> <001701c1a612$b0d5ac60$4007738c@q.j.tw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001701c1a612$b0d5ac60$4007738c@q.j.tw>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"tsenglm@????????????.??????.tw" <tsenglm@cc.ncu.edu.tw> wrote:

> Unicode [UNICODE] is a coded character set containing tens of thousands
> of characters. A single Unicode code point is denoted by "U+" followed
> by four to six hexadecimal digits...
> 
> My question are:
> Q1:  U+hhhh can be represented as u+hhhh or not ?

The Unicode standard always uses U+, never u+, and the same is true of
the IDNA draft.  The Punycode draft always uses U+ in the main spec, but
the sample implementation uses both U+ and u+ in order to represent the
annotation flags, and the examples section likewise uses both U+ and u+
to make it easy to feed the examples into the sample implementation.

> Q2:  Here U+HHHH is not a hostname , does it MUST be forced to lower
> u+hhhh or not in nameprep ?

The case of the U is not part of the code point.  A code point is just
an integer.  For example, U+0391 and u+0391 both represent the integer
913 (decimal) which is the code point for uppercase alpha.  U+03B1
and u+03B1 both represent the integer 945 (decimal) which is the code
point for lowercase alpha.  Nameprep always converts uppercase alpha
to lowercase alpha (so it would always output 945, never 913), but a
nameprep implementation that included support for mixed case annotations
would output not only an array of code points but also a parallel
array of case flags, and the lowercase alpha (945) would be flagged
as "wanting to be uppercase".  The flags could be passed along to the
Punycode encoder and recovered by the Punycode decoder.

The Punycode sample implementation and examples sections use U+03B1
to mean "lowercase alpha with flag set (wants to be uppercase)" and
use u+03B1 to mean "lowercase alpha with flag clear (wants to stay
lowercase)".

The flags have no affect on which ASCII letters and digits are output
by the Punycode encoder.  The flags merely affects the upper/lowercase
property of the ASCII letters.

AMC



From owner-idn@ops.ietf.org  Sat Jan 26 03:55:59 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03992
	for <idn-archive@lists.ietf.org>; Sat, 26 Jan 2002 03:55:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UOOl-000JUj-00
	for idn-data@psg.com; Sat, 26 Jan 2002 00:41:19 -0800
Received: from mail-out1.apple.com ([17.254.0.52])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UOOk-000JUd-00
	for idn@ops.ietf.org; Sat, 26 Jan 2002 00:41:18 -0800
Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g0Q8fGQ03372
	for <idn@ops.ietf.org>; Sat, 26 Jan 2002 00:41:17 -0800 (PST)
Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T58aca5eaca118164e13bc@mailgate2.apple.com>;
 Sat, 26 Jan 2002 00:41:16 -0800
Received: from [206.111.147.149] (vpn-gh-1065.apple.com [17.254.140.40])
	by scv3.apple.com (8.11.3/8.11.3) with SMTP id g0Q8fG612592;
	Sat, 26 Jan 2002 00:41:16 -0800 (PST)
Message-Id: <200201260841.g0Q8fG612592@scv3.apple.com>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Date: Sat, 26 Jan 2002 00:41:16 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: "Patrik F=?ISO-8859-1?Q?=e4ltstr=f6m?=" <paf@cisco.com>,
        <idn@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA03992

Patrik F�ltstr�m wrote:
>Example: If a.com and b.com is considered equal,
>why should not a.se and b.se be equal?

a.com. IN A     1.2.3.4
b.com. IN CNAME a.com.

a.se.  IN A     1.2.3.5
b.se.  IN A     1.2.3.6

In this (very simplified) example, "b.com." is declared to be no more 
than an alias for "a.com." Any lookup for any DNS record type for 
"b.com." will return the same answer as a lookup for that DNS record type 
for "a.com."

In contrast, "a.se." and "b.se." are different.

Why is this a problem?

>So, this wg decided that we will use one and only one matching rule,
>just like we decided to use only one character set. Both of these
>(the rule and the charset) are created in the Unicode Consortium.
>
>You also talk about "evolving matching rules over time". That
>is a very bad thing.

Unfortunately, the rules as created by the Unicode Consortium do change 
over time. Apple's HFS+ file system uses Unicode file names, with the 
restriction (as you would expect) that two files in a directory cannot 
have the same name.

Unfortunately, when the Unicode Consortium rules change (we're currently 
in the process of moving to Unicode 3.2 rules), this can result in two 
files that were previously considered different names, to now be 
considered the same name, hence resulting in an apparently invalid file 
system.

This is a mess. It would be much better if the file system on the volume 
could assert the version of the Unicode Consortium rules by which it 
abides, instead of being judged by the version of the Unicode Consortium 
rules in effect at the time it is read.

Hence my suggestion that IDN avoid the same mistake, and let the 
authoritative server for a domain assert the Unicode Consortium rules by 
which it abides.

>Let's say that we have registered apple.com and �pple.com. They
>are considered different. One day the equivalence rule change,
>and they are considered being the same. Who is calling Steve
>Jobs saying that apple.com have to give back it's domain name
>and pick something else? You? ICANN? The registry for .com?

Again, an argument supporting my suggestion that the authoritative server 
for the "com" domain should be allowed to assert the Unicode Consortium 
rules by which it abides, instead of having to change every time the 
Unicode Consortium rules change.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org





From owner-idn@ops.ietf.org  Sat Jan 26 06:43:38 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05530
	for <idn-archive@lists.ietf.org>; Sat, 26 Jan 2002 06:43:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UR1p-000Lqk-00
	for idn-data@psg.com; Sat, 26 Jan 2002 03:29:49 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UR1o-000Lqe-00
	for idn@ops.ietf.org; Sat, 26 Jan 2002 03:29:48 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id MAA24545;
	Sat, 26 Jan 2002 12:29:42 +0100 (MET)
Date: Sat, 26 Jan 2002 11:51:56 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Stuart Cheshire <cheshire@apple.com>, idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <14913501.1012045916@localhost>
In-Reply-To: <200201260841.g0Q8fG612592@scv3.apple.com>
References:  <200201260841.g0Q8fG612592@scv3.apple.com>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA05530

--On 2002-01-26 00.41 -0800 Stuart Cheshire <cheshire@apple.com> wrote:

> Patrik F�ltstr�m wrote:
>> Example: If a.com and b.com is considered equal,
>> why should not a.se and b.se be equal?
> 
> a.com. IN A     1.2.3.4
> b.com. IN CNAME a.com.
> 
> a.se.  IN A     1.2.3.5
> b.se.  IN A     1.2.3.6
> 
> In this (very simplified) example, "b.com." is declared to be no more 
> than an alias for "a.com." Any lookup for any DNS record type for 
> "b.com." will return the same answer as a lookup for that DNS record type 
> for "a.com."
> 
> In contrast, "a.se." and "b.se." are different.
> 
> Why is this a problem?

My point was that when talking about "equal", in DNS we compare labels one
by one, without looking at context, i.e. neighboring labels. So, if "a" and
"b" are the same, then both a.se and b.se are same and a.com and b.com are
the same.

You show an example where "a" and "b" are different (from DNS matching
point of view) but the domain name holder of a.com and b.com want them to
resolve to the same IP-address.

Which of course is ok.

>> So, this wg decided that we will use one and only one matching rule,
>> just like we decided to use only one character set. Both of these
>> (the rule and the charset) are created in the Unicode Consortium.
>> 
>> You also talk about "evolving matching rules over time". That
>> is a very bad thing.
> 
> Unfortunately, the rules as created by the Unicode Consortium do change 
> over time. Apple's HFS+ file system uses Unicode file names, with the 
> restriction (as you would expect) that two files in a directory cannot 
> have the same name.
> 
> Unfortunately, when the Unicode Consortium rules change (we're currently 
> in the process of moving to Unicode 3.2 rules), this can result in two 
> files that were previously considered different names, to now be 
> considered the same name, hence resulting in an apparently invalid file 
> system.

The changes are very controlled, and no changes are made which have the
impact you tell.

> This is a mess. It would be much better if the file system on the volume 
> could assert the version of the Unicode Consortium rules by which it 
> abides, instead of being judged by the version of the Unicode Consortium 
> rules in effect at the time it is read.
> 
> Hence my suggestion that IDN avoid the same mistake, and let the 
> authoritative server for a domain assert the Unicode Consortium rules by 
> which it abides.


See section 6 of the draft-hoffman-stringprep-00.txt document about
versioning.

>> Let's say that we have registered apple.com and �pple.com. They
>> are considered different. One day the equivalence rule change,
>> and they are considered being the same. Who is calling Steve
>> Jobs saying that apple.com have to give back it's domain name
>> and pick something else? You? ICANN? The registry for .com?
> 
> Again, an argument supporting my suggestion that the authoritative server 
> for the "com" domain should be allowed to assert the Unicode Consortium 
> rules by which it abides, instead of having to change every time the 
> Unicode Consortium rules change.

See the stringprep document and think about the impact on RR-Sets if the
matching rules are different.

  paf




From owner-idn@ops.ietf.org  Sat Jan 26 08:22:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06529
	for <idn-archive@lists.ietf.org>; Sat, 26 Jan 2002 08:22:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16USTS-000NEZ-00
	for idn-data@psg.com; Sat, 26 Jan 2002 05:02:26 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16USTR-000NEO-00
	for idn@ops.ietf.org; Sat, 26 Jan 2002 05:02:25 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0QD24421661;
	Sat, 26 Jan 2002 21:02:04 +0800 (CST)
Message-ID: <009401c1a669$469f33a0$4007738c@q.j.tw>
From: =?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "Kenneth Whistler" <kenw@sybase.com>
Cc: <idn@ops.ietf.org>
References: <200201260407.UAA04911@birdie.sybase.com>
Subject: Re: Thread on - Re: [idn] Prohibit CDN code points
Date: Sat, 26 Jan 2002 20:59:21 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Kenneth  & all:
         Thanks your response to these questions.
----- Original Message -----
From: "Kenneth Whistler" <kenw@sybase.com>

> The string "U+006A" is a denotation for the Unicode code point (in
> the overall range of possible values 0..10FFFF), as well as the
> character encoded at that code point, namely LATIN SMALL LETTER J.
>
              You point out another question  I want to know,  the data type
and range of UNICODE point that toASCII function module will be inputed.
Because IDNA may be a common module for all applications,  but  today there
are not only one vender like NSI/ISC as before , so it should define and
describe more clearly.  As the traditional habit in protocol of IETF RFC ,
the parameter are passed by ASCII string,  but if it is ASCII string , the
delimiter of each character and indicater MUST be very clear. Especially ,
there will be some pure ASCII string name may also passed to it.

> The case doesn't matter, although the Unicode Standard most
> often uses uppercase. So some people would also use "U+006a" or
> "u+006a" for the same Unicode code point.
>
> >
> > My question are:
> > Q1:   U+hhhh  can be represented as u+hhhh  or not ?
>
> Yes. And you can also just leave off
> the U+ altogether where it is clear you are referring to
> Unicode characters, i.e. "hhhh", so for the LATIN SMALL LETTER J,
> just "006A" or "006a".
>
> > Q2:   Here U+HHHH  is not a hostname , does it MUST be forced to lower
> > u+hhhh or not  in nameprep ?
>
> I think you are mixing things up. If you put a Unicode character
> into a hostname, you don't literally put the string "U+006A" (or
> whatever) into the hostname, you put the Unicode encoded representation,
> in whatever form of Unicode you are using, into the hostname.
>
> Thus, if my hostname was "jam", in Unicode UTF-8, that would be
> just 0x6A 0x61 0x6D, since the Unicode values for ASCII characters
> like "j" are the same as ASCII in UTF-8.
>
> If my hostname was the Chinese word for 'banana', just to pick
> a random example, that consists of two characters (pinyin: xiang1jiao1).
> The Unicode values for those characters are U+9999 U+8549. If you
> have a Unicode string, that would just be two 16-bit numbers,
> 0x9999 followed by 0x8549, if using Unicode UTF-16, or the
> following byte sequence if using Unicode UTF-8: 0xE9 0xA6 0x99
> 0xE8 0x95 0x89.
>
       Sorry,  in a function module , like such inportant one " toASCII" ,
the input parameter of  type , size range and representing format should be
defined more clearily to support inter-operability.
> > Q3:  Puny code  draft  accept  U+hhhh  or  u+hhhh  to let the final
encoded
> > ASCII character (last character of corresponding  encoded code point)
with
> > case upper or lower.
>
> If I am interpreting things correctly, Punycode is defined on the
> Unicode code points, and certainly not on
> the short identifier strings for the Unicode code points.
> So for the Chinese 'banana' example, you'd be encoding two
> code point integers (39321 = 0x9999, followed by 34121 = 0x8549),
> *not* the string of integers corresponding to the ASCII
> string "U+9999U+8549".
>
          You just point out the problem ,  how to differentiate them ?
IDNA  module is a common module shared by most applications or a full set
belong to each AP  independetly is not the same results in these
descriptions .  Does some one can clarify it more clearly ?

> Of course, somebody might want to try having a hostname or
> domain name of "U+9999U+8549", but that is a 12 character ASCII
> string, and is not the same thing at all as the two-character
> Unicode string for the Chinese word for 'banana'.
>
          It is different , but you can not avoid people to register such
name .  If it is a common module to all , it should consider the influence
from such input.

Thanks to all the reply
L.M.Tseng




From owner-idn@ops.ietf.org  Sat Jan 26 08:36:47 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06873
	for <idn-archive@lists.ietf.org>; Sat, 26 Jan 2002 08:36:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UStM-000NfS-00
	for idn-data@psg.com; Sat, 26 Jan 2002 05:29:12 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UStL-000NfM-00
	for idn@ops.ietf.org; Sat, 26 Jan 2002 05:29:11 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA01589;
	Sat, 26 Jan 2002 14:28:48 +0100 (MET)
Date: Sat, 26 Jan 2002 14:28:25 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: "=?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?=" <tsenglm@cc.ncu.edu.tw>,
        Kenneth Whistler <kenw@sybase.com>
cc: idn@ops.ietf.org
Subject: Re: Thread on - Re: [idn] Prohibit CDN code points
Message-ID: <15476872.1012055305@localhost>
In-Reply-To: <009401c1a669$469f33a0$4007738c@q.j.tw>
References: <200201260407.UAA04911@birdie.sybase.com>
 <009401c1a669$469f33a0$4007738c@q.j.tw>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-26 20.59 +0800 "=?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?="
<tsenglm@cc.ncu.edu.tw> wrote:

>           You just point out the problem ,  how to differentiate them ?
> IDNA  module is a common module shared by most applications or a full set
> belong to each AP  independetly is not the same results in these
> descriptions .  Does some one can clarify it more clearly ?

IDNA specifies what goes on the wire between two applications. Not what
libraries, functions etc are to be developed to reach that goal.

The functions specified in the IDNA draft is a functional specification on
what must happen with the strings. Not a specification of functions which
should exist in libc or such.

My personal guess is that we will see ToUnicode and ToAscii functions in
libraries which already take care of charset conversion. Like the Text
Encoding Converter from Apple. (see
http://developer.apple.com/techpubs/macos8/TextIntlSvcs/TextEncodingConvers
ionManager/TEC1.5/TEC.38.html)

Similar modules will certainly be developed as perl libraries and what not.

Many of them probably takes a native charset as input (such as BIG-5 or
ISO-8859-1) and not some encoding of Unicode.

IETF extremely rarely develops API's.

  paf




From owner-idn@ops.ietf.org  Sat Jan 26 20:02:39 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12683
	for <idn-archive@lists.ietf.org>; Sat, 26 Jan 2002 20:02:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UdPv-0008wt-00
	for idn-data@psg.com; Sat, 26 Jan 2002 16:43:31 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UdPu-0008wk-00
	for idn@ops.ietf.org; Sat, 26 Jan 2002 16:43:30 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0R0hJ405040
	for <idn@ops.ietf.org>; Sun, 27 Jan 2002 08:43:20 +0800 (CST)
Message-ID: <002b01c1a6cb$3f59b4a0$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "IETF idn working group" <idn@ops.ietf.org>
References: <c5.1cd8c61e.29803d8b@cs.com> <006801c1a43c$b87430e0$0601a8c0@neteka.com> <3C4E488E.AAEB8AF9@zetnet.co.uk> <01a001c1a4d9$ee9141c0$1901000a@jamessonyvaio> <001701c1a612$b0d5ac60$4007738c@q.j.tw> <20020126041536.GC19927@nicemice.net>
Subject: Re: Thread on - Re: [idn] Prohibit CDN code points
Date: Sun, 27 Jan 2002 08:40:35 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear  Adam  & all :
          Thanks your reply ,  It is very clear, Punycode has some optional
features that can be selected by the implementers.  How to input the
information of  annotational flag is an implementation issue.

> > Q1:  U+hhhh can be represented as u+hhhh or not ?
>
> The Unicode standard always uses U+, never u+, and the same is true of
> the IDNA draft.  The Punycode draft always uses U+ in the main spec, but
> the sample implementation uses both U+ and u+ in order to represent the
> annotation flags, and the examples section likewise uses both U+ and u+
> to make it easy to feed the examples into the sample implementation.
>
        To my understand, I descrbe it as:  if the implementation want to
use the feature of  annotation, then the flag of annotation should be passed
from  ToASCII  thru nameprep to Punycode. If a tradition of  IETF RFC
protocol  is followed , input parameter by an ASCII  string  like U+hhhh
will be used ,  so  U+/u+  can be an annotational flags.
> > Q2:  Here U+HHHH is not a hostname , does it MUST be forced to lower
> > u+hhhh or not in nameprep ?
>
> The case of the U is not part of the code point.  A code point is just
> an integer.  For example, U+0391 and u+0391 both represent the integer
> 913 (decimal) which is the code point for uppercase alpha.  U+03B1
> and u+03B1 both represent the integer 945 (decimal) which is the code
> point for lowercase alpha.  Nameprep always converts uppercase alpha
> to lowercase alpha (so it would always output 945, never 913), but a
> nameprep implementation that included support for mixed case annotations
> would output not only an array of code points but also a parallel
> array of case flags, and the lowercase alpha (945) would be flagged
> as "wanting to be uppercase".  The flags could be passed along to the
> Punycode encoder and recovered by the Punycode decoder.
>
> The Punycode sample implementation and examples sections use U+03B1
> to mean "lowercase alpha with flag set (wants to be uppercase)" and
> use u+03B1 to mean "lowercase alpha with flag clear (wants to stay
> lowercase)".
>
> The flags have no affect on which ASCII letters and digits are output
> by the Punycode encoder.  The flags merely affects the upper/lowercase
> property of the ASCII letters.
>
              I  think it is very clear,  the annotational flag just let the
Punycode input from an original  U/u+hhhh can output a LDH string with  a
upper/lower  character is set in its corresponding output part.  Punycode do
not change any results from nameprep even  it is work in single case
annotational mode.
            Actually, any  ACE encoder  can  do it the same way, but
Punycode is a special one that  treat basic code point and non-basic-point
as two separate parts, so it can let original flag information  can be
displayed in output string  even the coded ACE string is a lower case code
point .  The displayed case is no effect in DNS query, but it can help to
let user to view an original IDN form without  feeling  the nameprep has do
some strange thing to the ML-domain name.

Thanks  your  careful answers.
Best regards

L.M.Tseng




From owner-idn@ops.ietf.org  Sat Jan 26 20:19:14 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12763
	for <idn-archive@lists.ietf.org>; Sat, 26 Jan 2002 20:19:14 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Udj6-0009L1-00
	for idn-data@psg.com; Sat, 26 Jan 2002 17:03:20 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Udj5-0009Ku-00
	for idn@ops.ietf.org; Sat, 26 Jan 2002 17:03:19 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0R12W407718;
	Sun, 27 Jan 2002 09:02:36 +0800 (CST)
Message-ID: <001901c1a6cd$f0fb6bc0$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: "Dave Crocker" <dhc@dcrocker.net>
Cc: "YangWoo Ko" <newcat@spsoft.co.kr>, "IETF-IDN" <idn@ops.ietf.org>
References: <IHELIFNJKJLDFEMBCENDAEPHCLAA.huangk@alum.sinica.edu> <p05101204b870ab94166d@[165.227.249.20]> <3C4E8931.6080908@twnic.net.tw> <1676461.1011789799@localhost> <20020123214733.A9627@spsoft.co.kr> <2017401.1011795481@localhost> <20020123232445.C9627@spsoft.co.kr> <5.1.0.14.2.20020123095614.03c7de98@127.0.0.1>
Subject: Re: [idn] Prohibit CDN code points
Date: Sun, 27 Jan 2002 08:59:52 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Dave & all:
----- Original Message -----
From: "Dave Crocker" <dhc@dcrocker.net>
To: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>
Cc: "YangWoo Ko" <newcat@spsoft.co.kr>; "IETF-IDN" <idn@ops.ietf.org>
Sent: Thursday, January 24, 2002 2:35 AM
Subject: Re: [idn] Prohibit CDN code points


> At 12:29 AM 1/24/2002 +0800,
> =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= wrote:
> >           I  totally agree with these , whether the UNICODE is unified
or
> >not , it is not the issue in this thread, we want to know where is the
> >interface or room in IDNA and through which  the localization results and
> >information  can be passed.
>
> A standard that is focused on international interoperability cannot be the
> place for localization.
>
> So, the place for what you are seeking is outside IDNA.  In terms of
> architecture, it is at a layer above IDNA.
>
> d/
>
               A  layer above IDNA is a cocept view .  A layer above IDNA
may by-pass the lower layer and directly communicate in the wire  if there
are no entry or interface that the above localization module can exchange
the information between them . If  the requirement is neglected  and there
are no way to go ,  the international interoperability will not be keep in
proper way.
               I  think  Japan, Korean and China all want to know where is
the interface they can go thru .

L.M.Tseng

>
> ----------
> Dave Crocker  <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464
>
>




From owner-idn@ops.ietf.org  Sun Jan 27 03:01:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26879
	for <idn-archive@lists.ietf.org>; Sun, 27 Jan 2002 03:01:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UjvK-000Fne-00
	for idn-data@psg.com; Sat, 26 Jan 2002 23:40:22 -0800
Received: from mail-out1.apple.com ([17.254.0.52])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UjvJ-000FnY-00
	for idn@ops.ietf.org; Sat, 26 Jan 2002 23:40:21 -0800
Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225])
	by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g0R7eKQ25498
	for <idn@ops.ietf.org>; Sat, 26 Jan 2002 23:40:20 -0800 (PST)
Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T58b1942ea2118064e1388@mailgate1.apple.com>;
 Sat, 26 Jan 2002 23:40:00 -0800
Received: from [206.111.147.149] (vpn-gh-574.apple.com [17.254.138.61])
	by scv1.apple.com (8.11.3/8.11.3) with SMTP id g0R7eJI22853;
	Sat, 26 Jan 2002 23:40:19 -0800 (PST)
Message-Id: <200201270740.g0R7eJI22853@scv1.apple.com>
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Date: Sat, 26 Jan 2002 23:40:19 -0800
x-sender: cheshire@mail.apple.com
x-mailer: Claris Emailer 2.0v3, January 22, 1998
From: Stuart Cheshire <cheshire@apple.com>
To: "Patrik F=?ISO-8859-1?Q?=e4ltstr=f6m?=" <paf@cisco.com>,
        <idn@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

>My point was that when talking about "equal", in DNS we compare
>labels one by one, without looking at context, i.e. neighboring
>labels. So, if "a" and "b" are the same, then both a.se and
>b.se are same and a.com and b.com are the same.
>
>You show an example where "a" and "b" are different (from DNS
>matching point of view) but the domain name holder of a.com
>and b.com want them to resolve to the same IP-address.
>
>Which of course is ok.

Then I'm afraid I don't see your objection to my original proposal, which 
was *precisely* what you just said, namely: the DNS protocol doesn't 
determine if two names are equal; let the domain name holder decide.

>The changes are very controlled, and no changes are made which have
>the impact you tell.

I wish. I have to sit through the meetings where the file system guys 
debate how to handle each rule change, and its impact on forward and 
backward interoperability.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org





From owner-idn@ops.ietf.org  Sun Jan 27 05:37:01 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28230
	for <idn-archive@lists.ietf.org>; Sun, 27 Jan 2002 05:37:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16UmXk-000Hdf-00
	for idn-data@psg.com; Sun, 27 Jan 2002 02:28:12 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16UmXj-000HdZ-00
	for idn@ops.ietf.org; Sun, 27 Jan 2002 02:28:11 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA15538;
	Sun, 27 Jan 2002 11:28:04 +0100 (MET)
Date: Sun, 27 Jan 2002 11:13:59 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Stuart Cheshire <cheshire@apple.com>, idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <19960984.1012130039@localhost>
In-Reply-To: <200201270740.g0R7eJI22853@scv1.apple.com>
References:  <200201270740.g0R7eJI22853@scv1.apple.com>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-26 23.40 -0800 Stuart Cheshire <cheshire@apple.com> wrote:

> Then I'm afraid I don't see your objection to my original proposal, which 
> was *precisely* what you just said, namely: the DNS protocol doesn't 
> determine if two names are equal; let the domain name holder decide.

That was not what you said. You said:

> It seems to me that the solution is to give up on the idea of a single 
> global set of rules, and instead let each name server be authoritative 
> for the equivalence rules for the zones for which it is authoritative.

That is a completely different thing, and that was what I objected to.

The servers need to have exactly the same rules.

>> The changes are very controlled, and no changes are made which have
>> the impact you tell.
> 
> I wish. I have to sit through the meetings where the file system guys 
> debate how to handle each rule change, and its impact on forward and 
> backward interoperability.

Give one example after Unicode 3.0. (There is one change, and you might
catch that one, but that change was deliberate, and made in cooperation
with IETF....i.e. it was decided to make that change to 3.1 just because
IDN had not taken off yet.)

Before 3.0, sure.

And, yes, your filesystem guys have digged a very deep hole in the ground
where they are currently, trying to get up. I am thinking of the ability of
use of UFS or HFS(+) for MacOSX, where things like case insensitivity in
HFS+ is biting them. I have had some problems with Perl CPAN install
mechanisms which rely's on the fact that "Makefile" and "makefile" actually
should be two different files in "normal" UFS....so there are some problems
with some install scripts from CPAN.

So, I understand the discussions you have inhouse...I don't want to be
there.

  paf -- Very happy MacOSX user!!!





From owner-idn@ops.ietf.org  Sun Jan 27 20:48:23 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05760
	for <idn-archive@lists.ietf.org>; Sun, 27 Jan 2002 20:48:22 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16V0io-0000wG-00
	for idn-data@psg.com; Sun, 27 Jan 2002 17:36:34 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16V0in-0000vw-00
	for idn@ops.ietf.org; Sun, 27 Jan 2002 17:36:33 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0S1ZP404262;
	Mon, 28 Jan 2002 09:35:25 +0800 (CST)
Message-ID: <000d01c1a79b$b5a2cf40$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "Kenneth Whistler" <kenw@sybase.com>
Cc: <idn@ops.ietf.org>
References: <200201260407.UAA04911@birdie.sybase.com> <009401c1a669$469f33a0$4007738c@q.j.tw> <15476872.1012055305@localhost>
Subject: [idn] Mapping and Prohibit  of code points
Date: Mon, 28 Jan 2002 09:32:47 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Patrik Fältström & all:
                   I think to change a subject may be more good .
1. The problems:
          There are many need about character mapping and prohibition of
code points that are  more than the draft of nameprep described,  someone
call them local issue ,  language or area related issue.
2. The  interface before and after IDNA module:
         To solve these problems, the pre-IDNA approach is not clear,
especially in the interface.
Currently,  we can find web navigation of  Realname/Microsoft help to  do
resolving of   Verisign's IDN testbed. But  that is  one possible approach ,
some character mapping and prohibition can be processed in external matching
and conversion server.
         IDNA  approach is based on  ACE  encoding for backward
compatibility ,  we can view the ACE encoding approach is a tunnel
technology between client and server based on current  LDH-DNS server and
TLD.  As discussed in the mailing list , based on exhausted  label mapping ,
some kind of character mapping can be achieved by  multiple RR of
CNAME/DNAME  ,  such small and simple case can be done in this way . If  the
character mapping is a combination  in label then a  gateway to do multiple
matching rule  is need to reduce a lot of  label  records.  Actually a
gateway combined with the function of  UTF-8 DNS-like server may be one of
the approach .
3.  To  force  some character mapping/prohibition  out of  nameprep and call
them local issue without using the option concept  is not a good solution ,
but if  it can not be avoid in this architecture ,  then  the interface of
pre-IDNA  and post-ACE-encoding  MUST be defined clearly .  To use
ACE-string and  TLD as gateway selection  is in the  range of  DNS protocol
. By using  HTTP protocol  and web navigation  or another protocol  to reach
external server to do multiple matching  is out of  DNS  protocol  and out
of the expectation of  DNS manager.

L.M.Tseng

4. Which  solution is beter ?  that depends on requirements of user  and
expectations  of  DNS manager.   All the problem is  "where to do local
character/string mapping ? "   Annotational multi-case Punycode
encoding/decoding is a powerful  tool to do such mapping and multiple
matching  based on a uniform LDH-DNS matching rule.


----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>

> IDNA specifies what goes on the wire between two applications. Not what
> libraries, functions etc are to be developed to reach that goal.
>
> The functions specified in the IDNA draft is a functional specification on
> what must happen with the strings. Not a specification of functions which
> should exist in libc or such.
>
> My personal guess is that we will see ToUnicode and ToAscii functions in
> libraries which already take care of charset conversion. Like the Text
> Encoding Converter from Apple. (see
>
http://developer.apple.com/techpubs/macos8/TextIntlSvcs/TextEncodingConvers
> ionManager/TEC1.5/TEC.38.html)
>
> Similar modules will certainly be developed as perl libraries and what
not.
>
> Many of them probably takes a native charset as input (such as BIG-5 or
> ISO-8859-1) and not some encoding of Unicode.
>
> IETF extremely rarely develops API's.
>
>   paf
>
>




From owner-idn@ops.ietf.org  Mon Jan 28 02:21:33 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19562
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 02:21:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16V5tk-0004rQ-00
	for idn-data@psg.com; Sun, 27 Jan 2002 23:08:12 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16V5ti-0004rI-00
	for idn@ops.ietf.org; Sun, 27 Jan 2002 23:08:11 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA06023;
	Mon, 28 Jan 2002 08:07:30 +0100 (MET)
Date: Mon, 28 Jan 2002 08:03:55 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: "=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?=" <tsenglm@cc.ncu.edu.tw>,
        Kenneth Whistler <kenw@sybase.com>
cc: idn@ops.ietf.org
Subject: Re: [idn] Mapping and Prohibit  of code points
Message-ID: <24460853.1012205035@localhost>
In-Reply-To: <000d01c1a79b$b5a2cf40$4007738c@q.j.tw>
References: <200201260407.UAA04911@birdie.sybase.com>
 <009401c1a669$469f33a0$4007738c@q.j.tw> <15476872.1012055305@localhost>
 <000d01c1a79b$b5a2cf40$4007738c@q.j.tw>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-28 09.32 +0800
"=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<tsenglm@cc.ncu.edu.tw> wrote:

> 1. The problems:
>           There are many need about character mapping and prohibition of
> code points that are  more than the draft of nameprep described,  someone
> call them local issue ,  language or area related issue.

They are language, culture and other context dependent, and therefore a
localization issue, not internationalization issue and out of scope for
this wg.

> 2. The  interface before and after IDNA module:
>          To solve these problems, the pre-IDNA approach is not clear,
> especially in the interface.

You mix up a large number of things here. None of them is part of what this
working group is working with.

> Currently,  we can find web navigation of  Realname/Microsoft help to  do
> resolving of   Verisign's IDN testbed.

This binding doesn't exist explicitly. Some web browsers after a NXDOMAIN
response is going to a search system like Realname/Microsoft with the
domainname. That is one thing. Lack of support for the IETF IDN wg results
in the browsers of today is another. None of these have to do with
localization or "interface to IDNA".

> But  that is  one possible
> approach , some character mapping and prohibition can be processed in
> external matching and conversion server.

Yes, but that is done in a layer "above" DNS. Not as a replacement or in
parallell with DNS. Domain name is one thing and keyword another. You mix
them up.

>          IDNA  approach is based on  ACE  encoding for backward
> compatibility ,  we can view the ACE encoding approach is a tunnel
> technology between client and server based on current  LDH-DNS server and
> TLD.

Sort of, but rather from the client application and the registrant as the
encoding is invisible for the server aswell.

>  As discussed in the mailing list , based on exhausted  label
> mapping , some kind of character mapping can be achieved by  multiple RR
> of CNAME/DNAME  ,

Not DNAME. DNAME should not be used. And, you do not do character mapping. 

In DNS you make sure that a client get a response regardless of what the
query is. You might say that the result is the same for the user, but, it
is not translation which is done.

>  such small and simple case can be done in this way .

Yes.

> If  the character mapping is a combination  in label then a  gateway to
> do multiple matching rule  is need to reduce a lot of  label  records.

No. As I explaind on a different thread last week (see the archives), as
soon as you change the matching rules locally, you change the definition of
a RR-Set.

> Actually a gateway combined with the function of  UTF-8 DNS-like server
> may be one of the approach .

No. UTF-8 have nothing to do with this. UTF-8 is just another encoding of
Unicode.

What you really talk about (I think) is how to handle the IDN solution as
soon as possible, before applications have support for IDNA. And, your
proposal is to store whatever garbage the applications will send over the
network in the DNS servers in the encoding the clients happens to use. This
implies BIG5, UTF-8 encoded non-nameprepped Unicode, ISO-8859-1 and many
other charsets.

That should _NOT_ be done, as there is no way of discovering what charset
is used, and this will because of this lead to explicit domain name
infridgement which in turn is treated as trademark infringement.

Further, the application layer protocols can not handle other characters
than LDH, so you loose anyway.

All of this has already been discussed many times on this mailing list.

Especially the definition of RR-Sets. Didn't you see that last week?

> 3.  To  force  some character mapping/prohibition  out of  nameprep and
> call them local issue without using the option concept  is not a good
> solution , but if  it can not be avoid in this architecture ,  then  the
> interface of pre-IDNA  and post-ACE-encoding  MUST be defined clearly .

Maybe, but it is not a work for IETF. IETF do not work with API's.

IETF have not made API's for access to quoted-printable.

> To use ACE-string and  TLD as gateway selection  is in the  range of  DNS
> protocol . By using  HTTP protocol  and web navigation  or another
> protocol  to reach external server to do multiple matching  is out of
> DNS  protocol  and out of the expectation of  DNS manager.

Exactly.

> 4. Which  solution is beter ?  that depends on requirements of user  and
> expectations  of  DNS manager.   All the problem is  "where to do local
> character/string mapping ? "   Annotational multi-case Punycode
> encoding/decoding is a powerful  tool to do such mapping and multiple
> matching  based on a uniform LDH-DNS matching rule.

As I have said earlier, it is discussed in another forum than this wg.
Please stop talking about it here.

   paf




From owner-idn@ops.ietf.org  Mon Jan 28 02:54:02 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19919
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 02:54:02 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16V6WN-0005Ia-00
	for idn-data@psg.com; Sun, 27 Jan 2002 23:48:07 -0800
Received: from imo-m03.mx.aol.com ([64.12.136.6])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16V6WM-0005IU-00
	for idn@ops.ietf.org; Sun, 27 Jan 2002 23:48:07 -0800
Received: from DougEwell2@cs.com
	by imo-m03.mx.aol.com (mail_out_v31_r1.26.) id i.f2.15c9c254 (4395);
	Mon, 28 Jan 2002 02:47:53 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <f2.15c9c254.29865c29@cs.com>
Date: Mon, 28 Jan 2002 02:47:53 EST
Subject: Re: [idn] Mapping and Prohibit  of code points
To: idn@ops.ietf.org
CC: tsenglm@cc.ncu.edu.tw, kenw@sybase.com, paf@cisco.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I know the chairs consider this thread off-topic, so I will keep this brief.

The only result that can come from excluding Han characters from the IDN 
model "until" a solution to the claimed CJK problem is developed, is to 
ensure the failure of the currently planned IDN model.

Opponents would be able to claim truthfully that IDN completely fails to 
support CJK, which of course would be true if Han characters were prohibited.

They would then mount a new campaign to replace the discredited IDN model 
with a new CJK-oriented model, with local variations instead of global 
uniformity.

I am certain that at least some of those who are calling for CJK prohibition 
understand this.

-Doug Ewell
 Fullerton, California



From owner-idn@ops.ietf.org  Mon Jan 28 03:20:40 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20287
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 03:20:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16V6wi-0005oy-00
	for idn-data@psg.com; Mon, 28 Jan 2002 00:15:20 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16V6wh-0005os-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 00:15:20 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g0S8Fd201001
	for idn@ops.ietf.org; Mon, 28 Jan 2002 17:15:39 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Mon, 28 Jan 2002 17:15:39 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: idn@ops.ietf.org
Subject: Re: [idn] Mapping and Prohibit  of code points
Message-ID: <20020128081539.GB914@spsoft.co.kr>
References: <f2.15c9c254.29865c29@cs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <f2.15c9c254.29865c29@cs.com>
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Mon, Jan 28, 2002 at 02:47:53AM -0500, DougEwell2@cs.com wrote:
> I know the chairs consider this thread off-topic, so I will keep this brief.

Yes, I agree. Let's keep it brief.

> The only result that can come from excluding Han characters from the IDN 
> model "until" a solution to the claimed CJK problem is developed, is to 
> ensure the failure of the currently planned IDN model.
> 
> Opponents would be able to claim truthfully that IDN completely fails to 
> support CJK, which of course would be true if Han characters were prohibited.
> 
> They would then mount a new campaign to replace the discredited IDN model 
> with a new CJK-oriented model, with local variations instead of global 
> uniformity.

Your conclusion seems to be too hasty. As far as I can tell from postings
so far, they do not want "pre-" matured solution to be deployed which will
prevent deployment of "well-" matured solution in the future. That's it.

As Kenny Huang suggested, if nobody had a tangible solution right now in
hand, please make this off-topic for a while, and wait for good solution.

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Mon Jan 28 05:04:49 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21539
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 05:04:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16V8Rq-0006tK-00
	for idn-data@psg.com; Mon, 28 Jan 2002 01:51:34 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16V8Ro-0006tD-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 01:51:33 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0S9ogW25510;
	Mon, 28 Jan 2002 17:50:42 +0800 (CST)
Message-ID: <000d01c1a7e0$e50afce0$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "Kenneth Whistler" <kenw@sybase.com>
Cc: <idn@ops.ietf.org>
References: <200201260407.UAA04911@birdie.sybase.com> <009401c1a669$469f33a0$4007738c@q.j.tw> <15476872.1012055305@localhost> <000d01c1a79b$b5a2cf40$4007738c@q.j.tw> <24460853.1012205035@localhost>
Subject: Re: [idn] Mapping and Prohibit  of code points
Date: Mon, 28 Jan 2002 17:48:08 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>

>
> > Currently,  we can find web navigation of  Realname/Microsoft help to
do
> > resolving of   Verisign's IDN testbed.
>
> This binding doesn't exist explicitly. Some web browsers after a NXDOMAIN
> response is going to a search system like Realname/Microsoft with the
> domainname. That is one thing. Lack of support for the IETF IDN wg results
> in the browsers of today is another. None of these have to do with
> localization or "interface to IDNA".
>
> > But  that is  one possible
> > approach , some character mapping and prohibition can be processed in
> > external matching and conversion server.
>
> Yes, but that is done in a layer "above" DNS. Not as a replacement or in
> parallell with DNS. Domain name is one thing and keyword another. You mix
> them up.
>
                The possibility of external  NON-LDH-name server is existed
. It is isolated from current LDH-DNS server or cooperated by layer upon
LDH-DNS server or to  replace it or in parallel can not be easily
predicated.

> >          IDNA  approach is based on  ACE  encoding for backward
> > compatibility ,  we can view the ACE encoding approach is a tunnel
> > technology between client and server based on current  LDH-DNS server
and
> > TLD.
>
> Sort of, but rather from the client application and the registrant as the
> encoding is invisible for the server aswell.
>
> >  As discussed in the mailing list , based on exhausted  label
> > mapping , some kind of character mapping can be achieved by  multiple RR
> > of CNAME/DNAME  ,
>
> Not DNAME. DNAME should not be used. And, you do not do character mapping.
>
> In DNS you make sure that a client get a response regardless of what the
> query is. You might say that the result is the same for the user, but, it
> is not translation which is done.
>
> >  such small and simple case can be done in this way .
>
> Yes.
>
> > If  the character mapping is a combination  in label then a  gateway to
> > do multiple matching rule  is need to reduce a lot of  label  records.
>
> No. As I explaind on a different thread last week (see the archives), as
> soon as you change the matching rules locally, you change the definition
of
> a RR-Set.
>
> > Actually a gateway combined with the function of  UTF-8 DNS-like server
> > may be one of the approach .
>
> No. UTF-8 have nothing to do with this. UTF-8 is just another encoding of
> Unicode.
>
> What you really talk about (I think) is how to handle the IDN solution as
> soon as possible, before applications have support for IDNA. And, your
> proposal is to store whatever garbage the applications will send over the
> network in the DNS servers in the encoding the clients happens to use.
This
> implies BIG5, UTF-8 encoded non-nameprepped Unicode, ISO-8859-1 and many
> other charsets.
>
> That should _NOT_ be done, as there is no way of discovering what charset
> is used, and this will because of this lead to explicit domain name
> infridgement which in turn is treated as trademark infringement.
>
> Further, the application layer protocols can not handle other characters
> than LDH, so you loose anyway.
>
> All of this has already been discussed many times on this mailing list.
>
> Especially the definition of RR-Sets. Didn't you see that last week?
>
            I think you talk a solution that TWNIC/CNNIC have been used  in
transition state,  to a registry , the original name that is registered is
independent of  any encoding ,  that will be there.  Try to support service
in testbed can find many important issue.  I  have implement an experimental
Virtual Domain Name system that based on RACE , but support  any query  of
UTF-8, BIG5 , RACE  because they can be identified without language tag ,
but  mixed BIG5 , GB is not so easy to differentiate them as you point-out,
if it is suported by  HTTP protocol with lang-tag and used for browser ,
there are no problems,  that is the system you called  keyword  approach and
now I think  Realname/MicroSoft/VeriSign used in resolving by web
navigation. Unfortunately , that is only my personal experimental system to
try to solve TC/SC problems.
           Why I mention UTF-8 here , because based on current BIND DNS
technology that can  do character mapping easily .  If these server are
isolated from current LDH-DNS server , it can be a layer-2 server , it also
can be a gateway to do character mapping .
           Whether it is a Layer-2 server betwwen AP and IDNA nameprep or
it is a gateway between resolver and LDH-DNS server that is not so
important. Even I know the solution existed  in  multi-case AMC-Z encoding ,
but nameprep and IDNA fixed to refused to support it .  I  still  want to
solve our TC/SC problems first or we should to avoid to use the
non-suporting scheme.


> > 3.  To  force  some character mapping/prohibition  out of  nameprep and
> > call them local issue without using the option concept  is not a good
> > solution , but if  it can not be avoid in this architecture ,  then  the
> > interface of pre-IDNA  and post-ACE-encoding  MUST be defined clearly .
>
> Maybe, but it is not a work for IETF. IETF do not work with API's.
>
> IETF have not made API's for access to quoted-printable.
>
> > To use ACE-string and  TLD as gateway selection  is in the  range of
DNS
> > protocol . By using  HTTP protocol  and web navigation  or another
> > protocol  to reach external server to do multiple matching  is out of
> > DNS  protocol  and out of the expectation of  DNS manager.
>
> Exactly.
>
> > 4. Which  solution is beter ?  that depends on requirements of user  and
> > expectations  of  DNS manager.   All the problem is  "where to do local
> > character/string mapping ? "   Annotational multi-case Punycode
> > encoding/decoding is a powerful  tool to do such mapping and multiple
> > matching  based on a uniform LDH-DNS matching rule.
>
> As I have said earlier, it is discussed in another forum than this wg.
> Please stop talking about it here.
>
            To do  matching  by nameprep and ACE conversion then by LDH
server with single matching rule or to do multiple matching in higher layer
or gateway  then do single matching in LDH DNS server is not so boundary
clearily .  To us , we can select any approach to solve the  problems that
are initiated from UNICODE and this  IDN WG.
            May be the current nameprep should be  a local issue.

L.M.Tseng




From owner-idn@ops.ietf.org  Mon Jan 28 08:34:02 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24597
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 08:34:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VBck-00095s-00
	for idn-data@psg.com; Mon, 28 Jan 2002 05:15:02 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VBai-000943-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 05:14:01 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GQNGOT00.OIO; Mon,
          28 Jan 2002 21:12:29 +0800 
Message-ID: <005b01c1a7fc$33753100$4407e29f@deng>
From: "xiang deng" <deng@cnnic.net.cn>
To: "YangWoo Ko" <newcat@spsoft.co.kr>, <idn@ops.ietf.org>
References: <f2.15c9c254.29865c29@cs.com> <20020128081539.GB914@spsoft.co.kr>
Subject: Re: [idn] Mapping and Prohibit  of code points
Date: Mon, 28 Jan 2002 21:03:37 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id IAA24597


From: "YangWoo Ko" <newcat@spsoft.co.kr>

> On Mon, Jan 28, 2002 at 02:47:53AM -0500, DougEwell2@cs.com wrote:
> > I know the chairs consider this thread off-topic, so I will keep this brief.
> 
> Yes, I agree. Let's keep it brief.
> 
> > The only result that can come from excluding Han characters from the IDN 
> > model "until" a solution to the claimed CJK problem is developed, is to 
> > ensure the failure of the currently planned IDN model.
> > 
> > Opponents would be able to claim truthfully that IDN completely fails to 
> > support CJK, which of course would be true if Han characters were prohibited.
> > 
> > They would then mount a new campaign to replace the discredited IDN model 
> > with a new CJK-oriented model, with local variations instead of global 
> > uniformity.
> 
> Your conclusion seems to be too hasty. As far as I can tell from postings
> so far, they do not want "pre-" matured solution to be deployed which will
> prevent deployment of "well-" matured solution in the future. That's it.
> 
> As Kenny Huang suggested, if nobody had a tangible solution right now in
> hand, please make this off-topic for a while, and wait for good solution.

Exactly. 

Deng xiang 


From owner-idn@ops.ietf.org  Mon Jan 28 10:05:15 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28423
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 10:05:15 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VD36-000AZv-00
	for idn-data@psg.com; Mon, 28 Jan 2002 06:46:20 -0800
Received: from mail.paconline.net ([66.51.160.50])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VD35-000AZp-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 06:46:19 -0800
Received: from cs881964a ([24.43.70.205]) by mail.paconline.net
          (Post.Office MTA v3.5.3 release 223 ID# 0-72142U6300L600S0V35)
          with SMTP id net; Mon, 28 Jan 2002 07:01:38 -0800
Message-ID: <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com>
From: "ben" <ben@cc-www.com>
To: <DougEwell2@cs.com>, <idn@ops.ietf.org>
Cc: <tsenglm@cc.ncu.edu.tw>, <kenw@sybase.com>, <paf@cisco.com>
References: <f2.15c9c254.29865c29@cs.com>
Subject: [idn] Re: peanut gallery
Date: Mon, 28 Jan 2002 09:56:15 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Doug,

Rest assured that no one is trying to completely failed the IDN model.

The only possibility/compromise that I have read so far in these
posting is to "prohibit Simplified Chinese code points"... and even
with that idea, the WG is waiting for an Internet Draft before there
could be further discussions/considerations.

If I can't use IDNs in a couple of months, then I suggest changing the
name of the IETF to BPG (big peanut gallery).

Thanks,
Ben


----- Original Message -----
From: <DougEwell2@cs.com>
To: <idn@ops.ietf.org>
Cc: <tsenglm@cc.ncu.edu.tw>; <kenw@sybase.com>; <paf@cisco.com>
Sent: Monday, January 28, 2002 2:47 AM
Subject: Re: [idn] Mapping and Prohibit of code points


> I know the chairs consider this thread off-topic, so I will keep
this brief.
>
> The only result that can come from excluding Han characters from the
IDN
> model "until" a solution to the claimed CJK problem is developed, is
to
> ensure the failure of the currently planned IDN model.
>
> Opponents would be able to claim truthfully that IDN completely
fails to
> support CJK, which of course would be true if Han characters were
prohibited.
>
> They would then mount a new campaign to replace the discredited IDN
model
> with a new CJK-oriented model, with local variations instead of
global
> uniformity.
>
> I am certain that at least some of those who are calling for CJK
prohibition
> understand this.
>
> -Doug Ewell
>  Fullerton, California
>
>




From owner-idn@ops.ietf.org  Mon Jan 28 11:09:05 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00892
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 11:09:05 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VE5B-000BVZ-00
	for idn-data@psg.com; Mon, 28 Jan 2002 07:52:33 -0800
Received: from rwcrmhc53.attbi.com ([204.127.198.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VE5A-000BVS-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 07:52:32 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020128155231.GXZ10199.rwcrmhc53.attbi.com@c1340594a>;
          Mon, 28 Jan 2002 15:52:31 +0000
Message-ID: <00c301c1a814$180975d0$08d8ea0c@c1340594a>
From: "Mark Davis" <mark@macchiato.com>
To: "ben" <ben@cc-www.com>, <DougEwell2@cs.com>, <idn@ops.ietf.org>
Cc: <tsenglm@cc.ncu.edu.tw>, <kenw@sybase.com>, <paf@cisco.com>
References: <f2.15c9c254.29865c29@cs.com> <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com>
Subject: Re: [idn] Re: peanut gallery
Date: Mon, 28 Jan 2002 07:54:39 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

The 'prohibit Simplified Chinese code points', even from a purely
technical point of view, is a bad idea.
It is complicated: one would have to be very careful not to exclude
what appear to be simplified characters but are actually used either
in other languages, or in Chinese itself as a traditional character.
Trying to do it by just algorithmically comparing SC/TC standards
(e.g. GB 2812 to GB 12345) based on mapping tables will give the wrong
answer.

If it were to be done, it would require a very detailed document
listing all of the code points, plus a very through review by experts
of each of those code points from all the CJK countries. I suspect the
only existing body with the expertise to do so is the IRG (which
includes official representatives of China, Hong Kong (SAR), Macao
(SAR), Singapore, Japan, South Korea, North Korea, Taiwan and Vietnam,
plus a representative from the Unicode consortium. For more
information, see
http://www.info.gov.hk/digital21/eng/structure/intro_irg.html). I
doubt, however, that they would consider it worth the considerable
time and effort involved.

I will quote snipets of some other people's messages on the subject:

======
...
Thomas, do you have a reference for U+9EBC (麼) and U+9EBD (麽) being
different?  The only dictionary I have which contains both is the
(traditional) CiHai, it and it claims they're variants of each other.

Meanwhile, both Sanseido and KangXi say that U+5C1B (尛) is a member of
the family.  (KangXi says that anciently U+9EBC (麼) was written U+5C1B
(尛).
Mathews and Sanseido also remind us that U+5E85 (庅) is another
variant,
and Sanseido *also* lists U+5692 (嚒).

So, Doug, you see that U+4E48 (么) could conceivably be a traditional
character in its own right *or* the simplified form for no fewer than
six
(!) other ideographs.
...
======
...
Meanwhile, it is true that there are simplified characters which
correspond to more than one traditional form.  In the case of U+8721
(蜡),
it is *both* a traditional character in its own right *and* the
simplified
form for another character, U+881F (蠟).

Characters which are simplifications for more than one traditional
form
are quite common.  Just to do a quick survey, I pulled one dictionary
off
my shelf.  It has in the back a table of simplifications.  The first
page
has 99 simplified characters, five of which are simplifications for
more
than one traditional form.  Perhaps that many again are also
traditional
characters in their own right.  This is also missing out on some of
the
more spectacular instances, such as U+53F0 (台), which is a traditional
character itself *and* the simplified form for three others, U+6AAF
(檯), U+
81FA (臺), and U+98B1 (颱).  There's at least one other character which
is
the simplified form for four traditional ones, but off-hand I can't
remember what it is.
...
=====
...
First of all, we have "wax", Mandarin la4

  Traditional form: U+881F
  Simplified form:  U+8721

Then we have "maggot", Mandarin qu1, of which Cihai claims that
Shuowen says:

  Vulgar form:  U+86C6
  Correct form: U+43E3
  Archaic form: U+8721

  My Taiwan and PRC dictionaries both claim U+86C6 for "maggot", so
  that would now be considered both the Traditional and Simplified
form,
  with U+8721 being an obsolete, archaic variant for it.

Then we have "yearend ceremony (of Zhou dynasty)", Mandarin zha4

  Traditional form: U+8721

  Not listed in my contemporary PRC dictionary.

And yes, this is the kind of mess that has discouraged anybody from
doing a systematic survey of simplifications...
=====

—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "ben" <ben@cc-www.com>
To: <DougEwell2@cs.com>; <idn@ops.ietf.org>
Cc: <tsenglm@cc.ncu.edu.tw>; <kenw@sybase.com>; <paf@cisco.com>
Sent: Monday, January 28, 2002 06:56
Subject: [idn] Re: peanut gallery


> Hi Doug,
>
> Rest assured that no one is trying to completely failed the IDN
model.
>
> The only possibility/compromise that I have read so far in these
> posting is to "prohibit Simplified Chinese code points"... and even
> with that idea, the WG is waiting for an Internet Draft before there
> could be further discussions/considerations.
>
> If I can't use IDNs in a couple of months, then I suggest changing
the
> name of the IETF to BPG (big peanut gallery).
>
> Thanks,
> Ben
>
>
> ----- Original Message -----
> From: <DougEwell2@cs.com>
> To: <idn@ops.ietf.org>
> Cc: <tsenglm@cc.ncu.edu.tw>; <kenw@sybase.com>; <paf@cisco.com>
> Sent: Monday, January 28, 2002 2:47 AM
> Subject: Re: [idn] Mapping and Prohibit of code points
>
>
> > I know the chairs consider this thread off-topic, so I will keep
> this brief.
> >
> > The only result that can come from excluding Han characters from
the
> IDN
> > model "until" a solution to the claimed CJK problem is developed,
is
> to
> > ensure the failure of the currently planned IDN model.
> >
> > Opponents would be able to claim truthfully that IDN completely
> fails to
> > support CJK, which of course would be true if Han characters were
> prohibited.
> >
> > They would then mount a new campaign to replace the discredited
IDN
> model
> > with a new CJK-oriented model, with local variations instead of
> global
> > uniformity.
> >
> > I am certain that at least some of those who are calling for CJK
> prohibition
> > understand this.
> >
> > -Doug Ewell
> >  Fullerton, California
> >
> >
>
>
>




From owner-idn@ops.ietf.org  Mon Jan 28 11:44:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02039
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 11:44:37 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VEnY-000C9h-00
	for idn-data@psg.com; Mon, 28 Jan 2002 08:38:24 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VEnS-000C9G-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 08:38:19 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0SGbiW21189;
	Tue, 29 Jan 2002 00:37:44 +0800 (CST)
Message-ID: <001b01c1a819$bf78d360$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "Kenneth Whistler" <kenw@sybase.com>
Cc: <idn@ops.ietf.org>
References: <200201260407.UAA04911@birdie.sybase.com> <009401c1a669$469f33a0$4007738c@q.j.tw> <15476872.1012055305@localhost> <000d01c1a79b$b5a2cf40$4007738c@q.j.tw> <24460853.1012205035@localhost>
Subject: Re: [idn] Mapping and Prohibit  of code points
Date: Tue, 29 Jan 2002 00:35:07 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Dear Patrik Fältström :
                  Sorry , the previous mail has a lot of spelling error.
>
> What you really talk about (I think) is how to handle the IDN solution as
> soon as possible, before applications have support for IDNA. And, your

            I  think there are some mistake in here.  About  JAN  2000 ,
one company come to Taiwan and announced they supply  ML-gTLD  "公司"
(chinese name of .com) registration and  it will be a IETF and ICANN
standard in near furture .  The worst , this company also announced they
also supply ML-ccTLD "台灣" (chinese name of  TW) .  We find this company
used the client solution to transform ML to ASCII string and append a domain
to it.  That is one of the technology will cause infringement.
           The customer of  TWNIC is very worry about their  chinese domain
name will be lose . Since  the registrant registered their name  with both
chinese full company name and  LDH domain name in paper form, so I suggest
TWNIC should  put the chinese company name as the domain name by  this form
ML.ML-com.tw  to show to  them that  their name is under best protection of
our NIC.  We will wait the true standard to be approved  then support them
too.  Our NIC does not prefer any approach to work as an IDN solution.
           After that experimental testbed , we find TC/SC problems, so we
keep all attention to this troubles come from UNICODE.  So, we have the
draft about UNAME that basically describe the ACE identifier is necessary,
especially in TC/SC  browser to cross visting another SC/TC web server.

> proposal is to store whatever garbage the applications will send over the
> network in the DNS servers in the encoding the clients happens to use.
This
> implies BIG5, UTF-8 encoded non-nameprepped Unicode, ISO-8859-1 and many
> other charsets.
>
           The experimental testbed is restrict to chinese character only
and testing before the nameprep propasal. Actually, the testing registration
do not allow  any  full width ASCII ,  so the problems of  nameprep is
mapped out in registration phase .  We keep only chinese character name and
still wait a world-wide  IDN solution to update.

> That should _NOT_ be done, as there is no way of discovering what charset
> is used, and this will because of this lead to explicit domain name
> infridgement which in turn is treated as trademark infringement.
>
           My  personal  Virtual DNS server is based on the registered
record to do code conversion and present the  equivalence  name to client,
it is a combined module of BIND DNS and  transliteral code-converter to do
it. If the zone record is legal in a DNS , the transliteral conversion of
name label is the same as the (nameprep + Punycode) doing in client .  The
DNS tree has strong  authorized tree relation check , so it is better than
the client  solution to avoid  infringement by domain name appending .  As I
know , there are still a lot of client side ACE solution to replace  a
ML-COM(chinese name  of .com) and append a ascii-domain name to re-direct it
.  I  just trust  the BIND DNS  software maintener has more experience in
SERVER than client to avoid infringement.  May be it is not true .  But I
must be say IDNA have good potential, because it has one powerful tool-
mult-case Punycode.

L.M.Tseng





From owner-idn@ops.ietf.org  Mon Jan 28 12:09:50 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02672
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 12:09:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VFBD-000CVs-00
	for idn-data@psg.com; Mon, 28 Jan 2002 09:02:51 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VFBD-000CVm-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 09:02:51 -0800
Received: from classic (classic.viagenie.qc.ca [206.123.31.136])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0SHKTa72397
	for <idn@ops.ietf.org>; Mon, 28 Jan 2002 12:20:30 -0500 (EST)
Date: Mon, 28 Jan 2002 12:05:42 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: idn@ops.ietf.org
Subject: [idn] IDN WG Process: draft-ietf-idn-requirement-09.txt
Message-ID: <68200000.1012237542@classic>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


A statement about the requirement document was sent to the mailing list on
Dec 9th 2001 and was discussed during the Salt Lake City meeting.  Since
then, the co-chairs have seen no interest in the working group to continue
this work and have received no proposal for new editors. The co-chairs will
then ask the IETF secretariat to drop this document from the wg document
pool and to expire it immediately.

Marc & James





From owner-idn@ops.ietf.org  Mon Jan 28 12:10:06 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02708
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 12:10:05 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VFBZ-000CWE-00
	for idn-data@psg.com; Mon, 28 Jan 2002 09:03:13 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VFBZ-000CW8-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 09:03:13 -0800
Received: from classic (classic.viagenie.qc.ca [206.123.31.136])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0SHKqa72406
	for <idn@ops.ietf.org>; Mon, 28 Jan 2002 12:20:52 -0500 (EST)
Date: Mon, 28 Jan 2002 12:06:04 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: idn@ops.ietf.org
Subject: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Message-ID: <68840000.1012237564@classic>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Title: Preparation of Internationalized Strings ("stringprep")

This document describes a framework for preparing text strings in order
to increase the likelihood that string input and string comparison work
in ways that make sense for typical users throughout the world. The
stringprep protocol is useful for protocol identifier values, company
and personal names, internationalized domain names, and other text
strings.

This document does not specify how protocols should prepare text
strings. Protocols must create profiles of stringprep in order to fully
specify the processing options.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt

This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.

This document is for standards track.

Last call for this document is in conjunction with
draft-ietf-idn-nameprep, Stringprep Profile for Internationalized Host
Names. The original nameprep document was split into 2 documents:
stringprep and nameprep.


The co-chairs see a wg rough concensus on this document.
Please send any proposed modification of the text to the wg mailing list as
well as to the wg co-chairs, stating clearly the text to be modified and
the new text.

Marc & James




From owner-idn@ops.ietf.org  Mon Jan 28 12:10:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02722
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 12:10:13 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VFBO-000CW5-00
	for idn-data@psg.com; Mon, 28 Jan 2002 09:03:02 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VFBN-000CVz-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 09:03:01 -0800
Received: from classic (classic.viagenie.qc.ca [206.123.31.136])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0SHKfa72402
	for <idn@ops.ietf.org>; Mon, 28 Jan 2002 12:20:41 -0500 (EST)
Date: Mon, 28 Jan 2002 12:05:53 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: idn@ops.ietf.org
Subject: [idn] IDN WG Last Call: draft-ietf-idn-idna-06.txt
Message-ID: <68530000.1012237553@classic>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Title: Internationalizing Domain Names in Applications (IDNA)

Abstract:
Until now, there has been no standard method for domain names to use
characters outside the ASCII repertoire. This document defines
internationalized domain names (IDNs) and a mechanism called IDNA for
handling them in a standard fashion. IDNs use characters drawn from a
large repertoire (Unicode), but IDNA allows the non-ASCII characters to
be represented using the same octets used in so-called hostnames today.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-06.txt

This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.

This document is for standards track.

The co-chairs see a wg rough concensus on this document.
Please send any proposed modification of the text to the wg mailing list as
well as to the wg co-chairs, stating clearly the text to be modified and
the new text.

Marc & James




From owner-idn@ops.ietf.org  Mon Jan 28 12:10:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02751
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 12:10:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VFBl-000CWw-00
	for idn-data@psg.com; Mon, 28 Jan 2002 09:03:25 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VFBk-000CWq-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 09:03:24 -0800
Received: from classic (classic.viagenie.qc.ca [206.123.31.136])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0SHL3a72414
	for <idn@ops.ietf.org>; Mon, 28 Jan 2002 12:21:03 -0500 (EST)
Date: Mon, 28 Jan 2002 12:06:15 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: idn@ops.ietf.org
Subject: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Message-ID: <69120000.1012237575@classic>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Title: Punycode version 0.3.3

Abstract:
Punycode is a simple and efficient encoding designed for use with
Internationalized Domain Names [IDN] [IDNA].  It uniquely and
reversibly transforms a Unicode string [UNICODE] into an ASCII
string.  ASCII characters in the Unicode string are represented
literally, and non-ASCII characters are represented by ASCII
characters that are allowed in hostname labels (letters, digits,
and hyphens).  Bootstring is a general algorithm that allows a
string of basic code points to uniquely represent any string of code
points drawn from a larger set.  Punycode is an instance Bootstring
that uses particular parameter values appropriate for IDNA.  This
document specifies Bootstring and the parameter values for Punycode.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-00.txt

This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.

This document is for standards track.

The co-chairs see a wg rough concensus on this document.
Please send any proposed modification of the text to the wg mailing list as
well as to the wg co-chairs, stating clearly the text to be modified and
the new text.

Marc & James




From owner-idn@ops.ietf.org  Mon Jan 28 12:14:21 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02890
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 12:14:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VFBf-000CWP-00
	for idn-data@psg.com; Mon, 28 Jan 2002 09:03:19 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VFBe-000CWI-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 09:03:18 -0800
Received: from classic (classic.viagenie.qc.ca [206.123.31.136])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0SHKva72410
	for <idn@ops.ietf.org>; Mon, 28 Jan 2002 12:20:57 -0500 (EST)
Date: Mon, 28 Jan 2002 12:06:09 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: idn@ops.ietf.org
Subject: [idn] IDN WG Last Call: draft-ietf-idn-nameprep-07.txt
Message-ID: <69000000.1012237569@classic>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Title: Stringprep Profile for Internationalized Host Names

This document describes how to prepare internationalized host name parts
in order to increase the likelihood that name input and name comparison
work in ways that make sense for typical users throughout the world.
This profile of the stringprep protocol is used as part of a suite of
on-the-wire protocols for internationalizing the DNS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-07.txt

This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.

This document is for standards track.

Last call for this document is in conjunction with
draft-hoffman-stringprep, Preparation of Internationalized Strings
("stringprep"). The original nameprep document was split into 2 documents:
stringprep and nameprep.

The co-chairs see a wg rough concensus on this document.
Please send any proposed modification of the text to the wg mailing list as
well as to the wg co-chairs, stating clearly the text to be modified and
the new text.

Marc & James




From owner-idn@ops.ietf.org  Mon Jan 28 12:16:05 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02916
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 12:16:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VFHv-000Ci0-00
	for idn-data@psg.com; Mon, 28 Jan 2002 09:09:47 -0800
Received: from imo-m03.mx.aol.com ([64.12.136.6])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VFHu-000Chs-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 09:09:46 -0800
Received: from DougEwell2@cs.com
	by imo-m03.mx.aol.com (mail_out_v31_r1.26.) id i.43.59add6b (4397);
	Mon, 28 Jan 2002 12:09:38 -0500 (EST)
From: DougEwell2@cs.com
Message-ID: <43.59add6b.2986dfd2@cs.com>
Date: Mon, 28 Jan 2002 12:09:38 EST
Subject: Re: [idn] Mapping and Prohibit  of code points
To: idn@ops.ietf.org
CC: tsenglm@cc.ncu.edu.tw, paf@cisco.com, kenw@sybase.com
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: CompuServe 2000 32-bit sub 113
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

In a message dated 2002-01-28 8:47:06 Pacific Standard Time, 
tsenglm@cc.ncu.edu.tw writes:

> About  JAN  2000 ,
> one company come to Taiwan and announced they supply  ML-gTLD  "__"
> (chinese name of .com) registration and  it will be a IETF and ICANN
> standard in near furture .  The worst , this company also announced they
> also supply ML-ccTLD "__" (chinese name of  TW) .  We find this company
> used the client solution to transform ML to ASCII string and append a domain
> to it.  That is one of the technology will cause infringement.
...
>            The experimental testbed is restrict to chinese character only
> and testing before the nameprep propasal. Actually, the testing registration

I thought a cardinal rule of IDN was that compatibility with previously 
constructed testbeds, especially those geared toward a single language or 
script and those which violate the premises of this IDN (e.g. no nameprep), 
was a non-goal.

-Doug Ewell
 Fullerton, California



From owner-idn@ops.ietf.org  Mon Jan 28 16:44:43 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09623
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 16:44:43 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VJFh-000H5e-00
	for idn-data@psg.com; Mon, 28 Jan 2002 13:23:45 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VJFg-000H5Y-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 13:23:44 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16VJFf-00059o-00
	for <idn@ops.ietf.org>; Mon, 28 Jan 2002 13:23:43 -0800
Date: Mon, 28 Jan 2002 21:23:43 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <20020128212343.GC19209@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <200201270740.g0R7eJI22853@scv1.apple.com> <19960984.1012130039@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <19960984.1012130039@localhost>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Patrik F�ltstr�m <paf@cisco.com> wrote:

> The servers need to have exactly the same rules.

Do you not agree that an authoritative server can use whatever
method/rules it likes to decide authoritative answers to queries?  For
example, the server could compute the answer as a function of the
requestor's IP address and the time of day and the dynamic load on
various machines.  The server can do this because it is the *authority*
over that part of the namespace--whatever it says it the correct answer
by definition.  Given that authoritative servers have so much freedom,
isn't it absurd to imagine imposing restrictions on how they can process
the queries?

There is no need to discuss this here because it has no impact on IDN.
Authoritative servers have always had this ability, and will continue to
have it regardless of what sort of IDN gets adopted.

AMC



From owner-idn@ops.ietf.org  Mon Jan 28 21:26:46 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13741
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 21:26:45 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VNfc-000Mhi-00
	for idn-data@psg.com; Mon, 28 Jan 2002 18:06:48 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VNfb-000Mhc-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 18:06:47 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16VNfa-0005z5-00
	for <idn@ops.ietf.org>; Mon, 28 Jan 2002 18:06:46 -0800
Date: Tue, 29 Jan 2002 02:06:46 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: [idn] Re: peanut gallery
Message-ID: <20020129020645.GA22444@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <f2.15c9c254.29865c29@cs.com> <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00c301c1a814$180975d0$08d8ea0c@c1340594a>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Mark Davis <mark@macchiato.com> wrote:

> The 'prohibit Simplified Chinese code points', even from a purely
> technical point of view, is a bad idea.  Trying to do it by just
> algorithmically comparing SC/TC standards (e.g. GB 2812 to GB 12345)
> based on mapping tables will give the wrong answer.

Maybe so, but the goal of the proposal was not to settle the question
of exactly which characters are simplified and which are traditional,
the goal was to prohibit some code points that have no use outside the
Chinese community in order to leave the door open for partial TC/SC
folding in nameprep.  (We know that nameprep could never be capable of
full TC/SC folding.)

(And let say again that I favor IDNA as proposed.  This is just a backup
proposal in case a compromise is needed.  I hope it's not.)

Here's a more precise version of the proposal:  Prohibit a Han code
point iff it has a kTraditionalVariant and has only "G" sources
(China/Singapore).  Would that do what I intend?  The list of such code
points could be generated from Unihan.txt by a small awk script.

AMC



From owner-idn@ops.ietf.org  Mon Jan 28 21:48:18 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14901
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 21:48:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VO6j-000NHZ-00
	for idn-data@psg.com; Mon, 28 Jan 2002 18:34:49 -0800
Received: from dove.cc.ncu.edu.tw ([140.115.17.111])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VO6h-000NHS-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 18:34:48 -0800
Received: from LocalHost ([140.115.7.64])
	(authenticated tsenglm (0 bits))
	by dove.cc.ncu.edu.tw (8.11.2/8.11.2/dove/0.0.4) with ESMTP id g0T2U5B13530;
	Tue, 29 Jan 2002 10:30:06 +0800 (CST)
Message-ID: <000401c1a86c$7dacde60$4007738c@q.j.tw>
From: =?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>
To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <paf@cisco.com>,
        "Kenneth Whistler" <kenw@sybase.com>,
        "Postel Services, Inc" <info@postel.co.kr>
Cc: <idn@ops.ietf.org>
References: <200201260407.UAA04911@birdie.sybase.com>    <009401c1a669$469f33a0$4007738c@q.j.tw> <15476872.1012055305@localhost>    <000d01c1a79b$b5a2cf40$4007738c@q.j.tw> <24460853.1012205035@localhost>    <001b01c1a819$bf78d360$4007738c@q.j.tw> <150001c1a829$99c69b60$ec1bd9d2@temp>
Subject: Re: [idn] Mapping and Prohibit  of code points
Date: Tue, 29 Jan 2002 10:27:24 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear  Soobok:
          I  agree your point .  We may forget current Punycode only
supports single case per character. Even there are a higher service layer
above DNS, the multiple matching result will not apply  the good properties
of multiple-case ACE encoder to connect to 7 bits LDH  DNS server .
          Although there are a lot of equivalent character problems in
UNICODE  can not be solved  quickly,  but the fixed monolithtic IDN approach
should include the flexibility of multi-cased Punycode to support the
furture connection for higher layer service.

L.N.Tseng
----- Original Message -----
From: Postel Services, Inc
....
>In order to do multi-case Punycode correctly and suffiencienly  for TC/SC
and >latin/cherokee/gree/cyrillic and hangul jamo matters and turkish i and
others,  we >should devise *new layer* that would replace current stringprep
one. stringprep is far >from what users want.
...
>In summary,  multi-case Punycode require  completely new reworks of IDNA
draft sets. >it will be like making new ones. I believe it will take another
2~3 years..
...
>Personally, i believe that  DNS should  remain as 7bit ASCII one which is
>internationally recognizable and distiguinshable and verifiable. Instead,
the users' need >for "internationalized *access* to domain names" should  be
solved  *above DNS*   by >the best ways that can serve local user
communities. It will bring  users   more benefits >and conveniences than
fixed-forever monolithic  IDN approach.















From owner-idn@ops.ietf.org  Mon Jan 28 22:25:38 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15253
	for <idn-archive@lists.ietf.org>; Mon, 28 Jan 2002 22:25:38 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VOid-000O8J-00
	for idn-data@psg.com; Mon, 28 Jan 2002 19:13:59 -0800
Received: from m3001.hostcentric.net ([216.157.79.237])
	by psg.com with smtp (Exim 3.33 #1)
	id 16VOic-000O8D-00
	for idn@ops.ietf.org; Mon, 28 Jan 2002 19:13:58 -0800
Received: (qmail 20065 invoked by alias); 29 Jan 2002 03:14:07 -0000
Received: from unknown (HELO c1340594a) (12.234.216.8)
  by 0 with SMTP; 29 Jan 2002 03:14:07 -0000
Message-ID: <003c01c1a873$49945d90$08d8ea0c@c1340594a>
From: "Mark Davis \(jtcsv\)" <mark.davis@jtcsv.com>
To: "IETF idn working group" <idn@ops.ietf.org>
References: <f2.15c9c254.29865c29@cs.com> <002301c1a80b$f059ad00$cd462b18@mtag.phub.net.cable.rogers.com> <00c301c1a814$180975d0$08d8ea0c@c1340594a> <20020129020645.GA22444@nicemice.net>
Subject: Re: [idn] Re: peanut gallery
Date: Mon, 28 Jan 2002 19:16:04 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

No, that wouldn't do as you intend. The kTraditionalVariant is not a
normative field; it was originally based on an algorithmic comparison
of, as it happens, GB 2812 to GB 12345; while it has improved over
time, I would not put any real weight on it without a thorough review.

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: <idn@ops.ietf.org>
Sent: Monday, January 28, 2002 18:06
Subject: Re: [idn] Re: peanut gallery


> Mark Davis <mark@macchiato.com> wrote:
>
> > The 'prohibit Simplified Chinese code points', even from a purely
> > technical point of view, is a bad idea.  Trying to do it by just
> > algorithmically comparing SC/TC standards (e.g. GB 2812 to GB
12345)
> > based on mapping tables will give the wrong answer.
>
> Maybe so, but the goal of the proposal was not to settle the
question
> of exactly which characters are simplified and which are
traditional,
> the goal was to prohibit some code points that have no use outside
the
> Chinese community in order to leave the door open for partial TC/SC
> folding in nameprep.  (We know that nameprep could never be capable
of
> full TC/SC folding.)
>
> (And let say again that I favor IDNA as proposed.  This is just a
backup
> proposal in case a compromise is needed.  I hope it's not.)
>
> Here's a more precise version of the proposal:  Prohibit a Han code
> point iff it has a kTraditionalVariant and has only "G" sources
> (China/Singapore).  Would that do what I intend?  The list of such
code
> points could be generated from Unihan.txt by a small awk script.
>
> AMC
>
>




From owner-idn@ops.ietf.org  Tue Jan 29 03:35:00 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28091
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 03:34:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VTU8-0005qc-00
	for idn-data@psg.com; Tue, 29 Jan 2002 00:19:20 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VTU7-0005qW-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 00:19:19 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id JAA24330;
	Tue, 29 Jan 2002 09:19:10 +0100 (MET)
Date: Tue, 29 Jan 2002 08:25:47 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: IETF idn working group <idn@ops.ietf.org>, idn@ops.ietf.org
Subject: Re: [idn] Determining equivalence in Unicode DNS names
Message-ID: <28684394.1012292747@localhost>
In-Reply-To: <20020128212343.GC19209@nicemice.net>
References: <200201270740.g0R7eJI22853@scv1.apple.com>
 <19960984.1012130039@localhost> <20020128212343.GC19209@nicemice.net>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA28091

--On 2002-01-28 21.23 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

> Patrik F�ltstr�m <paf@cisco.com> wrote:
> 
>> The servers need to have exactly the same rules.
> 
> Do you not agree that an authoritative server can use whatever
> method/rules it likes to decide authoritative answers to queries?

We talked about the rules which define "equivalence", and they need to be
the same.

If the content of a RR-Set is changing over time, that is fine. But, as
soon as the RR-Set is changing, it needs to be resigned.

The important thing is that if a server sends out an RR-Set, that set needs
to stay complete when it sits in a caching server.

   paf




From owner-idn@ops.ietf.org  Tue Jan 29 03:42:19 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28187
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 03:42:19 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VTfv-00067N-00
	for idn-data@psg.com; Tue, 29 Jan 2002 00:31:31 -0800
Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VTfu-00066R-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 00:31:30 -0800
Received: from mailc.telia.se (localhost [127.0.0.1])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0T8VRY17686
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 09:31:27 +0100 (MET)
Received: from trab.se (valinor.malmo.trab.se [131.115.48.20])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0T8VMP17658
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 09:31:22 +0100 (MET)
Message-ID: <3C565DDA.648B9A53@trab.se>
Date: Tue, 29 Jan 2002 09:31:22 +0100
From: Dan Oscarsson <Dan.Oscarsson@trab.se>
X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: [idn] Future difficulties because of IDNA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

From the discussions I have had on the namedroppers list I see
that at least two things will be more difficult when we introduce
native UCS in DNS because of IDNA:

1) Additional overhead.
    This is because of IDNA, a UCS client MUST first query the server
   if the server can handle UCS, and then send the real query.
   Without IDNA the client could send the query without knowing
   if the server supports UCS or not.

2) DNSSEC will probably be much more complex to handle due to
   having both ACE encoded and native UCS labels.


I see a risk that IDNA will kill native support for internationalisation
of DNS.

    Dan




From owner-idn@ops.ietf.org  Tue Jan 29 04:12:51 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28476
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 04:12:51 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VU5j-0006fh-00
	for idn-data@psg.com; Tue, 29 Jan 2002 00:58:11 -0800
Received: from patan.sun.com ([192.18.98.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VU5i-0006fb-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 00:58:11 -0800
Received: from bebop.France.Sun.COM ([129.157.179.15])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09956;
	Tue, 29 Jan 2002 01:58:08 -0700 (MST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0T8w7F23942;
	Tue, 29 Jan 2002 09:58:07 +0100 (MET)
Date: Tue, 29 Jan 2002 09:54:33 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [idn] Mapping and Prohibit  of code points
To: YangWoo Ko <newcat@spsoft.co.kr>
Cc: idn@ops.ietf.org
In-Reply-To: "Your message with ID" <20020128081539.GB914@spsoft.co.kr>
Message-ID: <Roam.SIMC.2.0.6.1012294473.29038.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


> Your conclusion seems to be too hasty. As far as I can tell from postings
> so far, they do not want "pre-" matured solution to be deployed which will
> prevent deployment of "well-" matured solution in the future. That's it.
> 
> As Kenny Huang suggested, if nobody had a tangible solution right now in
> hand, please make this off-topic for a while, and wait for good solution.

Clarifying question: You could be suggesting two very different things and
I'd like to understand which one it is.
1. All work in the IDN WG should be suspended while we wait for a good
solution. 2. We should wait discussing a claimed good solution until there is
a clear
   Internet-Draft specifying such a solution and meanwhile proceed with the
   documents that are in working group last call.

Which one did you mean?

Thanks,
  Erik




From owner-idn@ops.ietf.org  Tue Jan 29 04:14:54 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28520
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 04:14:54 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VUFY-0006rz-00
	for idn-data@psg.com; Tue, 29 Jan 2002 01:08:20 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VUFX-0006rs-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 01:08:19 -0800
Received: from [192.168.1.5] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA02660;
	Tue, 29 Jan 2002 10:04:35 +0100 (MET)
Date: Tue, 29 Jan 2002 10:04:26 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: Dan Oscarsson <Dan.Oscarsson@trab.se>, idn@ops.ietf.org
Subject: Re: [idn] Future difficulties because of IDNA
Message-ID: <29039505.1012298666@localhost>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-29 09.31 +0100 Dan Oscarsson <Dan.Oscarsson@trab.se> wrote:

> From the discussions I have had on the namedroppers list I see
> that at least two things will be more difficult when we introduce
> native UCS in DNS because of IDNA:
> 
> 1) Additional overhead.
>     This is because of IDNA, a UCS client MUST first query the server
>    if the server can handle UCS, and then send the real query.
>    Without IDNA the client could send the query without knowing
>    if the server supports UCS or not.
> 
> 2) DNSSEC will probably be much more complex to handle due to
>    having both ACE encoded and native UCS labels.
> 
> 
> I see a risk that IDNA will kill native support for internationalisation
> of DNS.

What you object to is the transport encoding used, and I don't understand
why you see that as such big deal from a DNS perspective.

The _real_ problem is leakage from the DNS to various applications. If we
go for some compressed binary encoding (which is the best from DNS
perspective, and not UTF-8, UCS2 or whatever else already exists) like
Punycode without the base32 at the end, then you definitly will see that
binary stuff inside application layer protocols aswell.

Regarding your bullets above, (1) will be something needed anyway when you
introduce EDNS0 or whatever other signalling which will be introduced
anyways, because of various needs and (2) no, I don't agree for a second.

Neither of your arguments above have any real impact on calculation costs
etc.

And, no, there is _no_ consensus on the namedroppers list as your mail on
this list might envision. The discussion there is basically a discussion
between you and Erik, which is the responsible AD for this group, and the
two of you don't agree.

   paf
 



From owner-idn@ops.ietf.org  Tue Jan 29 04:24:49 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28672
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 04:24:47 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VUR7-0007Bi-00
	for idn-data@psg.com; Tue, 29 Jan 2002 01:20:17 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VUR5-0007Bb-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 01:20:16 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g0T9KNZ01713
	for idn@ops.ietf.org; Tue, 29 Jan 2002 18:20:23 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Tue, 29 Jan 2002 18:20:22 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: idn@ops.ietf.org
Subject: Re: [idn] Mapping and Prohibit  of code points
Message-ID: <20020129092022.GA1446@spsoft.co.kr>
References: <20020128081539.GB914@spsoft.co.kr> <Roam.SIMC.2.0.6.1012294473.29038.nordmark@bebop.france>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <Roam.SIMC.2.0.6.1012294473.29038.nordmark@bebop.france>
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

On Tue, Jan 29, 2002 at 09:54:33AM +0100, Erik Nordmark wrote:
> 
> > Your conclusion seems to be too hasty. As far as I can tell from postings
> > so far, they do not want "pre-" matured solution to be deployed which will
> > prevent deployment of "well-" matured solution in the future. That's it.
> > 
> > As Kenny Huang suggested, if nobody had a tangible solution right now in
> > hand, please make this off-topic for a while, and wait for good solution.
> 
> Clarifying question: You could be suggesting two very different things and
> I'd like to understand which one it is.
> 1. All work in the IDN WG should be suspended while we wait for a good
> solution. 2. We should wait discussing a claimed good solution until there is
> a clear
>    Internet-Draft specifying such a solution and meanwhile proceed with the
>    documents that are in working group last call.
> 
> Which one did you mean?
> 
> Thanks,
>   Erik

Dear Erik Nordmark,

Thank you for giving me a chance to clarify my statement.

It is too late to select option 1. So, I can not but select option 2.
But, I have not seen "a claimed good solution" yet. Instead, what Chinese
friends suggested is just exclusion of Chinese characters code range 
for this round of standardization, just like we are doing for some
prohibited characters. I wish Chinese friends may find good solution 
in the near future, and then we can re-start discussion based on that 
solution. 

If you know what "a claimed good solution" is, please let me know of it.

My best regards

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Tue Jan 29 04:26:30 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28712
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 04:26:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VULe-00072k-00
	for idn-data@psg.com; Tue, 29 Jan 2002 01:14:38 -0800
Received: from mercury.sun.com ([192.9.25.1])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VULe-00072e-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 01:14:38 -0800
Received: from bebop.France.Sun.COM ([129.157.179.15])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15575;
	Tue, 29 Jan 2002 01:14:36 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0T9EYF25703;
	Tue, 29 Jan 2002 10:14:34 +0100 (MET)
Date: Tue, 29 Jan 2002 10:11:01 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [idn] Future difficulties because of IDNA
To: Dan Oscarsson <Dan.Oscarsson@trab.se>
Cc: idn@ops.ietf.org
In-Reply-To: "Your message with ID" <3C565DDA.648B9A53@trab.se>
Message-ID: <Roam.SIMC.2.0.6.1012295461.12091.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> From the discussions I have had on the namedroppers list I see
> that at least two things will be more difficult when we introduce
> native UCS in DNS because of IDNA:

Dan,

Your summary of that discussion makes the unstated assumption
that the issue is "when".
I think the issue is "if" it makes sense to have what you call native UCS
in the DNS packets.
So far nobody has managed to convince me that the benefit of that improved
encoding efficiency in the DNS packets outweigh the costs relating to
transition combined with DNSsec; what you list here are some of those issues
with an ACE to native UCS transition.
Staying with ACE encoded strings in DNS packets forver avoids this complexity.

If we can get the application protocols to move towards native UCS support
that would be very good. But that doesn't require the DNS packets to contain
native UCS.

BUT: the WG should now really go off and read the documents in WG last call
carefully to make sure that they are as clear as they can be.

  Erik

> 1) Additional overhead.
>     This is because of IDNA, a UCS client MUST first query the server
>    if the server can handle UCS, and then send the real query.
>    Without IDNA the client could send the query without knowing
>    if the server supports UCS or not.
> 
> 2) DNSSEC will probably be much more complex to handle due to
>    having both ACE encoded and native UCS labels.
> 
> 
> I see a risk that IDNA will kill native support for internationalisation
> of DNS.
> 
>     Dan
> 
> 





From owner-idn@ops.ietf.org  Tue Jan 29 04:29:31 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28759
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 04:29:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VUQq-0007Av-00
	for idn-data@psg.com; Tue, 29 Jan 2002 01:20:00 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VUQp-0007Ap-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 01:19:59 -0800
Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id BAA12149;
	Tue, 29 Jan 2002 01:18:52 -0800
Message-Id: <5.1.0.14.2.20020129011619.03a05008@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Jan 2002 01:18:03 -0800
To: Dan Oscarsson <Dan.Oscarsson@trab.se>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Future difficulties because of IDNA
Cc: idn@ops.ietf.org
In-Reply-To: <3C565DDA.648B9A53@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 09:31 AM 1/29/2002 +0100, Dan Oscarsson wrote:
> >From the discussions I have had on the namedroppers list I see
>that at least two things will be more difficult when we introduce
>native UCS in DNS because of IDNA:
>
>1) Additional overhead.
>     This is because of IDNA, a UCS client MUST first query the server
>    if the server can handle UCS, and then send the real query.
>    Without IDNA the client could send the query without knowing
>    if the server supports UCS or not.

Dan, your claim has not been true any of the multiple times you have made 
it.  And continuing to repeat it will not make it true.


>2) DNSSEC will probably be much more complex to handle due to
>    having both ACE encoded and native UCS labels.

This does not alter DNSSec complexity at all.

Try to find some criticisms that are valid.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 29 04:48:08 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28953
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 04:48:07 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VUmq-0007i3-00
	for idn-data@psg.com; Tue, 29 Jan 2002 01:42:44 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VUml-0007hv-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 01:42:40 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GQP1OZ00.7KO; Tue,
          29 Jan 2002 17:43:47 +0800 
Message-ID: <023e01c1a8a8$38ad0600$4407e29f@deng>
From: "xiang deng" <deng@cnnic.net.cn>
To: "YangWoo Ko" <newcat@spsoft.co.kr>, <idn@ops.ietf.org>
References: <20020128081539.GB914@spsoft.co.kr> <Roam.SIMC.2.0.6.1012294473.29038.nordmark@bebop.france> <20020129092022.GA1446@spsoft.co.kr>
Subject: Re: [idn] Mapping and Prohibit  of code points
Date: Tue, 29 Jan 2002 17:34:59 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA28953


----- Original Message ----- 
From: "YangWoo Ko" <newcat@spsoft.co.kr>

> On Tue, Jan 29, 2002 at 09:54:33AM +0100, Erik Nordmark wrote:
> > 
> > > Your conclusion seems to be too hasty. As far as I can tell from postings
> > > so far, they do not want "pre-" matured solution to be deployed which will
> > > prevent deployment of "well-" matured solution in the future. That's it.
> > > 
> > > As Kenny Huang suggested, if nobody had a tangible solution right now in
> > > hand, please make this off-topic for a while, and wait for good solution.
> > 
> > Clarifying question: You could be suggesting two very different things and
> > I'd like to understand which one it is.
> > 1. All work in the IDN WG should be suspended while we wait for a good
> > solution. 2. We should wait discussing a claimed good solution until there is
> > a clear
> >    Internet-Draft specifying such a solution and meanwhile proceed with the
> >    documents that are in working group last call.
> > 
> > Which one did you mean?
> > 
> > Thanks,
> >   Erik
> 
> Dear Erik Nordmark,
> 
> Thank you for giving me a chance to clarify my statement.
> 
> It is too late to select option 1. So, I can not but select option 2.
> But, I have not seen "a claimed good solution" yet. Instead, what Chinese
> friends suggested is just exclusion of Chinese characters code range 
> for this round of standardization, just like we are doing for some
> prohibited characters. I wish Chinese friends may find good solution 
> in the near future, and then we can re-start discussion based on that 
> solution. 

I don't think it's too late. In Chinese, there is a idiom "steal bell after plug up ears ", 
its meaning is:
the fact is always be fact whether you concern it or not. 
the problem is always be problem while it is not be solved.
the only different is the problem is waiting for us in the near future.

Deng xiang 




From owner-idn@ops.ietf.org  Tue Jan 29 05:32:28 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29445
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 05:32:27 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VVUK-0008h8-00
	for idn-data@psg.com; Tue, 29 Jan 2002 02:27:40 -0800
Received: from [140.109.20.50] (helo=mail.iis.sinica.edu.tw)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VVUJ-0008gu-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 02:27:39 -0800
Received: from javalai (dhcp048 [140.109.21.55])
	by mail.iis.sinica.edu.tw (8.10.2/8.10.2) with SMTP id g0TAN0T07581
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 18:23:00 +0800 (CST)
Message-ID: <00df01c1a8b0$13c7dba0$24126d8c@iis.sinica.edu.tw>
From: "Lawrence Lai" <lawrence@iis.sinica.edu.tw>
To: <idn@ops.ietf.org>
References: <3C565DDA.648B9A53@trab.se>
Subject: Re: [idn] Future difficulties because of IDNA
Date: Tue, 29 Jan 2002 18:31:10 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message ----- 
From: "Dan Oscarsson" <Dan.Oscarsson@trab.se>
To: <idn@ops.ietf.org>
Sent: Tuesday, January 29, 2002 4:31 PM
Subject: [idn] Future difficulties because of IDNA


> From the discussions I have had on the namedroppers list I see
> that at least two things will be more difficult when we introduce
> native UCS in DNS because of IDNA:
> 
> 1) Additional overhead.
>     This is because of IDNA, a UCS client MUST first query the server
>    if the server can handle UCS, and then send the real query.
>    Without IDNA the client could send the query without knowing
>    if the server supports UCS or not.
> 
> 2) DNSSEC will probably be much more complex to handle due to
>    having both ACE encoded and native UCS labels.
> 
> 
> I see a risk that IDNA will kill native support for internationalisation
> of DNS.
> 
>     Dan
> 
> 
> 
> 




From owner-idn@ops.ietf.org  Tue Jan 29 05:33:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29462
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 05:33:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VVSC-0008dB-00
	for idn-data@psg.com; Tue, 29 Jan 2002 02:25:28 -0800
From: "Lawrence Lai" <lawrence@ibm.el.cycu.edu.tw>
To: <idn@ops.ietf.org>
Subject: Re: [idn] Mapping and Prohibit  of code points
Date: Tue, 29 Jan 2002 18:17:20 +0800
MIME-Version: 1.0
Content-Type: text/plain;
Message-Id: <E16VVSC-0008dB-00@psg.com>

charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk


----- Original Message -----
From: "YangWoo Ko" <newcat@spsoft.co.kr>
To: <idn@ops.ietf.org>
Sent: Tuesday, January 29, 2002 5:20 PM
Subject: Re: [idn] Mapping and Prohibit of code points


> On Tue, Jan 29, 2002 at 09:54:33AM +0100, Erik Nordmark wrote:
> >
> > > Your conclusion seems to be too hasty. As far as I can tell from
postings
> > > so far, they do not want "pre-" matured solution to be deployed
which
will
> > > prevent deployment of "well-" matured solution in the future.
That's
it.
> > >
> > > As Kenny Huang suggested, if nobody had a tangible solution right
now
in
> > > hand, please make this off-topic for a while, and wait for good
solution.
> >
> > Clarifying question: You could be suggesting two very different
things
and
> > I'd like to understand which one it is.
> > 1. All work in the IDN WG should be suspended while we wait for a
good
> > solution. 2. We should wait discussing a claimed good solution until
there is
> > a clear
> >    Internet-Draft specifying such a solution and meanwhile proceed
with
the
> >    documents that are in working group last call.
> >
> > Which one did you mean?
> >
> > Thanks,
> >   Erik
>
> Dear Erik Nordmark,
>
> Thank you for giving me a chance to clarify my statement.
>
> It is too late to select option 1. So, I can not but select option 2.
> But, I have not seen "a claimed good solution" yet. Instead, what
Chinese
> friends suggested is just exclusion of Chinese characters code range
> for this round of standardization, just like we are doing for some
> prohibited characters. I wish Chinese friends may find good solution
> in the near future, and then we can re-start discussion based on that
> solution.
>
> If you know what "a claimed good solution" is, please let me know of
it.
>
> My best regards
>
> --
> /*------------------------------------------------
> YangWoo Ko : newcat@spsoft.co.kr
> We Invent Enterprise Software Solutions
> and Make You Secure & Powerful.
> ------------------------------------------------*/
>
>
>








From owner-idn@ops.ietf.org  Tue Jan 29 07:30:30 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00731
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 07:30:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VXG0-000BL8-00
	for idn-data@psg.com; Tue, 29 Jan 2002 04:21:00 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VXFz-000BL2-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 04:20:59 -0800
Received: from cnnic.net.cn ([159.226.7.70]) by
          whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP
          id GQP90V00.TJP for <idn@ops.ietf.org>; Tue, 29 Jan 2002 20:22:07 +0800 
Message-ID: <3C569319.F867BB71@cnnic.net.cn>
Date: Tue, 29 Jan 2002 20:18:33 +0800
From: "xiaodong lee" <lee@cnnic.net.cn>
Reply-To: lee@cnnic.net.cn
Organization: CNNIC-CNIC-CAS
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: zh-CN,zh-TW,en,sv,el
MIME-Version: 1.0
CC: idn@ops.ietf.org
Subject: [idn] Unicode vs. IDN-CDN( personal opinion )
References: <5.1.0.14.2.20020129011619.03a05008@127.0.0.1>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello, every member of IDN maillist

Firstly, all that I said here is only my personal opinion, if anything
that I present is wrong, please correct me with my pleasure. I am a
student, so I try to understand such problem and express my opinion in a
student's point of view. I often discuss such IDN with my classmates in
Chinese Academy of Sciences; they also doubt why we are still working on
such problem, which has incomplete and faulty basis, in IETF which is
the highest and authoriative techinical organizaiton in Internet area.
Including WG chairs and many kind and wisdom persons, many people have
made many efforts in IDN, and proposed many solutions for IDN, to be
truth, however, current standards and technologies cannot meet the goal
of such WG. It is a big challenge as everyone knows.

Recently, we often talk about the impact of Unicode ambiguity on CJK; I
will follow such concept, which doesn't mean I don't support Unicode CJK
unification that is a great work achieved by some experts in CJK area. 

Of course, I don't want to oppugn if Unicode is appropriate or not,
because there are no better solutions than choosing Unicode as the
standard of IDN. What I want to do is to pick out the default bought by
selecting Unicode and to explain why we do 1-1 mapping in IDN and leave
other cases in other ways, such as registration or IRNSS. Some people in
this mail list oppugn TC/SC draft is an incomplete solution and cannot
be understand, I wish what I said could help them to understand the
difficulty and essential of TC/SC problems.

Nameprep announced that it would follow the change of Unicode. Because
Unicode only collect the scripts of most languages of the world, so it
cannot handle many problems, such as TC/SC. Of course, it doesn't
collect all scripts simply, it has been doing CJK unification, all
characters in same scripts are reduced to one code point in Unicode,
that is very useful in information exchange in CJK area, but it bring
much trouble for us to do TC/SC equivalent in IDN or CDN. So Unicode is
very successful in many technical areas, but it is an incomplete
solution for IDN, for at lease it cannot meet the requirement of CDN,
which own more than 70% code points in Unicode. That is why Mr. Kenny
Huang proposed to prohibit CJK code points in IDNA, I think.

Unicode has done CJK horizontal unification, and as some persons from
Unicode said, they are considering doing vertical unification in CJKV,
which will handle some problems, including TC/SC equivalent. WILL
NAMEPREP FOLLOW SUCH UNIFICATION IN THE FUTURE? I am wondering how to
deal with many problems caused by current IDN selection in the future,
and how does IETF explain such results for so many CJK users? So as a
co-author of Tsconv draft, I proposed to solve some doubtless problems
in IDN, and leave uncertain problems for the future or other area, which
is not a big problem as someone imaged and worried. Theoretically, if
some problems are very difficult to solve, why don't we solve it step by
step? 

If someone thinks I bring a problem not to be worth discussing, just
cancel it please, because when I saw recent many messages around such
problem, I feel a little pity about the future of IDN. Why don't we
select some feasible solution, more than doing hurried LAST-CALL for all
core documents.

Anyway, I suggest all members to consider such problem carefully and put
IDN into a successful process!

Best Regards!
-- 
______________________________________

      XiaoDong LEE ( X.D. Lee )
______________________________________
 China  Network   Information  Center
 Tel.  (O):      +86-10-62619750-3020       
 Email (O):          Lee@cnnic.net.cn         
       (P): XiaoDong.Lee@computer.org  
 Homepage :    http://xiaodong.n3.net
______________________________________



From owner-idn@ops.ietf.org  Tue Jan 29 08:27:58 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02464
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 08:27:58 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VY7q-000CgS-00
	for idn-data@psg.com; Tue, 29 Jan 2002 05:16:38 -0800
Received: from heron.verisign.com ([216.168.233.95])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VY7p-000CgM-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 05:16:37 -0800
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29])
	by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA09425;
	Tue, 29 Jan 2002 08:16:32 -0500 (EST)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19)
	id <C081WQ71>; Tue, 29 Jan 2002 08:16:22 -0500
Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5E4@vsvapostal3.bkup6>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'Marc Blanchet'" <Marc.Blanchet@viagenie.qc.ca>, idn@ops.ietf.org
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Date: Tue, 29 Jan 2002 08:16:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Marc,

A process point: this document is still written as an individual submission;
it's not listed as a WG I-D.  Is it within the WG's scope to conduct a last
call on the document?  Maybe it should be renamed and adopted by the WG
first.

-Scott- 

> -----Original Message-----
> From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca]
> Sent: Monday, January 28, 2002 12:06 PM
> To: idn@ops.ietf.org
> Subject: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
> 
> 
> Title: Preparation of Internationalized Strings ("stringprep")
> 
> This document describes a framework for preparing text 
> strings in order
> to increase the likelihood that string input and string 
> comparison work
> in ways that make sense for typical users throughout the world. The
> stringprep protocol is useful for protocol identifier values, company
> and personal names, internationalized domain names, and other text
> strings.
> 
> This document does not specify how protocols should prepare text
> strings. Protocols must create profiles of stringprep in 
> order to fully
> specify the processing options.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt
> 
> This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.
> 
> This document is for standards track.
> 
> Last call for this document is in conjunction with
> draft-ietf-idn-nameprep, Stringprep Profile for Internationalized Host
> Names. The original nameprep document was split into 2 documents:
> stringprep and nameprep.
> 
> 
> The co-chairs see a wg rough concensus on this document.
> Please send any proposed modification of the text to the wg 
> mailing list as
> well as to the wg co-chairs, stating clearly the text to be 
> modified and
> the new text.
> 
> Marc & James
> 



From owner-idn@ops.ietf.org  Tue Jan 29 09:13:29 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03742
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 09:13:29 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VYrQ-000DrY-00
	for idn-data@psg.com; Tue, 29 Jan 2002 06:03:44 -0800
Received: from jazz.viagenie.qc.ca ([206.123.31.2])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VYrP-000Dq2-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 06:03:43 -0800
Received: from classic (classic.viagenie.qc.ca [206.123.31.136])
	by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id g0TEKFa85395;
	Tue, 29 Jan 2002 09:20:15 -0500 (EST)
Date: Tue, 29 Jan 2002 09:05:21 -0500
From: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, idn@ops.ietf.org
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Message-ID: <270170000.1012313120@classic>
In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B5E4@vsvapostal3.bkup6>
References:  <3CD14E451751BD42BA48AAA50B07BAD60189B5E4@vsvapostal3.bkup6>
X-Mailer: Mulberry/2.1.2 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03742



-- mardi, janvier 29, 2002 08:16:24 -0500 "Hollenbeck, Scott" 
<shollenbeck@verisign.com> wrote/a �crit:

> Marc,
>
> A process point: this document is still written as an individual
> submission; it's not listed as a WG I-D.  Is it within the WG's scope to
> conduct a last call on the document?  Maybe it should be renamed and
> adopted by the WG first.

- good point.
- we have discussed about it with the ADs.
- the "old" version of nameprep was split in two documents:
  + stringprep, which is essentially a framework
  + and the current nameprep, which is a profile of stringprep.
  + the idea behind this split is to "standard reusability" ;-)). We feel 
(and actually see it) that this work would be useful for other working 
groups, but not necessarily in the exact same manner: so the rationale 
behind a framework document and profiles. One profiles for iSCSI is 
currently in the works, for example.
- the "old" version of nameprep was a wg document, so the splitted two 
should be.
- even if we don't see stringprep as wg document, there is another 
rationale:
 + nameprep references stringprep: this means that we (the ietf community 
in general) must forward the two documents to the IESG for simultaneous 
publication (as individual or wg document,doesn't matter).
 + stringprep contains a key discussion on versioning and other useful 
info, which must be read and implemented by implementors of idn.
- so even if we might fight about the fact that stringprep is a wg document 
or not, it is still important that all people in this wg review stringprep 
closely. This will get a much stronger case for publishing it as RFC. This 
is why we do a wg last call on it.  As you know, it happens often in the 
IETF that wg do wg last calls on documents that do not belong to their wg, 
just to have a much broader review. So this is a similar case.

- so the first goal here is to have this wg have a close review of 
stringprep. The fact that it is a wg document or not is not that important.

Marc.

>
> -Scott-
>
>> -----Original Message-----
>> From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca]
>> Sent: Monday, January 28, 2002 12:06 PM
>> To: idn@ops.ietf.org
>> Subject: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
>>
>>
>> Title: Preparation of Internationalized Strings ("stringprep")
>>
>> This document describes a framework for preparing text
>> strings in order
>> to increase the likelihood that string input and string
>> comparison work
>> in ways that make sense for typical users throughout the world. The
>> stringprep protocol is useful for protocol identifier values, company
>> and personal names, internationalized domain names, and other text
>> strings.
>>
>> This document does not specify how protocols should prepare text
>> strings. Protocols must create profiles of stringprep in
>> order to fully
>> specify the processing options.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt
>>
>> This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.
>>
>> This document is for standards track.
>>
>> Last call for this document is in conjunction with
>> draft-ietf-idn-nameprep, Stringprep Profile for Internationalized Host
>> Names. The original nameprep document was split into 2 documents:
>> stringprep and nameprep.
>>
>>
>> The co-chairs see a wg rough concensus on this document.
>> Please send any proposed modification of the text to the wg
>> mailing list as
>> well as to the wg co-chairs, stating clearly the text to be
>> modified and
>> the new text.
>>
>> Marc & James
>>
>



------------------------------------------
Marc Blanchet
Viag�nie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------



From owner-idn@ops.ietf.org  Tue Jan 29 10:02:40 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05112
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 10:02:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VZfU-000FFf-00
	for idn-data@psg.com; Tue, 29 Jan 2002 06:55:28 -0800
Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VZfT-000FFZ-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 06:55:28 -0800
Received: from mailc.telia.se (localhost [127.0.0.1])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0TEtOY20801
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 15:55:24 +0100 (MET)
Received: from trab.se (terra.malmo.trab.se [131.115.48.22])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0TEtBP20599;
	Tue, 29 Jan 2002 15:55:12 +0100 (MET)
Message-ID: <3C56B79F.DB80B1FB@trab.se>
Date: Tue, 29 Jan 2002 15:54:23 +0100
From: Dan Oscarsson <Dan.Oscarsson@trab.se>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org, paf@cisco.com, Erik.Nordmark@eng.sun.com,
        dhc@dcrocker.net
Subject: Re: [idn] Future difficulties because of IDNA
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit


This include comments to what Patrik F�ltstr�m, Erik Nordmark and
Dave Crocker wrote.


>> From the discussions I have had on the namedroppers list I see
>> that at least two things will be more difficult when we introduce
>> native UCS in DNS because of IDNA:

As Erik said, "if" is better then "when" and from the what I can see
I think it is possible that it will be ACE forever until DNS is replaced
with DNS-NG (at least that should happen some day). While I very much
dislike solutions layered on top of ASCII due to inefficiency and
due to the big problem with application developers that never
understands that you always must translate from the ASCII layer to
native encoding before interacting with users.

As Patrik said, there is no consensus on the namedroppers list.
Actually there is very little response except from Erik.

>> 
>> 1) Additional overhead.
>>     This is because of IDNA, a UCS client MUST first query the server
>>    if the server can handle UCS, and then send the real query.
>>    Without IDNA the client could send the query without knowing
>>    if the server supports UCS or not.

Yes, as Patrik says EDNS will result in the above.
But if you use UCS and EDNS you may get one additional query.
I know Dave do not think this is right, so I will try to give a quick
comment on why:
If you only allow IDN by having UCS aware servers, all clients
can send a query using either ACE or UCS and get the correct answer.
If you also allow IDNA servers, the IDNA servers can only give the
correct anser if the query is in ACE. This means that a UCS client
who want to send a UCS query, have to know if the server handles UCS
or not. If the answer is not, the UCS client have to send the query
using ACE. To test if the server can handle UCS, a separate query
must be sent. Here is the overhead.

>> 
>> 2) DNSSEC will probably be much more complex to handle due to
>>    having both ACE encoded and native UCS labels.
>> 

The complexity here is what I found out from my talk with Erik. You
might get away from most of it. In short this is because DNSSEC
signs RR-sets and with both UCS and ACE you have two representations
of the same label. The signing will be different depending on which you
use (unless you say signing should always be done on for example the
ACE form, but this looks wrong as an UCS client should never see
any records with ACE if they are sent from a UCS server).


   Dan



From owner-idn@ops.ietf.org  Tue Jan 29 10:35:53 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06300
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 10:35:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Va5x-000G1a-00
	for idn-data@psg.com; Tue, 29 Jan 2002 07:22:49 -0800
Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Va5v-000G1U-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 07:22:47 -0800
Received: from mailc.telia.se (localhost [127.0.0.1])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0TFMjY04121
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 16:22:45 +0100 (MET)
Received: from trab.se (terra.malmo.trab.se [131.115.48.22])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0TFMiP04115
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 16:22:44 +0100 (MET)
Message-ID: <3C56BE14.F8D0895D@trab.se>
Date: Tue, 29 Jan 2002 16:21:56 +0100
From: Dan Oscarsson <Dan.Oscarsson@trab.se>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: [idn] Needed changes to IDNA before last call
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

As I have the feeling that the IDNA way be the internationalisation
of the DNS in the near future, at least, and we now also have
last call on the drafts for it, I have looked at what I think is needed
before they can replace a complete native UCS solutions.

A quick look at the latest drafts make me happy, they are much closer
to what is needed now than they were before. Previously they have been
too focused on "host names".

To be complete, all DNS labels containing non-ASCII must be ACE
encoded. All using the same encoding and stringprep profile.
This will allow us to use non-ASCII everywhere in DNS excpet in things
like for example TXT and HINFO records.

I suggest the following is done:

The draft: idn-nameprep
Title change: Stringprep profile for Internationalised DNS labels.
It is for more than host names. Unless my quick look is wrong
it should work for all types of labels.

The draft: idn-idna:
The ToASCII must be applied to ALL labels containing non-ASCII.
The steps need a slight change:
 - character restrictions will apply depending on label, it could be
   host name or e-mail name.
 - Encoding into ACE must use Punycode WITH case marking so that
   case can be restored when using ToUnicode.

ToUnicode is fine, but decoding Punycode must restore case.

-
With the above changes the IDNA way is much more acceptible.
It is now a general solution for non-ASCII in labels, not just
some special cases. And it preserves the case semantics of
current DNS while at the same time allows the simple ASCII
matching algorith to be used.

If you do this you get all important things I have wanted my
native UCS solution to do (except using native UCS) and I
can support it.

Keep up the good work, you are nearly there.

   Dan



From owner-idn@ops.ietf.org  Tue Jan 29 11:02:49 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07376
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:02:48 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vaa4-000GtC-00
	for idn-data@psg.com; Tue, 29 Jan 2002 07:53:56 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vaa3-000Gt6-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 07:53:55 -0800
Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA24309;
	Tue, 29 Jan 2002 07:52:23 -0800
Message-Id: <5.1.0.14.2.20020129073156.0311e008@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Jan 2002 07:43:29 -0800
To: Dan Oscarsson <Dan.Oscarsson@trab.se>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Future difficulties because of IDNA
Cc: idn@ops.ietf.org, paf@cisco.com, Erik.Nordmark@eng.sun.com
In-Reply-To: <3C56B79F.DB80B1FB@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 03:54 PM 1/29/2002 +0100, Dan Oscarsson wrote:
>  While I very much
>dislike solutions layered on top of ASCII due to inefficiency and
>due to the big problem with application developers that never
>understands that you always must translate from the ASCII layer to
>native encoding before interacting with users.

MIME has not suffered the fate you claim is inevitable, yet is the same 
design approach as IDNA.


>As Patrik said, there is no consensus on the namedroppers list.
>Actually there is very little response except from Erik.

Lack of response on a mailing list usually means that people do not feel 
that the issue being raised is worth responding to.  In other words, it is 
an implicit vote of no confidence for the concern or suggestion being raised.


>If you also allow IDNA servers,

There will be no IDNA servers.

DNS servers do not need to be modified to support IDNA.  IDNA is supported 
by the software that creates the string and the software that does the 
query.  The software that services DNS requests and holds DNS data does not 
need modification.


>the IDNA servers can only give the
>correct anser if the query is in ACE.

This is not correct.


> >> 2) DNSSEC will probably be much more complex to handle due to
> >>    having both ACE encoded and native UCS labels.
>
>The complexity here is what I found out from my talk with Erik. You
>might get away from most of it. In short this is because DNSSEC
>signs RR-sets and with both UCS and ACE

Oh.  You mean that IDNA adds complexity, when (and if) we try to introduce 
an encoding that is more efficient.  (Please remember that 8-bit unicode is 
still an encoding.)

You are therefore making that claim that it is more complex to have an 
"interim" scheme.  Well, duh.

It is the nature of transitions that they incur "inefficiencies", if the 
transition is done in a way that preserves the installed base.

So the bottom line is that IDNA does not, itself, creates any special 
concerns for DNSSec, contrary to you claim.


At 09:31 AM 1/29/2002 +0100, Dan Oscarsson wrote:
>I see a risk that IDNA will kill native support for internationalisation
>of DNS.

Apparently you are unaware that 8-bit unicode is not at all more "native" 
than IDNA.  Both are encodings.  One is a bit more efficient, but requires 
creating an entirely new infrastructure.  The other works on the existing 
infrastructure.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 29 11:03:32 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07406
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:03:31 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vaa1-000Gt3-00
	for idn-data@psg.com; Tue, 29 Jan 2002 07:53:53 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vaa0-000Gsw-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 07:53:52 -0800
Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id HAA24312;
	Tue, 29 Jan 2002 07:52:23 -0800
Message-Id: <5.1.0.14.2.20020129074608.0311e008@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Jan 2002 07:49:17 -0800
To: Dan Oscarsson <Dan.Oscarsson@trab.se>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] Needed changes to IDNA before last call
Cc: idn@ops.ietf.org
In-Reply-To: <3C56BE14.F8D0895D@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 04:21 PM 1/29/2002 +0100, Dan Oscarsson wrote:
>last call on the drafts for it, I have looked at what I think is needed
>before they can replace a complete native UCS solutions.

8-bit Unicode is not a "native" encoding.

IDNA uses standard Unicode representations.

It is the ENCODING of that representation that differs from the standard 
encodings that are typical for Unicode, most of which are not "native".

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 29 11:06:36 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07480
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:06:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VaeF-000H1r-00
	for idn-data@psg.com; Tue, 29 Jan 2002 07:58:15 -0800
Received: from heron.verisign.com ([216.168.233.95])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VaeE-000H1l-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 07:58:14 -0800
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201])
	by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA23499
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 10:58:13 -0500 (EST)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19)
	id <DD9A7VC1>; Tue, 29 Jan 2002 10:58:06 -0500
Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5F2@vsvapostal3.bkup6>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: idn@ops.ietf.org
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Date: Tue, 29 Jan 2002 10:58:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

The stringprep draft contains this unanswered question a the end of section
4:

"Patrik asks: Is not addition of unassigned codepoints regarded an update of
UAX15? This is relevant here."

Paul and Marc: Given that we're last-calling the document with that question
still in place, how would you answer it?

-Scott-



From owner-idn@ops.ietf.org  Tue Jan 29 11:21:35 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08110
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:21:34 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vaum-000HZ7-00
	for idn-data@psg.com; Tue, 29 Jan 2002 08:15:20 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vaul-000HZ1-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 08:15:19 -0800
Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA25202;
	Tue, 29 Jan 2002 08:15:15 -0800
Message-Id: <5.1.0.14.2.20020129081013.02ec7320@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Jan 2002 08:11:28 -0800
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Cc: "'Marc Blanchet'" <Marc.Blanchet@viagenie.qc.ca>, idn@ops.ietf.org
In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B5E4@vsvapostal3.bkup6
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 08:16 AM 1/29/2002 -0500, Hollenbeck, Scott wrote:
>A process point: this document is still written as an individual submission;
>it's not listed as a WG I-D.  Is it within the WG's scope to conduct a last
>call on the document?  Maybe it should be renamed and adopted by the WG
>first.

there is no benefit in doing this.

naming an I-D to be within a working group is helpful during the working 
group process, to let people know what documents they MUST look at, if they 
wish to be current on working group activities.

Renaming this document might have been nice 6 months ago.  Not now.

The only things accomplished by changing the name now will be distraction 
and more delay.  Marc's response to you is a good indication of these 
effects.  He has diligently responded to your suggestion and the result is 
frankly confusing.  (That's not a criticism to his response but to the 
nature of dealing with your suggestion.)

The important thing to note is that there is not real benefit to making the 
name change, since it is the TITLE on the first page that is relevant to an 
rfc, NOT the I-D label.

d/


----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 29 11:26:00 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08258
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:26:00 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vax9-000Heh-00
	for idn-data@psg.com; Tue, 29 Jan 2002 08:17:47 -0800
Received: from m3001.hostcentric.net ([216.157.79.237])
	by psg.com with smtp (Exim 3.33 #1)
	id 16Vax7-000HeZ-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 08:17:46 -0800
Received: (qmail 23574 invoked by alias); 29 Jan 2002 16:17:55 -0000
Received: from unknown (HELO c1340594a) (12.234.216.8)
  by 0 with SMTP; 29 Jan 2002 16:17:55 -0000
Message-ID: <013601c1a8e0$c852e120$08d8ea0c@c1340594a>
From: "Mark Davis \(jtcsv\)" <mark.davis@jtcsv.com>
To: "Adam M. Costello" <amc@cs.berkeley.edu>
Cc: "Marc Blanchet" <Marc.Blanchet@viagenie.qc.ca>, <idn@ops.ietf.org>,
        "Markus Scherer" <markus.scherer@us.ibm.com>
References: <69120000.1012237575@classic>
Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Date: Tue, 29 Jan 2002 08:19:51 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

The decoding process is a bit hard to follow. I would recommend adding
some annotated examples of decoding to Punycode in a section 7.1 and
referencing them from the text. E.g.
...
3. Bootstring description

    Bootstring represents an arbitrary sequence of code points (the
    "extended string") as a sequence of basic code points (the
    "basic string").  This section describes the representation.
    Section 6 "Bootstring algorithms" presents the algorithms as
    pseudocode. [[[Section 7.1 "Annotated Decoding Examples"
    provides some examples of the decoding process which may
    be useful in understanding the following text.]]]
...

...
7.1 Annotated Decoding Examples
The following provides two examples of the decoding process. One
example contains mostly ASCII letters with a few accented characters,
while the other has only non-ASCII characters:

[[[The deltas are just pulled out of a hat for illustration; you'd run
your program to generate them.]]]

1. "Proprostnemluvesky-uyb24dma41a"

Since there is a delimiter, the basic string consists of:
  "Proprostnemluvesky"
and the delta codes are:
  "uyb24dma41a"
The delta codes provide instructions on where to insert other
characters in the stream.
The first delta is contained in "uy", and produces the number +YYYY
It inserts <ccaron> = U+XXXX at position 3, giving:
  "Pro<ccaron>prostnemluvesky"
[[[insert the rest of the steps]]]
The final result is:
  "Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky"

2. "ihqwcrb4cv8a8dqg056pqjye"

Since there is no delimiter, the basic codes are empty to start with,
and the entire encoded string consists of deltas.
The first delta is contained in "ih", and produces the number +XXXX.
It inserts <4ED6> at the start, giving:
 <4ED6>
[[[insert the rest of the steps]]]
The final result is:
<4ED6><4EEC><4E3A><4EC0><4E48><4E0D><8BF4><4E2D><6587>

Mark

----- Original Message -----
From: "Marc Blanchet" <Marc.Blanchet@viagenie.qc.ca>
To: <idn@ops.ietf.org>
Sent: Monday, January 28, 2002 09:06
Subject: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt


>
> Title: Punycode version 0.3.3
>
> Abstract:
> Punycode is a simple and efficient encoding designed for use with
> Internationalized Domain Names [IDN] [IDNA].  It uniquely and
> reversibly transforms a Unicode string [UNICODE] into an ASCII
> string.  ASCII characters in the Unicode string are represented
> literally, and non-ASCII characters are represented by ASCII
> characters that are allowed in hostname labels (letters, digits,
> and hyphens).  Bootstring is a general algorithm that allows a
> string of basic code points to uniquely represent any string of code
> points drawn from a larger set.  Punycode is an instance Bootstring
> that uses particular parameter values appropriate for IDNA.  This
> document specifies Bootstring and the parameter values for Punycode.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idn-punycode-00.txt
>
> This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.
>
> This document is for standards track.
>
> The co-chairs see a wg rough concensus on this document.
> Please send any proposed modification of the text to the wg mailing
list as
> well as to the wg co-chairs, stating clearly the text to be modified
and
> the new text.
>
> Marc & James
>
>
>




From owner-idn@ops.ietf.org  Tue Jan 29 11:32:29 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08454
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:32:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vb1y-000HpL-00
	for idn-data@psg.com; Tue, 29 Jan 2002 08:22:46 -0800
Received: from patan.sun.com ([192.18.98.43])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vb1y-000HpF-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 08:22:46 -0800
Received: from bebop.France.Sun.COM ([129.157.179.15])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10155;
	Tue, 29 Jan 2002 09:22:43 -0700 (MST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0TGMgF13530;
	Tue, 29 Jan 2002 17:22:42 +0100 (MET)
Date: Tue, 29 Jan 2002 17:19:08 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: "'Marc Blanchet'" <Marc.Blanchet@viagenie.qc.ca>, idn@ops.ietf.org
In-Reply-To: "Your message with ID" <3CD14E451751BD42BA48AAA50B07BAD60189B5E4@vsvapostal3.bkup6>
Message-ID: <Roam.SIMC.2.0.6.1012321148.9621.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> Marc,
> 
> A process point: this document is still written as an individual submission;
> it's not listed as a WG I-D.  Is it within the WG's scope to conduct a last
> call on the document?  Maybe it should be renamed and adopted by the WG
> first.

The AD approved doing the WG last call on this document.
While nameprep is the first user of stringprep there are other WGs that
are looking at using stringprep.
So having the IDN WG review this document is necessary but there might
potentially be other WGs that need to review it as well.
So it didn't make sense to make the draft be "owned" solely by IDN.

  Erik

> > From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca]
> > Sent: Monday, January 28, 2002 12:06 PM
> > To: idn@ops.ietf.org
> > Subject: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
> > 
> > 
> > Title: Preparation of Internationalized Strings ("stringprep")
> > 
> > This document describes a framework for preparing text 
> > strings in order
> > to increase the likelihood that string input and string 
> > comparison work
> > in ways that make sense for typical users throughout the world. The
> > stringprep protocol is useful for protocol identifier values, company
> > and personal names, internationalized domain names, and other text
> > strings.
> > 
> > This document does not specify how protocols should prepare text
> > strings. Protocols must create profiles of stringprep in 
> > order to fully
> > specify the processing options.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt
> > 
> > This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.
> > 
> > This document is for standards track.
> > 
> > Last call for this document is in conjunction with
> > draft-ietf-idn-nameprep, Stringprep Profile for Internationalized Host
> > Names. The original nameprep document was split into 2 documents:
> > stringprep and nameprep.
> > 
> > 
> > The co-chairs see a wg rough concensus on this document.
> > Please send any proposed modification of the text to the wg 
> > mailing list as
> > well as to the wg co-chairs, stating clearly the text to be 
> > modified and
> > the new text.
> > 
> > Marc & James
> > 
> 





From owner-idn@ops.ietf.org  Tue Jan 29 11:37:54 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08623
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 11:37:53 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vb8n-000I5F-00
	for idn-data@psg.com; Tue, 29 Jan 2002 08:29:49 -0800
Received: from heron.verisign.com ([216.168.233.95])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vb8m-000I58-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 08:29:48 -0800
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29])
	by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA26890;
	Tue, 29 Jan 2002 11:29:16 -0500 (EST)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19)
	id <C081W4TB>; Tue, 29 Jan 2002 11:29:05 -0500
Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5F5@vsvapostal3.bkup6>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'Dave Crocker'" <dhc@dcrocker.net>
Cc: "'idn@ops.ietf.org'" <idn@ops.ietf.org>
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Date: Tue, 29 Jan 2002 11:29:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Fine, Dave, it's a little uncommon for a WG to be last-calling a document
that isn't a WG work item and I wanted to be sure that we weren't getting
into a process issue that would cause problems later.  I understand the
relationship to the nameprep draft and withdraw the suggestion given Marc's
explanation that the ADs are OK with the process.

-Scott- 

> -----Original Message-----
> From: Dave Crocker [mailto:dhc@dcrocker.net]
> Sent: Tuesday, January 29, 2002 11:11 AM
> To: Hollenbeck, Scott
> Cc: 'Marc Blanchet'; idn@ops.ietf.org
> Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
> 
> 
> At 08:16 AM 1/29/2002 -0500, Hollenbeck, Scott wrote:
> >A process point: this document is still written as an individual
submission;
> >it's not listed as a WG I-D.  Is it within the WG's scope to conduct a
last
> >call on the document?  Maybe it should be renamed and adopted by the WG
> >first.
> 
> there is no benefit in doing this.

[snip]



From owner-idn@ops.ietf.org  Tue Jan 29 12:09:29 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09606
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 12:09:28 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VbXV-000Ivw-00
	for idn-data@psg.com; Tue, 29 Jan 2002 08:55:21 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VbXU-000Ivq-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 08:55:20 -0800
Received: from BBFUJIP.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id IAA26985;
	Tue, 29 Jan 2002 08:55:18 -0800
Message-Id: <5.1.0.14.2.20020129084054.02ff8008@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Jan 2002 08:42:56 -0800
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
From: Dave Crocker <dhc@dcrocker.net>
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Cc: "'idn@ops.ietf.org'" <idn@ops.ietf.org>
In-Reply-To: <3CD14E451751BD42BA48AAA50B07BAD60189B5F5@vsvapostal3.bkup6
 >
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 11:29 AM 1/29/2002 -0500, Hollenbeck, Scott wrote:
>Fine, Dave, it's a little uncommon for a WG to be last-calling a document
>that isn't a WG work item and I wanted to be sure that we weren't getting
>into a process issue that would cause problems later.  I understand the
>relationship to the nameprep draft and withdraw the suggestion given Marc's
>explanation that the ADs are OK with the process.

On the theory that the IETF makes standards of documents that are not part 
of a working group -- and indeed it does do this -- then it is difficult to 
imagine a problem with that document being first put through a working 
group review and approval.

You folks get top marks for thinking of the issue and raising it, but we 
are almost assuredly safe waiting for the IESG to push back on this one.  I 
can't imagine that they will.


d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Tue Jan 29 12:51:47 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11206
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 12:51:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vc7g-000K44-00
	for idn-data@psg.com; Tue, 29 Jan 2002 09:32:44 -0800
Received: from [211.218.145.193] (helo=postel2)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vc7f-000K3y-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 09:32:43 -0800
Received: (from root@localhost)
	by postel2.postel.co.kr (8.11.0/8.11.0) id g0THWYf31021
	for idn@ops.ietf.org; Wed, 30 Jan 2002 02:32:34 +0900
To: idn@ops.ietf.org
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by postel2 (8.11.0/8.11.0)
    with SMTP id g0THWV631018 for <idn@ops.ietf.org>; Wed, 30 Jan 2002
    02:32:32 +0900
MIME-Version: 1.0
X-Msmail-Priority: Normal
Message-Id: <042f01c1a8ea$e67e3910$ec1bd9d2@temp>
Subject: [idn] stringprep comment 1
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Wed, 30 Jan 2002 02:32:12 +0900
Content-Disposition: inline
Content-Type: text/html; charset=ks_c_5601-1987
Content-Transfer-Encoding: base64
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBU
cmFuc2l0aW9uYWwvL0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1
aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1r
c19jXzU2MDEtMTk4NyI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2
MDAuMCIgbmFtZT1HRU5FUkFUT1I+CjxTVFlMRT48L1NUWUxFPgo8L0hFQUQ+
CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4KPERJVj48U1RST05HPjxGT05UIGZh
Y2U9sby4siBzaXplPTI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElWPgo8
RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj5JbiZuYnNwOyBT
dHJpbmdwcmVwIHNlY3Rpb24gNi4zLCAKPC9GT05UPjwvU1RST05HPjwvRElW
Pgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj48L0ZPTlQ+
PC9TVFJPTkc+Jm5ic3A7PC9ESVY+CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNl
PbG8uLIgc2l6ZT0yPiIgPC9GT05UPjwvU1RST05HPk5ld2VyIHN0b3JlZCBz
dHJpbmcgLS0gClN1cHBvc2UgdGhhdCBhbiByZXF1ZXN0aW5nIGFwcGxpY2F0
aW9uIGlzIHVzaW5nPEJSPiZuYnNwO29sZFZlcnNpb24gYW5kIHRoZSAKc3Rv
cmVkIHN0cmluZyB3YXMgY3JlYXRlZCB1c2luZyBhIHByb2ZpbGUgdGhhdCB1
c2VzPEJSPiZuYnNwO25ld1ZlcnNpb24uIEJlY2F1c2UgCnRoZSByZXF1ZXN0
aW5nIGFwcGxpY2F0aW9uIHBhc3NlZCB0aHJvdWdoIGFueTxCUj4mbmJzcDt1
bmFzc2lnbmVkIGNvZGUgcG9pbnRzLCAKdGhlIHVzZXIgY2FuIHF1ZXJ5IG9u
IHN0b3JlZCBzdHJpbmdzIHRoYXQgdXNlPEJSPiZuYnNwO2NvZGUgcG9pbnRz
IGluIApuZXdWZXJzaW9uLiBObyBzdG9yZWQgc3RyaW5ncyBjYW4gaGF2ZSBj
b2RlIHBvaW50cyB0aGF0PEJSPiZuYnNwO2FyZSB1bmFzc2lnbmVkIAppbiBu
ZXdWZXJzaW9uLCBzaW5jZSB0aGF0IGlzIGlsbGVnYWwuIEluIHRoaXMgY2Fz
ZSwgdGhlPEJSPiZuYnNwO3F1ZXJ5aW5nIAphcHBsaWNhdGlvbiBoYXMgdG8g
ZW50ZXIgdGhlIHVuYXNzaWduZWQgY29kZSBwb2ludHMgaW4gdGhlPEJSPiZu
YnNwO2NvcnJlY3QgCm9yZGVyLCBhbmQgaGFzIHRvIHVzZSB1bmFzc2lnbmVk
IGNvZGUgcG9pbnRzIHRoYXQgd291bGQgbWFrZSBpdDxCUj4mbmJzcDt0aHJv
dWdoIApib3RoIHRoZSBtYXBwaW5nIGFuZCB0aGUgbm9ybWFsaXphdGlvbiBz
dGVwcy4iPEJSPjxCUj48U1RST05HPjxGT05UIGZhY2U9sby4siAKc2l6ZT0y
PiZuYnNwO1RoZSBvbGQgcXVlcnlpbmcgYXBwbGljYXRpb24gdXNpbmcgb2xk
VmVyc2lvbiBzdHJpbmdwcmVwJm5ic3A7IAoqY2Fubm90KiBwcmVkaWN0PC9G
T05UPjwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2x
vLiyIHNpemU9Mj48L0ZPTlQ+PC9TVFJPTkc+Jm5ic3A7PC9ESVY+CjxESVY+
PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPiZuYnNwOyAKMSkmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDt0aGU8L0ZPTlQ+PC9TVFJPTkc+PFNUUk9O
Rz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPiAKY29ycmVjdCBvcmRlciBvZiBj
b21iaW5pbmcgc2VxdWVuY2VzIG9mIG5ld2x5IGFzc2lnbmVkIApjaGFyYWN0
ZXJzPC9GT05UPjwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQg
ZmFjZT2xvLiyIHNpemU9Mj48L0ZPTlQ+PC9TVFJPTkc+Jm5ic3A7PC9ESVY+
CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPiZuYnNwOyZu
YnNwOzIpICZuYnNwOyZuYnNwOyB0aGUmbmJzcDsgCm5vcm1hbGl6ZWQgJmFt
cDsgY2FzZWZvbGRlZCBmb3JtIG9mIG5ld2x5IGFzc2lnbmVkIApjaGFyYWN0
ZXJzLjwvRk9OVD48L1NUUk9ORz48L0RJVj4KPERJVj48U1RST05HPjxGT05U
IGZhY2U9sby4siBzaXplPTI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElW
Pgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj4mbmJzcDtU
aGlzIGNob2ljZXMgYXJlIG9mdGVuIElNRShwbGF0Zm9ybSkgCmRlcGVuZGVu
dCBhbmQmbmJzcDsgZW5mb3JjaW5nIHN1Y2ggPC9GT05UPjwvU1RST05HPjwv
RElWPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj4mbmJz
cDsmbmJzcDsgbm9ybWFsaXplZCBjaGFyYWN0ZXIgaW5wdXRzIAphcmUmbmJz
cDsgYmV5b25kIGVuZCB1c2VycycgY2hvaWNlcyBhbmQgY2FwYWJpbGl0aWVz
PC9GT05UPjwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFj
ZT2xvLiyIHNpemU9Mj4mbmJzcDsmbmJzcDsgYW5kIGFsc28gYXJlIG91dCBv
ZiBjb250cm9sIG9mIAppbmRlcGVuZGFudCBhcHBsaWNhdGlvbiBhdXRob3Jz
IHdobyBhcmUgbm90PC9GT05UPjwvU1RST05HPjwvRElWPgo8RElWPjxTVFJP
Tkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj4mbmJzcDsmbmJzcDsgaW5zcGly
ZWQgCnByb3BoZXRzLjwvRk9OVD48L1NUUk9ORz48L0RJVj4KPERJVj48U1RS
T05HPjxGT05UIGZhY2U9sby4siBzaXplPTI+PC9GT05UPjwvU1RST05HPiZu
YnNwOzwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9
Mj4mbmJzcDsgTm9uLVVuaWNvZGUgbGVnYWN5IElNRXMgaGF2ZSZuYnNwO2Jl
ZW4gCnByb2R1Y2luZyB0aGVpciBvd24gcHJlZmVycmVkIGNoYXJhY3RlciBz
ZXF1ZW5jZXM8L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+CjxESVY+PFNUUk9ORz48
Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPiZuYnNwOyZuYnNwOyBmb3IgbmV3IHNj
cmlwdHMgYW5kIHRoZWlyIDEtMSAKbWFwcGluZyB0byBuZXcgVW5pY29kZSBw
b2ludHMmbmJzcDttYXkgcHJvZHVjZSB1bm5vcm1hbGl6ZWQgCm91dHB1dHM8
L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNl
PbG8uLIgc2l6ZT0yPiZuYnNwOyZuYnNwOyBhbmQgdGhleSB3aWxsIGJlIGZl
ZCBpbnRvIG9sZCAKYmxpbmQgYXBwbGljYXRpb25zIGFuZCBtYWtlIHRyb3Vi
bGVzIGFuZCBjb25mdXNpb25zIGFuZCAKZmFpbHR1cmVzLjwvRk9OVD48L1NU
Uk9ORz48L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXpl
PTI+Jm5ic3A7PC9GT05UPjwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+
PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj4mbmJzcDtUaGVyZWZvcmUsIHRoZSBs
YXN0IHNlbnRlbmNlIGluIHRoZSAKY2l0ZWQgcGFyYWdyYXBoIGRvZXMgbm90
IG1ha2Ugc2Vuc2UsIElNSE8uPC9GT05UPjwvU1RST05HPjwvRElWPgo8RElW
PjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj48L0ZPTlQ+PC9TVFJP
Tkc+Jm5ic3A7PC9ESVY+CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIg
c2l6ZT0yPlNvb2JvayBMZWU8L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+CjxESVY+
PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPiZuYnNwOyZuYnNwOyAK
PC9GT05UPjwvU1RST05HPjwvRElWPgo8aW1nIHNyYz1odHRwOi8vcG9zdGVs
Mi5wb3N0ZWwuY28ua3IvcmVhZC8xMDEyMzI1NTMyLWY5MGFjNWY4MDUzYTE2
NzlmMDNiNzk1N2JkNjg1YWVjLjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5p
ZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0aD0xIGhlaWdodD0xPgo8
L0JPRFk+CjwvSFRNTD4K



From owner-idn@ops.ietf.org  Tue Jan 29 13:01:39 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11540
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 13:01:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VcHY-000KNQ-00
	for idn-data@psg.com; Tue, 29 Jan 2002 09:42:56 -0800
Received: from [211.218.145.193] (helo=postel2)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VcHX-000KNG-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 09:42:55 -0800
Received: (from root@localhost)
	by postel2.postel.co.kr (8.11.0/8.11.0) id g0THgoX31383
	for idn@ops.ietf.org; Wed, 30 Jan 2002 02:42:50 +0900
To: idn@ops.ietf.org
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by postel2 (8.11.0/8.11.0)
    with SMTP id g0THgm631379 for <idn@ops.ietf.org>; Wed, 30 Jan 2002
    02:42:48 +0900
MIME-Version: 1.0
X-Msmail-Priority: Normal
Message-Id: <044001c1a8ec$55bb96f0$ec1bd9d2@temp>
Subject: [idn] stringprep comment 2
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Wed, 30 Jan 2002 02:42:34 +0900
Content-Disposition: inline
Content-Type: text/html; charset=ks_c_5601-1987
Content-Transfer-Encoding: base64
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBU
cmFuc2l0aW9uYWwvL0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1
aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1r
c19jXzU2MDEtMTk4NyI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2
MDAuMCIgbmFtZT1HRU5FUkFUT1I+CjxTVFlMRT48L1NUWUxFPgo8L0hFQUQ+
CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4KPERJVj48U1RST05HPjxGT05UIGZh
Y2U9sby4siBzaXplPTI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElWPgo8
RElWPjxGT05UIGZhY2U9sby4siBzaXplPTI+PFNUUk9ORz5JbiBzdHJpbmdw
cmVwJm5ic3A7IHNlY3Rpb24gCjYsPC9TVFJPTkc+PC9GT05UPjwvRElWPgo8
RElWPjxGT05UIGZhY2U9sby4siBzaXplPTI+PFNUUk9ORz48L1NUUk9ORz48
L0ZPTlQ+Jm5ic3A7PC9ESVY+CjxESVY+PEZPTlQgZmFjZT2xvLiyIHNpemU9
Mj48U1RST05HPiIgPC9TVFJPTkc+PEZPTlQgZmFjZT252cXBw7wgc2l6ZT0z
PjYuIFVuYXNzaWduZWQgCkNvZGUgUG9pbnRzIGluIFN0cmluZ3ByZXAgUHJv
ZmlsZXM8QlI+PEJSPlRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdHdvIGRpZmZl
cmVudCAKdHlwZXMgb2Ygc3RyaW5ncyBpbiB0eXBpY2FsPEJSPnByb3RvY29s
cyB3aGVyZSBpbnRlcm5hdGlvbmFsaXplZCBzdHJpbmdzIGFyZSAKdXNlZDog
InN0b3JlZCBzdHJpbmdzIiBhbmQ8QlI+InF1ZXJpZXMiLiBPZiBjb3Vyc2Us
IGRpZmZlcmVudCBJbnRlcm5ldCBwcm90b2NvbHMgCnVzZSBzdHJpbmdzIHZl
cnk8QlI+ZGlmZmVyZW50bHksIHNvIHRoZXNlIHRlcm1zIGNhbm5vdCBiZSB1
c2VkIGV4YWN0bHkgaW4gZXZlcnkgCnByb3RvY29sPEJSPnRoYXQgbmVlZHMg
dG8gdXNlIHN0cmluZ3ByZXAuIEluIGdlbmVyYWwsICJzdG9yZWQgc3RyaW5n
cyIgYXJlIApzdHJpbmdzPEJSPnRoYXQgYXJlIHVzZWQgaW4gcHJvdG9jb2wg
aWRlbnRpZmllcnMgYW5kIG5hbWVkIGVudGl0aWVzLCBzdWNoIGFzIApuYW1l
czxCUj5pbiBkaWdpdGFsIGNlcnRpZmljYXRlcywgRE5TIGRvbWFpbiBuYW1l
IHBhcnRzLCBhbmQgbmFtZXMgb2YgU05NUCAKb2JqZWN0cy48QlI+IlF1ZXJp
ZXMiIGFyZSBzdHJpbmdzIHRoYXQgYXJlIHVzZWQgdG8gbWF0Y2ggYWdhaW5z
dCBzdHJpbmdzIHRoYXQgCmFyZTxCUj5zdG9yZWQgaWRlbnRpZmllcnMsIHN1
Y2ggYXMgdXNlci1lbnRlcmVkIG5hbWVzIGZvciBkaWdpdGFsIApjZXJ0aWZp
Y2F0ZTxCUj5hdXRob3JpdGllcywgRE5TIGxvb2t1cHMsIGFuZCBTTk1QIHJl
cXVlc3RzLiAKIjwvRk9OVD48L0ZPTlQ+PC9ESVY+CjxESVY+PEZPTlQgZmFj
ZT2xvLiyIHNpemU9Mj48Rk9OVCBmYWNlPbG8uLIgCnNpemU9Mj48U1RST05H
PjwvU1RST05HPjwvRk9OVD48L0ZPTlQ+Jm5ic3A7PC9ESVY+CjxESVY+PFNU
Uk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPjwvRk9OVD48L1NUUk9ORz4m
bmJzcDs8L0RJVj4KPERJVj48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPjxGT05U
IGZhY2U9udnFwcO8IHNpemU9Mz48U1RST05HPjxGT05UIGZhY2U9sby4siBz
aXplPTI+SXMgCnRoaXMgY2xhc3NpZmljYXRpb24gZnJvbSZuYnNwOyBvdmVy
LXNpbXBsaWZpY2F0aW9ucyA/IAo8L0ZPTlQ+PC9TVFJPTkc+PFNUUk9ORz48
Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPm9ubHkgdHdvIAp0eXBlcz8mbmJzcDsm
bmJzcDs8L0ZPTlQ+PC9TVFJPTkc+PC9GT05UPjwvRk9OVD48L0RJVj4KPERJ
Vj48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPjxGT05UIGZhY2U9udnFwcO8IHNp
emU9Mz48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXplPTI+SXMgCnRoZXJl
IGFueSAzcmQgdHlwZSBwb3NzaWJsZT88L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+
CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPjwvRk9OVD48
L1NUUk9ORz4mbmJzcDs8L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9
sby4siBzaXplPTI+VG8gYmUgY29tcGxldGUsICd0eXBpY2FsJyAsJ2Nhbm5v
dCAuLiBleGFjdGx5JyAKYW5kICdpbiBnZW5lcmFsJyZuYnNwO2hhZCBiZXR0
ZXImbmJzcDtiZSByZW1vdmVkIGFuZDwvRk9OVD48L1NUUk9ORz48L0RJVj4K
PERJVj48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXplPTI+dGhlIGNsYXNz
aWZpY2F0aW9uIHNob3VsZCZuYnNwOyBmaXJzdCBkZWZpbmUgCiJzdHJvcmVk
IHN0cmluZ3MiIHByZWNpc2VseSBhbmQmbmJzcDsgdGhlbjwvRk9OVD48L1NU
Uk9ORz48L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXpl
PTI+ZGVmaW5lJm5ic3A7dGhlIGNvbXBsZW1lbnQgc2V0IAombmJzcDs8L0ZP
TlQ+PC9TVFJPTkc+PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPmFz
IHRoZSAicXVlcmllcyImbmJzcDsgaWYgaXQgCmlzIHByb3ZlZCB0aGF0IGFu
eSAzcmQgdHlwZSBkb2VzIG5vdCBleGlzdC48L0ZPTlQ+PC9TVFJPTkc+PC9E
SVY+CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPjwvRk9O
VD48L1NUUk9ORz4mbmJzcDs8L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZh
Y2U9sby4siBzaXplPTI+SSBoYXZlIGRvdWJ0Jm5ic3A7dGhhdCZuYnNwO3Ro
ZXJlIAphcmUmbmJzcDttYW55ICpncmF5IGFyZWFzKiB0aGF0Jm5ic3A7IGRv
IG5vdCBmYWxsIGludG8gZWl0aGVyIApjYXRlZ29yaWVzLjwvRk9OVD48L1NU
Uk9ORz48L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXpl
PTI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElWPgo8RElWPjxTVFJPTkc+
PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj5Tb29ib2sgTGVlPC9GT05UPjwvU1RS
T05HPjwvRElWPgo8RElWPjxCUj48L0RJVj48L0ZPTlQ+PC9GT05UPgo8aW1n
IHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZC8xMDEyMzI2
MTU0LWZjZWYxMWNmMDc5NDkxOWZlMGE5NGNkMDMzNjNkMjQyLjQxZTVmZDZm
MTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3
aWR0aD0xIGhlaWdodD0xPgo8L0JPRFk+CjwvSFRNTD4K



From owner-idn@ops.ietf.org  Tue Jan 29 13:27:18 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12592
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 13:27:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vcrc-000LZH-00
	for idn-data@psg.com; Tue, 29 Jan 2002 10:20:12 -0800
Received: from heron.verisign.com ([216.168.233.95])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vcrb-000LZB-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 10:20:11 -0800
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201])
	by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA06824
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 13:20:10 -0500 (EST)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19)
	id <DD9A751W>; Tue, 29 Jan 2002 13:20:03 -0500
Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B5F9@vsvapostal3.bkup6>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: idn@ops.ietf.org
Subject: RE: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Date: Tue, 29 Jan 2002 13:20:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

An editorial comment: would it be possible to capitalize instances of the
RFC 2119 directives "must", "may", "should", etc.?  Doing so will make it
far easier for implementers to not miss something that might come back to
bite them later.

-Scott-



From owner-idn@ops.ietf.org  Tue Jan 29 13:32:16 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12786
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 13:32:16 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VcqJ-000LWT-00
	for idn-data@psg.com; Tue, 29 Jan 2002 10:18:51 -0800
Received: from [211.218.145.193] (helo=postel2)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VcqI-000LWH-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 10:18:50 -0800
Received: (from root@localhost)
	by postel2.postel.co.kr (8.11.0/8.11.0) id g0TIIiD32661
	for idn@ops.ietf.org; Wed, 30 Jan 2002 03:18:44 +0900
To: idn@ops.ietf.org
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by postel2 (8.11.0/8.11.0)
    with SMTP id g0TIIh632659 for <idn@ops.ietf.org>; Wed, 30 Jan 2002
    03:18:43 +0900
MIME-Version: 1.0
X-Msmail-Priority: Normal
Message-Id: <047801c1a8f1$5a71d9c0$ec1bd9d2@temp>
Subject: [idn] stringprep comment 3
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Wed, 30 Jan 2002 03:18:29 +0900
Content-Disposition: inline
Content-Type: text/html; charset=ks_c_5601-1987
Content-Transfer-Encoding: base64
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBU
cmFuc2l0aW9uYWwvL0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1
aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1r
c19jXzU2MDEtMTk4NyI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI2
MDAuMCIgbmFtZT1HRU5FUkFUT1I+CjxTVFlMRT48L1NUWUxFPgo8L0hFQUQ+
CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4KPERJVj48U1RST05HPjxGT05UIGZh
Y2U9sby4siBzaXplPTI+PC9GT05UPjwvU1RST05HPiZuYnNwOzwvRElWPgo8
RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj4mbmJzcDtJbiBz
dHJpbmdwcmVwIAonYWJzdHJhY3QnPC9GT05UPjwvU1RST05HPjwvRElWPgo8
RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj48L0ZPTlQ+PC9T
VFJPTkc+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+IkFi
c3RyYWN0PEJSPjxCUj5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGZyYW1l
d29yayBmb3IgcHJlcGFyaW5nIHRleHQgCnN0cmluZ3MgaW4gb3JkZXI8QlI+
dG8gaW5jcmVhc2UgdGhlIGxpa2VsaWhvb2QgdGhhdCBzdHJpbmcgaW5wdXQg
YW5kIHN0cmluZyAKY29tcGFyaXNvbiB3b3JrPEJSPmluIHdheXMgdGhhdCBt
YWtlIHNlbnNlIGZvciB0eXBpY2FsIHVzZXJzIHRocm91Z2hvdXQgdGhlIAp3
b3JsZC4gVGhlPEJSPnN0cmluZ3ByZXAgcHJvdG9jb2wgaXMgdXNlZnVsIGZv
ciBwcm90b2NvbCBpZGVudGlmaWVyIHZhbHVlcywgCmNvbXBhbnk8QlI+YW5k
IHBlcnNvbmFsIG5hbWVzLCBpbnRlcm5hdGlvbmFsaXplZCBkb21haW4gbmFt
ZXMsIGFuZCBvdGhlciAKdGV4dDxCUj5zdHJpbmdzLiI8L0RJVj4KPERJVj4m
bmJzcDs8L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXpl
PTI+RG8geW91IHNlZSZuYnNwOyAiaW5jcmVhc2UgdGhlIGxpa2VsaWhvb2Qg
Li4uIiAKLCBub3QgImVuc3VyZSImbmJzcDsgPzwvRk9OVD48L1NUUk9ORz48
L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXplPTI+SG93
IGh1bWJsZSBhbmQgbW9kZXN0IAphc3NlcnRpb24hPC9GT05UPjwvU1RST05H
PjwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj5C
dXQsIGhvdyBjYW4gc3VjaCZuYnNwO2ZyYW1ld29yayBzZXJ2ZSBmb3IgCnBy
b3RvY29sICppZGVudGlmaWVyKiB2YWx1ZXMgPzwvRk9OVD48L1NUUk9ORz48
L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9sby4siBzaXplPTI+PC9G
T05UPjwvU1RST05HPiZuYnNwOzwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQg
ZmFjZT2xvLiyIHNpemU9Mj5DYW4gYW55IHN0YWJsZSBhbmQgdHJ1c3R3b3J0
aHkgaWRlbnRpZmllciAKc3lzdGVtIHJlbHkgb24gPC9GT05UPjwvU1RST05H
PjwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2xvLiyIHNpemU9Mj4m
bmJzcDtydWxlcyB0aGF0IGFyZSBqdXN0ICpsaWtlbHkgdG8gd29yayBmb3Ig
CnR5cGljYWwgdXNlcnMqID88L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+CjxESVY+
PEJSPiZuYnNwOzwvRElWPgo8RElWPiJJbiB0aGlzIGNhc2UsICJjb3JyZWN0
IiBtZWFucyB0aGF0IGlmIHR3byBkaWZmZXJlbnQgcGVvcGxlIGVudGVyIAp3
aGF0PEJSPnRoZXkgdGhpbmsgaXMgdGhlIHNhbWUgc3RyaW5nIGludG8gdHdv
IGRpZmZlcmVudCBpbnB1dCBtZWNoYW5pc21zLCAKdGhlPEJSPnN0cmluZ3Mg
c2hvdWxkIG1hdGNoIG9uIGEgY2hhcmFjdGVyLWJ5LWNoYXJhY3RlciBiYXNp
cy4iPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+PFNUUk9ORz48Rk9O
VCBmYWNlPbG8uLIgc2l6ZT0yPlRoaXMgcmVxdWlyZW1lbnQmbmJzcDsgaXMg
bm90IG1ldCZuYnNwOyBpbiAKInR1cmtpc2ggJmx0OyZuYnNwO0kgZG90LWFi
b3ZlJmd0OyBhbmQgJmx0O0kmZ3Q7Jmx0O2RvdC1hYm92ZSZndDsiIAouPC9G
T05UPjwvU1RST05HPjwvRElWPgo8RElWPjxTVFJPTkc+PEZPTlQgZmFjZT2x
vLiyIHNpemU9Mj5DdXJyZW50IHZlcnNpb24gb2Ygc3RyaW5ncHJlcCBmYWls
cyB0byB1bmlmaXkgCnRoZW0gYW5kIHRoZXJlZm9yZSA8L0ZPTlQ+PC9TVFJP
Tkc+PC9ESVY+CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0y
PmZhaWxzIHRvIHNhdGlzZnkmbmJzcDsmbmJzcDsgKnR5cGljYWwqIGF6ZXJp
IAphbmQgbGl0aHVhbmlhbiB1c2Vycy48L0ZPTlQ+PC9TVFJPTkc+PC9ESVY+
CjxESVY+PFNUUk9ORz48Rk9OVCBmYWNlPbG8uLIgc2l6ZT0yPjwvRk9OVD48
L1NUUk9ORz4mbmJzcDs8L0RJVj4KPERJVj48U1RST05HPjxGT05UIGZhY2U9
sby4siBzaXplPTI+U29vYm9rIApMZWU8L0ZPTlQ+PC9TVFJPTkc+PEJSPjwv
RElWPgo8aW1nIHNyYz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVh
ZC8xMDEyMzI4MzA5LWYwYjViM2RlYzVjYzcxNDA3NGIxMmYzZGI1Y2M3MmQ5
LjQxZTVmZDZmMTk3ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBv
c3RlbC50byB3aWR0aD0xIGhlaWdodD0xPgo8L0JPRFk+CjwvSFRNTD4K



From owner-idn@ops.ietf.org  Tue Jan 29 15:49:28 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20540
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 15:49:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vf2U-0000CN-00
	for idn-data@psg.com; Tue, 29 Jan 2002 12:39:34 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vf2T-0000CG-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 12:39:33 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TKdT301085
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 12:39:29 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101306b87cb36f187e@[165.227.249.20]>
In-Reply-To: <042f01c1a8ea$e67e3910$ec1bd9d2@temp>
References: <042f01c1a8ea$e67e3910$ec1bd9d2@temp>
Date: Tue, 29 Jan 2002 12:21:27 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] stringprep comment 1
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 2:32 AM +0900 1/30/02, Soobok Lee wrote:
>
>In  Stringprep section 6.3,
>
>" Newer stored string -- Suppose that an requesting application is using
>  oldVersion and the stored string was created using a profile that uses
>  newVersion. Because the requesting application passed through any
>  unassigned code points, the user can query on stored strings that use
>  code points in newVersion. No stored strings can have code points that
>  are unassigned in newVersion, since that is illegal. In this case, the
>  querying application has to enter the unassigned code points in the
>  correct order, and has to use unassigned code points that would make it
>  through both the mapping and the normalization steps."
>
>  The old querying application using oldVersion stringprep  *cannot* predict
>
>   1)    the correct order of combining sequences of newly assigned characters
>
>   2)    the  normalized & casefolded form of newly assigned characters.

Correct, but it does not need to, unless the Unicode Consortium goes 
against their promises about how they will handle normalization of 
newly-assigned characters. No new characters will be casefolded.

>  This choices are often IME(platform) dependent and  enforcing such
>    normalized character inputs are  beyond end users' choices and capabilities
>    and also are out of control of independant application authors

Agree. Fortunately, this is unneeded.

>   Non-Unicode legacy IMEs have been producing their own preferred 
>character sequences
>    for new scripts and their 1-1 mapping to new Unicode points may 
>produce unnormalized outputs
>    and they will be fed into old blind applications and make 
>troubles and confusions and failtures.

This makes no sense because new scripts don't have decompositions.

>  Therefore, the last sentence in the cited paragraph does not make 
>sense, IMHO.

It makes sense if you trust the Unicode Consortium to stick to its 
word about newly-assigned characters. If you don't, all of Section 6 
is useless, not just this subsection.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Tue Jan 29 15:49:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20553
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 15:49:32 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vf2U-0000CU-00
	for idn-data@psg.com; Tue, 29 Jan 2002 12:39:34 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vf2U-0000CM-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 12:39:34 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TKdU301088
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 12:39:30 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101307b87cb4cc6a4e@[165.227.249.20]>
In-Reply-To: <044001c1a8ec$55bb96f0$ec1bd9d2@temp>
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp>
Date: Tue, 29 Jan 2002 12:24:25 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] stringprep comment 2
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 2:42 AM +0900 1/30/02, Soobok Lee wrote:
>
>In stringprep  section 6,
>
>" 6. Unassigned Code Points in Stringprep Profiles
>
>This section describes two different types of strings in typical
>protocols where internationalized strings are used: "stored strings" and
>"queries". Of course, different Internet protocols use strings very
>differently, so these terms cannot be used exactly in every protocol
>that needs to use stringprep. In general, "stored strings" are strings
>that are used in protocol identifiers and named entities, such as names
>in digital certificates, DNS domain name parts, and names of SNMP objects.
>"Queries" are strings that are used to match against strings that are
>stored identifiers, such as user-entered names for digital certificate
>authorities, DNS lookups, and SNMP requests. "
>
>
>Is this classification from  over-simplifications ? only two types?
>Is there any 3rd type possible?

Maybe, but we could not think of any, and no one has suggested any 
yet. Do you have an example that we should deal with?

>To be complete, 'typical' ,'cannot .. exactly' and 'in general' had 
>better be removed and
>the classification should  first define "strored strings" precisely and  then
>define the complement set  as the "queries"  if it is proved that 
>any 3rd type does not exist.

That would indeed be complete. It is also impossible to do for the 
hundreds (thousands?) of Internet protocols.

>I have doubt that there are many *gray areas* that  do not fall into 
>either categories.

Your doubt may be correct, but we cannot act on your doubt without 
some concrete examples.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Tue Jan 29 15:50:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20595
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 15:50:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vf2W-0000Cc-00
	for idn-data@psg.com; Tue, 29 Jan 2002 12:39:36 -0800
Received: from above.proper.com ([208.184.76.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vf2V-0000CW-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 12:39:35 -0800
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TKdV301091
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 12:39:31 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05101308b87cb57f9442@[165.227.249.20]>
In-Reply-To: <047801c1a8f1$5a71d9c0$ec1bd9d2@temp>
References: <047801c1a8f1$5a71d9c0$ec1bd9d2@temp>
Date: Tue, 29 Jan 2002 12:39:25 -0800
To: idn@ops.ietf.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: [idn] stringprep comment 3
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 3:18 AM +0900 1/30/02, Soobok Lee wrote:
>
>  In stringprep 'abstract'
>
>
>"Abstract
>
>This document describes a framework for preparing text strings in order
>to increase the likelihood that string input and string comparison work
>in ways that make sense for typical users throughout the world. The
>stringprep protocol is useful for protocol identifier values, company
>and personal names, internationalized domain names, and other text
>strings."
>
>Do you see  "increase the likelihood ..." , not "ensure"  ?

Yes, exactly. We know *for sure* that there will be confusion; there 
have been many examples shown on this mailing list already.

>How humble and modest assertion!

Thank you.

>But, how can such framework serve for protocol *identifier* values ?

In exactly the same way that the current one does: there are lots of 
problems with string input and comparison today for LDH strings.

>Can any stable and trustworthy identifier system rely on
>  rules that are just *likely to work for typical users* ?

Of course. It works acceptably today for DNS names, for email 
addresses, and so on. Do you have a proposal for assuring the entry 
of today's DNS names and email addresses are correct? If so, many 
people would greatly want to see it!

>"In this case, "correct" means that if two different people enter what
>they think is the same string into two different input mechanisms, the
>strings should match on a character-by-character basis."
>
>This requirement  is not met  in "turkish < I dot-above> and <I><dot-above>" .
>Current version of stringprep fails to unifiy them and therefore
>fails to satisfy   *typical* azeri and lithuanian users.

Of course. This is no different than if one person enters 
"chongwon.co.kr" and another enters "chong-won.co.kr" and they get 
different results.

Everything you have said in this message is strong support for the 
IRNSS work. I hope you will contribute to it.

--Paul Hoffman, Director
--Internet Mail Consortium



From owner-idn@ops.ietf.org  Tue Jan 29 20:06:40 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26107
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 20:06:39 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vj48-0008m9-00
	for idn-data@psg.com; Tue, 29 Jan 2002 16:57:32 -0800
Received: from mail.i-dns.net ([203.126.116.228])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vj46-0008ly-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 16:57:31 -0800
Received: from jamessonyvaio (unknown [203.126.116.227])
	by mail.i-dns.net (Postfix) with SMTP
	id 6DD3CFFC2C; Wed, 30 Jan 2002 08:56:49 +0800 (SGT)
Message-ID: <002c01c1a929$1adba4c0$dd00a8c0@jamessonyvaio>
From: "James Seng/Personal" <jseng@pobox.org.sg>
To: "Marc Blanchet" <Marc.Blanchet@viagenie.qc.ca>,
        "Hollenbeck, Scott" <shollenbeck@verisign.com>, <idn@ops.ietf.org>
References:  <3CD14E451751BD42BA48AAA50B07BAD60189B5E4@vsvapostal3.bkup6> <270170000.1012313120@classic>
Subject: Re: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
Date: Wed, 30 Jan 2002 08:57:27 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

Just one additional note:

Whether a draft is tagged as draft-ietf-* or draft-<author>-*, they are
both internet draft. It is useful with an appropriate filename when
someone is search for wg work. Thus, it is norm to rename
draft-<author>-* name to draft-ietf-* when it become part of the wg
work.

However, it is not neccessary. A draft-<author>-* could still be a wg
draft so long the IETF Secretarial is informed. Since we doing the wg
last call, it is not neccessary to rename it...

All in the name... :-)

-James Seng

----- Original Message -----
From: "Marc Blanchet" <Marc.Blanchet@viagenie.qc.ca>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>; <idn@ops.ietf.org>
Sent: Tuesday, January 29, 2002 10:05 PM
Subject: RE: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt




-- mardi, janvier 29, 2002 08:16:24 -0500 "Hollenbeck, Scott"
<shollenbeck@verisign.com> wrote/a �crit:

> Marc,
>
> A process point: this document is still written as an individual
> submission; it's not listed as a WG I-D.  Is it within the WG's scope
to
> conduct a last call on the document?  Maybe it should be renamed and
> adopted by the WG first.

- good point.
- we have discussed about it with the ADs.
- the "old" version of nameprep was split in two documents:
  + stringprep, which is essentially a framework
  + and the current nameprep, which is a profile of stringprep.
  + the idea behind this split is to "standard reusability" ;-)). We
feel
(and actually see it) that this work would be useful for other working
groups, but not necessarily in the exact same manner: so the rationale
behind a framework document and profiles. One profiles for iSCSI is
currently in the works, for example.
- the "old" version of nameprep was a wg document, so the splitted two
should be.
- even if we don't see stringprep as wg document, there is another
rationale:
 + nameprep references stringprep: this means that we (the ietf
community
in general) must forward the two documents to the IESG for simultaneous
publication (as individual or wg document,doesn't matter).
 + stringprep contains a key discussion on versioning and other useful
info, which must be read and implemented by implementors of idn.
- so even if we might fight about the fact that stringprep is a wg
document
or not, it is still important that all people in this wg review
stringprep
closely. This will get a much stronger case for publishing it as RFC.
This
is why we do a wg last call on it.  As you know, it happens often in the
IETF that wg do wg last calls on documents that do not belong to their
wg,
just to have a much broader review. So this is a similar case.

- so the first goal here is to have this wg have a close review of
stringprep. The fact that it is a wg document or not is not that
important.

Marc.

>
> -Scott-
>
>> -----Original Message-----
>> From: Marc Blanchet [mailto:Marc.Blanchet@viagenie.qc.ca]
>> Sent: Monday, January 28, 2002 12:06 PM
>> To: idn@ops.ietf.org
>> Subject: [idn] IDN WG Last Call: draft-hoffman-stringprep-00.txt
>>
>>
>> Title: Preparation of Internationalized Strings ("stringprep")
>>
>> This document describes a framework for preparing text
>> strings in order
>> to increase the likelihood that string input and string
>> comparison work
>> in ways that make sense for typical users throughout the world. The
>> stringprep protocol is useful for protocol identifier values, company
>> and personal names, internationalized domain names, and other text
>> strings.
>>
>> This document does not specify how protocols should prepare text
>> strings. Protocols must create profiles of stringprep in
>> order to fully
>> specify the processing options.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-hoffman-stringprep-00.txt
>>
>> This two weeks WG last call ends Feb 11th 2002, 23h59 GMT-5.
>>
>> This document is for standards track.
>>
>> Last call for this document is in conjunction with
>> draft-ietf-idn-nameprep, Stringprep Profile for Internationalized
Host
>> Names. The original nameprep document was split into 2 documents:
>> stringprep and nameprep.
>>
>>
>> The co-chairs see a wg rough concensus on this document.
>> Please send any proposed modification of the text to the wg
>> mailing list as
>> well as to the wg co-chairs, stating clearly the text to be
>> modified and
>> the new text.
>>
>> Marc & James
>>
>



------------------------------------------
Marc Blanchet
Viag�nie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------





From owner-idn@ops.ietf.org  Tue Jan 29 21:03:21 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26778
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 21:03:20 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vjwc-000AKw-00
	for idn-data@psg.com; Tue, 29 Jan 2002 17:53:50 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vjwb-000AKq-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 17:53:49 -0800
Received: from cnnic.net.cn ([159.226.7.70]) by
          whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP
          id GQQANL00.OL6 for <idn@ops.ietf.org>; Wed, 30 Jan 2002 09:54:57 +0800 
Message-ID: <3C575199.4284394@cnnic.net.cn>
Date: Wed, 30 Jan 2002 09:51:22 +0800
From: "xiaodong lee" <lee@cnnic.net.cn>
Reply-To: lee@cnnic.net.cn
Organization: CNNIC-CNIC-CAS
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: zh-CN,zh-TW,en,sv,el
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: [idn] Unicode vs. IDN-CDN( personal opinion )
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

WITH SOME REVISION
Hello, every member of IDN maillist,

All that I said here is only my personal opinion, if anything
that I present is wrong, please correct me with my pleasure. I am a
student, so I try to understand such problem and express my opinion in a

student's point of view. I have often discussed such problems with my
classmates in
Chinese Academy of Sciences; they also doubt why we are still working on

such problem, which has incomplete and faulty basis, in IETF which is
the highest and authoriative techinical organizaiton in Internet area.
Including WG chairs and many kind and wisdom persons, many people have
made many efforts in IDN, and proposed many solutions for IDN, to be
truth, however, current standards and technologies cannot meet the goal
of such WG. It is a big challenge as everyone knows.

Recently, we often talked about the impact of Unicode ambiguity on CJK;
I
will follow such concept, which doesn't mean I don't support Unicode CJK

unification that is a great work achieved by some experts in CJK area.

Of course, I don't want to oppugn if Unicode is appropriate or not,
because there are no better solutions than choosing Unicode as the
standard of IDN. What I want to do is to pick out the default bought by
selecting Unicode and to explain why we do 1-1 mapping in IDN and leave
other cases in other ways, such as registration or IRNSS. Some people in

this mail list oppugn TC/SC draft is an incomplete solution and cannot
be understand, I wish what I said could help them to understand the
difficulty and essential of TC/SC problems.

Nameprep announced that it would follow the change of Unicode. Because
Unicode only collect the scripts of most languages of the world, so it
cannot handle many problems, such as TC/SC. Of course, it doesn't
collect all scripts simply, it has been doing CJK unification, all
characters in same scripts are reduced to one code point in Unicode,
that is very useful in information exchange in CJK area, but it bring
much trouble for us to do TC/SC equivalent in IDN or CDN. So Unicode is
very successful in many technical areas, but it is an incomplete
solution for IDN, for at lease it cannot meet the requirement of CDN,
which own more than 70% code points in Unicode. That is why Mr. Kenny
Huang proposed to prohibit CJK code points in IDNA, I think.

Unicode has done CJK horizontal unification, and as some persons from
Unicode said, they are considering doing vertical unification in CJKV,
which will handle some problems, including TC/SC equivalent. WILL
NAMEPREP FOLLOW SUCH UNIFICATION IN THE FUTURE? I am wondering how to
deal with many problems caused by current IDN selection in the future,
and how does IETF explain such results for so many CJK users? So as a
co-author of Tsconv draft, I proposed to solve some doubtless problems
in IDN, and leave uncertain problems for the future or other area, which

is not a big problem as someone imaged and worried. Theoretically, if
some problems are very difficult to solve, why don't we solve it step by

step?

If someone thinks I bring a problem not to be worth discussing, just
cancel it please, because when I saw recent many messages around such
problem, I feel a little pity about the future of IDN. Why don't we
select some feasible solution, more than doing hurried LAST-CALL for all

core documents.

I think we should split TC/SC problems into two parts: non-disputed 1-1
part and
the other, for the first part, it is the task of IDN, for the other
part, we could
handle them in IRNSS maybe.  and that, with IDN and IRNSS, we could try
to provide a perfect solution for end users, I think.

Anyway, I suggest all members to consider such problem carefully and put

IDN into a successful process!



Best Regards!

--
______________________________________

      XiaoDong LEE ( X.D. Lee )
______________________________________
 China  Network   Information  Center
 Tel.  (O):      +86-10-62619750-3020
 Email (O):          Lee@cnnic.net.cn
       (P): XiaoDong.Lee@computer.org
 Homepage :    http://xiaodong.n3.net
______________________________________





From owner-idn@ops.ietf.org  Tue Jan 29 21:41:57 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28209
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 21:41:57 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VkYH-000BJ5-00
	for idn-data@psg.com; Tue, 29 Jan 2002 18:32:45 -0800
Received: from [211.254.82.200] (helo=neokitty.localdomain)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VkYG-000BIz-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 18:32:44 -0800
Received: (from newcat@localhost)
	by neokitty.localdomain (8.11.3/8.11.3) id g0U2X7n02247
	for idn@ops.ietf.org; Wed, 30 Jan 2002 11:33:07 +0900
X-Authentication-Warning: neokitty.localdomain: newcat set sender to newcat@spsoft.co.kr using -f
Date: Wed, 30 Jan 2002 11:33:07 +0900
From: YangWoo Ko <newcat@spsoft.co.kr>
To: idn@ops.ietf.org
Subject: Re: [idn] Unicode vs. IDN-CDN( personal opinion )
Message-ID: <20020130023306.GA2122@spsoft.co.kr>
References: <3C575199.4284394@cnnic.net.cn>
Mime-Version: 1.0
Content-Type: text/plain; charset=euc-kr
Content-Disposition: inline
In-Reply-To: <3C575199.4284394@cnnic.net.cn>
User-Agent: Mutt/1.3.24i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dear Xiaodong Lee,

You clearly explained what Chinese people suggested through Kenny Huang. 
But, what I am not still so sure are;

(1) Is it possible to make a 1-1 table which will satisfy Chinese people,
other CJK people, and rest of the world ?
(2) If we depends on IRNSS (or other non-DNS solution), how can we handle
it seamless manner ? If ordinary people will (usually) use higher level 
service only, why is "TC/SC equivalence" so important, even though we can 
solve it (partially) by registraion policy of registries ?

My best regards

On Wed, Jan 30, 2002 at 09:51:22AM +0800, xiaodong lee wrote:
> WITH SOME REVISION
> Hello, every member of IDN maillist,
> 
> All that I said here is only my personal opinion, if anything
> that I present is wrong, please correct me with my pleasure. I am a
> student, so I try to understand such problem and express my opinion in a
> 
> student's point of view. I have often discussed such problems with my
> classmates in
> Chinese Academy of Sciences; they also doubt why we are still working on
> 
> such problem, which has incomplete and faulty basis, in IETF which is
> the highest and authoriative techinical organizaiton in Internet area.
> Including WG chairs and many kind and wisdom persons, many people have
> made many efforts in IDN, and proposed many solutions for IDN, to be
> truth, however, current standards and technologies cannot meet the goal
> of such WG. It is a big challenge as everyone knows.
> 
> Recently, we often talked about the impact of Unicode ambiguity on CJK;
> I
> will follow such concept, which doesn't mean I don't support Unicode CJK
> 
> unification that is a great work achieved by some experts in CJK area.
> 
> Of course, I don't want to oppugn if Unicode is appropriate or not,
> because there are no better solutions than choosing Unicode as the
> standard of IDN. What I want to do is to pick out the default bought by
> selecting Unicode and to explain why we do 1-1 mapping in IDN and leave
> other cases in other ways, such as registration or IRNSS. Some people in
> 
> this mail list oppugn TC/SC draft is an incomplete solution and cannot
> be understand, I wish what I said could help them to understand the
> difficulty and essential of TC/SC problems.
> 
> Nameprep announced that it would follow the change of Unicode. Because
> Unicode only collect the scripts of most languages of the world, so it
> cannot handle many problems, such as TC/SC. Of course, it doesn't
> collect all scripts simply, it has been doing CJK unification, all
> characters in same scripts are reduced to one code point in Unicode,
> that is very useful in information exchange in CJK area, but it bring
> much trouble for us to do TC/SC equivalent in IDN or CDN. So Unicode is
> very successful in many technical areas, but it is an incomplete
> solution for IDN, for at lease it cannot meet the requirement of CDN,
> which own more than 70% code points in Unicode. That is why Mr. Kenny
> Huang proposed to prohibit CJK code points in IDNA, I think.
> 
> Unicode has done CJK horizontal unification, and as some persons from
> Unicode said, they are considering doing vertical unification in CJKV,
> which will handle some problems, including TC/SC equivalent. WILL
> NAMEPREP FOLLOW SUCH UNIFICATION IN THE FUTURE? I am wondering how to
> deal with many problems caused by current IDN selection in the future,
> and how does IETF explain such results for so many CJK users? So as a
> co-author of Tsconv draft, I proposed to solve some doubtless problems
> in IDN, and leave uncertain problems for the future or other area, which
> 
> is not a big problem as someone imaged and worried. Theoretically, if
> some problems are very difficult to solve, why don't we solve it step by
> 
> step?
> 
> If someone thinks I bring a problem not to be worth discussing, just
> cancel it please, because when I saw recent many messages around such
> problem, I feel a little pity about the future of IDN. Why don't we
> select some feasible solution, more than doing hurried LAST-CALL for all
> 
> core documents.
> 
> I think we should split TC/SC problems into two parts: non-disputed 1-1
> part and
> the other, for the first part, it is the task of IDN, for the other
> part, we could
> handle them in IRNSS maybe.  and that, with IDN and IRNSS, we could try
> to provide a perfect solution for end users, I think.
> 
> Anyway, I suggest all members to consider such problem carefully and put
> 
> IDN into a successful process!
> 
> 
> 
> Best Regards!
> 
> --
> ______________________________________
> 
>       XiaoDong LEE ( X.D. Lee )
> ______________________________________
>  China  Network   Information  Center
>  Tel.  (O):      +86-10-62619750-3020
>  Email (O):          Lee@cnnic.net.cn
>        (P): XiaoDong.Lee@computer.org
>  Homepage :    http://xiaodong.n3.net
> ______________________________________
> 
> 

-- 
/*------------------------------------------------
YangWoo Ko : newcat@spsoft.co.kr
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/



From owner-idn@ops.ietf.org  Tue Jan 29 22:10:59 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28573
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 22:10:59 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vl0C-000C0D-00
	for idn-data@psg.com; Tue, 29 Jan 2002 19:01:36 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vl0B-000C06-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 19:01:36 -0800
Received: from deng ([159.226.7.68]) by whale.cnnic.net.cn
          (Netscape Messaging Server 4.15) with SMTP id GQQDRZ00.FLI; Wed,
          30 Jan 2002 11:02:23 +0800 
Message-ID: <00bb01c1a939$4e7a4330$4407e29f@deng>
From: "xiang deng" <deng@cnnic.net.cn>
To: "Mark Davis \(jtcsv\)" <mark.davis@jtcsv.com>,
        "Adam M. Costello" <amc@cs.berkeley.edu>
Cc: "Marc Blanchet" <Marc.Blanchet@viagenie.qc.ca>, <idn@ops.ietf.org>,
        "Markus Scherer" <markus.scherer@us.ibm.com>
References: <69120000.1012237575@classic> <013601c1a8e0$c852e120$08d8ea0c@c1340594a>
Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Date: Wed, 30 Jan 2002 10:53:33 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA28573


----- Original Message ----- 
From: "Mark Davis (jtcsv)" <mark.davis@jtcsv.com>
> The final result is:
> <4ED6><4EEC><4E3A><4EC0><4E48><4E0D><8BF4><4E2D><6587>
>

The final result is:
<4e16><754c><62e5><6709><4e0d><540c><7684><6c11><65cf><3001><6587><5316><3001><5386><53f2><ff0c><624d><663e><5f97><751f><52a8><53ef><7231>
<5f7c><6b64><5c0a><91cd><3001><76f8><4e92><5e2e><52a9><3001><5145><6ee1><4ec1><7231><ff0c><4e16><754c><624d><6709><660e><5929><7684><7f8e><597d><4e0e><548c><5e73>

Deng xiang 


From owner-idn@ops.ietf.org  Tue Jan 29 22:15:35 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28649
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 22:15:35 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vl07-000C04-00
	for idn-data@psg.com; Tue, 29 Jan 2002 19:01:31 -0800
Received: from [159.226.6.187] (helo=whale.cnnic.net.cn)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vl06-000Bzw-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 19:01:30 -0800
Received: from cnnic.net.cn ([159.226.7.70]) by
          whale.cnnic.net.cn (Netscape Messaging Server 4.15) with ESMTP
          id GQQDSE00.FLJ; Wed, 30 Jan 2002 11:02:38 +0800 
Message-ID: <3C576177.224CAE1E@cnnic.net.cn>
Date: Wed, 30 Jan 2002 10:59:03 +0800
From: "xiaodong lee" <lee@cnnic.net.cn>
Reply-To: lee@cnnic.net.cn
Organization: CNNIC-CNIC-CAS
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: zh-CN,zh-TW,en,sv,el
MIME-Version: 1.0
To: YangWoo Ko <newcat@spsoft.co.kr>, idn@ops.ietf.org
Subject: Re: [idn] Unicode vs. IDN-CDN( personal opinion )
References: <3C575199.4284394@cnnic.net.cn> <20020130023306.GA2122@spsoft.co.kr>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Mr. Ko,

As I know, not only Chinese people has such requirement, but also other people

of CJK area, of course, not including all codepoints of TC/SC. I consult such
problem with our expert in Unicode, he works on CJK area with other experts
of Korea and Japan. In some sense, I think it is trustworthiness.

Of course, we could not satify all people, but we could try to make a feasible

table for that, if we work hard, it maybe only need some months. As I know,
you and some persons of Korea have considered such problem carefully and
taken more positive actions on that. so I think it is possible, if we do not
only
care the time process to earn commercial profit on IDN.

As you know, registration solution is far in-sufficient for that. even though
it will
bring same result for end users( transparent for them), it make much trouble
for
administrator, there are so many Han characters.

If we let it be in IDN layer, and solve TC/SC problem in above layer. it will
hurt users profit, after all IDN is available for them. What we should do is
to
reduce it, if we could not solve it perfectly and completely, I think.

Best Regards!

Xiaodong

YangWoo Ko wrote:

> Dear Xiaodong Lee,
>
> You clearly explained what Chinese people suggested through Kenny Huang.
> But, what I am not still so sure are;
>
> (1) Is it possible to make a 1-1 table which will satisfy Chinese people,
> other CJK people, and rest of the world ?
> (2) If we depends on IRNSS (or other non-DNS solution), how can we handle
> it seamless manner ? If ordinary people will (usually) use higher level
> service only, why is "TC/SC equivalence" so important, even though we can
> solve it (partially) by registraion policy of registries ?
>
> My best regards
>
> On Wed, Jan 30, 2002 at 09:51:22AM +0800, xiaodong lee wrote:
> > WITH SOME REVISION
> > Hello, every member of IDN maillist,
> >
> > All that I said here is only my personal opinion, if anything
> > that I present is wrong, please correct me with my pleasure. I am a
> > student, so I try to understand such problem and express my opinion in a
> >
> > student's point of view. I have often discussed such problems with my
> > classmates in
> > Chinese Academy of Sciences; they also doubt why we are still working on
> >
> > such problem, which has incomplete and faulty basis, in IETF which is
> > the highest and authoriative techinical organizaiton in Internet area.
> > Including WG chairs and many kind and wisdom persons, many people have
> > made many efforts in IDN, and proposed many solutions for IDN, to be
> > truth, however, current standards and technologies cannot meet the goal
> > of such WG. It is a big challenge as everyone knows.
> >
> > Recently, we often talked about the impact of Unicode ambiguity on CJK;
> > I
> > will follow such concept, which doesn't mean I don't support Unicode CJK
> >
> > unification that is a great work achieved by some experts in CJK area.
> >
> > Of course, I don't want to oppugn if Unicode is appropriate or not,
> > because there are no better solutions than choosing Unicode as the
> > standard of IDN. What I want to do is to pick out the default bought by
> > selecting Unicode and to explain why we do 1-1 mapping in IDN and leave
> > other cases in other ways, such as registration or IRNSS. Some people in
> >
> > this mail list oppugn TC/SC draft is an incomplete solution and cannot
> > be understand, I wish what I said could help them to understand the
> > difficulty and essential of TC/SC problems.
> >
> > Nameprep announced that it would follow the change of Unicode. Because
> > Unicode only collect the scripts of most languages of the world, so it
> > cannot handle many problems, such as TC/SC. Of course, it doesn't
> > collect all scripts simply, it has been doing CJK unification, all
> > characters in same scripts are reduced to one code point in Unicode,
> > that is very useful in information exchange in CJK area, but it bring
> > much trouble for us to do TC/SC equivalent in IDN or CDN. So Unicode is
> > very successful in many technical areas, but it is an incomplete
> > solution for IDN, for at lease it cannot meet the requirement of CDN,
> > which own more than 70% code points in Unicode. That is why Mr. Kenny
> > Huang proposed to prohibit CJK code points in IDNA, I think.
> >
> > Unicode has done CJK horizontal unification, and as some persons from
> > Unicode said, they are considering doing vertical unification in CJKV,
> > which will handle some problems, including TC/SC equivalent. WILL
> > NAMEPREP FOLLOW SUCH UNIFICATION IN THE FUTURE? I am wondering how to
> > deal with many problems caused by current IDN selection in the future,
> > and how does IETF explain such results for so many CJK users? So as a
> > co-author of Tsconv draft, I proposed to solve some doubtless problems
> > in IDN, and leave uncertain problems for the future or other area, which
> >
> > is not a big problem as someone imaged and worried. Theoretically, if
> > some problems are very difficult to solve, why don't we solve it step by
> >
> > step?
> >
> > If someone thinks I bring a problem not to be worth discussing, just
> > cancel it please, because when I saw recent many messages around such
> > problem, I feel a little pity about the future of IDN. Why don't we
> > select some feasible solution, more than doing hurried LAST-CALL for all
> >
> > core documents.
> >
> > I think we should split TC/SC problems into two parts: non-disputed 1-1
> > part and
> > the other, for the first part, it is the task of IDN, for the other
> > part, we could
> > handle them in IRNSS maybe.  and that, with IDN and IRNSS, we could try
> > to provide a perfect solution for end users, I think.
> >
> > Anyway, I suggest all members to consider such problem carefully and put
> >
> > IDN into a successful process!
> >
> >
> >
> > Best Regards!
> >
> > --
> > ______________________________________
> >
> >       XiaoDong LEE ( X.D. Lee )
> > ______________________________________
> >  China  Network   Information  Center
> >  Tel.  (O):      +86-10-62619750-3020
> >  Email (O):          Lee@cnnic.net.cn
> >        (P): XiaoDong.Lee@computer.org
> >  Homepage :    http://xiaodong.n3.net
> > ______________________________________
> >
> >
>
> --
> /*------------------------------------------------
> YangWoo Ko : newcat@spsoft.co.kr
> We Invent Enterprise Software Solutions
> and Make You Secure & Powerful.
> ------------------------------------------------*/

--
______________________________________

      XiaoDong LEE ( X.D. Lee )
______________________________________
 China  Network   Information  Center
 Tel.  (O):      +86-10-62619750-3020
 Email (O):          Lee@cnnic.net.cn
       (P): XiaoDong.Lee@computer.org
 Homepage :    http://xiaodong.n3.net
______________________________________





From owner-idn@ops.ietf.org  Tue Jan 29 23:09:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00532
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 23:09:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vluo-000DTN-00
	for idn-data@psg.com; Tue, 29 Jan 2002 20:00:06 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vlun-000DTG-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 20:00:05 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16Vlum-0000iS-00
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 20:00:04 -0800
Date: Wed, 30 Jan 2002 04:00:04 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: [idn] Needed changes to IDNA before last call
Message-ID: <20020130040004.GC32582@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <3C56BE14.F8D0895D@trab.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3C56BE14.F8D0895D@trab.se>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dan Oscarsson <Dan.Oscarsson@trab.se> wrote:

> I suggest the following is done:
> 
> The draft: idn-nameprep
> Title change: Stringprep profile for Internationalised DNS labels.

I agree, except that I would recommend "Stringprep Profile for
Internationalized Domain Names", to be consistent with the title of the
IDNA draft.

> The draft: idn-idna:
> The ToASCII must be applied to ALL labels containing non-ASCII.

Rule 1 already says:

    Whenever a domain name is put into a generic domain name slot, every
    label MUST contain only ASCII characters.

"every label".

> The steps need a slight change:
>  - character restrictions will apply depending on label, it could be
>    host name or e-mail name.

Step 3 of ToASCII already says "If the label is part of a host name (or
is subject to host name syntax rules) then perform these checks".

When you say "e-mail name" do you mean the local part (before the @)?
That's outside our jurisdiction.  Another working group will have to
decide how to internationalize email local parts.  We can only tell how
to deal with domain names.

You may be concerned about resource records that contain email addresses
represented as domain names (with the local part as the first label).
Currently there is no problem, because all email address local parts are
ASCII according to RFC 2822.

>  - Encoding into ACE must use Punycode WITH case marking so that
>    case can be restored when using ToUnicode.
> 
> ToUnicode is fine, but decoding Punycode must restore case.

I have already argued for mixed-case support as best I can.  I couldn't
quite get it *mentioned* in the IDNA and Nameprep documents.  You don't
have a prayer of getting it *required*.

Of course, the working group that internationalizes email local parts
would have the option of writing a spec that requires Punycode with
mixed-case support.

AMC



From owner-idn@ops.ietf.org  Tue Jan 29 23:16:12 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00624
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 23:16:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vm3b-000Dcm-00
	for idn-data@psg.com; Tue, 29 Jan 2002 20:09:11 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vm3a-000Dcf-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 20:09:10 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16Vm3a-0000k8-00
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 20:09:10 -0800
Date: Wed, 30 Jan 2002 04:09:10 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: [idn] stringprep comment 2
Message-ID: <20020130040910.GD32582@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <044001c1a8ec$55bb96f0$ec1bd9d2@temp>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Soobok Lee <lsb@postel.co.kr> wrote:

> 6. Unassigned Code Points in Stringprep Profiles
>
> This section describes two different types of strings in typical
> protocols where internationalized strings are used: "stored strings"
> and "queries".
>
> Is this classification from over-simplifications ? only two types?  Is
> there any 3rd type possible?

I think what this section really depends on is that whenever two strings
are compared, at least one of the strings must have been prepared using
strict stringprep (no unassigned code points allowed), while the other
may have been prepared using loose stringprep (unassigned code points
allowed).  This allows false negatives (where the strings don't match
even though you wish they did), but prevents false positives (where the
strings match even though they shouldn't).

Applications and protocols need to do whatever is necessary to guarantee
that whenever two strings are compared, at least one was prepared using
strict stringprep.  Typically they would satisfy that requirement by
classifying strings into "stored strings" and "query strings", using
strict stringprep on the stored strings, and never comparing two query
strings.  But it's up to each application/protocol to define that
classification for its own strings.

Perhaps the document should say something like that.

AMC



From owner-idn@ops.ietf.org  Tue Jan 29 23:43:24 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01346
	for <idn-archive@lists.ietf.org>; Tue, 29 Jan 2002 23:43:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VmOl-000DuC-00
	for idn-data@psg.com; Tue, 29 Jan 2002 20:31:03 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VmOk-000Du6-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 20:31:02 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16VmOk-0000nN-00
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 20:31:02 -0800
Date: Wed, 30 Jan 2002 04:31:02 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: idn@ops.ietf.org
Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Message-ID: <20020130043102.GE32582@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <69120000.1012237575@classic> <013601c1a8e0$c852e120$08d8ea0c@c1340594a> <3CD14E451751BD42BA48AAA50B07BAD60189B5F9@vsvapostal3.bkup6>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <013601c1a8e0$c852e120$08d8ea0c@c1340594a> <3CD14E451751BD42BA48AAA50B07BAD60189B5F9@vsvapostal3.bkup6>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

"Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:

> An editorial comment: would it be possible to capitalize instances of
> the RFC 2119 directives "must", "may", "should", etc.?

It would certainly be *possible*.  :)

> Doing so will make it far easier for implementers to not miss
> something that might come back to bite them later.

I remain skeptical of that claim.  I personally find the all-caps MUST
SHOULD etc. to be distracting and not at all helpful.

If the group demands this then I'll write an awk script to take care of
it, but I'd rather not.

"Mark Davis (jtcsv)" <mark.davis@jtcsv.com> wrote:

> I would recommend adding some annotated examples of decoding to
> Punycode in a section 7.1 and referencing them from the text.

Good idea.

AMC



From owner-idn@ops.ietf.org  Wed Jan 30 00:45:09 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02504
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 00:45:09 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VnNa-000EaG-00
	for idn-data@psg.com; Tue, 29 Jan 2002 21:33:54 -0800
Received: from [211.218.145.193] (helo=postel2)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VnNY-000EaA-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 21:33:53 -0800
Received: (from root@localhost)
	by postel2.postel.co.kr (8.11.0/8.11.0) id g0U5Xb112223
	for idn@ops.ietf.org; Wed, 30 Jan 2002 14:33:37 +0900
To: "IETF idn working group" <idn@ops.ietf.org>
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by postel2 (8.11.0/8.11.0)
    with SMTP id g0U5XZ612218 for <idn@ops.ietf.org>; Wed, 30 Jan 2002
    14:33:35 +0900
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64
X-Msmail-Priority: Normal
Message-Id: <05f801c1a94f$a37b93a0$ec1bd9d2@temp>
Subject: Re: [idn] stringprep comment 2
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp>
    <20020130040910.GD32582@nicemice.net>
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Wed, 30 Jan 2002 14:33:24 +0900
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjExcHQnPgpI
aSwgQWRhbQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIApGcm9tJiM1
ODsgIkFkYW0gTS4gQ29zdGVsbG8iIDxpZG4uYW1jKzBAbmljZW1pY2UubmV0
LlJlbW92ZVRoaXNXb3JkPgpUbyYjNTg7IDxpZG5Ab3BzLmlldGYub3JnPgpT
ZW50JiM1ODsgV2VkbmVzZGF5LCBKYW51YXJ5IDMwLCAyMDAyIDEmIzU4OzA5
IFBNClN1YmplY3QmIzU4OyBSZSYjNTg7IFtpZG5dIHN0cmluZ3ByZXAgY29t
bWVudCAyCgoKPiBTb29ib2sgTGVlIDxsc2JAcG9zdGVsLmNvLmtyPiB3cm90
ZSYjNTg7Cj4gCj4gPiA2LiBVbmFzc2lnbmVkIENvZGUgUG9pbnRzIGluIFN0
cmluZ3ByZXAgUHJvZmlsZXMKPiA+Cj4gPiBUaGlzIHNlY3Rpb24gZGVzY3Jp
YmVzIHR3byBkaWZmZXJlbnQgdHlwZXMgb2Ygc3RyaW5ncyBpbiB0eXBpY2Fs
Cj4gPiBwcm90b2NvbHMgd2hlcmUgaW50ZXJuYXRpb25hbGl6ZWQgc3RyaW5n
cyBhcmUgdXNlZCYjNTg7ICJzdG9yZWQgc3RyaW5ncyIKPiA+IGFuZCAicXVl
cmllcyIuCj4gPgo+ID4gSXMgdGhpcyBjbGFzc2lmaWNhdGlvbiBmcm9tIG92
ZXItc2ltcGxpZmljYXRpb25zID8gb25seSB0d28gdHlwZXM/ICBJcwo+ID4g
dGhlcmUgYW55IDNyZCB0eXBlIHBvc3NpYmxlPwo+IAo+IEkgdGhpbmsgd2hh
dCB0aGlzIHNlY3Rpb24gcmVhbGx5IGRlcGVuZHMgb24gaXMgdGhhdCB3aGVu
ZXZlciB0d28gc3RyaW5ncwo+IGFyZSBjb21wYXJlZCwgYXQgbGVhc3Qgb25l
IG9mIHRoZSBzdHJpbmdzIG11c3QgaGF2ZSBiZWVuIHByZXBhcmVkIHVzaW5n
Cj4gc3RyaWN0IHN0cmluZ3ByZXAgKG5vIHVuYXNzaWduZWQgY29kZSBwb2lu
dHMgYWxsb3dlZCksIHdoaWxlIHRoZSBvdGhlcgo+IG1heSBoYXZlIGJlZW4g
cHJlcGFyZWQgdXNpbmcgbG9vc2Ugc3RyaW5ncHJlcCAodW5hc3NpZ25lZCBj
b2RlIHBvaW50cwo+IGFsbG93ZWQpLiAgVGhpcyBhbGxvd3MgZmFsc2UgbmVn
YXRpdmVzICh3aGVyZSB0aGUgc3RyaW5ncyBkb24ndCBtYXRjaAo+IGV2ZW4g
dGhvdWdoIHlvdSB3aXNoIHRoZXkgZGlkKSwgYnV0IHByZXZlbnRzIGZhbHNl
IHBvc2l0aXZlcyAod2hlcmUgdGhlCj4gc3RyaW5ncyBtYXRjaCBldmVuIHRo
b3VnaCB0aGV5IHNob3VsZG4ndCkuCj4gCj4gQXBwbGljYXRpb25zIGFuZCBw
cm90b2NvbHMgbmVlZCB0byBkbyB3aGF0ZXZlciBpcyBuZWNlc3NhcnkgdG8g
Z3VhcmFudGVlCj4gdGhhdCB3aGVuZXZlciB0d28gc3RyaW5ncyBhcmUgY29t
cGFyZWQsIGF0IGxlYXN0IG9uZSB3YXMgcHJlcGFyZWQgdXNpbmcKPiBzdHJp
Y3Qgc3RyaW5ncHJlcC4gIFR5cGljYWxseSB0aGV5IHdvdWxkIHNhdGlzZnkg
dGhhdCByZXF1aXJlbWVudCBieQo+IGNsYXNzaWZ5aW5nIHN0cmluZ3MgaW50
byAic3RvcmVkIHN0cmluZ3MiIGFuZCAicXVlcnkgc3RyaW5ncyIsIHVzaW5n
Cj4gc3RyaWN0IHN0cmluZ3ByZXAgb24gdGhlIHN0b3JlZCBzdHJpbmdzLCBh
bmQgbmV2ZXIgY29tcGFyaW5nIHR3byBxdWVyeQo+IHN0cmluZ3MuICBCdXQg
aXQncyB1cCB0byBlYWNoIGFwcGxpY2F0aW9uL3Byb3RvY29sIHRvIGRlZmlu
ZSB0aGF0Cj4gY2xhc3NpZmljYXRpb24gZm9yIGl0cyBvd24gc3RyaW5ncy4K
PiAKPiBQZXJoYXBzIHRoZSBkb2N1bWVudCBzaG91bGQgc2F5IHNvbWV0aGlu
ZyBsaWtlIHRoYXQuCj4gCj4gQU1DCgoKSW4gbWFueSBjYXNlcywgbGFiZWwg
c3RyaW5ncyBhcmUgaW1wb3J0ZWQgb3IgdHJhbnNtaXR0ZWQgZnJvbSBvdGhl
ciBhcHBsaWNhdGlvbnNzLCAKbm90IGdlbmVyYXRlZCBieSB0aGUgYXBwbGlj
YXRpb24gaXRzZWxmLiB0aGF0IG1ha2VzIGl0IGRpZmZpY3VsdCB0byBjbGFz
c2lmeSB0aGVtLgoKRm9yIGV4YW1wbGUsIGxldCdzIHRoaW5rIGFib3V0IElS
QyBzZXJ2ZXJzICB1c2luZyBlbWFpbCBhZGRyZXNzZXMgYXMgbmlja25hbWVz
LgpPbmUgSVJDIHBhcnRpY2lwYXRvciBhbm5vdW5jZXMgaGltIGFzIHVzZXJA
QS5jb20gIHVzaW5nIG9sZCBpRE5BLWF3YXJlIElSQyBjbGllbnQsCmFuZCBo
aXMgcGFydG5lciBpbnZpdGVzIGhpbSBhcyAndXNlckBCLmNvbScgdXNpbmcg
bmV3IGNsaWVudCwgCndoaWxlIEEgPT0gQiBtb2R1bG8gbmV3IHN0cmluZ3By
ZXAgLGJ1dCBBICE9IEIgbW9kdWxvIG9sZCBzdHJpbmdwcmVwLgoKVGhlIHNp
bWlsYXIgc2l0dWF0aW9ucyBjb21lIHdpdGggb3RoZXIgYXBwbGljYXRpb25z
IHVzaW5nIGVtYWlsIGFkZHJlc3NlcyBhcwpzdWNoIHNlc3Npb24vdXNlciBp
ZGVudGlmaWVycywgd2hpY2ggYXJlIG5vdCBuZWNlc3NhcmlsaXkgcGVybWFu
ZW50IGlkZW50aWZpZXJzLgpJbiBzdWNoIGNhc2VzLCBjb21wYXJpbmcgdHdv
ICJxdWVyeSBzdHJpbmdzIiBhcmUgaW5ldml0YWJsZSBhbmQgbWFrZSB0cm91
Ymxlcy4KCkFub3RoZXIgc2l0dXRhdGlvbnMuCkluIGNvbXBvc2luZyBlbWFp
bCBtZXNzYWdlcywgc2VuZGVycycgZW1haWwgYWRkcmVzc2VzIGFyZSAic3Rv
cmVkIHN0cmluZ3MiIG9yICJxdWVyaWVzIj8/CnRoZSByZWNpcGllbnRzIGFk
ZHJlc3NlcyBjYW4gYmUgY2xhc3NpZmllZCBhcyB0aGUgc2FtZSBvciBub3Qg
PyAgCnRoZSBlbWFpbCBhZGRyZXNzZXMgaW4gdGhlIGFkZHJlc3Nib29rPwpJ
dCBzZWVtcyB2ZXJ5IHN1YnRsZSBxdWVzdGlvbi4KClNvb2JvayBMZWUKCgo8
L1BSRT4KPGltZyBzcmM9aHR0cDovL3Bvc3RlbDIucG9zdGVsLmNvLmtyL3Jl
YWQvMTAxMjM2ODgwNC1hODBiZDM3OTBkMDI4M2RkNGQ0MGNiZjQwODZmZWJh
NS40MWU1ZmQ2ZjE5N2ViYzEwL2lkbkBvcHMuaWV0Zi5vcmcuY29uZmlybS5w
b3N0ZWwudG8gd2lkdGg9MSBoZWlnaHQ9MT4KPC9CT0RZPgo8L0hUTUw+Cg==



From owner-idn@ops.ietf.org  Wed Jan 30 02:20:30 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11624
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 02:20:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16Vose-000FYW-00
	for idn-data@psg.com; Tue, 29 Jan 2002 23:10:04 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16Vosd-000FYI-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 23:10:03 -0800
Received: from [10.1.1.90] (ssh-ams1.cisco.com [144.254.74.55])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA04362;
	Wed, 30 Jan 2002 08:09:54 +0100 (MET)
Date: Wed, 30 Jan 2002 07:54:00 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: IETF idn working group <idn@ops.ietf.org>, idn@ops.ietf.org
Subject: Re: [idn] Needed changes to IDNA before last call
Message-ID: <30129549.1012377240@localhost>
In-Reply-To: <20020130040004.GC32582@nicemice.net>
References: <3C56BE14.F8D0895D@trab.se>
 <20020130040004.GC32582@nicemice.net>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-30 04.00 +0000 "Adam M. Costello"
<idn.amc+0@nicemice.net.RemoveThisWord> wrote:

>>  - Encoding into ACE must use Punycode WITH case marking so that
>>    case can be restored when using ToUnicode.
>> 
>> ToUnicode is fine, but decoding Punycode must restore case.
> 
> I have already argued for mixed-case support as best I can.  I couldn't
> quite get it *mentioned* in the IDNA and Nameprep documents.  You don't
> have a prayer of getting it *required*.

The problem is that the definition of "case" is very hard to make. And, if
you preserve case, why not preserve other steps of nameprep?

Preserving anything is the beginning of a very slippery slope which will
end in the need for a redesign of Punycode and Nameprep completely.

Remember, nameprep is done before punycode, so when the string is passed to
the punycode (transport) encoding, the original string is lost.

    paf




From owner-idn@ops.ietf.org  Wed Jan 30 02:38:52 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11829
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 02:38:52 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VpFN-000Fmv-00
	for idn-data@psg.com; Tue, 29 Jan 2002 23:33:33 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VpFM-000Fmp-00
	for idn@ops.ietf.org; Tue, 29 Jan 2002 23:33:32 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16VpFI-0000QZ-00
	for <idn@ops.ietf.org>; Tue, 29 Jan 2002 23:33:28 -0800
Date: Wed, 30 Jan 2002 07:33:28 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] stringprep comment 2
Message-ID: <20020130073327.GA1427@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp> <20020130040910.GD32582@nicemice.net> <05f801c1a94f$a37b93a0$ec1bd9d2@temp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <05f801c1a94f$a37b93a0$ec1bd9d2@temp>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Soobok Lee <lsb@postel.co.kr> wrote:

> In many cases, label strings are imported or transmitted from other
> applicationss, not generated by the application itself. that makes it
> difficult to classify them.
>
> ...comparing two "query strings" are inevitable and make troubles.
>
> It seems very subtle question.

I'm starting to agree.

Hmmm, is it even necessary to avoid comparing two query strings?  Even
if you compare two strings prepared with loose stringprep (unassigned
code points allowed), the worst that can happen is still a false
negative (where they don't match when they should), you still can't get
a false positive (where they match when they shouldn't).

So maybe we could simply remove all this talk about stored strings
and query strings.  The Stringprep spec could make this yet another
parameter: the profile would have to specify, along with the mapping
tables etc, a single bit indicating whether unassigned code points are
prohibited or not.  The Stringprep spec would retain the discussion
about what can happen when unassigned code points are not prohibited.

The Nameprep document would define two profiles: strict Nameprep and
loose Nameprep, which differ only in that bit.  The IDNA spec would
require registrars to use strict Nameprep, and would let applications
decide for themselves when/if to allow loose Nameprep.

How's that?

AMC



From owner-idn@ops.ietf.org  Wed Jan 30 04:00:01 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12743
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 04:00:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VqHx-000GhD-00
	for idn-data@psg.com; Wed, 30 Jan 2002 00:40:17 -0800
Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VqHw-000Gh7-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 00:40:16 -0800
Received: from mailc.telia.se (localhost [127.0.0.1])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0U8eEY06615
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 09:40:14 +0100 (MET)
Received: from trab.se (valinor.malmo.trab.se [131.115.48.20])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0U8e8P06585
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 09:40:08 +0100 (MET)
Message-ID: <3C57B167.D7230E8F@trab.se>
Date: Wed, 30 Jan 2002 09:40:07 +0100
From: Dan Oscarsson <Dan.Oscarsson@trab.se>
X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org
Subject: Re: [idn] Needed changes to IDNA before last call
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> The draft: idn-idna:
>> The ToASCII must be applied to ALL labels containing non-ASCII.
>
>Rule 1 already says:
>
>    Whenever a domain name is put into a generic domain name slot, every
>    label MUST contain only ASCII characters.
>
>"every label".

Yes, but not all labels in DNS are "generic domain name slot" from what
I can understand. For example the e-mail name label in the SOA record.

>
>> The steps need a slight change:
>>  - character restrictions will apply depending on label, it could be
>>    host name or e-mail name.
>
>Step 3 of ToASCII already says "If the label is part of a host name (or
>is subject to host name syntax rules) then perform these checks".
>
>When you say "e-mail name" do you mean the local part (before the @)?
>That's outside our jurisdiction.  Another working group will have to
>decide how to internationalize email local parts.  We can only tell how
>to deal with domain names.

That is right, but the ACE encoding is not what defines the way to
internationalise host names. ACE is a transport encoding.
To support the future standard of non-ASCII characters in e-mail, the
labels in DNS that are used for e-mail must handle non-ASCII characters.
You could have the e-mail group define a "E-nail ASCII Compatible
Encoding"
but that is really stupid to have in DNS. Thare should only be ONE way
to encode non-ASCII on top of ASCII in DNS. There are already to many
different ways to encode non-ASCII on top of ASCII and it is a very
difficult thing to handle in software.
Therefore we should have ONE standard for all labels in DNS.


>>  - Encoding into ACE must use Punycode WITH case marking so that
>>    case can be restored when using ToUnicode.
>> 
>> ToUnicode is fine, but decoding Punycode must restore case.
>
>I have already argued for mixed-case support as best I can.  I couldn't
>quite get it *mentioned* in the IDNA and Nameprep documents.  You don't
>have a prayer of getting it *required*.
>
>Of course, the working group that internationalizes email local parts
>would have the option of writing a spec that requires Punycode with
>mixed-case support.

Yes, that is one of the reasons why case should be preserved during
ACE conversion in DNS. To suppport the systems that require
case preservation.

   Dan



From owner-idn@ops.ietf.org  Wed Jan 30 04:09:08 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12890
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 04:09:08 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VqSs-000Gos-00
	for idn-data@psg.com; Wed, 30 Jan 2002 00:51:34 -0800
Received: from mail.telia.se ([131.115.15.18] helo=mailc.telia.se)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VqSh-000Gok-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 00:51:33 -0800
Received: from mailc.telia.se (localhost [127.0.0.1])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0U8p1Y10872
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 09:51:11 +0100 (MET)
Received: from trab.se (valinor.malmo.trab.se [131.115.48.20])
	by mailc.telia.se (8.11.6/8.11.6) with ESMTP id g0U8nvP10304;
	Wed, 30 Jan 2002 09:50:16 +0100 (MET)
Message-ID: <3C57B3AB.373308F2@trab.se>
Date: Wed, 30 Jan 2002 09:49:47 +0100
From: Dan Oscarsson <Dan.Oscarsson@trab.se>
X-Mailer: Mozilla 4.78 [sv] (X11; U; SunOS 5.9 sun4u)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: idn@ops.ietf.org, paf@cisco.com
Subject: Re: [idn] Needed changes to IDNA before last call
Content-Type: text/plain; charset=iso-8859-1
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA12890


>From: Patrik F�ltstr�m <paf@cisco.com>

>
>>>  - Encoding into ACE must use Punycode WITH case marking so that
>>>    case can be restored when using ToUnicode.
>>> 
>>> ToUnicode is fine, but decoding Punycode must restore case.
>> 
>> I have already argued for mixed-case support as best I can.  I couldn't
>> quite get it *mentioned* in the IDNA and Nameprep documents.  You don't
>> have a prayer of getting it *required*.
>
>The problem is that the definition of "case" is very hard to make. And, if
>you preserve case, why not preserve other steps of nameprep?

Because Punycode have been selected and it only supports case
preservation.
If I remember correctely it is less than 1000 letters in UCS that has
case,
so the support is fairely simple to handle. It is also what RFC 1035
says:
case should be preserved if possible.
It is also good to have as long as some systems require e-mail addresses
to be case sensitive and we have to handle those in DNS.

>
>Remember, nameprep is done before punycode, so when the string is passed to
>the punycode (transport) encoding, the original string is lost.
>
That depends on implementation. In much software it would probably be
best
to combine "nameprep" with encoding to ACE. The order things are
described
in the document does not have to be followed as long as the result is
the
same. Changing order might make things much more efficient.
For example the definition on what characters are forbidden I would have
as an application matter while the rest could be done by a common
routine
for all software.

   Dan



From owner-idn@ops.ietf.org  Wed Jan 30 07:25:25 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16112
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 07:25:24 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VtWZ-000Inl-00
	for idn-data@psg.com; Wed, 30 Jan 2002 04:07:35 -0800
Received: from heron.verisign.com ([216.168.233.95])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VtWX-000Ine-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 04:07:33 -0800
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29])
	by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA16507
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 07:07:32 -0500 (EST)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19)
	id <C081XBVA>; Wed, 30 Jan 2002 07:07:19 -0500
Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B603@vsvapostal3.bkup6>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'IETF idn working group'" <idn@ops.ietf.org>
Subject: RE: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Date: Wed, 30 Jan 2002 07:07:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> -----Original Message-----
> From: Adam M. Costello [mailto:idn.amc+0@nicemice.net.RemoveThisWord]
> Sent: Tuesday, January 29, 2002 11:31 PM
> To: idn@ops.ietf.org
> Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
> 
> 
> "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
> 
> > An editorial comment: would it be possible to capitalize 
> instances of
> > the RFC 2119 directives "must", "may", "should", etc.?
> 
> It would certainly be *possible*.  :)
> 
> > Doing so will make it far easier for implementers to not miss
> > something that might come back to bite them later.
> 
> I remain skeptical of that claim.  I personally find the all-caps MUST
> SHOULD etc. to be distracting and not at all helpful.
> 
> If the group demands this then I'll write an awk script to take care of
> it, but I'd rather not.

It would be impossible to prove my assertion of implementer helpfulness, so
let me try another angle instead: consistency.  All of the other documents
in last call use the upper case form of the directives, they're used that
way in 2119 (though 2119 admittedly doesn't require upper case), and upper
case appears to be more common in published RFCs.  In my experience it's
what people are used to seeing.

Like I said, though, it's an editorial comment.  No big deal.

-Scott-



From owner-idn@ops.ietf.org  Wed Jan 30 07:40:34 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16441
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 07:40:33 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16VtwC-000JDa-00
	for idn-data@psg.com; Wed, 30 Jan 2002 04:34:04 -0800
Received: from mercury.sun.com ([192.9.25.1])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16VtwC-000JDU-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 04:34:04 -0800
Received: from bebop.France.Sun.COM ([129.157.179.15])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24455
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 04:34:01 -0800 (PST)
Received: from lillen (lillen [129.157.212.23])
	by bebop.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g0UCY0F24009
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 13:34:00 +0100 (MET)
Date: Wed, 30 Jan 2002 13:30:24 +0100 (CET)
From: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Reply-To: Erik Nordmark <Erik.Nordmark@eng.sun.com>
Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
To: IETF idn working group <idn@ops.ietf.org>
In-Reply-To: "Your message with ID" <20020130043102.GE32582@nicemice.net>
Message-ID: <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk


> I remain skeptical of that claim.  I personally find the all-caps MUST
> SHOULD etc. to be distracting and not at all helpful.
> 
> If the group demands this then I'll write an awk script to take care of
> it, but I'd rather not.

I think the RFC 2119 upper case terms are more exact and allows
distinguishing between regular english use of these terms, such as
"an implementor should consider the performance ...", and
rather exact statements about the requirement levels in the specification.

Thus it shouldn't be a search and replace everything with upper case.

Also, there appears to be "should not" even though the "not" terms are not
listed in the 2119 referencing text.

  Erik




From owner-idn@ops.ietf.org  Wed Jan 30 17:07:04 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03360
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 17:07:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16W2VI-0000gh-00
	for idn-data@psg.com; Wed, 30 Jan 2002 13:42:52 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16W2VG-0000gb-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 13:42:50 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16W2VF-0001wI-00
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 13:42:49 -0800
Date: Wed, 30 Jan 2002 21:42:49 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Message-ID: <20020130214249.GA7249@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <20020130043102.GE32582@nicemice.net> <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Erik Nordmark <Erik.Nordmark@eng.sun.com> wrote:

> I think the RFC 2119 upper case terms are more exact and allows
> distinguishing between regular english use of these terms, such as "an
> implementor should consider the performance ...", and rather exact
> statements about the requirement levels in the specification.

That's one of the reasons I don't like capitalizing those words.  What
if I'm reading a spec in which "must" is usually capitalized, but in one
sentence it is lowercase.  Am I required to obey that sentence or not?
At that point I think we're making distinctions that don't exist.

> Thus it shouldn't be a search and replace everything with upper case.

If I were persuaded to capitalize those words, I would manually check
each instance, and if it shouldn't be capitalized, I'd reword the
sentence to avoid that word altogether.  So in the end, those words
would be capitalized everywhere they appear.  Then I'd keep my master
copy uncapitalized and unpaginated, and use a script to add the
capitalization, pagination, and internet-draft/RFC boilerplate.

> Also, there appears to be "should not" even though the "not" terms are
> not listed in the 2119 referencing text.

Thanks, I'll revise the list of terms to match RFC 2119.

AMC



From owner-idn@ops.ietf.org  Wed Jan 30 17:59:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04255
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 17:59:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16W3Kq-0001Sp-00
	for idn-data@psg.com; Wed, 30 Jan 2002 14:36:08 -0800
Received: from router.boolean.net ([198.144.206.49] helo=pretender.boolean.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16W3Kp-0001Se-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 14:36:07 -0800
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1])
	by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g0UMa6C01234;
	Wed, 30 Jan 2002 22:36:06 GMT
	(envelope-from Kurt@OpenLDAP.org)
Message-Id: <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 30 Jan 2002 14:36:30 -0800
To: IETF idn working group <idn@ops.ietf.org>
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Cc: IETF idn working group <idn@ops.ietf.org>
In-Reply-To: <20020130214249.GA7249@nicemice.net>
References: <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <20020130043102.GE32582@nicemice.net>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 01:42 PM 2002-01-30, Adam M. Costello wrote:
>Erik Nordmark <Erik.Nordmark@eng.sun.com> wrote:
>> I think the RFC 2119 upper case terms are more exact and allows
>> distinguishing between regular english use of these terms, such as "an
>> implementor should consider the performance ...", and rather exact
>> statements about the requirement levels in the specification.
>
>That's one of the reasons I don't like capitalizing those words.  What
>if I'm reading a spec in which "must" is usually capitalized, but in one
>sentence it is lowercase.  Am I required to obey that sentence or not?
>At that point I think we're making distinctions that don't exist.

Yes.  "MUST" and "must" are equivalent.  Where one intends
another meaning than that defined by RFC 2119, one should
use a different word.

IMO, it's good to uppercase these imperatives so that
cases where an imperative was used unintentionally are easily
noticed and corrected during the editing and review process.

Kurt




From owner-idn@ops.ietf.org  Wed Jan 30 18:00:37 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04306
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 18:00:36 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16W3YV-0001fr-00
	for idn-data@psg.com; Wed, 30 Jan 2002 14:50:15 -0800
Received: from heron.verisign.com ([216.168.233.95])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16W3YU-0001fl-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 14:50:14 -0800
Received: from vsvapostalgw2.prod.netsol.com (vsvapostalgw2.prod.netsol.com [216.168.234.29])
	by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id RAA03426
	for <idn@ops.ietf.org>; Wed, 30 Jan 2002 17:50:13 -0500 (EST)
Received: by vsvapostalgw2.bkup1 with Internet Mail Service (5.5.2653.19)
	id <C081XN04>; Wed, 30 Jan 2002 17:49:59 -0500
Message-ID: <3CD14E451751BD42BA48AAA50B07BAD60189B612@vsvapostal3.bkup6>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "'IETF idn working group'" <idn@ops.ietf.org>
Subject: RE: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Date: Wed, 30 Jan 2002 17:50:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> -----Original Message-----
> From: Adam M. Costello [mailto:idn.amc+0@nicemice.net.RemoveThisWord]
> Sent: Wednesday, January 30, 2002 4:43 PM
> To: IETF idn working group
> Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
> 
> 
> That's one of the reasons I don't like capitalizing those words.  What
> if I'm reading a spec in which "must" is usually capitalized, but in one
> sentence it is lowercase.  Am I required to obey that sentence or not?
> At that point I think we're making distinctions that don't exist.

I recently (in the last month) went through the exact same issue with a
draft that had been sent to the IESG after WG last call.  I ended up having
to change non-normative uses of the 2119 terms to synonyms like "can" and
"might", and use upper case for the directives, to eliminate possible
confusion.  YMMV.

-Scott-



From owner-idn@ops.ietf.org  Wed Jan 30 21:40:30 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07526
	for <idn-archive@lists.ietf.org>; Wed, 30 Jan 2002 21:40:30 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16W70I-0005Vy-00
	for idn-data@psg.com; Wed, 30 Jan 2002 18:31:10 -0800
Received: from [211.218.145.193] (helo=postel2)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16W70H-0005Vq-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 18:31:09 -0800
Received: (from root@localhost)
	by postel2.postel.co.kr (8.11.0/8.11.0) id g0V2UoZ24976
	for idn@ops.ietf.org; Thu, 31 Jan 2002 11:30:50 +0900
To: "IETF idn working group" <idn@ops.ietf.org>
Received: Postel SMTP Relay v1.0
Received: from marketing ([210.217.27.236]) by postel2 (8.11.0/8.11.0)
    with SMTP id g0V2Uc624948 for <idn@ops.ietf.org>; Thu, 31 Jan 2002
    11:30:48 +0900
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64
X-Msmail-Priority: Normal
Message-Id: <098801c1a9ff$43f2ba20$ec1bd9d2@temp>
Subject: Re: [idn] stringprep comment 2
From: "Soobok Lee" <lsb@postel.co.kr>
X-Priority: 3
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp>
    <20020130040910.GD32582@nicemice.net>
    <05f801c1a94f$a37b93a0$ec1bd9d2@temp> <20020130073327.GA1427@nicemice.net>
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Date: Thu, 31 Jan 2002 11:30:21 +0900
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0rMT48UFJFICBzdHlsZT0nZm9udC1zaXplOjExcHQnPgoK
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAKRnJvbSYjNTg7ICJBZGFt
IE0uIENvc3RlbGxvIiA8aWRuLmFtYyswQG5pY2VtaWNlLm5ldC5SZW1vdmVU
aGlzV29yZD4KVG8mIzU4OyAiSUVURiBpZG4gd29ya2luZyBncm91cCIgPGlk
bkBvcHMuaWV0Zi5vcmc+ClNlbnQmIzU4OyBXZWRuZXNkYXksIEphbnVhcnkg
MzAsIDIwMDIgNCYjNTg7MzMgUE0KU3ViamVjdCYjNTg7IFJlJiM1ODsgW2lk
bl0gc3RyaW5ncHJlcCBjb21tZW50IDIKCgo+IFNvb2JvayBMZWUgPGxzYkBw
b3N0ZWwuY28ua3I+IHdyb3RlJiM1ODsKPiAKPiA+IEluIG1hbnkgY2FzZXMs
IGxhYmVsIHN0cmluZ3MgYXJlIGltcG9ydGVkIG9yIHRyYW5zbWl0dGVkIGZy
b20gb3RoZXIKPiA+IGFwcGxpY2F0aW9uc3MsIG5vdCBnZW5lcmF0ZWQgYnkg
dGhlIGFwcGxpY2F0aW9uIGl0c2VsZi4gdGhhdCBtYWtlcyBpdAo+ID4gZGlm
ZmljdWx0IHRvIGNsYXNzaWZ5IHRoZW0uCj4gPgo+ID4gLi4uY29tcGFyaW5n
IHR3byAicXVlcnkgc3RyaW5ncyIgYXJlIGluZXZpdGFibGUgYW5kIG1ha2Ug
dHJvdWJsZXMuCj4gPgo+ID4gSXQgc2VlbXMgdmVyeSBzdWJ0bGUgcXVlc3Rp
b24uCj4gCj4gSSdtIHN0YXJ0aW5nIHRvIGFncmVlLgo+IAo+IEhtbW0sIGlz
IGl0IGV2ZW4gbmVjZXNzYXJ5IHRvIGF2b2lkIGNvbXBhcmluZyB0d28gcXVl
cnkgc3RyaW5ncz8gIEV2ZW4KPiBpZiB5b3UgY29tcGFyZSB0d28gc3RyaW5n
cyBwcmVwYXJlZCB3aXRoIGxvb3NlIHN0cmluZ3ByZXAgKHVuYXNzaWduZWQK
PiBjb2RlIHBvaW50cyBhbGxvd2VkKSwgdGhlIHdvcnN0IHRoYXQgY2FuIGhh
cHBlbiBpcyBzdGlsbCBhIGZhbHNlCj4gbmVnYXRpdmUgKHdoZXJlIHRoZXkg
ZG9uJ3QgbWF0Y2ggd2hlbiB0aGV5IHNob3VsZCksIHlvdSBzdGlsbCBjYW4n
dCBnZXQKPiBhIGZhbHNlIHBvc2l0aXZlICh3aGVyZSB0aGV5IG1hdGNoIHdo
ZW4gdGhleSBzaG91bGRuJ3QpLgoKUmlnaHQuIGJ1dCwgVGhlIGxhdHRlciBj
YW4gYmUgYXMgY2F0YXN0cm9waGljICBhcyB0aGUgZm9ybWVyLgoKPiAKPiBT
byBtYXliZSB3ZSBjb3VsZCBzaW1wbHkgcmVtb3ZlIGFsbCB0aGlzIHRhbGsg
YWJvdXQgc3RvcmVkIHN0cmluZ3MKPiBhbmQgcXVlcnkgc3RyaW5ncy4gIFRo
ZSBTdHJpbmdwcmVwIHNwZWMgY291bGQgbWFrZSB0aGlzIHlldCBhbm90aGVy
Cj4gcGFyYW1ldGVyJiM1ODsgdGhlIHByb2ZpbGUgd291bGQgaGF2ZSB0byBz
cGVjaWZ5LCBhbG9uZyB3aXRoIHRoZSBtYXBwaW5nCj4gdGFibGVzIGV0Yywg
YSBzaW5nbGUgYml0IGluZGljYXRpbmcgd2hldGhlciB1bmFzc2lnbmVkIGNv
ZGUgcG9pbnRzIGFyZQo+IHByb2hpYml0ZWQgb3Igbm90LiAgVGhlIFN0cmlu
Z3ByZXAgc3BlYyB3b3VsZCByZXRhaW4gdGhlIGRpc2N1c3Npb24KPiBhYm91
dCB3aGF0IGNhbiBoYXBwZW4gd2hlbiB1bmFzc2lnbmVkIGNvZGUgcG9pbnRz
IGFyZSBub3QgcHJvaGliaXRlZC4KPiAKPiBUaGUgTmFtZXByZXAgZG9jdW1l
bnQgd291bGQgZGVmaW5lIHR3byBwcm9maWxlcyYjNTg7IHN0cmljdCBOYW1l
cHJlcCBhbmQKPiBsb29zZSBOYW1lcHJlcCwgd2hpY2ggZGlmZmVyIG9ubHkg
aW4gdGhhdCBiaXQuICBUaGUgSUROQSBzcGVjIHdvdWxkCj4gcmVxdWlyZSBy
ZWdpc3RyYXJzIHRvIHVzZSBzdHJpY3QgTmFtZXByZXAsIGFuZCB3b3VsZCBs
ZXQgYXBwbGljYXRpb25zCj4gZGVjaWRlIGZvciB0aGVtc2VsdmVzIHdoZW4v
aWYgdG8gYWxsb3cgbG9vc2UgTmFtZXByZXAuCgpVc2luZyBpRE4gZG9lc24n
dCBuZWNlc3NhcmlseSBtZWFuIHRoZSBhcHBsaWNhdGlvbiBzaG91bGQgKmdl
bmVyYXRlKiB0aGUKQUNFIGxhYmVsLiBBcyBleGFtcGxpZmllZCBpbiBteSBw
cmV2aW91cyBwb3N0aW5nLCB0aGUgSVJDIHNlcnZlciBtYXkgCmdldCBjaGF0
dGVycycgZW1haWwgYWRkcmVzc2VzIG9ubHkgZnJvbSBjaGF0dGluZyBjbGll
bnRzLG5vdCBtYWtpbmcgb24gaXRzIG93biwgCnRoZXJlZm9yZSwgdGhlIElS
QyBzZXJ2ZXJzIGNhbid0IGtub3cgd2hldGhlciB0aGUgaUROIGVtYWlsIGFk
ZHJlc3NlcyAKYXJlIG1hZGUgIHVzaW5nIHN0cm9uZyBuYW1lcHJlcCBvciB3
ZWFrIG9uZS4gdGhlIElSQyBzZXJ2ZXIgYXJlIGxlZnQgd2l0aApubyBjbHVl
IHRvIGRlY2lkZSB3aGV0aGVyIHRvIGNvbXBhcmUgdGhlbSBvciBub3QuCgpp
ZiBlYWNoIGFwcGxpY2F0aW9uIHZlbmRvciBhZG9wdHMgaXRzIG93biBkaWZm
ZXJlbnQgbmFtZXByZXAgcHJvZmlsZSwKICBhcHBsaWNhdGlvbnMgYmVoYXZp
b3JzIG1heSBiZSB1bnByZWRpY3RhYmxlIGFjcm9zcyBhcHBsaWNhdGlvbnMK
ICBmb3IgZW5kIHVzZXJzLiB0aGVuLCBJRE4gY2FuJ3QgZnVsZmlsbCB0aGUg
ZXNzZXNudGlhbCBjb25kaXRpb25zIG9mIHN1Y2Nlc3NmdWwKICB1bml2ZXJz
YWwgaWRlbnRpZmllciBzeXN0ZW0uCgpUbyBzaG90IGRvd24gbW92aW5nIHRh
cmdldHMsd2UgbmVlZCBtb3ZpbmcgZ3VucyBhbmQgbW92aW5nIGhhbmRzIGFu
ZCBtb3ZpbmcgZXllcy4KClNvb2JvayBMZWUKIAoKCjwvUFJFPgo8aW1nIHNy
Yz1odHRwOi8vcG9zdGVsMi5wb3N0ZWwuY28ua3IvcmVhZC8xMDEyNDQ0MjIx
LWE4MGJkMzc5MGQwMjgzZGQ0ZDQwY2JmNDA4NmZlYmE1LjQxZTVmZDZmMTk3
ZWJjMTAvaWRuQG9wcy5pZXRmLm9yZy5jb25maXJtLnBvc3RlbC50byB3aWR0
aD0xIGhlaWdodD0xPgo8L0JPRFk+CjwvSFRNTD4K



From owner-idn@ops.ietf.org  Thu Jan 31 03:03:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21523
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 03:03:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WBvA-000Dos-00
	for idn-data@psg.com; Wed, 30 Jan 2002 23:46:12 -0800
Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WBv9-000Dom-00
	for idn@ops.ietf.org; Wed, 30 Jan 2002 23:46:11 -0800
Received: from [0.0.0.0] (confmad-isdn.cisco.com [10.49.42.193])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA16717;
	Thu, 31 Jan 2002 08:45:38 +0100 (MET)
Date: Thu, 31 Jan 2002 08:20:19 +0100
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>,
        IETF idn working group <idn@ops.ietf.org>
cc: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] IDN WG Last Call: draft-ietf-idn-punycode-00.txt
Message-ID: <33122220.1012465219@localhost>
In-Reply-To: <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1>
References: <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <20020130043102.GE32582@nicemice.net>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

--On 2002-01-30 14.36 -0800 "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> wrote:

> Yes.  "MUST" and "must" are equivalent.  Where one intends
> another meaning than that defined by RFC 2119, one should
> use a different word.

Actually, in the IESG we have the policy of treating all-caps versions of
the words exactly like defined in RFC 2119, and lowercase as "information
to the reader".

So, what Scott explained is not uncommon.

Of course, if one can choose other words for non-normative use of the terms
that is better, but, that is not always possible.

I therefore suggest using all-caps for the terms that is to be treated as
defined in 2119.

   paf




From owner-idn@ops.ietf.org  Thu Jan 31 16:39:11 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13406
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 16:39:11 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WOk9-0005P0-00
	for idn-data@psg.com; Thu, 31 Jan 2002 13:27:41 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WOk8-0005Ou-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 13:27:40 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16WOk7-0005y2-00
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 13:27:39 -0800
Date: Thu, 31 Jan 2002 21:27:39 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: [idn] MUST/SHOULD vs. must/should
Message-ID: <20020131212739.GA22831@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <20020130043102.GE32582@nicemice.net> <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1> <33122220.1012465219@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <33122220.1012465219@localhost>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc?  If
there is anyone else, please speak up now.

If there is no rough consensus, I can only use my own best judgement,
but if everyone agrees except me, I'll go along.  (This pertains to the
Punycode draft).

AMC



From owner-idn@ops.ietf.org  Thu Jan 31 16:45:41 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13536
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 16:45:41 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WOvn-0005fh-00
	for idn-data@psg.com; Thu, 31 Jan 2002 13:39:43 -0800
Received: from 66.123.187.68.ar.com ([66.123.187.68] helo=bean.ar.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WOvm-0005fb-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 13:39:42 -0800
Received: from loki (IDENT:wessorh@loki [66.123.187.67])
	by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0VLdfU1025266
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 13:39:41 -0800 (PST)
Date: Thu, 31 Jan 2002 13:39:41 -0800 (PST)
From: Rick H Wesson <wessorh@ar.com>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] MUST/SHOULD vs. must/should
In-Reply-To: <20020131212739.GA22831@nicemice.net>
Message-ID: <Pine.LNX.4.30.0201311338400.20805-100000@loki.ar.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk



As an implementor I also prefer MUST/SHOULD/etc verses the lower case
equivalents.

-rick

On Thu, 31 Jan 2002, Adam M. Costello wrote:

> Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc?  If
> there is anyone else, please speak up now.
>
> If there is no rough consensus, I can only use my own best judgement,
> but if everyone agrees except me, I'll go along.  (This pertains to the
> Punycode draft).
>
> AMC
>




From owner-idn@ops.ietf.org  Thu Jan 31 16:47:04 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13575
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 16:47:04 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WOwT-0005hp-00
	for idn-data@psg.com; Thu, 31 Jan 2002 13:40:25 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WOwS-0005hj-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 13:40:24 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id NAA06092;
	Thu, 31 Jan 2002 13:40:21 -0800
Message-Id: <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 Jan 2002 13:40:03 -0800
To: IETF idn working group <idn@ops.ietf.org>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] MUST/SHOULD vs. must/should
Cc: IETF idn working group <idn@ops.ietf.org>
In-Reply-To: <20020131212739.GA22831@nicemice.net>
References: <33122220.1012465219@localhost>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <20020130043102.GE32582@nicemice.net>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1>
 <33122220.1012465219@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 09:27 PM 1/31/2002 +0000, Adam M. Costello wrote:
>If there is no rough consensus, I can only use my own best judgement,

or you could take the safest path.

This means limiting the use of those words to only normative references, 
and use other vocabulary for other purposes.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Jan 31 17:11:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14089
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 17:11:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WPL6-0006OW-00
	for idn-data@psg.com; Thu, 31 Jan 2002 14:05:52 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WPL5-0006OQ-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 14:05:51 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16WPL5-00064z-00
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 14:05:51 -0800
Date: Thu, 31 Jan 2002 22:05:51 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] MUST/SHOULD vs. must/should
Message-ID: <20020131220551.GB22764@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <33122220.1012465219@localhost> <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <20020130043102.GE32582@nicemice.net> <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1> <33122220.1012465219@localhost> <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dave Crocker <dhc@dcrocker.net> wrote:

> or you could take the safest path.
>
> This means limiting the use of those words to only normative
> references, and use other vocabulary for other purposes.

I will do that in any case.  The question is whether those words will be
all-caps or not.

AMC



From owner-idn@ops.ietf.org  Thu Jan 31 17:11:42 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14101
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 17:11:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WPIO-0006J4-00
	for idn-data@psg.com; Thu, 31 Jan 2002 14:03:04 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WPIN-0006Iy-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 14:03:03 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16WPIM-00063n-00
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 14:03:02 -0800
Date: Thu, 31 Jan 2002 22:03:02 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] stringprep comment 2
Message-ID: <20020131220302.GA22764@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp> <20020130040910.GD32582@nicemice.net> <05f801c1a94f$a37b93a0$ec1bd9d2@temp> <20020130073327.GA1427@nicemice.net> <098801c1a9ff$43f2ba20$ec1bd9d2@temp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <098801c1a9ff$43f2ba20$ec1bd9d2@temp>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This message argues both sides of the issue.  :)

Soobok Lee <lsb@postel.co.kr> wrote:

> The latter can be as catastrophic as the former.

I assume you meant that false negatives (where names don't match when
they should) can be as catastrophic as false positives (where names
match when they shouldn't).  Can you back up that claim?

> if each application vendor adopts its own different nameprep profile,
> applications behaviors may be unpredictable across applications for
> end users.

Do you have a suggestion?  What should happen when an application
encounters a name that uses code points newer than the application's
version of nameprep?  If the application prohibits unassigned code
points, then the name will never match anything, because ToASCII will
fail.  If the application allows unassigned code points, then the name
will never match the wrong thing, and might sometimes match the right
thing (in practice, I think it usually will work).  Which is preferable?
The conservative approach (never match) is more predictable, but the
other approach (match if you're lucky) might make users happier.

Wait, I just realized why we needed to avoid comparing two strings
that have both been prepared using loose stringprep.  If they both use
unassigned code points that turn out to be prohibited in future versions
of nameprep, then they might match even though they are both invalid
names.  That's a false positive, which is bad.  So we do indeed need to
avoid such comparisons.

Disregard my suggestion from my last message.

Perhaps the stringprep spec should say that applications may use loose
stringprep only if they know for sure that the name will never be
compared against a name that was also prepared using loose stringprep.
If there's no way to know, then you must use strict stringprep.

In the case of DNS, if the IDNA spec requires authoritative servers
to use strict nameprep, then clients are free to prepare queries
using loose nameprep.  Other protocols could in principle use similar
methods--requiring strict nameprep at "one end" (whatever that means for
that protocol) so that the "other end" can use loose nameprep.

But how practical is that?  Take email headers for example.  Who has any
idea what will be done with domain names that appear in email headers?

Maybe it would be a lot simpler and safer just to prohibit unassigned
code points always.  If you want to use new characters, you'll just have
to upgrade your software to the new nameprep, sorry.

Can we get some more people involved in this thread?  I think Soobok is
right that the existing wording in stringprep about "stored strings" and
"query strings" is going to be very difficult to interpret in practice,
and something needs to be done about it, but I don't know what.

AMC



From owner-idn@ops.ietf.org  Thu Jan 31 17:21:51 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14295
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 17:21:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WPUd-0006iW-00
	for idn-data@psg.com; Thu, 31 Jan 2002 14:15:43 -0800
Received: from rwcrmhc53.attbi.com ([204.127.198.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WPUd-0006iP-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 14:15:43 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020131221531.HYOE10199.rwcrmhc53.attbi.com@c1340594a>
          for <idn@ops.ietf.org>; Thu, 31 Jan 2002 22:15:31 +0000
Message-ID: <008801c1aaa5$1a7a8f50$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" <mark@macchiato.com>
From: "Mark Davis" <mark@macchiato.com>
To: "IETF idn working group" <idn@ops.ietf.org>
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp> <20020130040910.GD32582@nicemice.net> <05f801c1a94f$a37b93a0$ec1bd9d2@temp> <20020130073327.GA1427@nicemice.net> <098801c1a9ff$43f2ba20$ec1bd9d2@temp> <20020131220302.GA22764@nicemice.net>
Subject: Re: [idn] stringprep comment 2
Date: Thu, 31 Jan 2002 14:17:43 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

The comparison of loose vs loose should never be done, for the reasons
you outline. That leaves

a) strict vs strict
b) strict vs loose

(a) is always safe.

(b) works for situations like DNS, where there is a server on one side
storing strict keys, and queries are made on the other and may be
loose or strict. It would work for similar situations, such as email,
if at one end there is a server that does validation (of, in this
case, email names).

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: "IETF idn working group" <idn@ops.ietf.org>
Sent: Thursday, January 31, 2002 14:03
Subject: Re: [idn] stringprep comment 2


> This message argues both sides of the issue.  :)
>
> Soobok Lee <lsb@postel.co.kr> wrote:
>
> > The latter can be as catastrophic as the former.
>
> I assume you meant that false negatives (where names don't match
when
> they should) can be as catastrophic as false positives (where names
> match when they shouldn't).  Can you back up that claim?
>
> > if each application vendor adopts its own different nameprep
profile,
> > applications behaviors may be unpredictable across applications
for
> > end users.
>
> Do you have a suggestion?  What should happen when an application
> encounters a name that uses code points newer than the application's
> version of nameprep?  If the application prohibits unassigned code
> points, then the name will never match anything, because ToASCII
will
> fail.  If the application allows unassigned code points, then the
name
> will never match the wrong thing, and might sometimes match the
right
> thing (in practice, I think it usually will work).  Which is
preferable?
> The conservative approach (never match) is more predictable, but the
> other approach (match if you're lucky) might make users happier.
>
> Wait, I just realized why we needed to avoid comparing two strings
> that have both been prepared using loose stringprep.  If they both
use
> unassigned code points that turn out to be prohibited in future
versions
> of nameprep, then they might match even though they are both invalid
> names.  That's a false positive, which is bad.  So we do indeed need
to
> avoid such comparisons.
>
> Disregard my suggestion from my last message.
>
> Perhaps the stringprep spec should say that applications may use
loose
> stringprep only if they know for sure that the name will never be
> compared against a name that was also prepared using loose
stringprep.
> If there's no way to know, then you must use strict stringprep.
>
> In the case of DNS, if the IDNA spec requires authoritative servers
> to use strict nameprep, then clients are free to prepare queries
> using loose nameprep.  Other protocols could in principle use
similar
> methods--requiring strict nameprep at "one end" (whatever that means
for
> that protocol) so that the "other end" can use loose nameprep.
>
> But how practical is that?  Take email headers for example.  Who has
any
> idea what will be done with domain names that appear in email
headers?
>
> Maybe it would be a lot simpler and safer just to prohibit
unassigned
> code points always.  If you want to use new characters, you'll just
have
> to upgrade your software to the new nameprep, sorry.
>
> Can we get some more people involved in this thread?  I think Soobok
is
> right that the existing wording in stringprep about "stored strings"
and
> "query strings" is going to be very difficult to interpret in
practice,
> and something needs to be done about it, but I don't know what.
>
> AMC
>
>




From owner-idn@ops.ietf.org  Thu Jan 31 18:33:11 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15570
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 18:33:10 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WQW1-0008cQ-00
	for idn-data@psg.com; Thu, 31 Jan 2002 15:21:13 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WQW0-0008cJ-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 15:21:12 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA10085;
	Thu, 31 Jan 2002 15:21:09 -0800
Message-Id: <5.1.0.14.2.20020131151806.03379ed8@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 Jan 2002 15:18:26 -0800
To: IETF idn working group <idn@ops.ietf.org>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] MUST/SHOULD vs. must/should
Cc: IETF idn working group <idn@ops.ietf.org>
In-Reply-To: <20020131220551.GB22764@nicemice.net>
References: <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
 <33122220.1012465219@localhost>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <20020130043102.GE32582@nicemice.net>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1>
 <33122220.1012465219@localhost>
 <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 10:05 PM 1/31/2002 +0000, Adam M. Costello wrote:
>I will do that in any case.  The question is whether those words will be
>all-caps or not.

all-caps is the standard practise in the IETF.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Jan 31 21:06:51 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17467
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 21:06:50 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WSxt-000DKu-00
	for idn-data@psg.com; Thu, 31 Jan 2002 17:58:09 -0800
Received: from fluorine.singnet.com.sg ([165.21.74.72] helo=fluorine.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WSxs-000DKo-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 17:58:08 -0800
Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 1 Feb 2002 09:46:55 +0800
Received: from mx17.singnet.com.sg ([165.21.74.117]) by fluorine.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 1 Feb 2002 06:12:59 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx17.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VMCxWs008096
	for <milton8@singnet.com.sg>; Fri, 1 Feb 2002 06:12:59 +0800
Received: by blake.i-email.net (Postfix)
	id 0EA02A890F; Fri,  1 Feb 2002 06:12:59 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id B0E83A8901
	for <milton@i-email.net>; Fri,  1 Feb 2002 06:12:58 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WPL6-0006OW-00
	for idn-data@psg.com; Thu, 31 Jan 2002 14:05:52 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WPL5-0006OQ-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 14:05:51 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16WPL5-00064z-00
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 14:05:51 -0800
Date: Thu, 31 Jan 2002 22:05:51 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] MUST/SHOULD vs. must/should
Message-ID: <20020131220551.GB22764@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <33122220.1012465219@localhost> <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <20020130043102.GE32582@nicemice.net> <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1> <33122220.1012465219@localhost> <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Dave Crocker <dhc@dcrocker.net> wrote:

> or you could take the safest path.
>
> This means limiting the use of those words to only normative
> references, and use other vocabulary for other purposes.

I will do that in any case.  The question is whether those words will be
all-caps or not.

AMC



From owner-idn@ops.ietf.org  Thu Jan 31 21:07:18 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17479
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 21:07:17 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WSyg-000DN8-00
	for idn-data@psg.com; Thu, 31 Jan 2002 17:58:58 -0800
Received: from fluorine.singnet.com.sg ([165.21.74.72] helo=fluorine.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WSyf-000DN2-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 17:58:57 -0800
Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 1 Feb 2002 09:46:57 +0800
Received: from mx11.singnet.com.sg ([165.21.74.121]) by fluorine.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 1 Feb 2002 05:54:42 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx11.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VLsfOX012468
	for <milton8@singnet.com.sg>; Fri, 1 Feb 2002 05:54:41 +0800
Received: by blake.i-email.net (Postfix)
	id 82961A890F; Fri,  1 Feb 2002 05:54:41 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id 3233FA8901
	for <milton@i-email.net>; Fri,  1 Feb 2002 05:54:41 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WOwT-0005hp-00
	for idn-data@psg.com; Thu, 31 Jan 2002 13:40:25 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WOwS-0005hj-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 13:40:24 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id NAA06092;
	Thu, 31 Jan 2002 13:40:21 -0800
Message-Id: <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 Jan 2002 13:40:03 -0800
To: IETF idn working group <idn@ops.ietf.org>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] MUST/SHOULD vs. must/should
Cc: IETF idn working group <idn@ops.ietf.org>
In-Reply-To: <20020131212739.GA22831@nicemice.net>
References: <33122220.1012465219@localhost>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <20020130043102.GE32582@nicemice.net>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1>
 <33122220.1012465219@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 09:27 PM 1/31/2002 +0000, Adam M. Costello wrote:
>If there is no rough consensus, I can only use my own best judgement,

or you could take the safest path.

This means limiting the use of those words to only normative references, 
and use other vocabulary for other purposes.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Jan 31 21:10:43 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17540
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 21:10:42 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WSxd-000DKW-00
	for idn-data@psg.com; Thu, 31 Jan 2002 17:57:53 -0800
Received: from fluorine.singnet.com.sg ([165.21.74.72] helo=fluorine.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WSxc-000DKQ-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 17:57:52 -0800
Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 1 Feb 2002 09:46:51 +0800
Received: from mx17.singnet.com.sg ([165.21.74.117]) by fluorine.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 1 Feb 2002 05:53:26 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx17.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VLrPWs026721
	for <milton8@singnet.com.sg>; Fri, 1 Feb 2002 05:53:25 +0800
Received: by blake.i-email.net (Postfix)
	id 99529A890F; Fri,  1 Feb 2002 05:53:25 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id 48EC7A8901
	for <milton@i-email.net>; Fri,  1 Feb 2002 05:53:25 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WOvn-0005fh-00
	for idn-data@psg.com; Thu, 31 Jan 2002 13:39:43 -0800
Received: from 66.123.187.68.ar.com ([66.123.187.68] helo=bean.ar.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WOvm-0005fb-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 13:39:42 -0800
Received: from loki (IDENT:wessorh@loki [66.123.187.67])
	by bean.ar.com (8.12.0/8.12.0) with ESMTP id g0VLdfU1025266
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 13:39:41 -0800 (PST)
Date: Thu, 31 Jan 2002 13:39:41 -0800 (PST)
From: Rick H Wesson <wessorh@ar.com>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] MUST/SHOULD vs. must/should
In-Reply-To: <20020131212739.GA22831@nicemice.net>
Message-ID: <Pine.LNX.4.30.0201311338400.20805-100000@loki.ar.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-idn@ops.ietf.org
Precedence: bulk



As an implementor I also prefer MUST/SHOULD/etc verses the lower case
equivalents.

-rick

On Thu, 31 Jan 2002, Adam M. Costello wrote:

> Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc?  If
> there is anyone else, please speak up now.
>
> If there is no rough consensus, I can only use my own best judgement,
> but if everyone agrees except me, I'll go along.  (This pertains to the
> Punycode draft).
>
> AMC
>




From owner-idn@ops.ietf.org  Thu Jan 31 21:20:25 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17674
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 21:20:25 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WTAr-000Dty-00
	for idn-data@psg.com; Thu, 31 Jan 2002 18:11:33 -0800
Received: from tellurium.singnet.com.sg ([165.21.74.71] helo=tellurium.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WTAq-000Dts-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 18:11:32 -0800
Received: from mail pickup service by tellurium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 1 Feb 2002 10:08:37 +0800
Received: from mx13.singnet.com.sg ([165.21.74.113]) by tellurium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 1 Feb 2002 05:42:12 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx13.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VLgD3K032488
	for <milton8@singnet.com.sg>; Fri, 1 Feb 2002 05:42:13 +0800
Received: by blake.i-email.net (Postfix)
	id 285B1A890F; Fri,  1 Feb 2002 05:42:13 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id BD7BCA8901
	for <milton@i-email.net>; Fri,  1 Feb 2002 05:42:12 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WOk9-0005P0-00
	for idn-data@psg.com; Thu, 31 Jan 2002 13:27:41 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WOk8-0005Ou-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 13:27:40 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16WOk7-0005y2-00
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 13:27:39 -0800
Date: Thu, 31 Jan 2002 21:27:39 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: [idn] MUST/SHOULD vs. must/should
Message-ID: <20020131212739.GA22831@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <20020130043102.GE32582@nicemice.net> <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france> <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1> <33122220.1012465219@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <33122220.1012465219@localhost>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

Am I the only one who prefers must/should/etc. over MUST/SHOULD/etc?  If
there is anyone else, please speak up now.

If there is no rough consensus, I can only use my own best judgement,
but if everyone agrees except me, I'll go along.  (This pertains to the
Punycode draft).

AMC



From owner-idn@ops.ietf.org  Thu Jan 31 21:39:13 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18964
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 21:39:12 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WTUa-000Ejf-00
	for idn-data@psg.com; Thu, 31 Jan 2002 18:31:56 -0800
Received: from fluorine.singnet.com.sg ([165.21.74.72] helo=fluorine.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WTUZ-000EjZ-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 18:31:55 -0800
Received: from mail pickup service by fluorine.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 1 Feb 2002 10:14:52 +0800
Received: from mx11.singnet.com.sg ([165.21.74.121]) by fluorine.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 1 Feb 2002 06:13:19 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx11.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VMDJOX026229
	for <milton8@singnet.com.sg>; Fri, 1 Feb 2002 06:13:19 +0800
Received: by blake.i-email.net (Postfix)
	id 2E2DFA890F; Fri,  1 Feb 2002 06:13:19 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id C63D6A8901
	for <milton@i-email.net>; Fri,  1 Feb 2002 06:13:18 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WPIO-0006J4-00
	for idn-data@psg.com; Thu, 31 Jan 2002 14:03:04 -0800
Received: from arwen.cs.berkeley.edu ([128.32.46.192] helo=nicemice.net)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WPIN-0006Iy-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 14:03:03 -0800
Received: from amc by nicemice.net with local (Exim 3.33 #1 (Debian))
	id 16WPIM-00063n-00
	for <idn@ops.ietf.org>; Thu, 31 Jan 2002 14:03:02 -0800
Date: Thu, 31 Jan 2002 22:03:02 +0000
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: IETF idn working group <idn@ops.ietf.org>
Subject: Re: [idn] stringprep comment 2
Message-ID: <20020131220302.GA22764@nicemice.net>
Reply-To: IETF idn working group <idn@ops.ietf.org>
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp> <20020130040910.GD32582@nicemice.net> <05f801c1a94f$a37b93a0$ec1bd9d2@temp> <20020130073327.GA1427@nicemice.net> <098801c1a9ff$43f2ba20$ec1bd9d2@temp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <098801c1a9ff$43f2ba20$ec1bd9d2@temp>
User-Agent: Mutt/1.3.25i
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This message argues both sides of the issue.  :)

Soobok Lee <lsb@postel.co.kr> wrote:

> The latter can be as catastrophic as the former.

I assume you meant that false negatives (where names don't match when
they should) can be as catastrophic as false positives (where names
match when they shouldn't).  Can you back up that claim?

> if each application vendor adopts its own different nameprep profile,
> applications behaviors may be unpredictable across applications for
> end users.

Do you have a suggestion?  What should happen when an application
encounters a name that uses code points newer than the application's
version of nameprep?  If the application prohibits unassigned code
points, then the name will never match anything, because ToASCII will
fail.  If the application allows unassigned code points, then the name
will never match the wrong thing, and might sometimes match the right
thing (in practice, I think it usually will work).  Which is preferable?
The conservative approach (never match) is more predictable, but the
other approach (match if you're lucky) might make users happier.

Wait, I just realized why we needed to avoid comparing two strings
that have both been prepared using loose stringprep.  If they both use
unassigned code points that turn out to be prohibited in future versions
of nameprep, then they might match even though they are both invalid
names.  That's a false positive, which is bad.  So we do indeed need to
avoid such comparisons.

Disregard my suggestion from my last message.

Perhaps the stringprep spec should say that applications may use loose
stringprep only if they know for sure that the name will never be
compared against a name that was also prepared using loose stringprep.
If there's no way to know, then you must use strict stringprep.

In the case of DNS, if the IDNA spec requires authoritative servers
to use strict nameprep, then clients are free to prepare queries
using loose nameprep.  Other protocols could in principle use similar
methods--requiring strict nameprep at "one end" (whatever that means for
that protocol) so that the "other end" can use loose nameprep.

But how practical is that?  Take email headers for example.  Who has any
idea what will be done with domain names that appear in email headers?

Maybe it would be a lot simpler and safer just to prohibit unassigned
code points always.  If you want to use new characters, you'll just have
to upgrade your software to the new nameprep, sorry.

Can we get some more people involved in this thread?  I think Soobok is
right that the existing wording in stringprep about "stored strings" and
"query strings" is going to be very difficult to interpret in practice,
and something needs to be done about it, but I don't know what.

AMC



From owner-idn@ops.ietf.org  Thu Jan 31 21:43:40 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19039
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 21:43:40 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WTZq-000F15-00
	for idn-data@psg.com; Thu, 31 Jan 2002 18:37:22 -0800
Received: from hafnium.singnet.com.sg ([165.21.74.90] helo=hafnium.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WTZp-000F0z-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 18:37:21 -0800
Received: from mail pickup service by hafnium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 1 Feb 2002 10:23:57 +0800
Received: from mx12.singnet.com.sg ([165.21.74.122]) by hafnium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 1 Feb 2002 07:35:27 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx12.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VNZPvF009897
	for <milton8@singnet.com.sg>; Fri, 1 Feb 2002 07:35:25 +0800
Received: by blake.i-email.net (Postfix)
	id 7E9E2A890F; Fri,  1 Feb 2002 07:35:25 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id 23FD3A8901
	for <milton@i-email.net>; Fri,  1 Feb 2002 07:35:25 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WQW1-0008cQ-00
	for idn-data@psg.com; Thu, 31 Jan 2002 15:21:13 -0800
Received: from songbird.com ([208.184.79.7] helo=joy.songbird.com)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WQW0-0008cJ-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 15:21:12 -0800
Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged))
	by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA10085;
	Thu, 31 Jan 2002 15:21:09 -0800
Message-Id: <5.1.0.14.2.20020131151806.03379ed8@127.0.0.1>
X-Sender: dhc@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 Jan 2002 15:18:26 -0800
To: IETF idn working group <idn@ops.ietf.org>
From: Dave Crocker <dhc@dcrocker.net>
Subject: Re: [idn] MUST/SHOULD vs. must/should
Cc: IETF idn working group <idn@ops.ietf.org>
In-Reply-To: <20020131220551.GB22764@nicemice.net>
References: <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
 <33122220.1012465219@localhost>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <20020130043102.GE32582@nicemice.net>
 <Roam.SIMC.2.0.6.1012393824.16186.nordmark@bebop.france>
 <5.1.0.14.0.20020130142626.0175ee70@127.0.0.1>
 <33122220.1012465219@localhost>
 <5.1.0.14.2.20020131133906.01c582a8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-idn@ops.ietf.org
Precedence: bulk

At 10:05 PM 1/31/2002 +0000, Adam M. Costello wrote:
>I will do that in any case.  The question is whether those words will be
>all-caps or not.

all-caps is the standard practise in the IETF.

d/

----------
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464




From owner-idn@ops.ietf.org  Thu Jan 31 22:26:02 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19555
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 22:26:01 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WUC6-000GmI-00
	for idn-data@psg.com; Thu, 31 Jan 2002 19:16:54 -0800
Received: from tellurium.singnet.com.sg ([165.21.74.71] helo=tellurium.mcis.singnet.com.sg)
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WUC5-000GmC-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 19:16:53 -0800
Received: from mail pickup service by tellurium.mcis.singnet.com.sg with Microsoft SMTPSVC;
	 Fri, 1 Feb 2002 10:56:54 +0800
Received: from mx17.singnet.com.sg ([165.21.74.117]) by tellurium.mcis.singnet.com.sg  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Fri, 1 Feb 2002 06:23:28 +0800
Received: from blake.i-email.net (blake.i-email.net [203.126.116.232])
	by mx17.singnet.com.sg (8.12.2/8.12.2) with ESMTP id g0VMNUWs015261
	for <milton8@singnet.com.sg>; Fri, 1 Feb 2002 06:23:30 +0800
Received: by blake.i-email.net (Postfix)
	id 466AFA890F; Fri,  1 Feb 2002 06:23:30 +0800 (SGT)
Delivered-To: milton@i-email.net
Received: from psg.com (psg.com [147.28.0.62])
	by blake.i-email.net (Postfix) with ESMTP id 93EBEA8901
	for <milton@i-email.net>; Fri,  1 Feb 2002 06:23:29 +0800 (SGT)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WPUd-0006iW-00
	for idn-data@psg.com; Thu, 31 Jan 2002 14:15:43 -0800
Received: from rwcrmhc53.attbi.com ([204.127.198.39])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WPUd-0006iP-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 14:15:43 -0800
Received: from c1340594a ([12.234.216.8]) by rwcrmhc53.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020131221531.HYOE10199.rwcrmhc53.attbi.com@c1340594a>
          for <idn@ops.ietf.org>; Thu, 31 Jan 2002 22:15:31 +0000
Message-ID: <008801c1aaa5$1a7a8f50$08d8ea0c@c1340594a>
Reply-To: "Mark Davis" <mark@macchiato.com>
From: "Mark Davis" <mark@macchiato.com>
To: "IETF idn working group" <idn@ops.ietf.org>
References: <044001c1a8ec$55bb96f0$ec1bd9d2@temp> <20020130040910.GD32582@nicemice.net> <05f801c1a94f$a37b93a0$ec1bd9d2@temp> <20020130073327.GA1427@nicemice.net> <098801c1a9ff$43f2ba20$ec1bd9d2@temp> <20020131220302.GA22764@nicemice.net>
Subject: Re: [idn] stringprep comment 2
Date: Thu, 31 Jan 2002 14:17:43 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit

The comparison of loose vs loose should never be done, for the reasons
you outline. That leaves

a) strict vs strict
b) strict vs loose

(a) is always safe.

(b) works for situations like DNS, where there is a server on one side
storing strict keys, and queries are made on the other and may be
loose or strict. It would work for similar situations, such as email,
if at one end there is a server that does validation (of, in this
case, email names).

Mark
—————

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

http://www.macchiato.com

----- Original Message -----
From: "Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>
To: "IETF idn working group" <idn@ops.ietf.org>
Sent: Thursday, January 31, 2002 14:03
Subject: Re: [idn] stringprep comment 2


> This message argues both sides of the issue.  :)
>
> Soobok Lee <lsb@postel.co.kr> wrote:
>
> > The latter can be as catastrophic as the former.
>
> I assume you meant that false negatives (where names don't match
when
> they should) can be as catastrophic as false positives (where names
> match when they shouldn't).  Can you back up that claim?
>
> > if each application vendor adopts its own different nameprep
profile,
> > applications behaviors may be unpredictable across applications
for
> > end users.
>
> Do you have a suggestion?  What should happen when an application
> encounters a name that uses code points newer than the application's
> version of nameprep?  If the application prohibits unassigned code
> points, then the name will never match anything, because ToASCII
will
> fail.  If the application allows unassigned code points, then the
name
> will never match the wrong thing, and might sometimes match the
right
> thing (in practice, I think it usually will work).  Which is
preferable?
> The conservative approach (never match) is more predictable, but the
> other approach (match if you're lucky) might make users happier.
>
> Wait, I just realized why we needed to avoid comparing two strings
> that have both been prepared using loose stringprep.  If they both
use
> unassigned code points that turn out to be prohibited in future
versions
> of nameprep, then they might match even though they are both invalid
> names.  That's a false positive, which is bad.  So we do indeed need
to
> avoid such comparisons.
>
> Disregard my suggestion from my last message.
>
> Perhaps the stringprep spec should say that applications may use
loose
> stringprep only if they know for sure that the name will never be
> compared against a name that was also prepared using loose
stringprep.
> If there's no way to know, then you must use strict stringprep.
>
> In the case of DNS, if the IDNA spec requires authoritative servers
> to use strict nameprep, then clients are free to prepare queries
> using loose nameprep.  Other protocols could in principle use
similar
> methods--requiring strict nameprep at "one end" (whatever that means
for
> that protocol) so that the "other end" can use loose nameprep.
>
> But how practical is that?  Take email headers for example.  Who has
any
> idea what will be done with domain names that appear in email
headers?
>
> Maybe it would be a lot simpler and safer just to prohibit
unassigned
> code points always.  If you want to use new characters, you'll just
have
> to upgrade your software to the new nameprep, sorry.
>
> Can we get some more people involved in this thread?  I think Soobok
is
> right that the existing wording in stringprep about "stored strings"
and
> "query strings" is going to be very difficult to interpret in
practice,
> and something needs to be done about it, but I don't know what.
>
> AMC
>
>




From owner-idn@ops.ietf.org  Thu Jan 31 23:07:22 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21091
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 23:07:21 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WUjO-000IMY-00
	for idn-data@psg.com; Thu, 31 Jan 2002 19:51:18 -0800
Received: from friendly.realnames.com ([63.251.238.102])
	by psg.com with smtp (Exim 3.33 #1)
	id 16WUjN-000IMS-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 19:51:17 -0800
Received: (qmail 22986 invoked by uid 104); 1 Feb 2002 03:51:16 -0000
Received: from yves@realnames.com by friendly.realnames.com with qmail-scanner-0.96 (. Clean. Processed in 0.820785 secs); 01 Feb 2002 03:51:16 -0000
Received: from heaven.internal.realnames.com (10.1.5.39)
  by friendly.realnames.com with SMTP; 1 Feb 2002 03:51:15 -0000
Received: From RINCON.INTERNAL.REALNAMES.COM (10.1.5.99[10.1.5.99 port:2646]) by heaven.internal.realnames.com
	Mail essentials (server 2.422) with SMTP id: <232337@heaven.internal.realnames.com>
	 for <idn@ops.ietf.org>; Thu, 31 Jan 2002 7:46:56 PM -0800
	smtpmailfrom <yves@realnames.com> 
Received: by rincon.centraal.com with Internet Mail Service (5.5.2653.19)
	id <Y47QFR7P>; Thu, 31 Jan 2002 19:51:00 -0800
Message-ID: <7FC3066C236FD511BC5900508BAC86FE9195CC@trestles.internal.realnames.com>
From: Yves Arrouye <yves@realnames.com>
To: "'Paul Hoffman / IMC'" <phoffman@imc.org>, idn@ops.ietf.org
Subject: RE: [idn] stringprep comment 1
Date: Thu, 31 Jan 2002 19:48:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-idn@ops.ietf.org
Precedence: bulk

> Correct, but it does not need to, unless the Unicode Consortium goes
> against their promises about how they will handle normalization of
> newly-assigned characters. No new characters will be casefolded.

What about those cases (situations) where one wants to either delete newly
assigned characters? I mean, rather than prohibit them? How likely is that?

YA




From owner-idn@ops.ietf.org  Thu Jan 31 23:41:46 2002
Received: from psg.com (exim@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21765
	for <idn-archive@lists.ietf.org>; Thu, 31 Jan 2002 23:41:46 -0500 (EST)
Received: from lserv by psg.com with local (Exim 3.33 #1)
	id 16WVOW-000KLf-00
	for idn-data@psg.com; Thu, 31 Jan 2002 20:33:48 -0800
Received: from mail5.microsoft.com ([131.107.3.121])
	by psg.com with esmtp (Exim 3.33 #1)
	id 16WVOV-000KLU-00
	for idn@ops.ietf.org; Thu, 31 Jan 2002 20:33:47 -0800
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617);
	 Thu, 31 Jan 2002 20:33:41 -0800
Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Jan 2002 20:33:41 -0800
Received: from red-msg-08.redmond.corp.microsoft.com ([157.54.12.5]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 31 Jan 2002 20:33:40 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [idn] stringprep comment 1
Date: Thu, 31 Jan 2002 20:33:40 -0800
Message-ID: <9805B5E65CD0D0479D08B7EB832B369F01E2791E@red-msg-08.redmond.corp.microsoft.com>
Thread-Topic: [idn] stringprep comment 1
Thread-Index: AcGq1QbCowuM0fMoQlW1UaM9xVLkfgAAFYIQ
From: "Michel Suignard" <michelsu@microsoft.com>
To: "Yves Arrouye" <yves@realnames.com>,
        "Paul Hoffman / IMC" <phoffman@imc.org>
Cc: <idn@ops.ietf.org>
X-OriginalArrivalTime: 01 Feb 2002 04:33:40.0722 (UTC) FILETIME=[9FB61520:01C1AAD9]
Sender: owner-idn@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA21765

Not a chance. Unicode and ISO 10646 collect in fact some unneeded crumbs
that way. Once a character is officially approved for inclusion it is
there forever, whatever we don't like it or not. Characters get
deprecated (i.e. usage discouraged) but never removed. This is the price
you have to pay for stability and usage by other specification (like
IDN).

In the very early time of Unicode and ISO 10646 you could find some
counter-examples but then the installed based was still nascent, and
even then everybody got burned so bad that nobody would want to see that
now.
If you want to fix something, you add new characters and 'deprecate' the
old, but everything is still there.

BTW I don't think that you can prevent future characters to have folding
cases, you just don't want to fold to or from existing characters. If
new scripts have self-contained case folding we should be fine, right?
For example, Unicode 3.2 is adding new Cyrillic letters which obviously
have folding cases (like 048A and 048B). I don't think Unicode could do
such a broad promise.

Michel

-----Original Message-----
From: Yves Arrouye [mailto:yves@realnames.com] 
Sent: Thursday, January 31, 2002 7:49 PM
To: 'Paul Hoffman / IMC'; idn@ops.ietf.org
Subject: RE: [idn] stringprep comment 1


> Correct, but it does not need to, unless the Unicode Consortium goes 
> against their promises about how they will handle normalization of 
> newly-assigned characters. No new characters will be casefolded.

What about those cases (situations) where one wants to either delete
newly assigned characters? I mean, rather than prohibit them? How likely
is that?

YA