Subject: Re: [idn] wg milestones update

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 27 Apr 2001 07:58:38 +0800

Read RFC2026. The WG process should not be stop or delay due to IPR DoS
on the WG.

On the position on dealing with Walid patent, this decision has to come
from the WG (ie individual members), not the co-chairs. We can only
gather the decision from the members to decide how to move forward.

-James Seng

----- Original Message -----
From: "J. William Semich" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 27, 2001 12:44 AM
Subject: Re: [idn] wg milestones update

> Marc - what is the position on dealing with the Walid patent in this
process?
>
> thanks,
>
> Bill
>
> At 07:32 AM 4/26/2001 -0400, Marc Blanchet wrote:
> >Hi,
> > the milestones in the current charter are overdue. As said during
> >minneapolis, the chairs had the task to propose new milestones to the
> >wg.  Here is our proposal.
> >
> >Marc & James
> >
> >May 01 Submit Requirements I-D to IESG for Informational RFC
> >May 01 WG decision on IDN Protocol
> >May 15 Second version of Comparison I-D
> >Jun 01 Last Call on Comparison I-D
> >Jul 01 Final revision of IDN protocol I-D(s)
> >Aug 08 London IETF: final discussion on IDN protocol I-D(s)
> >Aug 15 Last Call on IDN Protocol I-D(s)
> >Sep 01 Submit Comparison I-D to IESG for Informational RFC
> >Sep 01 Submit Protocol I-D(s) to IESG for standard track RFC
> >
> >
> >
>

---

From: wenhui zhang <[email-masked]>
Date: Thu, 26 Apr 2001 17:31:21 -0700 (PDT)

hello

  Where is the latest
version(draft-ietf-idn-requirements-05.txt,)
requirement.

thanks

wenhui
 
> > >Sep 01 Submit Protocol I-D(s) to IESG for

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: wenhui zhang <[email-masked]>
Date: Thu, 26 Apr 2001 17:33:15 -0700 (PDT)

hello

  Where is the latest

thanks

wenhui

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 27 Apr 2001 08:35:51 +0800

requirements-06 has been updated and you should find it in the I-D
directory soon. In the meantime, -05 can be found here.

http://www.ietf.org/internet-drafts/draft-ietf-idn-requirements-05.txt

-James Seng

---

From: [email-masked] (deng)
Date: Fri, 27 Apr 2001 09:49:50 +0800

Excuse me. I can't find requirement-05 using the URL you provided now.
From www.i-d-n.net  and http://www.ietf.org/html.charters/idn-charter.html and
http://search.ietf.org/search/brokers/internet-drafts/query.html , I just found the requirements-04.
Maybe my problem and bored you. Where is the requirement-05? 

Deng xiang

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 27 Apr 2001 09:56:56 +0800

I will send it to you in private mail. I presume it is not publish yet.

-James Seng

----- Original Message -----
From: "deng" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>; <[email-masked]>
Sent: Friday, April 27, 2001 9:49 AM
Subject: Re: [idn] wg milestones update

> From www.i-d-n.net  and
http://www.ietf.org/html.charters/idn-charter.html and

---

From: [email-masked] (Sun Guonian)
Date: Sun, 29 Apr 2001 10:25:48 +0800

==============================
IETF IDN Working Group               Editors Zita Wenzel, James Seng
Internet Draft                       draft-ietf-idn-requirements-05.txt
24 April 2001                        Expires 24 October 2001

...

[30] Within a single zone, the zone manager MUST be able to define
equivalence rules that suit the purpose of the zone, such as, but not
limited to, and not necessarily, non-ASCII case folding, Unicode
normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or
traditional/simplified Chinese equivalence. Such defined equivalences
MUST NOT remove equivalences that are assumed by (old or
local-rule-ignorant) caches.
...
==============================
I think the traditional/simplified Chinese equivalence SHOULD be defined
as a single rule anywhere so that we can make user use IDN, or chinese
part
in IDN, without confusion.

