Subject: [idn] A question...

From: <[email-masked]>
Date: Fri, 8 Feb 2002 02:31:35 +0800

Dear all IDN members:

I'm a student at CSIE, National Taiwan University. I've recently heard
the
news for the
last call of IDN WG.

According the drafts,  my school should register 8 domain names
    ACE(U+53F0,U+6E7E,U+5927,U+5B66)
    ACE(U+53F0,U+6E7E,U+5927,U+5B78)
    ACE(U+53F0,U+7063,U+5927,U+5B66)
    ACE(U+53F0,U+7063,U+5927,U+5B78)
    ACE(U+81FA,U+6E7E,U+5927,U+5B66)
    ACE(U+81FA,U+6E7E,U+5927,U+5B78)
    ACE(U+81FA,U+7063,U+5927,U+5B66)
    ACE(U+81FA,U+7063,U+5927,U+5B78)
to let user to access my school (NTU, "台灣大學" in Big5) without
worrying
if he or she keys in right character.

and under each domain, we have to create 4 sub-domains for my
institite(CSIE,
"資訊系" in BIG5),
    ACE(U+8D44,U+8BAF,U+7CFB)
    ACE(U+8D44,U+8A0A,U+7CFB)
    ACE(U+8CC7,U+8BAF,U+7CFB)
    ACE(U+8CC7,U+8A0A,U+7CFB)

and under each of 8*4=32 sub-domains, create 4 records for a web
server(web,
"網頁"
in BIG5)
    ACE(U+7DB2,U+9801)
    ACE(U+7DB2,U+9875)
    ACE(U+7F51,U+9801)
    ACE(U+7F51,U+9875)

And finally, i have to set all 8*4*4=128 domain names at the
configuration
files to
prevent error messages such as "host not found", or "page not found"
even if
i have
correctly set my DNS server.

If it is true, please do not pass these drafts!! It's too terrible,
there
are many Web servers,
mail servers, and other severs.....

If I'm wrong, please correct me, and please forgive my poor English.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 8 Feb 2002 06:24:08 +0800

U+53F0 could either be SC or TC depending how it is been used.

In (U+53F0 U+6E7E) "taiwan", it is a simplified chinese.
In (U+53F0 U+7063) "taiwan", it is traditional chinese.
Another variant of traditional chinese of taiwan is (U+81FA U+7063).

For University, (U+5927 U+5B66) is a simplified chinese and (U+5927
U+5B78) is a traditonal chinese.

For "taiwan university" you get the following variants:

Simplified Chinese: (U+53F0 U+6E7E U+5927 U+5B66)
Traditional Chinese: (U+53F0 U+7063 U+5927 U+5B78)
    or (U+81FA U+7063 U+5926 U+5B78)

Therefore, in practice, you may like to have 3 names.

ps: For those who argue TC/SC can be done 1 to 1, this is an excellent
example why it cannot be done 1 to 1. Note I do TC/SC conversion in
pairs of Han ideographs, not one by one character.

-James Seng

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 7 Feb 2002 22:42:06 +0000

[email-masked] wrote:

> According the drafts, my school should register 8 domain names to let
> user to access my school without worrying if he or she keys in right
> character.
>
> institite
> server
> configuration files...

I don't think any of the drafts recommend this.  In fact, I think there
are plans to add language to the IDNA draft warning registrars about the
pitfalls of registering any and all names without any policies.

For example, although there may be 8 different ways to represent
your school name, there are probably only two ways that are most
common/convenient (call them X and Y), and the other six ways are much
less common/convenient.  Suppose the registrar prohibited anyone from
registering those six ways?

Furthermore, while there may be 4 ways to represent your institute,
there is probably one of them that is most common/convenient when used
with X, and one of them that is most common/convenient when used with Y.
And so on, for the remaining labels.

If the registrars imposed sensible prohibitions, your 128 names could
be reduced down to 2.  The other 126 would be prohibited by the
registrars, so you wouldn't need to worry about getting spoofed.  Users
who accidentally type one of the non-existent 126 ways might get a
host-not-found error, but that should be fairly rare (because those 126
ways were deliberately chosen to be the less common/convenient ways),
and enhanced application software that knows some of the registrars'
policies could auto-generate suggestions for other names more likely to
be in the DNS.

AMC

---

From: Dan Ebert <[email-masked]>
Date: 07 Feb 2002 15:03:34 -0800

> registering those six ways?

It may not be realistic to expect registrars to do this.  (Would each
registrar have to check for the existence of a domain 'variation' every
time someone wants to register a name?)

If this prohibition is to occur would it be better achived at the
registry level?

Dan Ebert.

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 8 Feb 2002 08:40:04 +0900

----- Original Message -----
From: "Adam M. Costello" <[email-masked]>
> policies could auto-generate suggestions for other names more likely to

Adam, you may have missed the point Tseng and et al raised.

In the case of LDH domains,  aPPLe.com would seldom be entered by end users.
But, in chinese letters, TC/SC distinctions are not as clear as
lower/uppercase distinctions of Latin  alphabets. Not all chinese
people are font/letter variant experts.

