Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 03 Feb 2002 21:35:29 -0500

There'a a good discussion of the security risks of the code point
problem at http://www.csl.sri.com/users/neumann/insiderisks.html#140

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Feb 2002 07:40:52 -0800

Steve,

>problem at http://www.csl.sri.com/users/neumann/insiderisks.html#140

homographic attacks are not new with the IDN effort.

for example, MICROS0FT.COM was done.

For that matter, choice of different top-level domains permits a degree of 
homographic attack.  Try looking at dnso.com, rather than dnso.org.  (No, 
this approach does not qualify precisely as homographic, but it takes 
advantage of a small difference from the real name, hoping that users will 
not notice.  And it does work.)

Hence, the IDN work does not introduce a new risk.

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: Mon, 04 Feb 2002 11:01:15 -0500

Dave,

I agree that there is no new risk here.  The question is whether
or not it is desirable to expand that risk, perhaps into
populations that are less sensitive to it because they would,
naturally, be more trusting of texts that appear to be written
in their own languages (after not having seen those before).
And the answer to that question, I believe, must involve
weighing the tradeoffs between the value of the expanded name
space and the costs of the expanded risk.  Believing that
question/ tradeoff is easy or obvious, is, I believe, naive,
regardless of the conclusion on reaches about the question
itself.

And I would hope that relevant documents coming out of the WG
would explicitly alert people to these risks.

    john

--On Monday, 04 February, 2002 07:40 -0800 Dave Crocker
<[email-masked]> wrote:

>> There'a a good discussion of the security risks of the code
>> point problem at
>> http://www.csl.sri.com/users/neumann/insiderisks.html#140
> 
> For that matter, choice of different top-level domains permits
> a degree of homographic attack.  Try looking at dnso.com,
> rather than dnso.org.  (No, this approach does not qualify
> precisely as homographic, but it takes advantage of a small
> difference from the real name, hoping that users will not
> notice.  And it does work.)
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Feb 2002 08:13:48 -0800

At 11:01 AM 2/4/2002 -0500, John C Klensin wrote:
>   The question is whether

The questions are really whether

         a) we are going to expand the scope of the working group beyond 
what is required to solve the actual requirement of the working group, and

         b) whether the IETF is now going to claim parental concerns for 
people's behaviors, protecting them from their deficiencies -- while 
remembering that we are exceeding poor at that task.

>space and the costs of the expanded risk.

Claims about the costs are based on behavioral assumptions that have no 
empirical basis.  Existence proofs, yes.  Proof of widespread danger, no.

>would explicitly alert people to these risks.

Adding language about implications of errors is typically a Good Thing, as 
long as a) the language is readily produced, and b) there is not so much of 
it that it gets in the way of the technical specification.

d/

----------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Feb 2002 17:24:14 -0000

> for example, MICROS0FT.COM was done.

I can see the difference between O and 0, even without a slash through
the 0; the O is more square. I bet you can see the difference too.

In contrast, a properly printed uppercase B is identical to a properly
printed uppercase Beta. A font designer would have to be illiterate to
distinguish them.

Some people say that the B-B problem is inherent in internationalized
domain names. That's simply not true. We can

   * declare that uppercase letters are obsolete, although software will
     still have to accept uppercase ASCII for compatibility, and

   * allow selected characters that don't cause visual confusion, such
     as lowercase beta.

Yes, people will be prohibited from using other characters. Yes, we will
have to be very careful. Yes, we will have to review each character
individually, paying attention to what we're actually doing. This is the
price of doing the job right.

A similarly careful approach will also let us move directly to UTF-8
instead of this special-purpose-character-set insanity. Yes, sendmail
corrupts bytes 128 through 159, but it doesn't corrupt lowercase beta.

---Dan

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 4 Feb 2002 13:32:43 -0800

The message from CDNC says that the Traditional-Simplified problem 
for Chinese users cannot be solved by registration policy. This is 
not true, and many of the CDNC members who have come to IETF meetings 
know that. Of course, CDNC members would like to maximize their 
financial gain in registration, but the concern of the IETF is always 
towards helping users. There is a huge different between "cannot be 
solved" and "it will cost a small number of organizations a lot of 
money".

