Subject: [idn] opting out of SC/TC equivalence

From: "Edmon" <[email-masked]>
Date: Wed, 8 Aug 2001 05:24:39 -0400

From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
> What is the key value for users "opting out" of SC/TC equivalences?

There are two main scenarios that I could think of that I would like to see
SC/TC opted out.
Say I wanted to have different online identities in the PRC, HongKong and
Taiwan with two Chinese charcters.  And I want to use:
<SC><SC> in PRC
<SC><TC> in HK and
<TC><TC> in Taiwan

I want them to resolve to different places. If SC/TC is folded, I will not
be able to do so.  Which means if I have an employee John in both the PRC
and Taiwan, I could not use John@<SC><SC> and John@<TC><TC> at the same time
and use it for different person.

Scenario two:
If I have a franchisee/partnership operations in the above three regions and
the ownership of each is very different, but we want to maintain the name.
We wont be able to use the SC/TC/mix to distinguish our domains.

Edmon

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 08 Aug 2001 06:08:17 -0400

In a previous note I commented on the scaling issue I understand this form
of [30] (registrant assigned equivalence rules, vs zone manager assigned
equivalence rules, in obsoleted versions of the requirements draft) to pose.
Insight into proposed mechanism and its scaling properties would be of real
interest.

I also suggested to the earlier proponent of this form of [30] that s/he
attempt to state a variation of [30] that would express his or her, and now
your, desired policy.

Eric

---

From: [email-masked] <[email-masked]>
Date: Wed, 8 Aug 2001 17:36:51 +0800

----- Original Message -----
From: "Edmon" <[email-masked]>
To: "ben" <[email-masked]>; "Eric Brunner-Williams in Portland Maine"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 08, 2001 5:24 PM
Subject: [idn] opting out of SC/TC equivalence

> We wont be able to use the SC/TC/mix to distinguish our domains.
         In  HongKong, people use BIG5 code that is major in traditional
chinese characters,
After 1997,  Hong-Kong Goverment announce an extension set including fonts
of TC/SC.
MicroSoft provided them with GBK code but display the message in TC font.
GBK is the extension of GB, and  China use them in MicroSoft IE now.  GBK
include the font of some traditional chinese character.  The TC/SC
translation  majorly focus on BIG5 <-> UNICODE <-> GBK , especially for BIG5
<--> GB/GBK.
         If TC/SC  one to one  font/script mapping is fiexed, it shoud be
processed in normalization/unification phase .  But  one to many font/script
mapping can not be easily solved by this way,  if the mixing type
<SC><TC><SC><TC>  are all one one mapping in each character then they will
be reduced to one canonical  representation.  If the mixing type including
one to many characters  one string are assigned by the registrant in
registration time.
         That draft is just to solve your 2  problems.  Hope these can help
understanding.
> Edmon

L.M.Tseng

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Aug 2001 06:34:21 -0400

--On Wednesday, 08 August, 2001 05:24 -0400 Edmon
<[email-masked]> wrote:

> There are two main scenarios that I could think of that I would
> like to see SC/TC opted out.
> Say I wanted to have different online identities in the PRC,
> HongKong and Taiwan with two Chinese charcters.  And I want to
> use: <SC><SC> in PRC
> <SC><TC> in HK and
> <TC><TC> in Taiwan
> 
> I want them to resolve to different places. If SC/TC is folded,
> I will not be able to do so.  Which means if I have an employee
> John in both the PRC and Taiwan, I could not use John@<SC><SC>
> and John@<TC><TC> at the same time and use it for different
> person.
> 
> Scenario two:
> If I have a franchisee/partnership operations in the above
> three regions and the ownership of each is very different, but
> we want to maintain the name. We wont be able to use the
> SC/TC/mix to distinguish our domains.

Edmon,

I think we have been here before --in terms of things the DNS
can't do and should not be expected to do-- in only slightly
different form.

Briefly, either SC and TC are equivalent, or they are not.  If
they are, we shouldn't be having this discussion.  If they are
not, we shouldn't be having this discussion either.  In the
particular case of TC and SC, what we have been told, repeatedly,
is that people (normal human beings, not computer experts), will
expect to be able to use them interchangably.   If you try to do
this, you will get errors in the hosts or sites that are found
when people forget your subtle distinctions/ clues and get them
wrong.

What you are asking for is, IMO, really 

Scenario one: 
  Different resolution for <name> based on whether it is resolved
wrt a site in PRC, HK, or Taiwan.

Scenario two:
  Different resolution for <name> based on whether it is resolved
by a user located in PRC, HK, or Taiwan.

Both of those desires generalize to other places, other scripts,
and other languages.  Both are legitimate.  But they require
information about context, not little tricks of script-choice,
especially on a per-character basis.

Now, while I don't think the idea is satisfactory for many
reasons, you could get that context from the TLD.  <name>.CN,
<name>.HK, and <name>.TW are clearly different; we would expect
them to resolve differently (although they could be made to
resolve to the same target if someone wished).  And we would
expect that behavior whether we fold SC and TC together or not.  

Otherwise, IMO, you need to get the context from something else,
and that means "outside the DNS".

    john

---

From: "Edmon" <[email-masked]>
Date: Wed, 8 Aug 2001 06:43:18 -0400

Hi Eric,
I dont really have a specific "policy" in mind, its just some scenarios that
I think needs consideration when making such policies.
Edmon

---

From: "Edmon" <[email-masked]>
Date: Wed, 8 Aug 2001 09:18:56 -0400