Even for me, the subtle difference between U+6DF8 and U+6E05 would not be noticed
without careful inspection. The same for U+654E and U+6559. It will be
very difficult for ordinary chinese people to have as complete  knowledge as
IRG/Han experts  to whom the distinction may be very very very clear though.

I feel that in many aspects, TC/SC distintions are like the distinction
between 'A' in times roman font  and  'A' in script font, rather than
one between 'A' and 'a' in the same font set.

In short, TC/SC equivalence can be put somewhere between
simpified font variants relations and bicameral relations.

To repeat one more time, non CJK people should try to understand and learn  :
  TC/SC distinction may not be so clear as between 'A' and 'a'  in chinese culture
  and How often TC and SC letters are used interchangeably in everyday life of chinese.

Just having 2 registrations of one TC and one SC label  from 8 candiates may be not sufficient for
ordinary chinese end users. More attention, please!

(from Tseng's example in UTF8)

淸眞敎 U+6DF8 U+771E U+654E
淸眞教 U+6DF8 U+771E U+6559
淸真敎 U+6DF8 U+771F U+654E
淸真教 U+6DF8 U+771F U+6559
清眞敎 U+6E05 U+771E U+654E
清眞教 U+6E05 U+771E U+6559
清真敎 U+6E05 U+771F U+654E
清真教 U+6E05 U+771F U+6559

Soobok Lee

---

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 8 Feb 2002 01:20:15 +0000

Soobok Lee <[email-masked]> wrote:

> Not all chinese people are font/letter variant experts.
>
> Even for me, the subtle difference between U+6DF8 and U+6E05 would not
> be noticed without careful inspection.

For the purposes of my proposal, it doesn't matter whether you can see
the difference.  When you sit down at a keyboard with a domain name
in your mind and type it in, how many distinct strings have a good
chance of being produced?  There may be 2^n possibilities, but the
vast majority would require deliberate extra effort to type, and have
virtually no chance of being produced accidentally.  I'm hypothesizing
that usually only a very few of the many possible strings actually have
a good chance of getting typed in by a naive user.

Dan Ebert <[email-masked]> wrote:

> > common/convenient (call them X and Y), and the other six ways are
> > much less common/convenient.  Suppose the registrar prohibited
> > anyone from registering those six ways?
>
> registrar have to check for the existence of a domain 'variation'
> every time someone wants to register a name?)

I am not proposing that the registrar allow an arbitrary pair of the
128 variants to be registered, whichever two are requested first.  I am
proposing that the registrar adopt an algorithmic policy for deciding
whether a given string is admissible (regardless of what else may or may
not be registered).  Once the algorithm has decided that the string is
admissible, the registrar would check whether it's already registered
(as usual).

If the requested string is inadmissible, the registrar would probably
offer some suggestions for "nearby" admissible unregistered strings,
just as registrars today offer suggestions when the requested string is
already registered.

> If this prohibition is to occur would it be better achived at the

Maybe.  In this discussion I have not been thinking about the
distinction between registrars and registries.

AMC

---

From: <[email-masked]>
Date: Fri, 8 Feb 2002 12:06:53 +0800

----- Original Message -----
From: "James Seng/Personal" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, February 08, 2002 6:24 AM
Subject: Re: [idn] A question...

> Therefore, in practice, you may like to have 3 names.

It is not ture. I think, maybe you are not familiar how Chinese
characters
are used in our daily work. But the other 5 cases are often written
(not inputed), especially U+53F0, U+6E7E, U+5B66 are sometimes
preferrd because they are less-strokes.
What you said are in a restricit environment, like Windows 98, on which
you can not input those characters on some limited IME. However,
Windows 2000 will change the user behavior.

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 8 Feb 2002 12:23:55 +0800

characters
> are used in our daily work.

Perhaps you are not be aware I am possibly a Chinese myself too and I
use Chinese in my daily live, both traditional (in Malaysia) and
simplified (Singapore).  And I work with many Chinese linguists in the
last 2 years and the many of them are not Chinese.

> But the other 5 cases are often written

Thanks. Then we have no problem.

> Windows 2000 will change the user behavior.

By default, TC or SC will be output depending which IME you use. Of
course, you *could* manually scroll down the list to get the characters
or you could toggle the input method to do so.

The user behavior education about domain names should be that domain
names are identifier, not names. They should enter into the computer
exactly as they seen it or reference it.

Anyhow, you are raising issues which have been debated in the list
before, one which the wg is quite well aware of. So unless you have a
TC/SC solution which you willing to contributed to the group, I consider
this discussion closed.

And if you do have a TC/SC solution, one which have not be considered by
the group and UTC and IRG, I would definately love to hear your idea.

-James Seng

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Feb 2002 06:41:39 -0000

> exactly as they seen it or reference it.

So why are you demanding that implementors convert uppercase non-ASCII
to lowercase?

---Dan

---

From: "jw-lin" <[email-masked]>
Date: Fri, 08 Feb 2002 05:14:58 -0800

<[email-masked]>
Subject: Re: [idn] A question...
Date: Fri, 8 Feb 2002 16:47:24 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [email-masked]
Precedence: bulk

Dear Adam:

The world will go in another direction....i think...

