Subject: Fwd: Re: [idn] Intro to my I-D

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

The list ([email-masked]) was not included in my reply to Ben's note to the
tsconv authors and myself.

------- Forwarded Message

Date: Sun, 29 Jul 2001 07:22:00 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>

Ben,

You've proposed to place the locus of control for scope of equivalance
rules in the hands of the registrant. 

	One of the benefits offered under this system is that a
	Traditional CDN will be able to go to a location that is
	different from the Simplified CDN, if the registrant so
	chooses.                                  ^^^^^^^^^^

In the requirements draft, up to revision 6, there was a condition [30]
([35] in revision 4 and earlier), whch read as follows:

	[30] Within a single zone, the zone manager MAY 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.

The important difference in scope is that in [30] equivalence rules are made
for zones. In your comment, equivalence rules are made for entries in zones,
or are defined not to exist, to disambiguate Simplified from Traditional forms
of Chinese characters.

So, what I propose you expand is how to express a requirement, which may be
optional, that modifies the sense of [30] to be consistent with the view you
have of what is useful.

Please ignore for the moment that [30] is no longer in the requirements
document, and the probability that few may find your proposal interesting,
and just try and get your idea expressed as well as you can.

Eric

------- End of Forwarded Message

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 29 Jul 2001 14:18:19 -0400

Ben,

The example offered by Deng, which should cause you less of a headache
than French-Indian.

For example:

Deng registers a Simplified Chinese domain name: XYZ.cn. (ip addr 1.2.3.1)

	Assume Simplified characters X, Y, and Z, each have just one
	Traditional form, characters U, V and W, respectively.

	The names formed from the union of these three equivalence classes
	are:
		XYZ, XYW, XVZ, XVW, UYZ, UYW, UVZ, UVW

Under your proposal (pending), XYZ is registered in .cn, and the remaing set
of seven (7) names are reserved to the registrant.
	
Deng wants users to be able to visit his domain name. Some live in Mainland
China, some in Hongkong, some in Maco, some in Taiwan, and some in North
America.

Deng now has to register or otherwise map the following seven (7) names to
the same ip address (1.2.3.1):

	{XYZ, XYW, XVZ, XVW, UYZ, UYW, UVZ, UVW}.cn (ip addr 1.2.3.1)

This will avoid surprising Chinese who are accustomed to the SC <-> TC
equivalence, who _know_ that all eight (8) are equivalent as identifiers,
even if they appear to non-Chinese eyes as distinct "words" or characters.

In your proposal the registrant can create new equivalence rules, in the
worst case, only known to the registrant, e.g., ignoring the Y <-> V map,
creating
	{XYZ, XYW, UYZ, UYW}.cn (ip addr 1.2.3.1)
and
	{XVZ, XVW, UVZ, UVW}.cn (ip addr 1.2.3.2)

An additional issue is the temporal duration of your proposal. In the SC/TC
map, there is no expiry of the equivalence mapping. In your proposal there
is a reservation, how long does it last?

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 29 Jul 2001 16:24:37 -0400

Ben,

Assume Simplified characters X, Y and Z, each have just one
Traditional form, characters U, V and W, respectively.

If the registrant is able to do the following as he or she so chooses:
XYZ.cn (ip addr 1.2.3.1)
XYW.cn (ip addr 1.2.3.2)
UYZ.cn (ip addr 1.2.3.3)
UYW.cn (ip addr 1.2.3.4)
XVZ.cn (ip addr 1.2.3.5)
XVW.cn (ip addr 1.2.3.6)
UVZ.cn (ip addr 1.2.3.7)
UVW.cn (ip addr 1.2.3.8)

Then the following is possible, neh? (Assume subnet of 1.2.3 throughout)

+-------+-------+-------+-------+-------+-------+-------+-------+---------
Number of characters with only one equivalent character (SC/TC, simple case)
1 (2)		2 (4)		3 (8)		4 (16)		...
Registrat A	Registrant B	Registrant C	Registrant D	...
+-------+-------+-------+-------+-------+-------+-------+-------+---------
				XYZ.cn (1)
				XYW.cn (2)
                XY.cn (127)	UYZ.zn (3)
X.cn (254)	UY.cn (127)	UYW.cn (4)
U.cn (253)      XV.cn (127)	XVZ.cn (5)
		UV.cn (127)	XVW.cn (6)
				UVZ.cn (7)
				UVW.cn (8)
+-------+-------+-------+-------+-------+-------+-------+-------+---------
multiple	unique		multiple	...		...

I'm glad you intend to comment on any draft, whether by writing a comment,
or an alternative draft. However, this appears to require users to have
access into the ideosyncratic (private) semantic preferenances of the
registrant. How, as a set of labels is expanded from one initial character
to some maximum number of characters, each a single character suffix to
the preceeding label's set of characters, e.g., a, ab, abc, abcd, ...
are labels to be understood? As having consistent equivalence rules, or as
having label-unique equivalence rules? All this is within a single zone.

Not that I consider the interests of trademark holders to be the only ones
worth examining, but if some set of SC and TC characters are registered
marks in some jurisdiction, then how would a mix of SC and TC characters
from both registered marks appear to the trademark holder? It appears that
the advantage of your proposal is that users must engage in vastly more
complex name-to-address management, as must marks enforcers.

Your initial note claimed the benefits are mapping content script to label
script, and user-defined, reserved character equivalence definition. Have
I got your proposal's main points?

Eric