First of all, sorry for missing out on the previous discussions.
Anyway, I think the point I want to make is that perhaps it makes sense for
SC/TC equivalence to be an optional technical policy matter for different
registries.  Perhaps ccTLDs such as .hk, .tw, .cn, .sg will adopt the SC=TC
and gTLDs might opt not to adopt it.  Does anyone think this is sensible?
Or does everyone believe that SC=TC should be part of nameprep?
Edmon

---

From: "ben" <[email-masked]>
Date: Wed, 8 Aug 2001 09:21:17 -0400

Although the current ccTLDs and gTLDs will work for IDNs, they cannot
totally satisfy the needs of the users of CDNs.  Another type of TLD
must be created and I will tentatively call it lsTLDs (Language Script
TLDs).  lsTLDs are in native language script... not English- thus
bringing out the issue of <IDN>.<IDN> that ICANN has already expressed
their interest in.

This is not just an issue for ICANN.  I do still need to write a draft
and submit it to the IDN WG because lsTLDs are not a simple straight
forward concept as ccTLDs and gTLDs.  2 techniques / mechanism must be
documented:

1.  A relationship exist between the <.traditional> and <.simplified>
lsTLDs
2.  During Nameprep, an error checking is done to disallow improper
characters for a lsTLD.

Thanks
Ben Chan

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: "Edmon" <[email-masked]>; "ben" <[email-masked]>; "Eric
Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 08, 2001 5:36 AM
Subject: Re: [idn] opting out of SC/TC equivalence

----- Original Message -----
From: "Edmon" <[email-masked]>
To: "ben" <[email-masked]>; "Eric Brunner-Williams in Portland Maine"
<[email-masked]>
Cc: <[email-masked]>

> There are two main scenarios that I could think of that I would like
to
see
> Say I wanted to have different online identities in the PRC,
HongKong and
> and Taiwan, I could not use John@<SC><SC> and John@<TC><TC> at the
same
time
> If I have a franchisee/partnership operations in the above three
regions
and
> We wont be able to use the SC/TC/mix to distinguish our domains.
         In  HongKong, people use BIG5 code that is major in
traditional
chinese characters,
After 1997,  Hong-Kong Goverment announce an extension set including
fonts
of TC/SC.
MicroSoft provided them with GBK code but display the message in TC
font.
GBK is the extension of GB, and  China use them in MicroSoft IE now.
GBK
include the font of some traditional chinese character.  The TC/SC
translation  majorly focus on BIG5 <-> UNICODE <-> GBK , especially
for BIG5
<--> GB/GBK.
         If TC/SC  one to one  font/script mapping is fiexed, it shoud
be
processed in normalization/unification phase .  But  one to many
font/script
mapping can not be easily solved by this way,  if the mixing type
<SC><TC><SC><TC>  are all one one mapping in each character then they
will
be reduced to one canonical  representation.  If the mixing type
including
one to many characters  one string are assigned by the registrant in
registration time.
         That draft is just to solve your 2  problems.  Hope these can
help
understanding.

L.M.Tseng

---

From: Dave Crocker <[email-masked]>
Date: Wed, 08 Aug 2001 14:35:26 +0100

At 02:18 PM 8/8/2001, Edmon wrote:
>registries

sorry, no.  it makes the standard useless.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 08 Aug 2001 10:23:19 -0400

do let me know when one is added to the root.

---

From: "ben" <[email-masked]>
Date: Wed, 8 Aug 2001 10:42:11 -0400

The Chinese culture is paramount.

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "ben" <[email-masked]>
Cc: "tsenglm@pºô¤¤¤ß.¤¤¤j.tw" <[email-masked]>; "Edmon"
<[email-masked]>; "Eric Brunner-Williams in Portland Maine"
<[email-masked]>; "John C Klensin" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, August 08, 2001 10:23 AM
Subject: Re: [idn] opting out of SC/TC equivalence

---

From: [email-masked] <[email-masked]>
Date: Wed, 8 Aug 2001 22:46:56 +0800

> do let me know when one is added to the root.
   TC/SC  translation  are these ponits that users need them to reduced the
complexity of number of name registration and user can key in the name they
more familiar.
    This ia a problem of normalization/canonicalization in nameprep, why it
need to add to the root ?   There are many solutions , lsTLD  is just one of
them.

L.M. Tseng

---

From: "ben" <[email-masked]>
Date: Wed, 8 Aug 2001 13:04:58 -0400

Hi L.M. Tseng

I agree.  Solutions need not be mutually exclusive.  Infact, the
"TC<->SC" conversion will only make the "lsTLD system" even better.

Thanks
Ben Chan

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: "ben" <[email-masked]>; "Eric Brunner-Williams in Portland Maine"
<[email-masked]>
Cc: "Edmon" <[email-masked]>; "Eric Brunner-Williams in Portland
Maine" <[email-masked]>; "John C Klensin"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, August 08, 2001 10:46 AM
Subject: Re: [idn] opting out of SC/TC equivalence

> do let me know when one is added to the root.
   TC/SC  translation  are these ponits that users need them to
reduced the
complexity of number of name registration and user can key in the name
they
more familiar.
    This ia a problem of normalization/canonicalization in nameprep,
why it
need to add to the root ?   There are many solutions , lsTLD  is just
one of
them.

L.M. Tseng

---

From: "Edmon" <[email-masked]>
Date: Wed, 8 Aug 2001 13:19:23 -0400

From: "Dave Crocker" <[email-masked]>
> sorry, no.  it makes the standard useless.

why would it make the standard useless?
I think the "standard" is a standard way of processing mapping of SC=TC
(this is almost independent of DNS), but with the background of issues
pertaining DNS in mind.
it will be used by TLDs who wish to adopt it and not by those who dont... A
lot of standards have options...??...
if we force it into nameprep, then it would mean that all TLDs must adopt
it.  Also, it means that I can't have <net in TC>.domain.example go to one
IP and <net in SC>.domain.example go to another one, even if I own
domain.example.
Edmon