Please see the story below. (I've mentioned this to James Seng  in my
reply)

By doing so, i can image that:
The phone in office of the computer center at my school will ring all of
the days, and never stop. The administrators should reply for the
complain
from students, and make reports to the managers who are complained
by professors. And one day, at the meeting for school affair, the
principal
will take care of these complains. He may ask how much does it
cost to register all possible names. And maybe my school is rich, and
doesn't care about money. The principal say "pay it, and register all."
Of course, he won't ask how complicated things are. Because it is the
work of the administrators:-(
And finally, the administrators must register all 128 names, and
configure
these 128 names on each server which will check the "domain name" of
the requests.

You are trying to change the feeling to Chinese characters for Chinese.
I don't think it works. The result is all administrators register all
possible
names if they have enough money, and configure their servers well.
If not, apologize and explain to their customers.

Maybe it is a way to keep all administrators of Chinese domain names
busy.

---

From: "Chun-Hsin Wu" <[email-masked]>
Date: Sat, 9 Feb 2002 05:12:49 +0800

Dear James,

Adopting your word, please don't try to PAINT yourself as a daily Chinese
computer user. As I know, you did not use Chinese Windows system daily
nor input Chinese characters often in your dialy work. I'm afraid that an
unfamiliar or inexperienced Chinese-system user can not thoroughly realize
what troubles the proposed IDN solution will make to world-wide Chinese
Internet societies. Although we have discussed inputting and using SC/TC
characters in the end of Oct 2001, I still quite doubt whether you really
understand what I try to explain.

### Inputting mixed SC/TC Characters

In http://www.imc.org/idn/mail-archive/msg04520.html, you said it's
difficult to type mixing TC and SC and we need to switch from TC IME
to SC IME repeatively. Followed by Xiang Deng from CNNIC in
http://www.imc.org/idn/mail-archive/msg04521.html, he told you:
    "No, I do can type TC AND SC in a very usual IME without swich."
Besides, in http://www.imc.org/idn/mail-archive/msg04523.html, I also
told you:
    "Most IMEs in Traditional Windows 2000 can support TC and SC
    directly without switching, even they can let the user type in
    Japanese characters without switching.  It is not unusual for one IME
    to support all, or as many as possible, Unicode characters if the system
    supports Unicode.  For examples, the phonetic imput method and the
    Boshimy input method. The former is the default method in all Chinese
    systems and almost every Chinese or Taiwanese who uses computers
    knows how to use it easily. The later is widely used by many people
    who want to have high Chinese input rate, especially for professional
    users."

Two daily native Chinese Windows users have tried to tell you we do
be able to input mixed TC/SC by a single input method software (IME).
However, you still claimed in your response:
http://www.imc.org/idn/mail-archive/msg04524.html
    "On Windows, you install 2 IME, one for TC and the other for SC.
    You toggle between these two while you key in."
Well, how were you so confident? To give you more feeling, in
http://www.imc.org/idn/mail-archive/msg04545.html , I demostrated
two examples that use a single IME to input mixed SC/TC, and told you:
    "So it is clear that we don't need to install TWO IMEs to
    input mixed TC and SC in TC Windows 2000. The user also
    does not need to toggle between TC and SC while input. It
    is natural that one TC input method software aims to make
    the user input as many Unicode characters (and as easy)
    as possible. Indeed, almost every add-on TC input method
    software can support far more HAN characters than those
    defined in Unicode, since some other charsets define more
    characters than Unicode. The market will drive the software
    company to do so, becoming a Uni-input method software
    and supporting as many HAN characters as possible."

Now, in http://www.imc.org/idn/mail-archive/msg05781.html you still
claimed:
    "By default, TC or SC will be output depending which IME you use. Of
    course, you *could* manually scroll down the list to get the characters
    or you could toggle the input method to do so."
Well, well, .... Fine. See:
    http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm
It gives you three examples and respective window snapshots to prove
that one single IME can output TC and SC easily. I believe many IME
softwares have more functions  for multi-lingual inputs than your
understanding. Indeed, IME developers also plan to support inputting
multi-lingual Unicode characters more conveniently in their new
versions. Next time you come to Taiwan, I can help you discuss IME
issues with the developers of top 3 IME softwares in Taiwan, in
Chinese conversation.

By the way, can you easily distinguish the displayed Chinese names in
Example 2 and Example 3: eight combinations for "Islam" in Example 2
and two combinations for "Ministry of the Interior" in Example 3?

If you do check the variants in Unicode AND display them under Chinese
Unicode systems such as Traditional Chinese Windows 2000, you can
find more similar-looking but easy-confusing SC/TC pairs.

### 3-month late or 30-year's pain?

I've been using Chinese computer systems for about twenty years. In
addition to input-method developers, Chinese software developers,
Internet application developers and IDN-related professionals and officers,
these months people from CDNC have also discussed Unicode and IDN
issues with many Chinese linguists, several of them having experiences in
Chinese/Han encoding for more than twenty years. Except for PunnyCode,
I can say none of them agree with passing current proposed IDN WG's
drafts for CDN hastily. It is just like that ALL Chinese participants in
IETF
IDN WG meetings, who use Chinese systems daily, did not agree with the
proposed IDN solution.

Things go worse due to that it's not easy for experienced native Chinese
users to explain the CDN issues to unfamiliar or inexperienced
Chinese-system users fluently in English. That's part of the reasons that
Unicode Consortium/WG2 needed to form IRG to discuss Han ideographs
and it's more easy for JET members (CJKT) to have concrete discussions
and consensus. Within IDN WG, it's clear that most IDN WG members
are unfamiliar or inexperienced Chinese-system users.  It's said that they
are tired and time-stressed. Although they have tried very hard to solve
IDN issues, however, IETF IDN WG seem to stand like that their solution
is also best to CDN and be trying to pass the proposed IDN solution for
CDN, which does not  have the consensus from CDNC and native
Chinese participants in IDN WG meetings. If IDN is really important to
the developement of Internet, I'm afraid that the process of passing current
IDN standards under the above condition would become a bad case and
symbol in the history of Internet.

To be responsible for world-wide and Chinese Internet societies, hope we
all move carefully and responsibly. That's my two-cent point. Hope we have
peaceful and justicial Internet World.

Happy Chinese New Year

Chun-Hsin Wu

---

From: Ted Hardie <[email-masked]>
Date: Fri, 8 Feb 2002 14:27:37 -0800

Dear Chun-Hsin Wu,
	Thank you for your message and your New Year's greetings.
http://www.iis.sinica.edu.tw/~wuch/idn/examples/mixinput.htm gives a
very visually powerful demonstration of the problem the working group
has debated over these many months, and I have no doubt that is useful
for many members of the working group to see some of the character
mixtures rather than hear them described.  Thank you for your efforts.
	Like others in this forum, I am an "inexperienced"
Chinese-system user (I use an English-language system with two Chinese
language IMEs installed, much like the system James described below).
Even in that context, it has been clear to me, and to many in the
group, that the TC/SC problem and its concomitant issues are very
real.  We do not dispute the problem.
	We are faced, then, with the following situation: after
receiving a great deal of expert advice, the working group has come to
believe that the problem of character equivalence cannot be solved
within the context of this working group.  Based on that belief, we
can do one of two things:

1) stop, and declare that the problem we set out to solve (increasing
the repertoire of available characters) should not be attempted until
the character equivalence problem can be solved.