Solving the Traditional-Simplified problem in the IDN protocol would 
have given more uniform results for users. The intense discussions 
over the past 18 months have shown that not only is it unlikely that 
there will ever be an IETF-based solution, and it has also become 
clear that a registration-based solution will likely give Chinese 
users more sensible naming that anything than the IETF could 
standardize. For example, in the IDN WG, the proposals from CDNC 
members only addressed part of the Traditional-Simplified problem 
(the 1:1 mapping), while the registration solution can address all of 
the problem in a manner that will help Chinese users.

Due to the efforts of some CDNC members, the IETF is now well aware 
of the "2^n" variant problem that is unique to the use of Han 
characters in the Chinese language. Fortunately, using registration 
guidelines will solve the problem. The only people seriously affected 
by the size of DNS zones created by the "2^n" problem will be very 
large, flat zones such as those managed by CDNC members, but they are 
able to compensate for the size of zones with no changes to the DNS 
protocols.

Of course, the character variant problem exists in many different 
languages, not just in Chinese. Because of this, each registry or 
zone that includes IDN names needs to make decisions about name 
equivalence (and therefore multiple registrations) before they enter 
any IDN names into their zone. Based on this input during Working 
Group last call from the CDNC, it seems clear that we need to explain 
these points more in the IDNA document.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Feb 2002 14:00:55 -0800

At 01:32 PM 2/4/2002 -0800, Paul Hoffman / IMC wrote:
>languages, not just in Chinese. Because of this, each registry or zone 
>that includes IDN names needs to make decisions about name equivalence 
>(and therefore multiple registrations) before they enter any IDN names 
>into their zone. Based on this input during Working Group last call from 
>the CDNC, it seems clear that we need to explain these points more in the 
>IDNA document.

This approach has some major benefits.

1.  It acknowledges the basic issue.

2.  It moves the handling of the issue to a venue better able to resolve it.

3.  It avoid major complexities being added to the IDN/DNS protocol.

d/

----------

---

From: "xiang deng" <[email-masked]>
Date: Tue, 5 Feb 2002 10:40:46 +0800

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

> solved" and "it will cost a small number of organizations a lot of 

If you want talk about financial problem, let me correct it:
TC/SC solution(or registration solution ) will save user's money and cost registrar's money
DON'T do TC/SC will cost user's money and make money for registrar.
So what your comment is distorting fact.

And, Please give me a successiveful example of such registration solution.

> guidelines will solve the problem. 

Who will follow this registration guideline? All administrators?

Regards. 
Deng xiang

---

From: Dave Crocker <[email-masked]>
Date: Mon, 04 Feb 2002 09:30:46 -0800

>the 0; the O is more square. I bet you can see the difference too.

You are relying on a) particular font representation differences on your
screen, and b) user perceptual skills that are not always present.

In point of fact, this "attack" has been performed, presumably with some
success.  The fact that it has some technical differences from the
current
source of worry is a minor point.

The real point is that we have moved from technical specification into
analysis of human behavior and the IETF is exceedingly bad at this
latter
activity, particularly with respect to predictions of the future for
problems that are not already significant.

>printed uppercase Beta.