---

From: Dan Ebert <[email-masked]>
Date: Wed, 08 Aug 2001 10:41:20 -0700

It seems to me that it would be more confusing if TC/SC behaved
differently for different TLDs.  One of the (I think beneficial)
features of DNS is that the behavior is uniform across all TLDs (com
works like net works like org ...).  I would suggest that it may be a
better idea to use have a script on the web server look at user IP or
browser environment variable to determine what page should be displayed
(or redirect to a different server).

-- 
Dan Ebert      <[email-masked]>       eNIC Corporation
------------------------------------------------------------
I've had a perfectly wonderful evening. But this wasn't it.
   -- Groucho Marx

---

From: David Hopwood <[email-masked]>
Date: Wed, 08 Aug 2001 12:17:17 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> Taiwan with two Chinese charcters.  And I want to use:

Unless I'm missing something, SC/TC equivalence doesn't affect the protocol;
it's purely a local issue for administrators of zones that include names
with Chinese characters. They could configure the authoritative servers for
those zones to use any of the following approaches:

1. have zone entries for each combination.
2. have zone entries only for folded names, and do folding in the server.
3. have the server try to match the unfolded name first, and if not found,
   try to match the folded name.

Intermediate servers will cache the variants that are actually used (which
is probably only a small subset of the possible variants).

So the WG doesn't need to decide this, apart from pointing out the options.

- -- 
David Hopwood <[email-masked]>

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

---

From: David Hopwood <[email-masked]>
Date: Wed, 08 Aug 2001 21:41:02 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> bringing out the issue of <IDN>.<IDN> that ICANN has already expressed

I don't see why there would be any technical problem associated with
having non-ASCII TLDs. They're just like any other label, except that
the first octet must not be US-ASCII '0'-'9' (to allow a domain name to
be distinguished from an IPv4 address).

(Obviously there are plenty of political problems associated with adding
any TLD, but that's ICANN's problem.)

- --

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 8 Aug 2001 21:22:35 +0000

David Hopwood <[email-masked]> wrote:

> Unless I'm missing something, SC/TC equivalence doesn't affect the
> protocol; it's purely a local issue for administrators of zones that
> include names with Chinese characters.
>

Thank you!  One thing that should be considered by anyone contemplating
server-side equivalence rules is that clients will not know that the
names are equivalent.  For web browsers, this will affect visited link
coloring, page caching, cookie permissions, etc.  Similar pitfalls will
exist in other applications.  Zone administrators willing to tolerate
such limitations are free to do server-side equivalence matching to
their heart's content.  It would be ludicrous for this working group to
try to prohibit this practice, because it's equivalent to populating the
zone with identical data for all the matching names, which is obviously
permitted.

AMC

---

From: "ben" <[email-masked]>
Date: Wed, 8 Aug 2001 17:48:24 -0400

Hi David,

The ICANN Board's Internal Working Group asked:  "Presumably there
will be a demand for top level IDNs, i.e., [IDN].[IDN]. What role
should ICANN play with respect to the selection of these top level
names and their registries? What should be the role of the country
code registry of the country where a particular script is a native
script? And what if a particular script is a native script in more
than one country?"

I know ICANN is interested and I will show ICANN why in my 2 years of
gathering data from everyday people from all over the world that there
is indeed a need for lsTLDs (Language Script TLDs).

Thanks
Ben Chan

----- Original Message -----
From: "David Hopwood" <[email-masked]>
To: "ben" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 08, 2001 4:41 PM
Subject: Re: [idn] opting out of SC/TC equivalence

-----BEGIN PGP SIGNED MESSAGE-----

I don't see why there would be any technical problem associated with
having non-ASCII TLDs. They're just like any other label, except that
the first octet must not be US-ASCII '0'-'9' (to allow a domain name
to
be distinguished from an IPv4 address).

(Obviously there are plenty of political problems associated with
adding
any TLD, but that's ICANN's problem.)

- --

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

---

From: David Hopwood <[email-masked]>
Date: Thu, 09 Aug 2001 00:50:12 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> script? And what if a particular script is a native script in more

These are policy issues, not technical issues, so it isn't the role of
the IDN WG to take any position on them. (That doesn't prevent you or
anyone else making an individual comment on this subject to ICANN, of
course. I suggest reading RFC 3071 first.)

- --

---

From: "Edmon" <[email-masked]>
Date: Thu, 9 Aug 2001 07:26:53 -0400

I concur.
Edmon

----- Original Message -----
> Unless I'm missing something, SC/TC equivalence doesn't affect the
protocol;

---

From: "Edmon" <[email-masked]>
Date: Thu, 9 Aug 2001 07:31:48 -0400

From: "Dan Ebert" <[email-masked]>
> works like net works like org ...)

This is not true.  Registration restrictions differ from TLD to TLD.

> I would suggest that it may be a

What about emails?

Edmon

---

From: "ben" <[email-masked]>
Date: Thu, 9 Aug 2001 07:41:37 -0400

Hi David,

Thanks for the info-  I will certainly take a look at that.

As far as there being "no technical issues", I don't think I am quite
off the hook yet.  The IDN WG may still tear apart my idea because it
is not a straight forward concept as gTLDs/ccTLDs and involves:
1.  Relationship between lsTLDs of the same language.
2.  Nameprep to prohibit invalid scripts of lsTLDs.

You may not be so generous when you read my draft on the 14th.

Thanks
Ben Chan

----- Original Message -----
From: "David Hopwood" <[email-masked]>
To: "ben" <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 08, 2001 7:50 PM
Subject: Re: [idn] opting out of SC/TC equivalence