2) explicitly acknowledge that we have not solved the character
equivalence problem but increase the repertoire of available
characters, allowing others to limit by policy which characters may be
used in specific domains.

	As the chairs and others have repeatedly noted, a solution to
the problem of character equivalence in the context of Unicode and
Unicode's CJK unification is very difficult, and we have no single
entity who is authoritative for Chinese, Japanese, and Korean on whom
to rely.  If we select choice one, we cannot have any firm or
reasonable expectation for the timing of the emergence of a standard.
It would also have to wait for all of the other, similar character
equivalence problems in Unicode to reach resolution.  This means that
the repertoire would remain that of US-ASCII for the foreseeable
future, with all of the drawbacks that implies.

	We have heard significant objections in the last call period
that the work involved in limiting characters by policy will be
onerous and that it will not solve all of the problems of character
equivalence for the Chinese language community.  That is a substantive
objection.  The chairs' response could be expressed as: "given your
objection, can you present a solution for *CJK* character equivalence
*in Unicode* at this time?"  

	Absent a realistic answer to that question, the group seems
likely to adopt some variation of 2) above.  The other choice,
to continue to limit the repertoire to US-ASCII seems untenable.  
That may reflect a bias on the group's part to reach some resolution
to the character repertoire problem, but it also seems like a fairly
reasonable response; given the choice between having eight potential
character groupings for "qingzhenjiao" and zero, it has chosen eight.
If you would prefer zero, with no time horizon for anything better,
than this is the period to make that preference known.

	My apologies to the chairs or the group if I misrepresented
their sense of consensus.
			regards,
				Ted Hardie

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 9 Feb 2002 08:22:09 +0800

1. Lets do away with the personal attack on me. It does nothing to help
your arguments.

2. I acknowledge I am weaker in my daily chinese compared to people in
China/Taiwan, this does not mean I do not know the chinese script and
its orthography. And no, I understand you perfectly well. But I doubt
you understand (or hear) me - See note 6.

3. Have you speak to your IRG and SC2 representives lately and ask them
about this problem? What is their unambigitous response?

4. I stand correct in my statement last mail: You can input either TC or
SC by manually scrolling down the system. Your screen shot represent
nothing. Different IME will give you different predictive result
depending on the frequency of a personal usage of the characters.
Therefore, a screen shot on your computer would be totally different
from mine.

5. You have only repeated problems that we already knows. You have not
demonstrated any solution which is technical possible now. This is not a
3 months or 30yrs plan thing. It is about what is technically feasible
and what is not.

6. Maybe working for another 30yrs time, we might come up with an AI
that can do TC/SC, and for all the other language issues. But it appears
you and your colleague continue to ignore (something we been telling you
again and again):
    1. DNS is an identifier system. We deal with scripts, not languages.
    2. Human language is complex. Expect DNS to deal with language
            is technically impossible right now. (Proof me otherwise).

