Subject: Re: [idn] Prohibit CDN code points

From: [email-masked] (J. William Semich)
Date: Mon, 21 Jan 2002 11:37:14 -0500

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)" <[email-masked]>
>To: "[email-masked]" <[email-masked]>; "Kenny Huang"
><[email-masked]>; "IETF-IDN" <[email-masked]>; "Paul Hoffman
>/ IMC" <[email-masked]>
>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: "[email-masked]" <[email-masked]>
> > To: "ben" <[email-masked]>; "Kenny Huang" <[email-masked]>;
> > "IETF-IDN" <[email-masked]>; "Paul Hoffman / IMC"
><[email-masked]>
> > 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" <[email-masked]>
> > > To: "ben" <[email-masked]>; "Kenny Huang"
><[email-masked]>;
> > > "IETF-IDN" <[email-masked]>
> > > 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: [email-masked] <[email-masked]>
Date: Tue, 22 Jan 2002 00:47:00 +0800

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" <[email-masked]>
To: "ben" <[email-masked]>; <[email-masked]>; "Kenny Huang"
<[email-masked]>; "IETF-IDN" <[email-masked]>
Sent: Tuesday, January 22, 2002 12:37 AM
Subject: Re: [idn] Prohibit CDN code points

> >To: "tsenglm@è¨^ç¶²ä¸­å¿f.ä¸­å¤§.tw" <[email-masked]>; "Kenny
Huang"
> > > From: "tsenglm@è¨^ç¶²ä¸­å¿f.ä¸­å¤§.tw" <[email-masked]>

---

From: "ben" <[email-masked]>
Date: Mon, 21 Jan 2002 12:32:23 -0500

Hi Bill,

>I think that's what he means by "we

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: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 21 Jan 2002 10:14:30 -0800

>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

---

From: "ben" <[email-masked]>
Date: Mon, 21 Jan 2002 16:09:52 -0500

> 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: [email-masked] <[email-masked]>
Date: Tue, 22 Jan 2002 07:23:50 +0800

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

---

From: "Kenny Huang" <[email-masked]>
Date: Tue, 22 Jan 2002 11:29:31 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Paul Hoffman / IMC
> Sent: Tuesday, January 22, 2002 2:15 AM
> To: [email-masked]

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).

> .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.

> 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: hoho <[email-masked]>
Date: Tue, 22 Jan 2002 12:18:12 +0800

曾老師，

我們還是得注意 Paul 問的問題，也就是在英文 domain之下建立中文domain,
例如 中文.harvard.edu。由於缺乏接納包含他們在內的中文使用者的機制，
cDNC很容易被他們冠以排外之名。

在IETF的環境下，我們提供的答案還是要得到他們的共識。

建明

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Jan 2002 08:06:45 -0800

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Jan 2002 18:00:48 -0500

--On Tuesday, 22 January, 2002 08:06 -0800 Dave Crocker
<[email-masked]> 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: [email-masked] <[email-masked]>
Date: Wed, 23 Jan 2002 08:52:01 +0800

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" <[email-masked]>
To: "Dave Crocker" <[email-masked]>
Cc: "IETF-IDN" <[email-masked]>
Sent: Wednesday, January 23, 2002 7:00 AM
Subject: Re: [idn] Prohibit CDN code points

> to support a potentially-large collection of "if  TLD isthe X,
> isrules  Y and then..." and "if the TLD the SLD is Z" while

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 23 Jan 2002 03:54:55 +0000

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: YangWoo Ko <[email-masked]>
Date: Wed, 23 Jan 2002 13:37:37 +0900

On Wed, Jan 23, 2002 at 03:54:55AM +0000, Adam M. Costello wrote:
> (snip)  Mixed-case annotations could be used to indicate

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 : [email-masked]
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 23 Jan 2002 05:12:33 +0000

> 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