-----BEGIN PGP SIGNED MESSAGE-----

- --

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Aug 2001 09:01:49 -0400

--On Thursday, 09 August, 2001 07:31 -0400 Edmon
<[email-masked]> wrote:

>> differently for different TLDs.  One of the (I think
>> beneficial) features of DNS is that the behavior is uniform
>> across all TLDs (com works like net works like org ...)
> 

But a query is interpreted independent of TLD.  And once the
query is made, the name is resolved exactly the same way,
regardless of the TLD.

Those things, which are the important issues in determining
whether a given name "means" the same thing to you as it does to
me, are, and would be, true even if a particular domain violates
the current LDH rules in the names it accepts/ registers.

   john

---

From: "Edmon" <[email-masked]>
Date: Thu, 9 Aug 2001 10:36:15 -0400

> query is made, the name is resolved exactly the same way,

You are right.  I should re-write my point:
You wont expect to go to the same place if you typed in abc.com vs abc.ca
so I dont think you would be too surprised to see that <SC>.com doesnt go to
the same place as <TC>.cn
Which means that TLD dependent SC=TC should not create any problem on a user
expectation stand point.
If you know that typing <SC>.cn and <TC>.cn goes to the same place, it will
happen no matter where you are connected to the network.
But that doesnt mean that <SC>.tld and <TC>.tld must therefore go to the
same place.
There should be no compelling user expectation for this to happen.
Edmon

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Aug 2001 11:03:24 -0400

--On Thursday, 09 August, 2001 10:36 -0400 Edmon
<[email-masked]> wrote:

> Which means that TLD dependent SC=TC should not create any
> problem on a user expectation stand point.
> If you know that typing <SC>.cn and <TC>.cn goes to the same
> place, it will happen no matter where you are connected to the
> network. But that doesnt mean that <SC>.tld and <TC>.tld must
> therefore go to the same place.

Edmon,

Let me say to you --and the WG-- what I said to Dave Crocker
after our exchange of comments at the mike.  It seems to me that
the WG is singing one song, but dancing to a different tune.
There are, I think, two, perfectly reasonable, positions:

	(i) The IDN effort is about identifiers and characters,
	not about languages or even strings.
	
	(ii) The IDN effort is about making it possible to put
	non-English words and phrases into the DNS, just as it is
	feasible to put English ones (with some constraints)
	there today.

Now, if we really believe the first, then it is not clear how
much of nameprep is needed (somewhat less, I think, although
probably not zero).  But discussions of SC/TC equivalence, Arabic
non-spacing break characters, similarity of characters with
non-similar glyphs between languages, distinctions between CJK
contexts, similar characters in different scripts or blocks, and
so on, are all irrelevant and inappropriate -- those are _all_
conversations about words, languages, and the way language
phrases are written.

But many people --I would suggest a majority of those who care
about the IDN issue, independent of those explicitly represented
in the WG-- are interested in words and languages.  To the extent
that they really represent the requirement for this work, all of
the issues excluded above are important and cannot be excluded.
Your assertion about "no compelling user expectation" is, in that
context, false: a compelling user expectation has been asserted
by CNNIC and others.   

And, if any of those language issues are part of the real
requirement, the WG is simply at risk of being irrelevant.  Not
wrong, but irrelevant.   If one reaches that conclusion, then
there is a procedural and responsibility question as to whether
the WG should (and can) report that it can't, within its charter,
do anything relevant or whether it is obligated to report
_something_ out anyway.

    john

---

From: "Edmon" <[email-masked]>
Date: Thu, 9 Aug 2001 11:44:33 -0400

Hi John,

I completely concur with you, perhaps you misunderstand my statement.  What
I am saying is that if CNNIC believes that there is compelling user
expectation within their registry to have SC=TC, then they should absolutely
implement it.  However, if another TLD say .tld believes that preserving
TC/SC information is important, then they will have the option to do so.
The registrant will always have the option to make them equivalent.

I also concur that IDN should strive to solve some language issues, however,
I also think that it is the IDN "implementations" that should solve the
problem and not the "core protocol" which we should concern ourselves with
at this moment.

Edmon

---

From: Dan Ebert <[email-masked]>
Date: Thu, 09 Aug 2001 08:57:42 -0700

> This is not true.  Registration restrictions differ from TLD to TLD.

I should have been more specific.  I was thinking in terms of
resolution, not registration.
I just think it could be confusing if each TLD makes up their own rules
regarding resolution.

i.e. <TC>.tld1 may-or-may-not-be-equivalent-to <SC>.tld1
 but <TC>.tld2 is-always-equivalent-to <SC>.tld2

> > (or redirect to a different server).

Good point.

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Aug 2001 12:01:42 -0400

--On Thursday, 09 August, 2001 11:44 -0400 Edmon
<[email-masked]> wrote:

> Hi John,
> 
> I completely concur with you, perhaps you misunderstand my
> statement.  What I am saying is that if CNNIC believes that
> there is compelling user expectation within their registry to
> have SC=TC, then they should absolutely implement it.  

And they should somehow to contrive to be sure that no records
are cached outside China, where other rules would apply as a
query is applied to a cached record?   I continue to be afraid
that the choices are between 

	-- the whole DNS using the same procedures or
	
	-- fragmenting the network

Now, if CNNIC says, "ok, we are going to register only SC, and to
get TC translations, you need to use our translating software 
However, if you have client software that doesn't use our
translation software and tables, you had better make queries in
SC, and reverse mapping records are going to return SC no matter
what you do", that would work with your model.  But I haven't
heard from them going that route is an accceptable model.

> if another TLD say .tld believes that preserving TC/SC
> information is important, then they will have the option to do
> so. The registrant will always have the option to make them
> equivalent.