7. . Since TWNIC is so insistent on the solution, I suggest TWNIC (or
anyone else) put a total ban on all chinese characters in the
registration system. That will also solve your so-called "2^n" problem
in your system. Then continue to work with IRNSS (or some other areas)
for a solution you can accept.

8. Some suggestions: If you want other to consider your issues
favourably, then
    1. present your arguments unbiasly.
    2. consider a broader scope of the problem
    3. understand other people issues and willingness to compromise
    4. learn how the process works in IETF
So far, I have seen all otherwise.

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 9 Feb 2002 09:18:47 +0800

Btw, do you realise that all W2K Traditional IME have a configuration
called "只顯示BIG5字集" (only show BIG5 characters) which will effectly
elimenate all the confusion you mention here in this mail?

Similar options are available for Simplified IME whereby you can select
between GB2312 and GBK.

-James Seng

---

From: "xiang deng" <[email-masked]>
Date: Sat, 9 Feb 2002 09:33:56 +0800

Dear Ted,

Thanks for your comment.
Discussion make issue more clearly.

we are clear:
1. Current IDNA is a good solution.
2. IDNA ONLY will be detrimental to Chinese Internet Community.
3. IDN WG chairs' express: it's out of scope. But decision maker is not 
    family with Chinese character and never use Chinese character in daily life.
4. Chinese Internet community object IDNA ONLY solution.
5. Unicode haven't finish the equivalent set of Chinese character.

from 1. we get:  It's based on all member's hard work.
from 2. we get:  IDNA ONLY is not enough to solve Chinese character issue.
from 3. we get:  If IDN WG chairs don't consider the detriment, Chinese.
Internet Community have responsibility to solve it for Chinese Internet future 
and Chinese users before the detriment become true.
from 4. we get:  IDNA ONLY solution lost the basis to be widely applicated.
from 5. we get:  If Unicode begin this work, it'll refer to "A complete set of Chinese
Simplified Character", so it is a good beginning of next step.

Best regards
Deng xiang

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 9 Feb 2002 09:54:11 +0800

Same old discussion. Response is already in the archive
http://www.imc.org/idn/mail-archive/msg04621.html

-James Seng

----- Original Message -----
From: "xiang deng" <[email-masked]>
To: <[email-masked]>; "Chun-Hsin Wu" <[email-masked]>
Cc: "James Seng/Personal" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, February 09, 2002 9:33 AM
Subject: Re: Inputting mixed SC/TC (Re: [idn] A question...)

---

From: "xiang deng" <[email-masked]>
Date: Sat, 9 Feb 2002 09:55:25 +0800

Hi James,

Maybe you not realize that your following input Chinese string 
is  TC/SC mixed: 
the simplified is "只显示BIG5字集"
<u+53ea u+663e u+793a u+0042 u+0049 u+0047 u+0035 u+5b57 u+96c6>

the traditional is "隻顯示BIG5字集"
<u+96bb u+986f u+793a u+0042 u+0049 u+0047 u+0035 u+5b57 u+96c6>

your input is "只顯示BIG5字集"
<u+53ea u+986f u+793a u+0042 u+0049 u+0047 u+0035 u+5b57 u+96c6>

And, do you mean User will set a cofiguration to forbiden himself to use 
his familiar character? I'm also interested in this cofiguration in MS-IME,
If you can find it.

Regards
Deng xiang 

----- Original Message ----- 

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 9 Feb 2002 10:11:10 +0800

> his familiar character? I'm also interested in this cofiguration in
MS-IME,

Go to Start/Setting/Control Panel/Regional Options/Input Locale

Select your IME, then IME Setting.

-James Seng

---

From: "xiang deng" <[email-masked]>
Date: Sat, 9 Feb 2002 10:10:30 +0800

Chair's responsibily is not to create conflict but to collect all different argument
and coordinate to find a possible solution.

what your reference is not fit your position and duty.

Regards
Deng xiang

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Feb 2002 22:35:33 -0500

--On Saturday, 09 February, 2002 10:10 +0800 xiang deng
<[email-masked]> wrote:

> Chair's responsibily is not to create conflict but to collect
> all different argument and coordinate to find a possible
> solution.

Under normal IETF procedures, which apply to this Working Group
as well, the Chair's responsibility, at this stage in the
process, is to move work along.  That includes, quite
explicitly, 

	* Discouraging the further discussion of topics on which
	the WG has already reached a conclusion.
	
	* Discouraging discussion of problems that are either
	out of the WG's scope, or for which realistic solutions
	(e.g., solutions that deal with all appropriate cases)
	have not been proposed.

James (and Marc) have, if anything, been more tolerant of
extended discussions of topics the WG can't fix, or has already
reached consensus that it won't try to fix, than is normal in
the IETF.

Since I have started on this, I am very concerned about the very
real and serious problems with TC<->SC.  I am also very
concerned about problems with look-alike characters in
alphabetic character sets.  I am also very concerned about the
implications of non-language characters in Unicode that, from my
point of view, don't belong in the DNS (however coded).  