--
*****************************************************
* China Internet Network Information Center (CNNIC) *
*   Sun Guonian                    No.4, S.4 Street *
*                                  Zhong Guan Cun   *
* Phone: 86-10-62553604            Haidian District *
* Email: [email-masked]          Beijing          *
* http://drop.cnnic.net.cn/~sun/   P.O.Box: 100080  *
*****************************************************
* ÖÐ¹ú»¥ÁªÍøÂçÐÅÏ¢ÖÐÐÄ    Ëï¹úÄî                    *
*****************************************************

---

From: "Jonathan Rosenne" <[email-masked]>
Date: Sun, 29 Apr 2001 06:17:17 +0300

I think we should endeavor to avoid zone equivalence rules and make them all
global.

Jony

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Sun Guonian
> Sent: Sunday, April 29, 2001 5:26 AM
> To: [email-masked]

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 28 Apr 2001 23:45:34 -0400

Jon,

Would you care to elaborate why an operational issue (for a zone file
operator) has global scope? Please be specific to _this_ operational
issue.

> I think we should endeavor to avoid zone equivalence rules and make them all

I'm curious to know the rational(s) for:

	... [w]ithin a single zone, the zone manager MUST NOT be able to
	define equivalence rules that suit the purpose of the zone ...

Cheers,
Eric

---

From: [email-masked] (deng)
Date: Sun, 29 Apr 2001 12:46:16 +0800

If zone manager has the right to define different equivalence rules ,it'll be difficult to keep consistency between different name servers.

For example: if A manager define A equivalence rule( A=a ) in A-zone,at same time, B manager not define A equivalence rule in B-zone, so, a user can register  AAA in B-zone,but the user just can register aaa (for AAA=aaa).

Deng Xiang

>From: Jonathan Rosenne <[email-masked]>
>To: <[email-masked]>
>Sent: Sunday, April 29, 2001 11:17 AM
>Subject: RE: [idn] Zone rules (was: wg milestones update)

---

From: "Jonathan Rosenne" <[email-masked]>
Date: Sun, 29 Apr 2001 08:34:09 +0300

Eric,

One has to decide: Either we are consistent or we are inconsistent, but we
cannot have it once one way and once the other.

I would go for as wide as possible equivalences, but make them global.

For example, take digits in Arabic. It is a widely used script, likely to be the
major internationalized script in several zones using several languages. Some
countries use Arabic (also known as European) digits, some countries use Indic
(also known, wrongly, as Arabic) digits. It may be assumed that a certain zone
would wish to define them as equivalent. If other zones do not, either because
they are not aware of the issue or because they had made a conscientious
decision, what would the poor end user experience when he tries to access a web
site he heard of over the radio?

This is not the case of an ignorant person like me trying to access a Chinese
location, this is the case of a person using his own language in his own
country, in the context of two equivalent representations of the same thing.

Jony

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Eric Brunner-Williams in Portland Maine
> Sent: Sunday, April 29, 2001 6:46 AM
> To: Jonathan Rosenne
> Cc: [email-masked]; [email-masked]
> Subject: Re: [idn] Zone rules (was: wg milestones update)
>
>
> Jon,
>

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 29 Apr 2001 10:08:10 -0400

Jony,

My first comment is that requirement 35 has been in the requirements document
for several drafts. A one line expressions of preference is under motivating.

My second comment is that any mechanism which allows non-degenerate scope,
and for which a policy of specific consistency between two or more instances
of scope, requires a  mechanism to obtain consistency. The notion that
	"[e]ither we are consistent or we are inconsistent, but we cannot
	have it once one way and once the other."
presumes that consistency is a global, binary property. Is this consistency
loose and converging or strict and atemporal?

My third comment is in response to your example. Could you provide one with
specific code-points and two distinct equivalence rules and restate the core
issue?

Incidently, since you happened to mention digits, Wabanakis in New England,
Quebec, and the Canadian Maritimes define "8" as an equivalent to "ou", as
the "w" character was not present in French when that writing system was
adopted. There are UNICODE code points for the characters, but North American
keyboards have the digit "8", which is used.

So, without stepping outside of the LDH code points, the manager of a zone
could create a rule that treats a 0x38 as 0x4f followed by 0x55, assuming
the "8" appeared within an alpha string as the first, or as 0x6f followed
by 0x75, for an in-fix character, and 0x38 if as a terminal, and, as 0x57
or 0x77, using the same first-or-infix rule. This could "suit the purpose
of the zone".