As I think others have pointed out, this works only if you assume
that TC/SC equivalence can be solved by exactly two
registrations, one of each.  As soon as there are combinations of
the two forms, the combinatorics get you in major ways.

> I also concur that IDN should strive to solve some language
> issues, however, I also think that it is the IDN
> "implementations" that should solve the problem and not the
> "core protocol" which we should concern ourselves with at this
> moment.

If language issues are left to "implementations", we almost
certainly end up with different implementations interpreting the
same string in different ways and resolving it to different
targets.  That is, in essence, the fragmentation problem.
 
     john

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Aug 2001 13:04:59 -0400

>         -- fragmenting the network

I don't think that's an accurate characterization.   As a practical
manner, any DNS zone can create multiple names within that zone that
resolve to equivalent RRs, and any DNS zone can establish procedures
for keeping those names consistent, without affecting the DNS protocol
or the applications that use it.  Similarly, if two zones are controlled
by the same party, that party can maintain those zones such that
label X in zone A and label X' in zone B resolve to an equivalent set of 
RRs, and the party controlling those zones can keep those two zones 
consistent with one another.

I don't see this as inherently undesirable.  True, caches will not recognize 
that these zones are equivalent, but this mainly serves to increase lookup 
delay for names in those zones and to increase load on the authoritative 
servers for those zones.  Each zone can decide for itself whether it's 
worth the additional delay and cost.

Nothing that IDN does is going to change the ability to create multiple
names that produce equivalent RRs.  Nor do I think that IDN can build a 
better way to solve this problem.  We certainly don't want to embed 
knowledge of SC/TC equivalence into applications, DNS libraries, or 
DNS servers.

Users can tell the difference between TC and SC.  So they will be able
to figure out that even if TC and SC names are equivalent within some
particular TLD, they are not necessarily equivalent elsewhere.

Bascially I think this issue is out of scope for IDN, because you can't 
expect a networking protocol to fix all naming equivalence problems in 
all languages.

Keith

---

From: "Edmon" <[email-masked]>
Date: Thu, 9 Aug 2001 13:50:52 -0400

John,

> that the choices are between
They do not have to contrive.  If a UserA types in <TC>.cn in Finland, the
.cn registry will do the TC=SC folding and respond saying that <TC>.cn=IP
and this will be cached in the Finland ISP resolver.  Now if a UserB types
in <TC>.cn, this could be responded using the cache.  If a User C types in
<SC>.cn, then the request will reach CNNIC and will resolve <SC>=IP and this
will be cached in the Finland ISP resolver.  This does not fragment the DNS.

> heard from them going that route is an accceptable model.

The TC=SC mechanism could be done on the TLD server end.

> the two forms, the combinatorics get you in major ways.

If you employ a server-end mapping mechanism, there would be only one
registration.

> targets.  That is, in essence, the fragmentation problem.

I think I need to rephrase.  What I meant is that language issues should be
dealt with in a higher layer than the core DNS, that is implementation of
applications that will access the DNS.  Perhaps an application when prompted
with a particular name will perform multiple DNS requests to determine the
closest semantic representation.  If more than one is found, then it would
prompt the user to choose.  This is just a very very crude idea, but my
point is that linguistic/semantic issues should and could be dealt with in a
higher layer.

Edmon

---

From: Dan Ebert <[email-masked]>
Date: Thu, 09 Aug 2001 11:00:28 -0700

Edmon wrote:

<snip>

> If you employ a server-end mapping mechanism, there would be only one

Yes, but if nameprep is done on the client side wouldn't that cause
problems?

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 10 Aug 2001 08:47:32 +0200 (CEST)

> zone with identical data for all the matching names, which is obviously

I don't think this WG prohibits this - it shouldn't as far as I can tell.
But the ability of the client to tell
that it got the right answer to a DNS query does add some severe constraints.
[I assume DNS protocol experts will correct me if I got thins wrong.]

If the client asks for A and gets a respose with QNAME A' and answer X then how
does the client know that it wasn't spoofed? Applying DNSSEC would just tell
the client that X is indeed the answer to the question for A'.

So unless the server mains records for both A and A' (with their SIGs)
(where A and A' really expand to all the possible combinations as in
the UNAME) then the client needs to verify that A and A'
match.

Thus there seem to be two choices:
 - client sends A to server
 - server folds A to A' (A' := nameprep(A)), looks up A' and responds to client
 - client verifies that A and A' are the same by checking nameprep(A) = A'
   (to prevent being spoofed)

OR
 - client does A' := nameprep(A), sends A' to server
 - server looks up A' and responds to client
 - done

Thus client might as well do the nameprep before composing the query
and save the work in the server.

  Erik

---

From: "ben" <[email-masked]>
Date: Fri, 10 Aug 2001 06:51:48 -0400

Hi John,

I agree with what you said below.

Thanks
Ben Chan

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Edmon" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 09, 2001 11:03 AM
Subject: Re: [idn] opting out of SC/TC equivalence

Edmon,

    john

---

From: "ben" <[email-masked]>
Date: Fri, 10 Aug 2001 10:34:26 -0400

Hi Keith,

As unpleasant as the bath water may be, we cannot throw out the baby-
it will come back and haunt each and everyone of us.

Thanks
Ben Chan

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "Edmon" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 09, 2001 1:04 PM
Subject: Re: [idn] opting out of SC/TC equivalence

I don't think that's an accurate characterization.   As a practical
manner, any DNS zone can create multiple names within that zone that
resolve to equivalent RRs, and any DNS zone can establish procedures
for keeping those names consistent, without affecting the DNS protocol
or the applications that use it.  Similarly, if two zones are
controlled
by the same party, that party can maintain those zones such that
label X in zone A and label X' in zone B resolve to an equivalent set
of
RRs, and the party controlling those zones can keep those two zones
consistent with one another.

