Subject: [idn] Re: [JET-member 443] Re: Fw: Re: new members invitation

From: [email-masked] <[email-masked]>
Date: Sun, 28 Oct 2001 20:42:27 +0800

> > TC/SC tables are just less than 10K, while NFKC/Legacy/Font
> requirements
> > is much higher. implementation complexity is for engineers.
> > but, deployment costs are transferred to innocent end users.
>
> I am not going to argue for or against TC/SC here. I am stuck in the
> middle myself, torn between been a Chinese and been a co-chair for IDN.
>
> But the arguments for inclusive of TC/SC or not should be done on a pure
> technical evaluation basis in IETF. Economy arguments as above is not a
> factor for consideration.
>
> This is why it is known as engineering trade off, not economy trade off.
>
> -James Seng
>
James:
             Let us to know what is pure technical evaluation basis in your
mind as you are a co-chair in an IETF working group.
             If an Engineering Requirement is not related to the user's cost
and what are user need that must be a very interest projects.  I think many
members in IDN WG of IETF also like to know the detail .  You give me a very
strange impression of IETF.  Can someone in IETF can help more ?

L.M.Tseng

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 28 Oct 2001 23:25:07 +0800

Prof Tseng,

I do not see what so strange about my comment. IETF is an engineering
group so we deal with technical issues. Political, economy and business
issues are really out not our concern.

But cc: IDN WG at this moment without relevant discussion which taken
place in JET mailing list is confusing to other so let me pull a piece
of our discussion:

Deng Xiang comment that TC-SC that:

"Because IDN should be global protocol and will force all Chinese users
to register all form TC/SC domain  name and pay unlimited money and face
unlimited domain name disputation. Do you still think it's the local
issue?

Yes. all over the world. If you want earn money from Chinese people."

I responded that

"While I sympathis with this argument, unfortunately, IETF usually do
not consider non-technical issues relevant. This is considered Layer 9
aka "political" issues from IETF perspective." (Lee then corrected me
that this is a "economy" issues, not "political")

and also

"We dont ask how much CNNIC charges per name, nor we care what Verisign
charges to their registrar. neither do we can how much Entrust or
Baltimore charges per certificate nor do we regulate how much hosting
companies going to charge to their customer.

None of these cost is a concern to IETF. We leave these to market force
to play it. That is the nature of the free-market forces."

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 28 Oct 2001 10:55:56 -0500

James,

Substitute "cost" (or "economy") for "scale".

As Deng pointed out some _weeks_ ago, the buy-to-exhaustion "solution" to
the SC/TC issue DOESN'T SCALE. The same holds for any contention mechanism,
aka a "DRP". Even when both are "free".

Remember scaling?

Cheers,
Eric

---

From: [email-masked] <[email-masked]>
Date: Sun, 28 Oct 2001 23:55:35 +0800

Dear James:
                    I just have the question: In what condition , an
Enginnering problems is never related to cost , especially a protocol that
so many user will be used .
                    Many draft are discussed and comparing with the  the
cost and time of depolyment .  And that is the first time , I can not
understand the requirements are unrelated to users who will use the results
of them.
                    I  must be learn more , I need some help to let me
understand IETF more.

L.M.Tseng

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 01:04:05 +0800

> Anyway, this is an overflow discussion from JET. If we wish to take

s/take/talk/

> about "scale" problem, lets wait for the draft which JET is preparing

s/JET/some of the JET members/

> first then others can participate the discussion in a more
constructive
> manner.

Sorry, need sleep now.

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 01:00:04 +0800

I agree with you - "scale" is an engineering consideration.
But "cost" (economy), OTOH, is not.

Anyway, this is an overflow discussion from JET. If we wish to take
about "scale" problem, lets wait for the draft which JET is preparing
first then others can participate the discussion in a more constructive
manner.

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, October 28, 2001 11:55 PM
Subject: Re: [idn] Re: [JET-member 446] Re: Fw: Re: new members
invitation

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 28 Oct 2001 09:00:43 -0800

At 8:42 PM +0800 10/28/01, 
=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= wrote:
>and what are user need that must be a very interest projects.

There is no inherent cost to multiple registrations. All registration 
cost is assigned by the registry (and, in some models, by the 
registry's agents, the registrars). A registry can have a policy that 
"if many names have identical meanings, all those names are 
registered for the same fee as a single name". It is up to the 
registry to decide what "identical" and "meanings" is, of course. For 
every language, there are different guidelines for those two words; 
it would be good to have some common advice on various languages.

>   I think many
>members in IDN WG of IETF also like to know the detail .

Yes, exactly. This discussion has elicited a lot of detail that was 
unknown to many people before now.

>   You give me a very

If you listen to just one person's description of the IETF, you are 
sure to get a skewed picture. If you listen to many peoples' 
descriptions, you can weight and combine them yourself. The IETF is 
an extremely open organization. The mailing lists of all the WGs are 
freely available. And everyone has an email address at which you can 
contact them. :-)

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 28 Oct 2001 15:05:48 -0500

James,

> But "cost" (economy), OTOH, is not.

Assume that "registration" of a "name" containing characters in the SC and/or
TC character sets with the .FROTZ TLD registry is "free". No VISA card, no
wire transfer, postal coupons or micro-payments. Free. Like .US.