I'd appreciate clarification if this is or isn't an instance of the practice
(depricated in your note) referred in in requirement 35. I could be lacking
a clue.

Finally, what do you propose as rewording of requirement 35?

Eric

References:
U+0222	LATIN CAPITAL LETTER OU
U+0223	LATIN SMALL LETTER OU

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 30 Apr 2001 07:15:16 +0200

At 10:25 29.04.2001 +0800, Sun Guonian wrote:
>part in IDN, without confusion.

If it was possible to write down this equivalence rule on a single sheet of 
paper (without the codepoints), I would agree.
Unfortunately not even the definitions of the different classes of 
traditional/simplified Chinese equivalence seems to fit on a single sheet 
of paper (the 1-n, n-1 and contextual mappings in particular).

A complex specification is prone to implementation errors, especially when 
there are large markets (US, Western Europe) where a sloppy implementation 
will not be challenged by real-life usage of the functionality.

---

From: [email-masked] (Sun Guonian)
Date: Mon, 30 Apr 2001 18:19:37 +0800

sorry, about -05 [30] maybe I don't express my point clear.

if the zone managers could define the equivalence rules respectively, users could
be confusing between different zones.

for chinese user, the TC-SC equivalence rule is just alike the case-folding rule.
I'd like to show an example followed using the case-folding rule.

under zone .COM, if manager defines upper case characters equal to lower case
characters. users could access IBM' domain with ibm.com, IBm.com, ... in any
case.

in another hand, under zone .NET, if manager defines upper case characters DON'T
equal to lower case characters. then ibm.net , IBm.net, iBM.net, ... will be
eight different domains, (without considering the TLD .net, such as .NET, .Net),
and, if the .NET-registry do the equivalence in their policy, they must put 8
records in their zone. if they don't, users will get the different experience
between .COM and .NET .

So I think the TC-SC equivalence rule SHOULD be consistent anywhere .

regards,
sun guonian

---

From: [email-masked] (deng)
Date: Mon, 30 Apr 2001 18:52:10 +0800

----- Original Message ----- 
From: Harald Tveit Alvestrand <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 30, 2001 1:15 PM
Subject: traditional/simplified (Re: [idn] wg milestones update)

> of paper (the 1-n, n-1 and contextual mappings in particular).

    We are preparing a draft about traditional/simplified Chinese equivalence.

> will not be challenged by real-life usage of the functionality.

    Agree. As a part of DNS, any functions must be precision.The largest users of Chinese 
domain name is in China, we must be responsible for our users. If it's unfortunate that the 
fact tall us that there a wall before us, we'll be responsible for work. But now ,we find 
a road,so we have to go along the road and maybe the light will be brilliant on the end of
the road. 
 
your regards
Deng Xiang

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Apr 2001 07:19:33 -0400

--On Monday, April 30, 2001 07:15 +0200 Harald Tveit Alvestrand
<[email-masked]> wrote:

>> [30] Within a single zone, the zone manager MUST be able to
>> define equivalence rules that suit the purpose of the zone,
>> such as, but not limited to, and not necessarily, non-ASCII
>> case folding, Unicode normalizations (if Unicode is chosen),
>... 
> If it was possible to write down this equivalence rule on a
> single sheet of paper (without the codepoints), I would agree.
> Unfortunately not even the definitions of the different classes
> of traditional/simplified Chinese equivalence seems to fit on a
> single sheet of paper (the 1-n, n-1 and contextual mappings in
> particular).
> 
> A complex specification is prone to implementation errors,
> especially when there are large markets (US, Western Europe)
> where a sloppy implementation will not be challenged by
> real-life usage of the functionality.

Let me try a different answer, or pair of answers, without in any
way disagreeing with Harald (i.e., these are two or three
separate reasons for the same conclusion)...