I don't see this as inherently undesirable.  True, caches will not
recognize
that these zones are equivalent, but this mainly serves to increase
lookup
delay for names in those zones and to increase load on the
authoritative
servers for those zones.  Each zone can decide for itself whether it's
worth the additional delay and cost.

Nothing that IDN does is going to change the ability to create
multiple
names that produce equivalent RRs.  Nor do I think that IDN can build
a
better way to solve this problem.  We certainly don't want to embed
knowledge of SC/TC equivalence into applications, DNS libraries, or
DNS servers.

Bascially I think this issue is out of scope for IDN, because you
can't
expect a networking protocol to fix all naming equivalence problems in
all languages.

Keith

---

From: David Hopwood <[email-masked]>
Date: Fri, 10 Aug 2001 14:27:45 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Erik Nordmark wrote:
> Adam M. Costello <[email-masked]> wrote:
> But the ability of the client to tell that it got the right answer to a
> DNS query does add some severe constraints.
> [I assume DNS protocol experts will correct me if I got this wrong.]
> 
> If the client asks for A and gets a response with QNAME A' and answer X
> then ...

It won't - it will get a response with QNAME A.

For DNSSEC, all responses for names that are actually used will have to be
signed. This is an inevitable consequence of wanting TC/SC equivalence without
putting TC/SC folding in nameprep (that is, the client-side canonicalization
function). The decision that WG has to make is whether TC/SC folding is in
nameprep or not. If that answer is "yes", it also has to define the folding,
and require that all clients implement it.

Personally I don't think nameprep should include any folding that depends
on the semantics of particular languages - even if that causes inefficiencies
for DNSSEC. The 'ONE' work demonstrates how complicated "semantic folding"
can be:

James Seng wrote:
# Our (as in i-DNS.net) approach have been working on Onomastic
# Normalization Engine for registration time to handle possible multiple
# names since Nov last year. The work on ONE turns out to be much more
# complex and time consuming then originally expected. And there is
# different ONE for each language (See ONE-J and ONE-K at
# http://playground.i-dns.net/one/index.html).

- --

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 10 Aug 2001 10:28:02 -0700

For SC/TC equivalence, the feedback I have gotten is that "In practice, most
Chinese would expect either simplified or traditional, but not a mixture of
both", and from another writer, "Simplified and traditional are
usually used in their own contexts, and a domain name is a single context,
and thus wouldn't result in a mixture of the two systems."

If that is true, then for TC/SC, unlike case, registering exactly two
variants of any particular domain name would be sufficient; one would not
have to register n^2 combinations. Given that, registering SC/TC variants is
much more like registering two different languages and/or scripts, something
best left to documentation instead of changing nameprep.

Mark

—————

πάντων μέτρον ἄνθρωπος — Πρωταγόρας
[http://www.macchiato.com]

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 10 Aug 2001 22:28:11 +0000

Erik Nordmark <[email-masked]> wrote:

> If the client asks for A and gets a respose with QNAME A'...
>
> the UNAME) then the client needs to verify that A and A' match.

I think the server is always supposed to answer the query that was asked
(A, not A').  If maintaining records for all equivalent variants of
A' is too expensive, it could instead generate the response (and the
signature) on the fly.  It could use caching to remember the responses
for the most common variants.

AMC

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 15:50:23 +0200 (CEST)

David Hopwood wrote:

> signed. This is an inevitable consequence of wanting TC/SC equivalence
> without putting TC/SC folding in nameprep (that is, the client-side
> canonicalization function). The decision that WG has to make is whether
> TC/SC folding is in nameprep or not. If that answer is "yes", it also has to
> define the folding, and require that all clients implement it.

If it gets a response with QNAME A then there must be a separate SIG for
QNAME A' and QNAME A for each RRset. Since DNSsec should be capable of
operating  with offline private keys this means that the signature couldn't
have been  created when the server received the query.

Thus I think you are pointing at the same type of solution to this as
Keith was: the server maintains the same responses (all RRsets) for
queries on A and A'.

That is quite different than what I've heard discribed as the DNS server
doing a mapping on the fly.

The former might have result in combinatorial explosion but works
with DNS including DNSsec.
The latter can avoid the combinatorial explosion but doesn't work with the
DNS as I pointed out.

> for DNSSEC.

Agreed. IDN is about identifiers and not words and languages.
(And just like in the current non-IDN world folks will try to overload
words and phrases on IDN but that should really be a separate problem.)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 16:02:34 +0200 (CEST)

> for the most common variants.

DNSsec is specified to work without keeping the private key on-line
(doing the signing off-line can be made secure) thus you
can't assume that servers will be able to sign on the fly.

  Erik

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Aug 2001 11:39:02 -0400

> doing a mapping on the fly.

In my mind, the choice of mechanism used to keep the RRsets equivalent for
the sets of equivalent labels is up to the maintainer of the zone.
Of course, if the maintainer of the zone uses DNSsec, that will influence 
the choice.  

Doing a mapping on the fly might be attractive for some zones that
did not use DNSsec.  But I wouldn't specify such a mechanism as part 
of the standard.

Keith

---

From: "ben" <[email-masked]>
Date: Tue, 14 Aug 2001 10:35:34 -0400

Hi

I am looking for support for my Supreme Chinese Domain Name System so
that it will become a standard.  It involves a standard way of
registration by all registries that offers CDNs as well as adding a
prohibit function to nameprep of CDNs.

However, if I don't have your support in making it a standard, that is
absolutely fine.  Perhaps you can still comment on my other
alternative to implementing this system by creating a new type of
lsTLD.  If you are concerned that discussions of <IDN>.<IDN> is out of
the scope of the IDN WG, please do email me privately.