I have raised those issues with the WG, discovered that the WG
isn't interested in the problems, and gone on to worry about
contexts in which those problems _can_ be solved.   That does
not make me worry less, nor does it mean that I think the
problems are unimportant.  But, until and unless I think I have
new arguments or evidence, I don't bring them up again, and I
would _expect_ James or Marc to tell me that I'm out of order if
I did.  I also don't try to convince the WG that those topics
are important by getting many people --who have not been
participating in the WG's work-- to send identical notes
complaining, nor do I circulate notes to other groups in the
hope that they will somehow overrule the WG.  I avoid doing
those things for two reasons: they are considered in very bad
taste in the IETF and they never convince anyone; instead, they
tend to irritate people enough that they stop listening.

What is strange, to me, about this discussion is that there is a
way to delay CDN deployment without impacting Korean or
Japanese.  It is fairly simple, and does not require that the
IDN WG agree. And I had assumed it would be obvious to everyone.
Specifically, the four NICs simply refuse to register such
names.  You try to convince Singapore and other countries with
large Chinese-speaking populations to join them in that
prohibition.  You expand on Erin's document, some of Prof
Tseng's notes, and other comments and examples which have been
introduced here to provide other registries cautions about the
problems they could cause by registering such names.  And you
try to convince ICANN to prohibit those names in gTLDs.   From
the perspective of this WG, that is a policy move, made in
policy forums.  The fact that the WG provides a _mechanism_ for
encoding CDNs does not imply that any registry need _permit_
CDNs.  And it seems to me that, at this late date and given the
overlapping Japanese and Korean issues, that may be your most
efficient way forward on this particular problem.

regards,
     john

---

From: "ben" <[email-masked]>
Date: Sat, 9 Feb 2002 00:59:13 -0500

> efficient way forward on this particular problem.

After reading all the email exchanges lately concerning the TC<->SC
issue, I must admit that this part of John's email is the most
constructive.  It reminds of the Chinese saying:

塞翁失马，焉知非福

Which is literally translated as:
"A man who lost his horse is neither fortune nor misfortune."

or roughly translated to mean:
"What ever will be... will be."

Thanks,
Ben

---

From: "ben" <[email-masked]>
Date: Sat, 9 Feb 2002 09:41:13 -0500

>It reminds of the Chinese saying:
>
> 塞翁失马，焉知非福
>

I got some offline feedback that basically says, "Huhh?  What are you
talking about?"

For most who probably do not care about what I have to say, please
press the delete button now.  For those who do, this is the story I
heard when I was a kid...

Long long time ago lived a very old man in China.  Although he lived
alone with his only grandson, he was not lonely- he was a very well
liked and respected old man.  When he was younger, he was a dedicated
and hard working jockey.  But as he got older, he became too weak to
race horses so he retired to training wild horses instead- perfecting
the art of a horse whisperer.  One day, the fence on his ranch broke
and his horse ran away.  The neighbours heard about it and felt really
bad for him.  They went to his house to console him... but to their
surprise, the old man was not at all sad.  Instead, he said, "This may
be a fortune".  The neighbours were no longer worried about the old
man and went home happy knowing that he can be so optimistic.  Amazing
how fate works... the next day, not only did the horse found his way
home, he brought back a wild but gorgeous companion.  When the
neighbours heard about this good new, they were so happy for him and
went to his house to congratulate him.  However, to their surprise,
the old man was not at all happy.  Instead, he said, "This may be a
mis-fortune".  The neighbours were completely puzzled by the old man's
reaction and went home thinking the poor old man has become senile.
Amazing how fate works... the next day when the old man tried to tame
the new wild horse by having his grandson ride it, the young man fell
off and broke his leg.  When the neighbours heard about the news, they
rushed to his house to see if the young man was okay and to see if he
needed any help.  Again, to their surprise, the old man said, "This
may be a fortune.".  Call it fate... call it coincidence... the next
day, the army drafted all the young men in the village to go to war.
But because the old man's grandson had a broken leg, he was not
drafted and permitted to stay home.  The sad thing was that all the
young men drafted either perished or were seriously injured in the
war.

Thanks,
Ben

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 9 Feb 2002 08:31:52 -0800

At 9:33 AM +0800 2/9/02, xiang deng wrote:
>3. IDN WG chairs' express: it's out of scope.

It is incredibly inappropriate to blame this on WG chairs. There have 
been many, many other people in the WG who have stated the same 
opinion. If you object to this, you can follow the IETF rules for 
appealing. Hint: that does not involve spamming the mailing list.

>  But decision maker is not

Why do you feel that is relevant in a standards body?

>4. Chinese Internet community object IDNA ONLY solution.

The two name registries on this mailing list do not represent the 
Chinese Internet community any more than Verisign represents the US 
community. Many of us know know lots of other Chinese people, and it 
is safe to say that the extreme rudeness and inability to work with 
others is not representative of the Chinese Internet community.

>5. Unicode haven't finish the equivalent set of Chinese character.

More importantly, ISO has not started it either.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Feb 2002 01:54:42 -0000

John C Klensin writes:
> already reached consensus

These claims of consensus are fraudulent. There have always been strong
objections from many regular group participants. We believe that the
current proposals are extremely harmful and should not be deployed. We
are speaking on behalf of a huge number of users.