(i) Even were it technically feasbile, it it not desirable to tie
interpretation rules to subdomain trees (zones are even worse).
If there are not to be a single, global, set of resolution and
matching rules, the rules applied should be best be those that
matches the language and perceptions of the user entering the
name.  For the simplifie/ traditional Chinese example, this may
not make any difference (I'm not educated enough to know).  But
for things like different interpretations of Unicode matching/
case folding, either the rules need to match the perceptions of
the requesting user, or they need to be globally uniform, or the
user will need, ultimately, to remember different rules for each
zone that might be encountered.  Or the users will be continually
astonished, which is not good.

(ii) User-end handling of these things is best accomplished in,
or very close to, the user agent, not in DNS servers or in
interception mechanisms.  If I am visiting a country other than
my own, I ought to be able to use the settings and resolution
rules I am used to, rather than having local ones imposed on me.
To take an example that does not involve Roman-based characters
at all, a traveller from China to an Arabic-speaking country
should be able to use Chinese rules to access Chinese sites
(whether located in China or elsewhere) rather than, e.g., Arabic
ones.

But a user-agent approach increases the risk that, with different
user agent configurations, a putative domain name that works for
me and that I send to you will not be resolvable by you because
your UA has a different set of translation or canonicalization
rules.

Unfortuately, if one believes the above, one is led, I think, to
one of two conclusions:

* We must accept a single, global, set of resolution rules,
rather than domain or zone-specific ones.  And that suggests that
the right place to do conversions between simplified and
traditional Chinese, or British and American English, is either
by having user agents convert to a single, canonical form for
each case before making a query (and registering only the
canonical form in the DNS).  Or we could make a "no mixing"
requirement and then register both forms but not the "some of one
and some of the other" variations.  But I have been told by
experts that a "no mixing" requirement is not practical in many
cases, and must accept that.

* We give up on the DNS as an environment in which to solve these
problems.  There are many advantages to server-based resolution
of names and matching rather than forcing users (or user agents)
into generating canonical forms and hoping that the canonical
forms match, not least of which is that we can have some local
flexibility while retaining very high recall of records the users
perceive as matching.  But the price is moving beyond the
"lookup" mechanisms of the DNS into an environment in which
UA-driven searching with imprecise matching is possible.

     john

---

From: "Maynard Kang" <[email-masked]>
Date: Mon, 30 Apr 2001 19:54:17 +0800

Hi Guonian,

...
> So I think the TC-SC equivalence rule SHOULD be consistent anywhere .

Since we're on this topic of TC-SC equivalence yet again, I'd like to point
out two issues that I think we should all consider before we go further, if
these have not been reiterated enough in previous postings made by more
qualified individuals than myself in the past:

1) The ruleset for TC-SC equivalence is not a 1-n or n-1 mapping of
abstract characters, as pointed out by Harald Alvestrand. It can
be hideously complex (see draft-ietf-idn-cjk-01.txt for details), with
numerous lexical and contextual considerations. I am sure that you would
know about the "头发" = "頭髮" but "发财" != "髮財" problem.

2) Case-folding is a simple canonical process, and the folding rules are
the same, I believe (someone please correct me if I'm wrong), for most
scripts which are able to be represented in ASCII (i.e. English, Swahili,
Hawaiian,
Malay, etc).

For example, there is no debate as to whether "CAT" or "cat" or "cAt"
refers to the same thing (in English), or whether "KUCHING" or "kuching" or
"kUchiNG" refers to the same thing ("cat" in Malay).

However, Han character canonicalization does not follow the same rules. Han
characters used in Chinese, Japanese and Korean have different equivalence
rules. This is also pointed out in draft-ietf-idn-cjk-01.txt.

For example, "日產" = "日产"  in Chinese, but "日產" != "日产"  in Japanese.
In both cases, the exact same code points in Unicode are used. This has
been pointed out too, that since Unicode does not recognize the difference
between languages, but only the difference between scripts. Hence, it will
be difficult for any Unicode-based system to function on language-based
equivalence rules.

I do agree with you that the problem that you have pointed out is indeed a
real problem and there is a need for TC-SC equivalence for locating
resources on the Internet.

However, it is a problem that cannot be solved by a Unicode-based DNS
solution within the parameters of the IDN WG and hence this may not be the
right place to address these issues.

maynard

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 30 Apr 2001 19:57:23 +0800

I think irregardless of the whether TC-SC is possible or whether there
is any merit to do it, I think that part of the discussion should be
done else where, not the requirements doc. Putting design specific
issues into requirements doc (especially one which is language specific)
is not going to be constructive.

I suggest we move the discussion of TC-SC to some other doc (primarly I
am looking at Nameprep here. Dont shoot me :) so we can move on with the
requirements doc.

-James Seng

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Apr 2001 08:53:38 -0400

--On Monday, April 30, 2001 19:54 +0800 Maynard Kang
<[email-masked]> wrote:

>...
> 2) Case-folding is a simple canonical process, and the folding
> rules are the same, I believe (someone please correct me if I'm
> wrong), for most scripts which are able to be represented in
> ASCII (i.e. English, Swahili, Hawaiian,
> Malay, etc).