Attached below is my draft.

Thanks for your support
Ben Chan

_________________________________

Internet Draft
Author: Ben Chan
July 14, 2001
Expires in six months

  Supreme Chinese Domain Name System

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

Abstract

Chinese can be written in 2 different scripts, traditional Chinese and
simplified Chinese, that cannot be distinguished by many people of
certain background/cultures/groups who use them interchangeably.  As a
result, users of Chinese Domain Names (CDN) have special needs that
can only be satisfied by adding a label to CDNs that distinguish a CDN
with traditional characters from a CDN with simplified characters.
This labeling is an entire system that can be accomplished with SLDs
or by creating a new type of TLD called Language Script TLD (lsTLD).
This draft describes the benefits that the system will provide and the
techniques involved in implementing it.

1.  Introduction

(Labeling of a CDN can be accomplished with either SLDs or lsTLDs.
However, for simplicity, most of this draft will only use lsTLD to
describe the system and its techniques.  For more information on how
SLDs can be used, please see section 5.2.)

The <.traditional> and <.simplified> TLDs in Chinese characters are:
a) <.traditional> in traditional Chinese is ".繁體" (U+7E41)(
U+9AD4)
b) <.traditional> in simplified Chinese is ".繁体" (U+7E41)( U+4F53)
c) <.simplified> in simplified Chinese is ".简体" (U+7B80)( U+4F53)
d) <.simplified> in traditional Chinese is ".簡體" (U+7C21)( U+9AD4)

Using the 4 language script TLDs above, a Chinese Domain Name System
can be created to satisfy the needs of CDN users by combining together
the following 3 benefits:

Benefit A- A registrant is given the choice of pointing a traditional
CDN to one location (ie. traditional Chinese website) and pointing the
corresponding simplified CDN to another location (ie. simplified
Chinese website).

Benefit B- The registration of a simplified CDN will automatically
reserves the corresponding traditional CDN(s) and visa versa thus
giving users the flexibility of using either script.

Benefit C- A method that will guide users to enter a CDN in their
applications (ie. web browsers) matching the meaning that was intended
by the registrant when the CDN was registered.

2.  Description of the Importance of the Benefits

It is important to understand the needs of ordinary everyday people
who will be the users of CDNs.  The following subsections will explain
in detail the 3 benefits of this system that satisfied those needs.

2.1  Importance of Benefit A.

It would be appropriate for a traditional CDN to be pointing to a
traditional website with contents that are suitable for visitors from
Hong Kong or Taiwan.  On the same line, it would be appropriate for a
simplified CDN to be pointing to a simplified website with contents
that are suitable for visitors from China or Singapore.

2.2  Importance of Benefit B.

Since many Chinese can read / write in both scripts, it is only
appropriate for a traditional CDN to be mapped to its corresponding
simplified CDN by applying a conversion.  This will ensure that no
matter what script the user types in, he will always be able to reach
the intended location(s).

2.3  Importance of Benefit C.

The relationship between simplified Chinese and traditional Chinese is
very complicated.  A TC character that corresponds to a SC character
may not have the same meaning.  To complicate the situation, one TC
character can be mapped into many different SC and visa versa.  One
CDN can potential have a great number of different written variations.
Without a method, a user can be given a CDN and type in the correct
CDN but still cannot reach the proper destination because it is a
variation of the original CDN not intended by the registrant.

3.  Solution / Method

The method for implementing this system is done both at the
registration system and at the client end.

3.1  Implemented at the registration system

The solution to delivering the 3 benefits explained above is a Chinese
domain name system that uses language script TLDs- a TLD of
<.traditional> for traditional CDNs (defined here as a CDN that uses
all traditional characters) and a TLD of <.simplified> for simplified
CDNs (defined here as a CDN that uses all simplified characters).
During registration, a person is allowed to register CDNs in either
all traditional Chinese characters or all simplified Chinese
characters but not by mixing the 2 scripts together.  If he registers
in traditional characters, he will be given a traditional CDN (with
the TLD of <.traditional>) and any similar traditional CDNs will be
reserved.  At the same time, the corresponding simplified CDN(s) (with
the TLD of <.simplified>) will also be reserved- to be activated at a
later date if the registrant chooses to do so.  If he registers in
simplified characters, he will be given a simplified CDN (with the TLD
of <.simplified>) and any similar simplified CDNs will be reserved.
At the same time, the corresponding traditional CDN(s) (with the TLD
of <.traditional>) is reserved.

3.2 Implemented at the client end.

If a user types in a traditional CDN (with the <.traditional>), error
checking can be done by the application (ie. web browser- nameprep to
prohibit invalid entries) on the CDN by searching for the characters
in a Unicode table containing all the valid traditional Chinese
characters.  If a certain character is found not to be a valid
traditional character, an error will be displayed to point out which
character is invalid.  If a user types in a simplified CDN (with the
<.simplified>), the same error checking will be performed by searching
for valid simplified Chinese character.  (Please see Appendix A for a
list of the disallowed Unicodes for traditional CDNs and simplified
CDNs.)

4.  Conclusion

Under such a method of creating a relationship between the lsTLDs, all
3 benefits will be satisfied.  Benefit A will be satisfied because he
can point <whatever>.<traditional> to a traditional website and point
<whatever>.<simplified> to a simplified website.  Benefit B will be
satisfied because when a user is given a <whatever>.<traditional> CDN,
but because he is from mainland China and is more comfortable using
the simplified script, he can simply use the corresponding CDN of
<whatever>.<simplified>.  In other words, a user can use the script of
his choice whether it is traditional Chinese or simplified Chinese and
still reach the location(s) intended by the registrant.  Benefit C
will be satisfied because when the user is given the
<whatever>.<traditional> CDN, the <.traditional> tells him that he
must set his Chinese Input editor to recognize TC only and thereby
preserving the original intended meaning of the CDN when it was first
registered.  In other words, the language script TLDs give the users
much more control and eliminates any guess work.