Assume also that "dispute resolution" of a "name" containing characters in
the SC and/or TC character sets under the Dispute Resolution Policy (DRP)
of the .FROTZ TLD registry is "free". No VISA card, no wire transfer, postal
coupons or micro-payments. Free. Also like .US, at least in theory.

Now that everything in the problem space is zero "cost", and "buy" means
only perform whatever non-cash ritual is required by the the .FROTZ registry
system (registrars don't charge money either), and "defend" in the .FROTZ DRP
means only perform whatever non-cash ritual is required by the .FROTZ registry
system (mediators and lawyers don't charge money either), and the non-cash
ritual is simply to read and write modest bits of email without the use of
any autonoma other than a comodity MUA ...

For a 10 character "name", assuming only 1-to-1 equivalences for all 10 of
the characters, 2^^10 items of email are required to "register" the name.
Another 2^^10 items to "defend" the name. That's about the total volume of
email on the IDN list this year (between 1K and 2K seperate mailings, but
I'm _not_ counting -- the point is tedium, saturation even boredom). Even
if there is no "cost" associated with any action, the take-to-exhaustion
"solution" has the effect of limiting the length of character strings to a
fraction of whatever scheme is employed to use the 63 bytes available.

You had this issue in another WG, where you thought that the authentication
mechanism could be, without cost, extended from a end-point set the size of
10^^3 or 10^^4, to an end-point set the size of 10^^6 or 10^^7.

Neither that activity nor this one is theoretical. Cost is not "layer 9",
if you really think it is, go sit in on variable- vs fixed-length forwarding
lookup or any equivalent problem in layers 2 or 3.

Now, on the registry side that was 2^^10 blips in the zone file for each
name, assume 10^^6 distinct names, each 10 character, plus 2^^10 extra
equivalences ... that's 10^^9 records. To be equitable, assume I/O, store,
and processing are "free", but not instantaneous. Even if there is no "cost"
associated with any action, the multiple entries in zone files recommended
(the UTC recommendataion) "solution" has the effect of limiting the length
of character strings to a fraction of whatever scheme is employed to use the
63 bytes available.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 10:53:04 +0800

You whole long mail basically "scale" (not "economy cost") maybe a
problem we need to look into.

As I said, I agree with you that discussion of "scale" is within
technical scope, but not "economy cost" on how much V charges per name
or B charges per cert etc and how much it would cost C to use it.

-James Seng

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, October 29, 2001 4:05 AM
Subject: Re: [idn] Re: [JET-member 446] Re: Fw: Re: new members
invitation

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 28 Oct 2001 22:23:50 -0500

Now I am confused. Deng, L.M. Tseng, and I write about scaling. You reply
that engineering isn't about "cost", then something about "economy cost".

What is "economy cost"?

Please clarify.

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 11:29:57 +0800

You are confusing me too. So let me put it in another way.

There are many different kind of 'cost'. 'scaling cost' like what you
described and 'economy cost' like what deng/tseng.

I am saying 'scaling cost' is an engineering considering, but not
'economy cost'.

Is this better?

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 28 Oct 2001 23:30:00 -0500

> Is this better?

Nope.

You brought up "how much V charges per name or B charges per cert etc and
 how much it would cost C to use it".

  > factor for consideration.
it appears that you characterizing a fundamental scaling property of any
sequence of binary-valued tokens -- the 2^^N problem, as non-technical. You
also wrote:
  > This is considered Layer 9 aka `political' issues from IETF perspective..

I don't agree.

It doesn't change the scaling property to associate Verisign price points
or bits of colored glass to the required user- and registry-acts and the
stored state required for each if TC/SC isn't included.

Eric

---

From: [email-masked] <[email-masked]>
Date: Mon, 29 Oct 2001 15:26:34 +0800

----- Original Message -----
From: "Paul Hoffman / IMC"
> it would be good to have some common advice on various languages.
         I think  the cost assigned by the registry is the service charge.
it is not the inherent cost of multiple registrations of TC/SC name.
Charging can be reduced to zero by policy but the overhead or
non-effectiveness in technologies is inherent cost in the method or approach
, it is always evaluated and based them to improve or to  make decision.
         Some user register one domain name and setup a DNS to extend his
domain service for organizations' host name. To handle the multiple TC/SC
name registry is an overhead to treat them, the size of storage and the time
for careful treatment is an inherent cost of  complexity. The complexity
come from a neglection to reduce them in a proper level .  That complexity
and cost will let the system manager try to not provide TC/SC multple
records in his managed zone file, then the stability and trust to use CJK
domain name will be very low. Finally , it come back to reflect it is not a
workable approach.
> --Internet Mail Consortium
         Thanks your good suggestion.
L.M.Tseng

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 16:48:05 +0800

> I don't think these are relevant, and as your reply to LM Tseng was:

Please dont misrepresent me. I bought that up to say it is not relevant
which you say so too.

-James Seng

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Oct 2001 07:13:16 -0500

--On Monday, 29 October, 2001 11:29 +0800 "James Seng/Personal"
<[email-masked]> wrote:

> There are many different kind of 'cost'. 'scaling cost' like
> what you described and 'economy cost' like what deng/tseng.
> 
> I am saying 'scaling cost' is an engineering considering, but
> not 'economy cost'.
> 
> Is this better?

James, Eric, and others,

I suspect that what I'm about to say is similar to what others
have been saying, but there is apparently sufficient confusion
that perhaps a different way to say it will help.

I'm not sure the distinction you are trying to make above helps.
But, more important, we are getting into areas here that are not
only not within WG scope, but are not even IETF issues.  

Let's distinguish between two types of economic issues.  In one
case, there is a protocol choice in which one option is
_inherently_ more expensive than another.  For example, suppose
we had one way of doing something that was vastly more costly to
develop or operate than another but, presumably, offered some
technical benefits.   It would be reasonable, and necessary, for
the IETF to consider the tradeoffs involved.  And, if we get it
wrong, we presumably get punished in the market.  

By contrast, assume there is a choice that depends on a
difference in pricing, not on costs.   Pricing is not our
problem, although we might offer some advice to registrars,
registries, or to ICANN.  To take the present situation as an
example, someone (presumably not an IETF WG) could possibly
convince some registrar that, if they offered a two-for-one deal
on TC and SC registrations, they could sufficiently increase
their volume on such registrations to make up any losses on
costs and, therefore, that doing so would be in their economic
interest.  No protocol changes needed.  Or one might try to
convince ICANN to presuade registries to adopt a similar rule.

There are potential IETF issues here, but they aren't within
IDN's scope.  For example, if one wanted to make a "TC and SC
for price of one" strategy cheap and easy, it might be sensible
to put some specific features to support that option into a
registrar-registry protocol (I'd hope we do not go down that
path  until and unless we have clear direction from either ICANN
or some ccTLD registries that they want such a thing).  Or one
might want to think about facilitating such matching by
registering and installing, e.g., the SC name normally, but
putting in the TC name as a DNAME RR, rather than series of NS
RRs.  I'd want to get advice from DNSEXT or some other
collection of DNS experts, but it might help with the solution
in the registrar/ registry space.  But, again, it is not an IDN
decision matter.

To oversimplify this a bit, my financial and economist friends
make a very strong distinction between cost issues and pricing
ones.  Cost issues may well be constraints on protocols, and
hence are something IETF should, IMO, carefully consider.  But
pricing issues are another matter, since prices are determined
by policies -- about what one can get away with, about the
allocation of costs, and so on.    Pricing issues are not an
IETF matter and, realistically, we could not directly influence
them if we try.  And a conversation about what some registry or
registrar will charge for various services is clearly a pricing
issue.

That one should be taken somewhere else.  I'd suggest the ICANN
DNSO, or their new IDN committee.  And perhaps this is an area
in which MINC should organize a lobbying and educational effort.

But it does not appear to me to be within the scope of the IDN
WG.

    john

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 29 Oct 2001 09:09:39 -0500

James,

It wasn't my intention to misrepresent you. Please represent yourself.

Why is SC/TC "economic" and not "technical"?

What is "pure technical" and how does it relate to technical?

As L.M.Tseng has asked similar questions [1] being the most recent in this
same thread, an answer to him might be an answer to me.

In a seperate thread (RE: [idn] An ignorant question about TC<-> SC), in a
reply to Scott Hollenbeck <[email-masked]>, Kenny Huang wrote to
a similar point in [2]. This thread isn't cc'd to the [email-masked]
list.

In that same thread, Deng Xiang wrote [4] that "the registration solution
isn't a solution", having previously made the a similar scaling observation,
here in a reply to Patrik Faltstrom, an IDNA co-author, who replied "multiple
registrations is a solution to the problem, and the recommended one by [the]
Unicode Consortium for the SC/TC issue". 

Again, an anwer to one (L.M.Tseng, Kenny Huang, Deng, ...) may be an answer
to all. I appreciate that you may find it difficult to write to me.

Eric

[1] <[email-masked]> 
[2] <[email-masked]>
[3] Mon, 29 Oct 2001 12:20:06 +0100
[4] <006d01c16061$55b60150$4407e29f@deng>

P.S. My comment [5] on the utility of the UTC's participation in the technical
question (SC/TC in "the protocol" or in "the zonefile") read:

	In this one note I'm troubled to see the UTC presume to know
	better than the sources available to the authors of tsconv,
	and to know better than the authors of some eventual STANDARD
	and/or BCP track APPS or DNS IDs.

[5] <[email-masked]>

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 22:30:48 +0800

> Why is SC/TC "economic" and not "technical"?

This is why this thread should never be in IDN WG in the first place
because there are so many discussion which was never even in this group.
It is a carried over from JET list.

I did *not* say SC/TC is "economy". Deng bought up arguments on why
TC/SC is neccessary because of "economy cost" in JET list. I responsed
to say that "economy cost" is generally not a consideration for IETF.

I feel there is no need to continue this discussion in the IDN WG until
we have the draft they promised. If you wish to continue, then please
feel free to do so in the JET list where the original discussion have
taken place.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 29 Oct 2001 09:26:53 -0500

John,

It may not be apparent, but the question is SC/TC in the protocol or in
some other mechanism, e.g., the way the UTC want it. Someone, you pick,
wrote that this wasn't a technical question. I think that person erred.

I want my registries to interoperate with other registries, the point of
an IETF, for things (labels, keywords, etc) which use code-points from
a common reference that are associated with "CJKV".

Everything else, with the exception of bidi, appears to be vastly easier.

Eric

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 29 Oct 2001 22:46:00 +0800

I must be very bad at expressing myself or someone have reading my mails
in a way he choose to interpret. So let me put it blantly:

1. I did not say TC/SC is an economy issue. Someone else did.

2. I did not say TC/SC is not an technical issue. Someone suggested I
did.

3. "I am saying that IETF is an engineering group which consider
   technical trade-off, not economy ones.

I suspect someone is can twist these fairly simple point again of
course, for example, since "I did not say TC/SC is not an technical
issues" => "I say TC/SC is an technical issues" => "TC/SC is within
scope".

I am not sure about others folk here but I find this childish game very
tiring. This is my last email on this.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 29 Oct 2001 09:52:02 -0500

James,

> I did *not* say SC/TC is "economy".

> factor for consideration.

The "above" was a discussion of where the complexity exists, in the design
and implementation of a protocol, or in end-user use of that protocol. Two
design points -- the tsconv and similar drafts at one end, and the Unicode

> This is why it is known as engineering trade off, not economy trade off.

So, hence my questions about what you think scaling is, in this context.

> feel free to do so in the JET list where the original discussion have

If you'd be responsive in that list, fine. Please make your response to
that list. Someone on the JET list will eventually forward your reply to
me. If you prefer to defer until that draft is posted to this list, fine.
The issue isn't going away.

Eric

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Oct 2001 09:59:27 -0500

--On Monday, 29 October, 2001 09:26 -0500 Eric Brunner-Williams
in Portland Maine <[email-masked]> wrote:

> It may not be apparent, but the question is SC/TC in the
> protocol or in some other mechanism, e.g., the way the UTC
> want it. Someone, you pick, wrote that this wasn't a technical
> question. I think that person erred.

The general question is certainly a technical one.  It is not
clear that it is in scope for the IDN WG (let me come back to
that in another note).  If it is within scope for the IDN WG,
then I believe solutions are not possible (i.e., not solutions)
unless they solve (or avoid worsening) some other problems,
which I've tried to outline in earlier notes.

However, if one says "we need to do this because otherwise we
have to do double (or more) registrations and those are too
costly", _that_ question is not a technical one, except, as I
suggested, it interacts with either registrar-registry protocols
(not in IDN's scope) or the registration and use of CNAME
records (not in IDN's scope, I think).

> I want my registries to interoperate with other registries,
> the point of an IETF, for things (labels, keywords, etc) which
> use code-points from a common reference that are associated
> with "CJKV".

Yes.  So do we all.  And?

> Everything else, with the exception of bidi, appears to be

Well, I think it depends on your perspective.  We have,
potentially, many nearly-equivalent problems with languages that
are written in multiple scripts or other variants: if we try to
match them correctly, we end up with side-effects in other
places.  The _users_ of those languages have been less present,
and less articulate, than those concerned about Chinese, and
there are certainly fewer of them than there are users of
Chinese (or other Han-based character sets), but the problem is
not, IMO, any easier.

    john

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 29 Oct 2001 10:30:29 -0500

John,

> have to do double (or more) registrations and those are too

We're discussing exponential behavior. Scaling is the problem we are trying
to solve. Does an out-of-protocol SC/TC equivalance mechanism both exist and
scale, for the existing problem constraints?

Eric

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Oct 2001 10:47:09 -0500

--On Monday, 29 October, 2001 10:30 -0500 Eric Brunner-Williams
in Portland Maine <[email-masked]> wrote:

> We're discussing exponential behavior. Scaling is the problem
> we are trying to solve. Does an out-of-protocol SC/TC
> equivalance mechanism both exist and scale, for the existing
> problem constraints?

Beats me.  I'm still not sure I understand the stated problem
constraints (e.g., I'm not sure whether we really have to
"translate" an arbitrary combination of mixed TC and SC
characters to some other arbitrary combination of them or
whether the problem can sensibly be constrained to translating
entirely-TC strings to entirely-SC strings and/or back).  The
two, obviously, have widely different scaling properties if one
tries to go the multiple registration route as most of us would
not spend a lot of effort on a factor of two.

Conversely, there are some potentially serious problem
constraints that I'm not sure I see being addressed.  And I
prefer to not try to guess at how (or whether) some proposal
will deal with them until I see the proposal.   Among those
constraints is that we don't language-label and we don't insist
that the labels of an FQDN be homogeneous (or even predictable
from each other) wrt language or even script embedded in Unicode.

    john

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 29 Oct 2001 12:48:51 -0500

John,

"Beats me" is fine answer, as is looking critically at the stated, and
unstated, problem constraints.

If we were to consider Abenaki/Mikmaq/Maliseet/... (17th century French
script derived scripts) and other Indian languages (contemporary, even
modern Spanish and English derived scripts) character sets and "Roman",
we'd be looking at the following equivalence problem:

                U+0070          "8"     when in an alpha-string
                U+0222          "8"     LATIN CAPITAL LETTER OU
                U+0223          "8"     LATIN SMALL LETTER OU
                U+0117,U+0125   "OU"
                U+O117,U+0165   "Ou"
                U+0157,U+0165   "ou"
                U+0127          "W"
                U+0167          "w"

This just for the "8". "TC" in this context would be Abenaki (etc) written
with niche-market IBM Selectric type sets, similar to Inuktitut, and "SC"
would be the same written on an unforgiving 101 key IBM PC keyboard, ACSII.
We call it "diacritically simplified" characters -- basically everything is
promoted to its nearest ASCII look-alike, and all or almost all diacriticals
are stripped.

I don't claim that "solving for Abenaki <or even Cree or Dine'>" is nearly
as important as the SC/TC problem.

Eric

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Oct 2001 11:22:17 -0800

At 3:50 PM +0800 10/29/01, Erin Chen wrote:
>If we consider TC/SC are not the names similar but just like
>Uppercase/Lowercase English letter.

It has been shown that this is *not* just like case in English. That 
would only be true if Han characters could be converted 1:1, if there 
was a stable matching system that did not need human context, and if 
everyone in all countries that use Han agreed to the matching system. 
None of those three things are true.

>If you think of TC/SC requirement is non-technical human means,
>then hou about Uppercase/Lowercase English letter deal in DNS?

English case folding meets that set of requirements, and more. Note 
that, even though it is pretty much universally accepted, it still 
has its problems. Capitalization is very important to some people's 
names, and the case folding smashes their names in an unpleasant way.

At 5:56 PM +0800 10/29/01, Erin Chen wrote:
>As mentioned in draft TSCONV, there are mainly 3 categories of TC/SC
>conversion. They are 1-1 , 1-n , n-1
>
>In the case of 1-1 , do not to care about the meaning. the matching of TC/SC
>can be achieved by a matching function or a finite matching table. That is to
>say matching of TC/SC can be done as Uppercase/Lowercase English letter
>(EX: A-a).

Maybe this is a false analogy. From my understanding, some of the 
*characters* that would be mapped in a 1-to-1 mapping are part of 
*words* and *names* that would instead be mapped n-to-1, yes? If so, 
doing the 1-to-1 mapping would make the DNS label unreadable.

Further, and more important, please remember that many of the 
characters that would be mapped in the 1-to-1 table are used in 
languages other than Chinese. It is, of course, completely 
unacceptable to do a traditonal-to-simplified mapping in a Japanese 
or Korean name, yet it is impossible for a system that is doing the 
mapping to tell the language in the label.

At 5:55 PM +0800 10/29/01, xiang deng wrote:
>On Monday, October 29, 2001 1:27 PM, Paul Hoffman / IMC wrote:
>
>>  Why not, indeed? No one here is saying that it should not be done. We
>>  are saying that it should not be mandated in a technical
>>  specification. There are many types of non-technical specifications
>>  that would be very useful here. We have been told that the JET group
>>  is coming out with one Real Soon Now, so that might address the
>>  problem in a suitable fashion.
>
>I'm not sure what's your meaning.  I always hear two voices:
>1. go to UTC.
>the requirements are:
>(1) preserve the characteristic of TC /SC.
>(2) compare without care of TC/SC.
>TC and SC are different character, there needn't mapping from
>TC(SC) to SC (TC), it will make a character disappear.
>
>2.two records solution, one is SC form and the other is TC fom.
>it's not applicable.

Well, I'm sure you hear more than just two voices on this! :-) I have 
never talked about a "two record solution" because we know that there 
will need to be more than two for many Chinese names. What I am 
saying is that it seems likely that there can be good advice given to 
registries and registrants about equivalence for Han names that might 
be used when registering (or even after registering), and that such 
advice might be appropriate for this WG to work on.

The people who have said "go to the UTC" have been responding to the 
assertion that  a technical mapping of traditional-simplified is 
possible today. Other people have countered that there is no 
well-agreed-on table for the mapping; still others have said that 
such a table is impossible because of the need for context; and still 
others have said that this is all moot because 
traditional-to-simplified mapping must not be done on Japanese or 
Korean names, but there is no way to prevent that without context.

Assertions that "we can do this" are OK, but if it hasn't been 
approved by an international body that is respected, it probably 
won't be approved here. So, "go to the UTC" might mean "until we hear 
from such a body that this is finished, stable, and sensible, we 
cannot wait for it". Fortunately, we don't need to: 
traditional-simplified and other similar mappings can help DNS users 
of the world without having to be part of the IDN protocol.

Where JET and/or CDNC can definitely help here is in clearly 
articulating the problem for Han characters and a proposed solution 
for people registering names, and for the agencies doing the 
registering. We have not seen such a document yet, so the WG cannot 
decide if that would be something we want to work on. Even if it is 
not done in the IETF, such a document (and similar documents for the 
many other languages with similar problems) will be very useful in 
the world.

>          I think  the cost assigned by the registry is the service charge.

This has nothing to do with the IDN specification. A registry can 
charge as much or as little (including zero) as it wants. The 
overhead for assigning three additional names to one person who asks 
for one is so small that it would make sense if the cost went away. 
This is analogous to Internet Service Providers allowing one person 
to have five mailboxes for the same price as one mailbox. Some ISPs 
do this, and they attract customers because of it; others don't do it.

>domain name will be very low. Finally , it come back to reflect it is not a

It is unfortunate that some people keep talking about this as if it 
was only a Chinese issue. It is *not*. The very same issue appears 
for every language where there are words and names with nearly 
identical meaning, and the issue appears in every language where 
there are words and names with nearly identical spellings.

This discussion has an undercurrent of Chinese vs. non-Chinese, and 
that is really ugly. The problems faced in traditional-simplified 
conversion (that the conversions are 1:1, 1:n, and n:1; that there is 
not a single, stable standard; that it cannot be applied to Japanese 
or Korean characters) are similar to those faced in throughout the 
world. Making this a Chinese issue is deeply disrespectful to all the 
other people throughout the world who have exactly the same problem 
as the Chinese do. Nor is this an issue of the number of speakers of 
the language: some of these issues arise in Indian and Arabic names.

Once again: the DNS is pretty bad at dealing with these kinds of 
issues for names. This was proven conclusively first for US English, 
then for all languages that can use Latin characters. IDN will simply 
make these problems apparent for many scripts throughout the world. 
The people who say "the IETF cannot move forwards with IDN until it 
is better for my language than for other people's language" are doing 
a disservice to everyone, including the people who use their own 
language.

--Paul Hoffman, Director

---

From: "ben" <[email-masked]>
Date: Mon, 29 Oct 2001 21:56:28 -0500

Hi Paul,

> --Internet Mail Consortium

Although I generally like to stay out of discussions on TC<->SC (due
to my lack of technical knowledge compared to most people in this WG),
I must correct you on the above.  To blame the Chinese people in this
WG for delaying the progress of the IETF is so unfair.  How is it
possible for people to delay the progress of the IETF by simply
posting up messages and writing drafts?

Thanks,
Ben

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 29 Oct 2001 19:34:55 -0800

>posting up messages and writing drafts?

Ben, that is both absurd and deeply offensive. You purposely put two 
unrelated quotes together and then misquote me. I never said "the 
Chinese people" did anything because I know that "the Chinese people" 
don't all agree on everything or do the same things. There have been 
folks from a number of different countries who have exhibited the 
behavior I was complaining about. Further, all of us together are 
responsible for the advance and delay in this Working Group.

Right now, we are waiting for a draft from a group of people that is 
comprised of both Chinese and non-Chinese folks who have a deeper 
understanding of an important topic that many of the rest of us do. 
The nationality of the people writing that document is mostly 
irrelevant: their knowledge of the topic is what most important here. 
Trying to draw nationalistic lines is not helpful, and is 
particularly silly in a body like the IETF.

--Paul Hoffman, Director

---

From: "ben" <[email-masked]>
Date: Tue, 30 Oct 2001 00:34:49 -0500

Hi Paul,

I did *not purposely* misquote you.  I truly thought they were related
so I did not think there was a need to forward the entire quote-
especially since everyone has *already got* a copy of the original.
It was important for me that you clarify what you mean- thanks for
that.

However, I still don't understand how anyone (whether they are Chinese
or non-Chinese) can delay this process by posting up messages and
writing drafts?

Thanks,
Ben

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 30 Oct 2001 07:01:55 +0100

--On 01-10-29 21.56 -0500 ben <[email-masked]> wrote:

> How is it

By

(a) Talking about an important issue
(b) People tell the author what part of that issue can be solved
    in the DNS, and how, and point to other solutions for
    the other part(s) of the issue
(c) Talking about the important issue again, with no changes
(d) People tell the author again that things have to be changed
    because the issue can not be solved in DNS
(e) Go to (c)

Myself, I have with the CNNIC people now passed point (e) four(!) times,
and I start to get tired on this. The proposals from CNNIC have not changed
at all since (a), and conversations have occurred on the IDN mailing list,
in private conversations (one is going on at the moment) and in face to
face meetings.

Further, at second pass of (e), myself and others talked with the
authorities on Chinese scripts we know to verify that we were not stupid or
misunderstood something. _ALL_ of these said that it was the CNNIC people
which had not understood the complexity of the problem. Further, the
Unicode Consortium have already been through the SC/TC problem once, and to
explicitly state this fact, the Unicode Consortium explicitly sent a liason
statement to the IETF stating this fact.

When all of these things was presented to the CNNIC people, the rough
consensus in the wg on what to do, the information from external sources,
and the liason statement from Unicode Consortium, the response is:

- The wg don't understand the problem
- The external sources don't understand the problem
- Unicode Consortium don't work on these issues
- ISO have nothing to do with Chinese Characters

And we go back to (c) again from (e).

Sorry, but this is absolutely NOTHING but a delaying process from ignorant
people.

Note that I am nowhere above saying that SC/TC is a problem. Just like
other equality (define the word equality whatever way you want) when you
use more than one script -- and in some cases even with one.

I am as you can see extremely tired on this wg not making process just
because one group of people is blocking the discussions.

This wg is not making any progress.

Absolutely NOTHING has been changed in the proposals which are on the table
the last couple of months, and as in all processes, we _could_ have been
able to discuss things which we still have to polish here and there. For
example, the part of the SC/TC issues which have to do with mappings from
local charsets to Unicode, use of Unicode in other protocol elements than
domain names etc.

So, at the moment it is CNNIC which effectively see that the world can not
use Chinese Characters in the DNS.

     paf

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 30 Oct 2001 07:28:47 +0100

--On 01-10-30 07.01 +0100 Patrik Fältström <[email-masked]> wrote:

> Note that I am nowhere above saying that SC/TC is a problem.

s/is a/is not a/

  paf

---

From: "Kenny Huang" <[email-masked]>
Date: Tue, 30 Oct 2001 15:48:19 +0800

Hi Patrik,

Sorry for bothering you and others so much time. I believe there are some
misunderstanding in the communication loop. I know CNNIC and TWNIC 
detail proposals  are almost completed. These documents will be sent
to JET mailing for feedback information gathering before 3rd Nov.  We can
discuss the technical details based on the written document.  The scenario 
will be much more clear. I want to encourage everyone not to give up right
now.  Although we are all exhausted for being sunk into  IDN endless loop 
for more than 2 years.

Kenny Huang

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Patrik Faltstrom
> Sent: Tuesday, October 30, 2001 2:02 PM
> To: ben; [email-masked]; Paul Hoffman / IMC
> Cc: [email-masked]
> Subject: [JET-member 486] Re: [idn] Traditional-simplified, yet again
> 
>

---

From: "xiang deng" <[email-masked]>
Date: Tue, 30 Oct 2001 16:16:22 +0800

Who give you the power to make this STATEMENTS?

Who give you the power to STIGMATIZE other people 
in the IETF AND JET-MEMBER FORUM?

Who give you the power to THREATEN AND TERRIFY others?

Who give you the power to DENY CNNIC's effort?

Who give you the power to COMMAND others
what should and what shouldn't do?

Deng xiang

---

From: "James Seng/Personal" <[email-masked]>
Date: Tue, 30 Oct 2001 16:42:45 +0800

Deng and Pat & and all,

I suggest everyone take a time out...

The IETF works on drafts. So instead of having this conversation, the
time should be spend on working on draft.

The WG move forward with consensus. There will be differences in
opinions and it should not be taken personally. And it also means not
everyone will be happy with the result. We just do the best we can with
the existing technology and information available to us.

-James Seng

----- Original Message -----
From: "xiang deng" <[email-masked]>
To: <[email-masked]>; "ben" <[email-masked]>; <[email-masked]>;
"Paul Hoffman / IMC" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 30, 2001 4:16 PM
Subject: [JET-member 489] Re: [idn] Traditional-simplified, yet again

---

From: "xiaodong lee" <[email-masked]>
Date: Tue, 30 Oct 2001 17:02:30 +0800

Dear Patrik:

Everyone is tired in IDN, you and all. We do not want to make this 
in the truth. We brought up such problem, but it is a difficult problem 
to be solved based on so-called principles said by someone of IDN.
So we must prompt new solution to solve the big problem for Chinese
people again and again, which is not our aspiration. Who want to do that?
not you, and not us too.

You said some authorities on Chinese scripts think it is a complex problem,
I think so, CNNIC people and all Chinese people think it is not easy to solve 
too.
To do TS/SC in context is a difficult problem, it should not be solved in DNS.
but any difficult problem could be reduced in some case, and based on some
priciples. DNS is identifier, so we solve part of TS/SC problem in DNS, which 
will solve most of the TS/SC problem.
I don't know how you explain such problem for those authorities, I still think there
are some misunderstanding in such problem, we have explain the special 
problem of TS/SC for our chinese scripts expert which is author of the RFC about 
Chinese character, he agree with us too. we must differ this conversion problem 
from other TS/SC conversion, which I have explain in my draft, and will be explain 
again in our new draft that will be submitted soon after.

So I think you might read our draft carefully and understand our question.
maybe I cannot explain it in my draft for you for my poor English, but I do want
to discuss this with you  in detail.

let's be more patient on such problem and more progress for IDN too. OK?

Xiaodong Lee

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Oct 2001 08:08:28 -0800

Thank you for this message, particularly the tone of it. You talk 
about a draft and ask us to read it carefully. I would very much like 
to do that (and would certainly like to read it more than the recent 
messages!), but I don't know which draft you are speaking about. Was 
it announced and I missed it? Or will it be ready soon?

--Paul Hoffman, Director

---

From: "Tim Langdell" <[email-masked]>
Date: Tue, 30 Oct 2001 09:13:20 -0800

As many of your already know, we here at XTNS are proponents of a layer that
sits on top of DNS because we feel there are many issues and potential
future features of IDN resolution that are better handled (at this time,
anyway) via such a layer than seeking to devise and integrate solutions into
the root. And indeed, our XTNS System does just that, enabling IDNs to be
"resolved" within the Address Bar of Internet Explorer, and then being
translated -- if desired -- to ACE to be routed to the root, or simply at
this time to be resolved directly to specific URLs or IP addresses.

It seems to us that this issue of TC<->SC mapping is  a perfect example of a
problem that is perhaps best dealt with at this time in the layer that we
provide sitting on top of DNS, rather than perhaps seeking an elusive
'perfect' solution in order to integrate such mapping into the DNS itself at
this time. The power of dealing with the TC<->SC issues in the layer that we
provide is that it can be dynamic (allowing for evolution of TC<->SC mapping
in the future) and can enable the on-going development of a solution that
can eventually be integrated into the root system for all IDNs. Our layer is
perfect for dealing with issues that are not simple one-to-one mappings, and
where context dictionary based problems are to be dealt with.

Moreover, as our system also handles Japanese.Japanese, Korean.Korean, etc,
we can equally coordinate other mapping issues as and when they arise such
as the example given by Mark:

>If there were a recognized 1-1 subset mapping between SC characters and TC
>characters, I don't think unification would be an issue in matching. For
>example, it would matter little to Japanese users that an SC character
could
>be typed in instead of one of their TC characters, so long as two different
>TC characters used in Japan were *not* matched. This could be done as long
>as the mapping never identifies two different TC characters with the same
SC
>character.

Were there a situation where two different TC characters really "ought" to
be mapped to the same SC character (and I do not know if there would be)
then here would be a perfect example of an issue that can be easily handled
via the XTNS System sitting on top of DNS, but is complex to even consider
resolving within the core IDN system itself. One to one mapping could be
eventually integrated into the root, leaving the exceptions and complex
translation issues to remain to be dealt with in the layer sitting on top of
DNS.

Tim

Dr. Tim Langdell
CEO
XTNS

----- Original Message -----
From: "xiaodong lee" <[email-masked]>
To: "Patrik Fältström" <[email-masked]>; "ben" <[email-masked]>;
<[email-masked]>; "Paul Hoffman / IMC" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 30, 2001 1:02 AM
Subject: Re: [idn] Traditional-simplified, yet again

---

From: "xiaodong lee" <[email-masked]>
Date: Wed, 31 Oct 2001 08:57:04 +0800

Dear Paul:

We are preparing a draft about requirement of Chinese Domain Name( approximately named as this) and a draft of how to treat this requirement. we do hope these two draft could be accepted by IDNese and these two draft are useful for IDNese to understand the real attempt to do that TSconv.  These draft will be made rough consensus in JET and submitted to IDN soon after.

You might read it about in less than two weeks. and We do hope to get your help and suggestion of these two draft too, just as your comprehension and help in Aug meeting in London and before.

Xiaodong Lee

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 31 Oct 2001 09:51:43 +0800

I like to remind everyone that if a draft is not published AND have not
been accepted into this working group, the draft is as good as not exist
in the view of the working group. We will not and cannot wait
indefinately. Neither should we stall the process on a REAL-SOON-NOW
draft.

The working group should, must and will proceed with the drafts
currently in its pool, currently:

Internationalizing Host Names In Applications
(IDNA)(draft-ietf-idn-idna)
Preparation of Internationalized Host Names (draft-ietf-idn-nameprep)
Proposal for a determining process of ACE identifier
(draft-ietf-idn-aceid)
Japanese characters in multilingual domain name label
(draft-ietf-idn-jpchar)
Traditional and Simplified Chinese Conversion (draft-ietf-idn-tsconv)
Hangeul NAMEPREP recommendation version 1.0(draft-ietf-idn-hangeulchar)
Improving ACE using code point reordering v1.0(draft-ietf-idn-lsb-ace)
AMC-ACE-Z (draft-ietf-idn-amc-ace-z)

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 31 Oct 2001 09:16:28 +0800

Japanese characters in multiling ual domain name label

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 30 Oct 2001 22:03:05 -0500

James,

I remind you that the difference between the timeline you suggested and the
timeline I suggested is about six months, and one of the consequences your
schedule is the chance that when the greatest effort is made, it will be "too
late".

When Masanobu Katoh summarized the results of the IDN survey at Stockholm,
only five short months ago, the data available was that speculators and IP
holders were the overwhelming "users" of an IDN (the VGRS RACE product). We
have more time than fatigued contributors, or eager marketers, are willing
to allow.

There are lots of people I wouldn't "stall the process" for (your words, not
mine), some vendors come to mind. The JET membership is not among them, not
in my mind, as they are ccTLD NICs, with a "duty to serve the community" [1].

Please do not rush, and please do not spend time looking for the hidden
insult to you. The only content of this note is time.

Eric

[1] rfc1591, March 1994

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 31 Oct 2001 11:25:06 +0800

> schedule is the chance that when the greatest effort is made, it will
be "too

Yes, and that is still a discussion on another thread in the wg on that
topic so follow up there.

But so far, my take is that there are more people who wants IDN WG to
produce some work so we can move on to discuss other issues than people
who wants IDN WG to slow down. I may be wrong so lets wait for that
discussion to complete.

> in my mind, as they are ccTLD NICs, with a "duty to serve the
community" [1].

My note is fairly simple reminder to all that the WG proceed on drafts
in its core interest. We should focus our discussion on the core
interest.

Unpublished drafts or promised draft (be it 2 weeks or 2 months) are not
part of core interest and there should not be foul call when the wg
proceed without them.

I recieve private mails regularly that he/she is going to send in a
draft for review but eventually never made the group at all, some as
long as 18 months ago. Therefore, I am not referring to anyone in
particular.

-James Seng