Well, nearly.

As soon as one moves significantly out of the ASCII subset (not
"English") used in traditional host names, little idiosyncracies
show up.  Some scripts have characters that don't have
representations in the "other" case (the German esszet is one
example), others have mapping rules related to accent or
diacritical characters that differ between countries, even within
a script.

One of the more significant problems with the Chinese conversion/
translation is that, as I understand it, one character in
traditional may map to a two or more character phrase in
simplified and, in general, one cannot expect a 1:1 mapping on
character count.  But, while it is less common, that problem
occurs in Roman-based scripts as well due to historical
representation issues.  For example, the character "u with
umlaut" (one character) is often written as "ue" (two
characters).  "ae" may be a two-character sequence, or a
representational form for a single-character diphthong, or a
representational form for "a with umlaut".  As far as I know, the
second of these never matches the third, but the first can match
either the second, or third, or neither depending on the
underlying language (i.e., one can't tell from script alone).

One may, of course, try to make these problems different by
describing some of them as "case folding" and others as something
else, but I'm not convinced  that is helpful.   So, while the
scale may be different, I don't think the problems themselves are
really very different.

    john

---

From: "Mark Davis" <[email-masked]>
Date: Mon, 30 Apr 2001 08:07:10 -0700

Case folding does have some edge cases, but is not comparable in complexity.
The use of ae, oe and ue to represent ä, ö, and ü is not a case folding
issue, any more than the use of aa to represent å. In both cases, they don't
represent modern usage, but instead are only used in modern writing in
situations where accents are not permitted, thus serving as fallbacks. These
are an issue for internationalized collation (see
http://www.unicode.net/unicode/reports/tr10/), but not for domain names. The
character ß expands to SS when capitalized (and there are some other cases
in Unicode of that happening), but that is not issue with TC->SC folding.

The issue with TC-SC folding is represented by cases where character X maps
to character Y, but X and Y have substantially different ranges of meanings.
There are certain edge where this happens with case folding: e.g., "China"
could mean either the country or the pottery, while "china" could only mean
the pottery. For case mappings, these are extemely rare and represent no
significant barrier to comprehension.

I am told that there are a substantial number of problem cases in TC->SC
mappings, where meaning is conflated, and that the mapping is not just 1-n
but m-n. More importantly, this issue has been batted about for a year or so
now, and yet to my knowledge nobody has made a specific proposed mapping
public. Such a mapping should have been presented long ago, so that it there
would be enough time for detailed review and assessment by experts in the
field.

Mark

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 30 Apr 2001 22:52:15 +0000

> for chinese user, the TC-SC equivalence rule is just alike the

There are at least two differences.

First, case equivalence is much simpler.  It's almost always a
one-to-one map, and the few exceptions (like German sharp s)
disappear after you perform Unicode's "compatible decomposition"
(which is a one-to-many map).  As others have pointed out, the
traditional/simplified Chinese equivalence is much more complex.

This complexity is important because equivalence of domain names must
be computable by applications, not just DNS servers.  Browsers need to
check domain names for equality in order to do things like color visited
links and reject cookies from particular domains.

The second difference is that case equivalence is intuitive.  Any
person who knows the letter "a" also knows that "A" and "a" are the
same letter (even if you put diacritics on them, and even when they
appear in words of an unknown language).  I don't think this is true
of traditional/simplified Chinese characters.  If I'm not mistaken,
many people from China cannot read many of the traditional characters,
and many people from Taiwan, Hong Kong, etc. cannot read many of the
simplified characters.  And as others have pointed out, the equivalence
holds in Mandarin but not in Japanese (and I would guess not in
Cantonese and other Chinese languages, but I don't know).

AMC