5.  Other Comments

There are 2 important related issues- “TC<->SC equivalence” and
“lsSLDs”.

5.1  TC<->SC equivalence

An interest question is how this system is effect with TC<->SC
equivalence in the DNS protocol?  The answer is that it will even be
better.  With TC<->SC equivalence in the DNS protocol, all 4 lsTLDs
are used.  No error checking will be performed.  The <.traditional>
lsTLD in both simplified and traditional forms are consider equivalent
and point to the same location (ie.  traditional website).  The
<.simplified> lsTLD in both simplified and traditional forms are
considered equivalent and point to the same location (ie.  simplified
website).  The author of this draft strongly endorse any efforts made
in finding a reasonable solution to the TC<->SC equivalence.

5.2 lsSLDs

The same techniques documented in this draft can also be applied to
the current gTLD and ccTLD registries by using SLDs.  In order to be
fair, everyone must agree to this system and make it a standard.  In
addition, every registry must change their current registered second
level domains to third level domains (ie.
<whatever>.<traditional>.TLD, <whatever>.<simplified>.TLD)

6.  Author’s Address

Ben Chan
cc-www.com
Box 92241
2900 Warden Avenue
Scarborough, Ontario
Canada
M1W 3Y9

7.  References

[IDNREQ]  Requirements of Internationalized Domain Names, Zita Wenzel,
James Seng, draft-ietf-idn-requirements

Appendix A-  Error checking for Unicodes of traditional/simplified
Chinese characters

(The following is a partial list for information only.  A complete
list will be presented upon actual implementation.)

Acceptable Unicodes         Acceptable Unicodes
for a simplified                    for a traditional
CDN                                 CDN

7691                                    769A
788D                                   7919
7231                                    611B
8884                                    8956
5965                                    5967
575D                                   58E9
7F62                                    7F77
6446                                    64FA
8D25                                   6557
9881                                    9812
529E                                    8FA6
7ECA                                  7D46
5E2E                                   5E6B
7ED1                                   7D81
9551                                    938A
8C24                                   8B17
5265                                    525D
9971                                    98FD
5B9D                                   5BF6
62A5                                    5831
9C8D                                   9B91
8F88                                    8F29
8D1D                                   8C9D
94A1                                    92C7
72C8                                    72FD
5907                                     5099
60EB                                    618A
7EF7                                    7E43
7B14                                    7B46
6BD5                                    7562
6BD9                                    6583
5E01                                     5E63
95ED                                    9589
8FB9                                    908A
7F16                                    7DE8
8D2C                                   8CB6
53D8                                    8B8A

etc.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Aug 2001 16:20:40 -0700

At 07:34 PM 8/7/2001, John C Klensin wrote:
>not, we shouldn't be having this discussion either.

The length of this topic thread, and its persistent recurrence, warrants 
making the point even more strongly than John's polite note:

Language equivalence has nothing at all to do with the iDN task of adding 
non-ASCII characters to the DNS.

iDNS concerns a richer set of characters, NOT "language".

Language equivalence is a worthy topic, but not in this forum!

d/

----------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 16 Aug 2001 22:53:42 -0400

Dave,

My take on at least a part of this interminible thread is scope, [30],
not language. Some of the local scope proponents are flogging product,
others appear to be concerned with local, even private differentiation.
We may also be doing a Hamming-distance dance around trademarks, which
may account for some of the heat without light.

I find it perplexing. In the case of roman scripts used for Algonquin
languages, either in their diacritical rich or simplified forms, we use
latin or extended latin differently from Europeans and Euro-Americans.
Different languages and scripts, same character repitoires, with some few
exceptions (e.g., Eastern Algonquin "8" U+0222 and U+0223).

In this case, local scope [30] seems sensible. Ditto for Siouian, Athabascan,
...
In the SC/TC context, local scope [30] seems senseless.

If you and/or John could just sort out the issue of scope, we could all
leave the question of scoped rules to those who actually have clue.

Eric

---

From: [email-masked] <[email-masked]>
Date: Fri, 17 Aug 2001 11:14:37 +0800

Hi !  Friends in this WG:
     We have different culture and experiences and we should respect each
other !  I think John is concerned his duty and time limitation. I found
people in this WG they talk about foreign scripts or language characters as
it is their own mother language , and they care something so they worry some
case will happen and they applied some  partial case to full situations,
that is a basic wrong .
      In TC/SC  characters, there are small set of equivalent characters
that are exactly the same situation as  english case folding but if it is
neglected that will be more worse than other scripts, because there are many
sources of  confusing troubles. Another set of equivalent word (content
sensitive equivalent characters) are not the case of case folding. But
someone try to cut or mixed them together to one simple class , then the
hurt will happen.
      If your statements are meant John is the God father , so no one can
pass over the line he defined , I will ask what is the goal of this WG ?
Does it is used to hurt other people in this world ?
      IDN is very complex ,  but if  you try to neglect some truth then the
political issue will be introduced , then no one will be happy .

L.M.Tseng

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Aug 2001 22:02:11 -0700

I've posted a copy of the slides used for my "iDN Choices" presentation at 
the London IETF, last week.

This version has minor corrections from the version used at the working 
group meeting, and I have added some commentary text that approximates the 
comments I made during the presentation.

The powerpoint file is at:

         <http://www.brandenburg.com/presentations/iDN-choices-comments.ppt>

d/
----------