Sorry, no.  'B' and 'beta' are quite different.  The difference is quite
clear on my screen.  (or, rather, it is as clear as 0 and O.

d/

----------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Feb 2002 07:12:13 -0000

Dave Crocker writes:
> we have moved from technical specification into analysis of human behavior

Wake up, Dave: Human behavior is a central issue. The whole point of
IDNs is to improve the user interface. IDNs are supposed to allow
_humans_ to see non-ASCII glyphs in domain names.

You say that the IETF is exceedingly bad at this. No argument there.

> In point of fact, this "attack" has been performed, presumably with
> some success.

You admit that some users have been fooled by domain names with similar
appearance, yet you continue to advocate that we allow domain names with
_identical_ appearance, names that can't be visually distinguished even
by the most careful reader. Wow.

---Dan

---

From: hoho <[email-masked]>
Date: Sat, 09 Feb 2002 11:17:46 +0800

Dear Paul,

Paul Hoffman / IMC wrote：

> know that.

Interesting question. As we could also noticed,  functions of nameprep,
mapping,
prohibit, and normalization can all be performed by registration policy.
So, what's
the point of asking this question?

Anyway, from our point of view, nameprep mechanism helps to make sure
that all
international registries  follow a global set of rules and it becomes the
core set of
registration policy.

Since the WG insists on a client solution based on Unicode, without on
such technical
solution, we have no way to depend on the courtesy of internationalized
companies
to make registration policies being friendly to language communities
including Chinese
who will be most seriously damaged by the decision of the WG. It would be
a pity
if we could not prevent greedy business from dumping defective domain
name products
into Chinese community. We definitely are positive for your efforts in
bring up a solution
that solves DN problem for many languages. But, please do not force the
Chinese
community to be the victim of the side-effect.

> Of course, CDNC members would like to maximize their

This is also interesting. As far as I know, TWNIC has their social
responsibily
in our country. There major concern for TWNIC to work with IDN WG is
consumer
protection. The reason why they work on TC/SC, is that we all aware the
lack
of an international standard on Han variants which we could use to
convince the
WG to pay attention. Thus TC/SC becomes the best hope because it's
something
exists for more than 50 years. If the working group could adopt it, then
at least this is
something for all registries to restrict their name space a little bit
and not too make
too much trouble to Chinese community. It's a very humble wish, but
unfortunately, was
rejected by the WG. On the other hand, I can assure you that there is no
way for TWNIC
to make a registration policy without taking the maximum set of Han
variants into account.
As a non-profit organization, consumer protection is beyond the goal of
making a big
profit. Furthermore, dometistic consumer protection groups will not allow
that to
happen either.

I am going back to my family in another city for Chinese New Year now.
I'll respond to
the rest of your questions as soon as possible.

By the way, I have trouble sending a message with a long list of
recipients. Could you
cut your list shorter please? I guess most people on your list is already
on IDN list.
Thanks,

-- Janming Ho, PhD
Deputy Director
Institute of Information Science
Academia Sinica

---

From: YangWoo Ko <[email-masked]>
Date: Sat, 9 Feb 2002 13:05:32 +0900

[I removed most of personal e-mail addresses to make header short.]

On Sat, Feb 09, 2002 at 11:17:46AM +0800, hoho wrote:
> mapping, prohibit, and normalization can all be performed by registration 
> policy. So, what's the point of asking this question?

Dear Paul Hoffman, Janming Ho and others,

Yes. All NAMEPREP things can be handled by registration policy. Even, it
seems easier and more flexible to coordinate registration policies among
registries than just waiting for major software vendors to implement both
NAMEPREP and all localization improvements. If we took future upgrades of
Unicode and their impacts to implementation, I would rather forget whole
NAMEPREP.

For example, in Korea, we are almost finalizing a RFC-KR (RFC for .kr) 
which restricts scope of code points used in hostnames to get around 
inadequacy of current NFKC for Hangeul. I know this method is of no help
for TC/SC issue.

What I am trying to tell is we should consider again "why we began to
come up with NAMEPREP". If current version of NAMEPREP could not satisfy
its goal "in order to increase the likelihood that name input and name 
comparison work in ways that make sense for typical users throughout the 
world" (quote from NAMEPREP-06), this document could not go beyond WG
last call.

Happy New Lunar Calendar Year !

-- 
/*------------------------------------------------
YangWoo Ko : [email-masked]
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/

---

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

>to make registration policies being friendly to language communities

Correct.

>who will be most seriously damaged by the decision of the WG.

You have never given any justification for that assumption. In fact, 
later in your message you show that there are solutions to the 
problem.

>  It would be
>into Chinese community.

Then you should work to prevent it for your community. The IETF has 
absolutely no control over the products that use the standards we 
produce. Everyone knows that.

>  We definitely are positive for your efforts in
>bring up a solution

The IETF could not force such a thing, and obviously does not want to do so.

>WG to pay attention.

That work, which was done by CNNIC starting a year ago, was 
successful. The WG now understands the scope of the problem. We also 
understand what it would take to solve the problem in the IDN 
standards or in a registration solution. (I don't consider the spam 
and technically misleading messages that TWNIC has been sending for 
the last two weeks to be constructive work on TC/SC.)

>  Thus TC/SC becomes the best hope because it's
>something
>too much trouble to Chinese community.

We fully agree here. However, in order for the WG to adopt it, we 
need an Internet Draft that contains a protocol that can be used in 
the IETF. So far, no such Internet Draft has appeared, even after 
lots of strong efforts of CNNIC. Further, in recent private 
conversations, TWNIC has told people in the IETF that they don't 
believe such a draft is possible. So you are asking the WG to adopt 
something that you believe it cannot.

>  It's a very humble wish, but
>unfortunately, was

It is good to hear you finally admit that this is possible! Note that 
the declaration that started this thread said it was not possible. 
Such a registration policy will indeed help the people of Taiwan and 
the rest of China.

>profit. Furthermore, dometistic consumer protection groups will not allow

Then it is your responsibility to show them how to prevent the problem.

>the rest of your questions as soon as possible.

Please enjoy the holiday; many of us here will be doing the same.

>cut your list shorter please? I guess most people on your list is already

Um, that long list was started by TWNIC. Most of us are quite happy 
to have the list shorter.

--Paul Hoffman, Director

---

From: [email-masked] <[email-masked]>
Date: Sun, 10 Feb 2002 02:23:10 +0800

Dear Paul Hoffman:
               You have release many messages ,  talking some people from
TWNIC in SLT or in private mail with you  that one always agree your point
like such as:
               1. make more money from registration
               2. it is impossible to solve TC/SC
               3. registration policy can solve all ...
               etc....
Can you specify more clearly ? we all like to know what is the reference ?
              In these discussion of  TC/SC , case mapping , normalization
of character set , prohibition . these  are all related to your draft and
you never response what is wrong or what can be improved to solve the TC/SC
problems.

----- Original Message -----
From: "Paul Hoffman / IMC" <[email-masked]
> Further, in recent private
        These draft are present in TSCONV . Are you have eye in it ?
We , all come from Taiwan  like to know these message or people that you
referenced.

> Such a registration policy will indeed help the people of Taiwan and
       To solve TC/SC only rely on registration is impossible to solve
problems of delegation and scalabilty .
You just to play the word tricky to fool others .

L.M.Tseng

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sat, 9 Feb 2002 11:47:37 -0800

>Can you specify more clearly ? we all like to know what is the reference ?

Sure. The "reference" is personal conversations that folks from CDNC 
had with other people active in the IDN WG during the Salt Lake City 
meeting. Many people met with CDNC members in Salt Lake City, and 
many of us heard similar statements in our discussions.

>                1. make more money from registration

People from both CNNIC and TWNIC have said "we cannot do a 2^n 
registration solution because we need to charge end users for each 
name in the zone". Of course, you do not need to charge per name: you 
can charge per group of names that come from a single base name. But 
the fact that this argument still comes up leads one to think that 
maybe you want to charge per name even though doing that will hurt 
the Chinese people.

>                2. it is impossible to solve TC/SC

I never said that; I have said the opposite many times. What I said 
was that it is impossible to get the solutions proposed in the tsconv 
Internet Drafts approved by the IETF because of their obvious 
technical and political flaws, all of which have been openly 
discussed in the WG. During meetings in Salt Lake City, CDNC members 
agreed with this and said that they would pursue a good 
Traditional-Simplified solution outside the confines of the IETF.

>                3. registration policy can solve all ...

No one has ever said that "registration policy can solve all ...". 
What has been said, and agreed to by TWNIC people, is that in the 
absence of Traditional-Simplifed mapping in IDN, registration policy 
can serve end users. It will not be consistent, so it will not serve 
them as well as it would if we could have put it into IDN. Of course, 
doing T-S registration can serve users better than anything that ever 
appeared in the tsconv drafts because it will not be limited to 1:1 
mapping, and it will allow mapping that comes from humans instead of 
limited tables.

--Paul Hoffman, Director

---

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

>Can you specify more clearly ? we all like to know what is the reference ?

1.      There have been many postings, from many people, about these 
points.  There is no need to respond to this query because

                 a) these issues have nothing to do with him in particular, and

                 b) the explanations have been posted many times.

         Anyone who wishes to learn those details is encouraged to review 
the working group archive.

2.      I also must note some concern over the style of criticisms being 
lodged against the some participants in the working group.

         I have always been taught that Asians have a much better 
appreciation for personal politeness than do Americans.  And my direct 
experience has almost always matched that.  In this forum, however, there 
has been a large number of vigorous, ad hominem attacks coming from some 
Asian participants.  Perhaps there are subtleties to the cultural norms 
that I am missing, but public abuse of people is not acceptable in the IETF 
even from us crude Americans.

         Those engaging in personal attacks damage themselves and their 
point of view.

         Further pursuit of ad hominem criticisms is worthy of 
banishment.  We need to ignore postings from people who make these issues 
personal.

3.      We are also seeing challenges to IETF working group process that 
demonstrate a clear lack of understanding of working group management 
requirements and IETF process rules.

         We need to simply refer posters who demonstrate such failings to 
the considerable IETF documentation on these matters, rather than try to 
educate them online.  Such efforts participate in a denial of service 
attack on the working group.

d/

----------

---

From: [email-masked] <[email-masked]>
Date: Sun, 10 Feb 2002 05:53:40 +0800

Dear  Paul  Hoffman:

> name in the zone".
          Are  you sure you do not make any mistake in these statements ?
In  SLT , I  have heard from Director . Mao
talk to John Klensin , making more money is not the goal of CNNIC , so he
can accept the delay of CJK deployment to protect  all  CJK  users.  CEO of
TWNIC Prof. W.S. Chen is not in SLT ,  I can make sure it is also the same
answer as CNNIC .
> Of course, you do not need to charge per name: you

> Traditional-Simplified solution outside the confines of the IETF.
                  Sorry , I do not see discussions of TC/SC related to
technique of  Validation , HSE , Multi-Case ACE in here . I  am also in SLT
, why  I  have not  this  solution ?  We hope this WG  temporarily delay the
CJK deployment by code point inhibition to let CJK area can get a TC/SC
solution if  this WG is so hurry to pass all,  because it is incomplete and
irreversible  for  user to  register CJK  name.

> mapping, and it will allow mapping that comes from humans instead of
               I  think people from TWNIC recognizes that to solve TC/SC
problems , it  need  multiple stage/level to cooperate . 1-1 mapping  table
are proposed in the draft that can be applied in the mapping after  nameprep
and before Puny code encoding. 1-n mapping need more time to discuss and
select one of  them  as 1-1 mapping or no any mapping , if   no-mapping is
assigned by language expert , the registration approach can help to register
all of them or select few of them by register.
              All the argument in here is " 1-1 mapping should be doing in
which level ?"  1. inside IDNA  2. Outside-IDNA: a client local module or
level-2 server  like  IRNSS and what is the connection interface between
this module with IDNA, 3. Registration policy .

L.M.Tseng

---

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

At 05:53 AM 2/10/2002 +0800, 
=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= wrote:
>talk to John Klensin , making more money is not the goal of CNNIC ,

In fact, this issue is not relevant to the technical efforts of the working 
group.  Hence it does not need to be discussed further.

>, why  I  have not  this  solution ?  We hope this WG  temporarily delay

Indeed, it has been quite clear that there is a desire by some to delay 
this working group, including through efforts to request continued 
consideration of topics that a) have been thoroughly considered over the 
last few years, or b) are outside the immediate scope of effort of the 
working group.

>problems

Indeed there is quite a bit of support for the efforts to solve this 
challenging and important problem.  However that support does not include 
further delay for the IDN effort.

d/

----------

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 10 Feb 2002 08:59:14 +0800

Prof Tseng,

We are rethrashing issues which have been discussed and concluded.

So please, lets stop this thread, or at least bring it offline. There
are more important things to discuss at the moment, like completing the
last call.

The last call _will_ conclude on 11th feb. Time are better spend with
substainted points references to the last call drafts then to bring up
yet-another-proposal.

ps: A man whom I admired a lot, for his writing, his personality and
view of life once wrote these famous words: "Violence is the last resort
of the incompetent".

-James Seng

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: <[email-masked]>; "Paul Hoffman / IMC" <[email-masked]>
Sent: Sunday, February 10, 2002 5:53 AM
Subject: Re: [idn] Chinese Domain Name Consortium (CDNC) Declaration

> > >Can you specify more clearly ? we all like to know what is the
reference
> ?

---

From: hoho <[email-masked]>
Date: Mon, 11 Feb 2002 01:45:28 +0800

Paul Hoffman / IMC 寫入：

> have given more uniform results for users.

Agree. For example, LDH naming constraints are also built into the
DNS instead of registration policies which might vary from registry to
registry.

> The intense discussions
> standardize.

A written document presenting detailed ideas would be helpful for
further discussions. I appreciate it if you could give a pointer to
one such document.

But, I am not sure whether you're referring to a global registration
policy of equivalent names based on Han characters, or various
inconsistent registration policies  among all the registries including
TLD, SLD, etc.?

A hybrid approach combining both IDN protocol and registration
policy is indeed an effective approach for the Chinese domain name
problem. Without implementing basic equivalence matching function
in IDN protocol, I am not sure if  registration policy along would make
sense.

Chinese  domain names service is not only provided by CNNIC,
KRNIC, JPNIC, and TWNIC, but is also provided by other ccTLD and
gTLD. Second level domain name holders can also develop their cDN
registry business by selling the third level names to other parties.
Thus,
it is essential to build a standard Han variant table into the IDN
protocol
so that users are guaranteed to receive consistent resolution of Chinese
domain names independent of the many registries. We also believe that
the developing IRNSS protocol will add more equivalence matching
capabilities to Chinese domain names, especially for those with context
sensitive variants or language-specific variants.

We believe that with international collaboration, there is an opportunity

to develop a more reasonable domain name technology. Please do not
rush into a standard to allow registries to dump premature products
into Chinese Internet community.

> For example, in the IDN WG, the proposals from CDNC

I understand that the 1:1 mapping table does not solve all the problems.
But, I am not sure if, "the" registration solution had ever been
proposed,
and it's going to solve all the problems.

> able to compensate for the size of zones with no changes to the DNS

There is obviously serious scalability problem associated with this
large,
flat zone solution. Though it seems to work fine for the time being. But,

its management is complicated. Furthermore, with various dictionaries
of Han variants,  registries may choose to adopt different policy of name

equivalence.  Consistent resolution of domain names is thus hard to
maintain among the registries unless character variant equivalence
matching is part of the IDN protocol.

Without supports in IDN protocol, do you have a feasible solution to
mandate a consistent registration policy on Han characters among all
registries interested in commercializing Chinese domain names, including
TLD, SLD, etc?

> any IDN names into their zone.

If you mean to say that each registry may decide its own name
equivalence, then you are wrong. Language is international and thus
name equivalence MUST be consistent among all registries.

> Based on this input during Working

No, explanations are not good enough. The IDN protocol has serious
roblems in dealing with Han ideograph. We need to pay more attention
on those problems.

---

From: hoho <[email-masked]>
Date: Mon, 11 Feb 2002 04:29:01 +0800

Paul Hoffman / IMC 寫入：

> >we have no way to depend on the courtesy of internationalized
> >companies

> later in your message you show that there are solutions to the

No! This is misleading. Please refer to later part of this message.

> produce. Everyone knows that.

I have to reiterate, this situation comes from IDN protocol because it
adopts Unicode. Because the IDN protocol does not have the capability
to handle character model of Han characters in a proper way as it does
for some other languages, thus it is an incomplete solution. The
negative
side-effects on Chinese Internet community comes from this
incompleteness.

> The IETF could not force such a thing, and obviously does not want to do so.

Are you saying that IETF does not care if a WG is providing an
incomplete 
solution to the Internet community?

> >of an international standard on Han variants which we could use to

You didn't answer the question. Who do you call in specific is trying to
maximize their financial gain? What is your evidence before making
these interesting comments?

> the last two weeks to be constructive work on TC/SC.)

Those messages are not sent by TWNIC.  James replied to each of
the protest emails to confirm the existence and willingness of the
senders,
didn't he? Do not accuse people for something they did not do. Do you
intend to mislead the WG to wrong conclusions? I believe this is a
mistake.

> something that you believe it cannot.

But, isn't it one of the functions of stringprep? So, it sounds like you
are admitting that stringprep is incomplete?

> --Internet Mail Consortium

Jan-Ming Ho, PhD
Research Fellow and Deputy Director
Institute of Information Science
Academia Sinica

---

From: "Jonathan Rosenne" <[email-masked]>
Date: Sun, 10 Feb 2002 23:41:05 +0200

I think it would be inadvisable to proceed against strong opposition of
Chinese experts. 

I'm not sure I understand what it is all about, and whether it is
justified or not, but it would be better if it could be resolved in an
amicable manner.

Jony

---

From: Dave Crocker <[email-masked]>
Date: Sun, 10 Feb 2002 14:12:21 -0800

>justified or not, but it would be better if it could be resolved in an

indeed it is always nice to be able to resolve things, especially amicably.

however before you call for delaying an effort that is already a couple of 
years late, perhaps you will consider becoming familiar with the issues and 
history.

d/

----------

---

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

> many of us heard similar statements in our discussions.

I'm from CNNIC and Mainland of China, as a technical member of CDNC,
I also interested in YOUR reference of CDNC.

> maybe you want to charge per name even though doing that will hurt 

Funny! If you want stigmatize others, don't use the word "Maybe".
 
Deng xiang