Even more damning than the number of objections is the superficial way
in which the objections are treated. For example:

   * When we point out in detail how the proposed deployment plan
     creates serious interoperability problems---mail will bounce; web
     pages will fail to load---we're told that users should stop using
     pipes, copy-and-paste, and other program-linking mechanisms.

   * When two hundred users complain about the handling of Chinese,
     they're told that their objections ``don't count,'' and that they
     should learn to type _exactly_ what they see, no matter how painful
     that might be.

   * When I ask why the same principle doesn't apply to the uppercase
     issue, saving implementors a huge amount of case-conversion effort,
     my question is simply ignored.

The idea that objections should be ignored because ``we have to do
something'' is contrary to common sense, contrary to IETF procedures,
and contrary to United States antitrust law.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Feb 2002 19:05:58 -0800

At 01:54 AM 2/10/2002 +0000, D. J. Bernstein wrote:
>These claims of consensus are fraudulent.

Folks,

Dan has a pattern of making this claim, whenever he does not disagrees with 
a working group's decision.  It has become something of a trademark.

So far, he has not believed his own claims enough to follow IETF appeals 
procedures.  Instead he simply keeps making these sorts of claims through 
email.

d/

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

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Feb 2002 05:14:40 -0000

My comments on the level of consensus here are based directly on the
mailing-list discussions, and can easily be verified from the archives.

For example, Marc Blanchet reported the results of a straw poll in May
2001, showing that _fourteen_ group participants disagreed with the IDNA
approach. James Seng stated on 5 June 2001 that he would not ``declare
consensus on IDNA'' over that number of objections. Now he seems to have
decided to ram the proposal down our throats despite all the objections.

Dave Crocker says that my reports of these facts---and the facts
themselves---should be ignored because I've pointed out similar problems
in a few other working groups. He neglects to mention that my statements
in all of these cases are supported by extensive evidence. He also
neglects to mention his own role in those other groups.

For example, http://cr.yp.to/smtp/klensin.html explains many problems in
RFC 2821. It includes detailed historical notes on how our beloved John
Klensin, the document editor, deliberately created one of the problems:

   * Klensin, without WG approval, singlehandedly changed the text;
   * five people objected, and nobody answered the objections;
   * Chris Newman, DRUMS WG chair, issued a ``Call for Consensus'';
   * more people objected, and nobody answered the objections;
   * people at a meeting were overwhelmingly _against_ Klensin's change;
   * the meeting note-taker declared consensus _against_ the change;
   * Klensin issued another draft, leaving his change in place;
   * I objected again, showing exactly how the text had to be fixed;
   * Klensin issued yet another draft, leaving his change in place;
   * Newman sent out a Last Call, ignoring all of the objections;
   * Newman and our beloved Dave Crocker declared consensus.

The web page includes detailed quotes and more than enough references
for readers to verify everything I say from the mailing-list archives.

Klensin and Crocker keep claiming consensus. I keep saying that they're
liars. The difference is that my claims are backed up by the facts. I'm
perfectly willing to provide detailed evidence for everything I say. In
contrast, Klensin and Crocker slither away when they're asked to defend
their claims.

``So far, he has not believed his own claims enough to follow IETF
appeals procedures,'' Crocker writes in his latest message. In fact, I
tried the IETF appeals process many years ago, and found it to be a
sham. As described in http://cr.yp.to/djbdns/namedroppers.html, I tried
the process again more recently, all the way to the ISOC board of
trustees; I again found the process to be a sham.

I recommend that anyone who is hurt financially by IETF file a United
States antitrust lawsuit against the document editors, committee chairs,
IESG members, IAB members, and ISOC members, as well as the companies
they work for. Antitrust law puts stringent requirements on the
procedures used by standards organizations; the IETF procedures don't
even come close to meeting those requirements. See

   http://caselaw.findlaw.com/cgi-bin/getcase.pl?court=US&vol=456&invol=556

for an example where a standards organization ended up paying $4.75
million for failing to impose procedures sufficient to prevent
anticompetitive behavior by a subcommittee chair.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Feb 2002 21:42:12 -0800

At 05:14 AM 2/10/2002 +0000, D. J. Bernstein wrote:
>in a few other working groups.

Thank you Dan.  It always helps to see one's statements distorted so well.

>In fact, I
>sham. As described in http://cr.yp.to/djbdns/namedroppers.html,

Indeed I do stand corrected.  Tough to imagine how this stellar exception 
was missed, though of course Dan's assessment of the results is no 
surprise.  After all, being respectful of contrary opinions and assessments 
is difficult.

>  Antitrust law puts stringent requirements on the
>even come close to meeting those requirements.

And now Dan is trying to practise law.  How quaint.

For reference, folks, documentation of IETF procedures included 
considerable legal review by folks actually qualified in that profession.

d/

ps.  and this is easily the last note from me on this matter, lest Dan be 
permitted to drag things out further.

----------

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 10 Feb 2002 13:56:19 +0800

> decided to ram the proposal down our throats despite all the
objections.

All these are true with a few other fact missing:

1. We did not move IDNA forward in May/June 2001 (Have you check your
   calender lately?)

2. The minutes from SLC have been send to the group and for comments.
   Action items from the SLC include consensus to move IDNA for Last
   Call.

I trim off other information from the mail since it is irrelevant to the
IDN work.

-James Seng

---

From: "D. J. Bernstein" <[email-masked]>
Date: 10 Feb 2002 06:59:42 -0000

James Seng/Personal writes:
> 1. We did not move IDNA forward in May/June 2001

What exactly has changed since then? You've been tweaking details. We
were objecting to fundamental flaws in the IDNA design. Those flaws are
still present in the current IDNA design. We continue to object to them.

>    Action items from the SLC include consensus to move IDNA for Last

The working group is _not_ the same as the set of people who show up at
an IETF meeting. See RFC 2418, section 3.2:

   Electronic mail permits the widest participation ... The WG must
   ensure that its process does not serve to exclude contribution by
   email-only participants ... Internet email discussion is possible for
   a much wider base of interested persons than is attendance at IETF
   meetings, due to the time and expense required to attend.

I accuse you of bias in your procedures for evaluating consensus. You
select procedures on the fly to support your position:

   * You run straw polls that you think will support IDNA, and you
     refuse to run other straw polls.

   * You say ``A louder voice does not make anyone more important than
     others'' when several of us put a great deal of time into
     explaining the flaws in your proposals in detail.

   * You say ``This is not an election'' when more than _two hundred_
     people state that they object to your proposals.

What's consistent is that you're discounting the views of people who
disagree with you. I call upon you to resign and find someone neutral to
serve as chair.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Feb 2002 23:22:05 -0800

(sorry.  meant to post no further notes on this, but Dan has decided to 
attack James.)

At 06:59 AM 2/10/2002 +0000, D. J. Bernstein wrote:
>What exactly has changed since then?

Repeated public discussion and review, and repeated IETF management review.

>an IETF meeting.

And since no one has claimed otherwise, raising this point is not terribly 
relevant.

>I accuse you of bias in your procedures for evaluating consensus.

Well, yes, James has shown a major flaw in his management, although not the 
one Dan cites.  James and Marc have allowed far, far too much distraction 
and protraction, such as tolerating the sort of silliness that Dan is raising.

The real consensus was developed long ago.  However James and Marc desired 
to provide extra time to seek consensus with those unhappy at the dominant 
view.  Alas, all that has ensued from that kind effort has been to give 
this vocal minority more of a sense of credibility than they warrant.

>  You select procedures on the fly to support your position:

Dan has, as usual, asserted actions as personal when they were in fact 
subject to broad review, assistance, and agreement.  Dan does not want to 
acknowledge this clear fact, of course.

(And, by the way, variable consensus-assessment procedures are standard 
fare for the IETF.  They work well.  It's even in the formal rules, though 
Dan's selective citation effort managed to miss this point.)

>disagree with you.

Dan needs to stop accusing others of his own faults.

d/

----------

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 10 Feb 2002 22:36:39 +0800

I am not responding to this mail because it will only divert into
another series of discussions on your opinion of IDNA, which the group
(and the chairs) have heard before and already noted.

I stand by my action. Lets other be the judge.

-James Seng

---

From: "Chun-Hsin Wu" <[email-masked]>
Date: Tue, 12 Feb 2002 05:26:23 +0800

From "James Seng/Personal" <[email-masked]>
> 1. Lets do away with the personal attack on me. It does nothing to help
Agree. I'm not interested in personal attack.
 
> you understand (or hear) me - See note 6.
I'd like to learn more experiences from you. :-)

> about this problem? What is their unambigitous response?

There are differences among name conversion, unicode conversion and
DNS identifier conversion.

> Therefore, a screen shot on your computer would be totally different

At least the IMEs used in my last examples do not depend on the
frequency of personal usage. If you do try these examples, you should
be able to see the same screent shot as mine.
This is one of the design points for IME. Other IMEs may depend on
personal usage, but the demonstrated IMEs don't.

> 3 months or 30yrs plan thing. It is about what is technically feasible
Hope IDN friends do really understand the problems.

>             is technically impossible right now. (Proof me otherwise).

I think IDN is also complex. :P
Hopefully, we don't expect language-level conversion or complete
Unicode conversion, what we need is identifier-level conversion,
for identifying domain name rather than solve all the conversion issues
in Unicode or human-space.

> for a solution you can accept.
Is it a personal or organizationall attack?
I'm a researcher and I do not stand for TWNIC.
I expect a global unique IDN, not a fragmented DNS nor Internet world.

> So far, I have seen all otherwise.

Personal attacks again?  :P

Chun-Hsin Wu

---

From: "xiang deng" <[email-masked]>
Date: Tue, 19 Feb 2002 11:08:24 +0800

Internet Users in China: 
  Totally 33,700,000. Among them, 6,720,000 use leased line connections, 
21,330,000 are dial-up users and 5,650,000 use both. 

The online survey had received 75,383 responses, among which 64,627 responses were valid. For the sampling survey, we carried on telephone interviews by using the sampling survey method, and 53,797 samples are available (under the confidence coefficient of 95%, the absolute error of the provincial result is less than 3%) .

Regards.
Deng xiang 

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>