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

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 14 Aug 2001 19:08:47 -0700

ben <[email-masked]> wrote:

> The solution to delivering the 3 benefits explained above is a
> Chinese domain name system that uses language script TLDs- a TLD of
> <.traditional> for traditional CDNs (defined here as a CDN that uses
> all traditional characters) and a TLD of <.simplified> for simplified
> CDNs (defined here as a CDN that uses all simplified characters).

This would limit people's choice of registration authority.

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

I don't think there's any need to require that all domains containing
Chinese characters follow this convention.  It could be left up
to each registrant whether they want to include <traditional> or
<simplified> in their domain name.  It needn't be at the second
level either.  The convention could be that clients with the added
Chinese support would be suspicious of simplified characters
anywhere to the left of .<traditional>. (wherever it appears) and
be suspicious of traditional characters anywhere to the left of
>.<simplified>. (wherever it appears).  This would allow things
like <FOO>.<traditional>.ac.uk.  It could be recommended (but
probably not required) that registration authorities never allow
<traditional> or <simplified> to be registered under any zone, but
rather require registrants to register <something>.<traditional> or
<something>.<simplified>.  It could be recommended (but probably not
required) that registrars register such names in pairs.

One nice thing about your proposal is that it appears to be orthogonal
to IDNA.  Clients without the added Chinese support can still access
all domain names, they just won't provide the extra hints when mistyped
names fail.

AMC

---

From: "ben" <[email-masked]>
Date: Wed, 15 Aug 2001 01:18:53 -0400

Hi Adam,

> This would limit people's choice of registration authority.

In my system, CDNs cannot be a mix of TC and SC.  If that is
considered "limit people's choices..." then I am afraid I am guilty.
However, can you come up with even one good reason why we should allow
a CDN to have mixed TC and SC?

> all domain names, they just won't provide the extra hints when
mistyped

I feel very strongly that there is a need to create a new type of TLD
(lsTLD- as described in my draft) to implement my idea to satisfy the
needs of CDN users.  Do you have any opinions on that?

Thanks
Ben Chan

---

From: [email-masked] <[email-masked]>
Date: Wed, 15 Aug 2001 14:11:09 +0800

> a CDN to have mixed TC and SC?
       In HongKong , Taiwan,  user use BIG5 code . This code set has no
simpified chinese scripts. In China , GB code set has no traditional chinese
scripts . So there are no mixed type of  GB and BIG5 .  But you know
VeriSign/NSI  announced ML.com  with any UNICODE can be mixed.
That is the key problems.
       Any suggestions must be considered  what to do for .COM in this WG.
If english character is treated as case folding, Why  CJK can not treated as
the same way to reduce the number of registrations for trade mark
considerations?  Case folding is also not a protocol issue .  It is
othogonal to IDNA too.

L. M. Tseng,

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 15 Aug 2001 16:34:06 +0900

----- Original Message -----
From: "[email-masked]" <[email-masked]>
> considerations?  Case folding is also not a protocol issue .  It is

Tseng, which solution do you support ?

 1. Registration/Dispute Resolution Policy that assures:

     The first registrant of a SC or TC .com domain should take
     all of its SC/TC equivalent alternatives.

 2. The new version of Unicode Standard   defines
     additional case-mapping rules  for SC/TC equivalences and
     NAMEPREP  refers to that standard document  for doing SC/TC case folding.

Soobok Lee

---

From: [email-masked] <[email-masked]>
Date: Wed, 15 Aug 2001 17:15:44 +0800

> Tseng, which solution do you support ?
Lee,  sorry, some IDN problems need them both.
    Method 1 is policy based approach.  Method 2 is technique approach.  To
solve problems ,  first one is technique possibility then  policy is
considered finally .  For  chinese scripts ,  Method 2 only applied to case
of bidirectional one one mapping . It also has one trouble : In a set of
scripts, which script is the canonical form ? If  script display is needed .
The transformed ACE code can not recover to the original  scripts . So it
solve only partial problems.
    Method 1 is considered to reduce the complexity of  1 to n or n to n
mapping case ,  if there are no simple way to solve the difficulty, 1 to n
scrpts mapping are forecd to selected one by user in registration time.
Actually,  1 to n  and n to n or forbidden one are always solved by policy.
But these selection need assign one SC or TC as the primary form , so ACE
encoding is the mapping table form to map IDN(TC) and IDN(SC) to primary
ACE(IDN) .  This is a policy of selecting best one .  It also solve partial
problems too.
     So, both are need . If you considered the suitable display  scripts
form, Another table mapping method should be included to reverse reference
them.

L.M.Tseng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 15 Aug 2001 05:57:49 -0400

Soobok,

Perhaps you wrote in haste. 

Mechanism: Specification of SC/TC equivalance sufficient for dns identifier
comparison may be done in nameprep.

Additionally, Specification of SC/TC equivalance necessary but not sufficient
for dns identifier comparison may be done in a seperate document in this WG,
e.g., the existing tsconv or suggested uniprep drafts.

Further, Specification of SC/TC equivalance sufficient for other forms of
comparison which exceede those for dns identifier comparison may be done in
a seperate document, external to this WG.

Policy: Specification of policy, e.g., "first-come, first-served", whether
scoped or unscoped, is out of scope for this WG.

Scope: Specification of mechanism scope, e.g., registry specific, may be
done, but see the discussion of [30].

Eric

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 15 Aug 2001 19:35:09 +0900

Some participants suggest we need to recover the pre-normalization/pre-folding
characters from folded domains for various reasons (political or aesthetical).
Do we really support this need in nameprep and uniprep contexts?

IMHO,under current version of "light-weight" nameprep, we don't need do that.

But for future heavier uniprep( or nameprep ) that includes SC/TC mappings,
i am sure we should devise some mechanisms (in DNS scope or out of DNS scope)
to recover the pre-normalization forms.

Soobok Lee

----- Original Message ----- 
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>

---

From: Erin Chen <[email-masked]>
Date: Wed, 15 Aug 2001 18:54:13 +0800

Dar Adam,

"Adam M. Costello" ¼g¤J¡G

> > CDNs (defined here as a CDN that uses all simplified characters).

<.traditional> and <.simplified> maybe not the only one and not the
best one method of manage CDN. But it really could reduce the size
of the zone file. Because which is no more need to reserve the all possible

mixed TC/SC CDN for equivalent match .

If existing ccTLD or a new possible IDNccTLD could imply particular
scripe, then it do not necessary have the additional <.traditional> nor
<.simplified>

> This would limit people's choice of registration authority.

Certainly, we should consider carefully  not to limit people's choice when
they register CDN. But, how if the people live in PRC, Taiwan, Hongkong,
Macao and the Chinese some other where they do not use Chinese in the
way of mixed TC/SC ? In such case, that is not limit the piople, it should
be fit the people.

Maybe people may ask how if some of the people they do not familar
Chinese culture and custom might to use the CND in mixed TC/SC ?
Fine, nameprep it as case folding before send the request to resolver as
defined in IDNA. Or some intelligent match service could help things like
that.

> > <whatever>.<traditional>.TLD, <whatever>.<simplified>.TLD)

If the TLD could imply certain scripe, it does can provide the registration

of <certain scripe IDN>.TLD(imply certain scripe)

> required) that registrars register such names in pairs.

In TWNIC testbed, when the registrants register an TCDN.tw we let them
to use the corresponding one SCDN.tw . We makes such names in pairs.

> all domain names, they just won't provide the extra hints when mistyped

After the fight of IDNA-NAMEPREP-ACE solution, hope the IDN WG would
face  forward to consider about mutilayer resolution,  a new Class. It
would not
be treat as orthogonal to IDNA, it could be the expansion.

Erin Chen

---

From: "Edmon" <[email-masked]>
Date: Wed, 15 Aug 2001 10:02:54 -0400

Hi Ben

> a CDN to have mixed TC and SC?

is rather irresponsible.  TC-SC mix is already common place in HK.

Edmon

---

From: "ben" <[email-masked]>
Date: Wed, 15 Aug 2001 10:12:46 -0400

Hi L. M. Tseng

I understand that "SC/TC equivalence" is very important to users of
CDNs.  That is why I've made it very clear that I am totally behind
any efforts in finding a reasonable solution to this issue.  I
understand (and I am sure you also understand) that what is considered
a reasonable solution to some, is total unacceptable to others.  The
question then becomes exactly what is it that we can all (or atleast a
majority of us) agree on that can be provided to the users of CDNs- as
ultimately, it is the users of CDNs that should benefit from our work.

If everyone can agree that my Supreme CDN system is indeed "supreme"
(with all humbleness), then there is indeed a need to implement this
supreme system to benefit the users of CDN.  In my opinion, I feel
that the best way is to create a new type of TLD (<.traditional> and
<.simplified>) as described in my draft.

(Everytime I talk about <IDN>.<IDN>, I am so afraid that someone will
respond by saying "this is out of the scope of this IDN WG"... which
is probably true... but anyways...)

Thanks
Ben Chan

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: "ben" <[email-masked]>; "Adam M. Costello" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, August 15, 2001 2:11 AM
Subject: Re: [idn] opting out of SC/TC equivalence

---

From: "ben" <[email-masked]>
Date: Wed, 15 Aug 2001 10:37:13 -0400

Hi Edmon,

You are correct, TC-SC is indeed mixed and that is a reality.  I have
said all along that TC and SC are used interchangeably by certain
groups/cultures/background and that is why they are indistinguishable
to those people.

However, my question is "...can you come up with even one good reason
why we should allow a CDN to have mixed TC and SC?"

In other words, just because people mix them, a "supreme CDN system"
should not add to the confusion by allowing a CDN to have mixed TC and
SC (unless you can come up with even one good reason why I should then
I may modify my draft as necessary.)

Thanks
Ben Chan

---

From: David Hopwood <[email-masked]>
Date: Wed, 15 Aug 2001 12:37:01 +0100

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

[email-masked] wrote:
> "ben" <[email-masked]> wrote:
> > "Adam M. Costello" <[email-masked]> wrote:
> > > This [top-level <.traditional> and <.simplified>] would limit people's
> > > choice of registration authority.

I agree. A TLD (regardless of what script it is in) should specify which
registration authority is responsible for allocations below that TLD.
If language script specifiers are needed then they should go to the left
of the TLD.

However, I don't see any need to require script specifiers; the following
algorithm (to be performed when typing a name into a browser location
field, for example), would seem to be sufficient:

 1. Find the rightmost character (i.e. last in logical order [*]) that is
    specific to TC or SC. Call its script the "rightmost script", and the
    other Chinese script the "opposite script". If there is no such
    character, use the name as-is.
 2. If the name contains any characters from the opposite script, convert
    them to the rightmost script and ask the user whether that's what he/she
    meant.

Support for this would be OPTIONAL; the fact that a name with mixed TC and
SC can be converted to a valid name would not mean that the mixed name is
valid.

[*] Labels that mix Chinese and right-to-left scripts are unlikely; this is
    specified just to make the algorithm unambiguous.

> > a CDN to have mixed TC and SC?

I don't think Adam was suggesting that. The issue is who handles registrations
under <.traditional> and <.simplified> in your scheme.

> That is the key problems.

Verisign/NSI would be highly premature in announcing any policy about Unicode
names - they don't know what the protocol will support yet. Where did they
announce this?

> considerations?

Because this type of folding requires only two (or at least a small number
of) registrations if it is done at the server end, whereas case folding
would require on the order of 2^n registrations. Therefore, the trade-off
between client complexity (i.e. the complexity of nameprep) and any server-
side or registration difficulties is quite different.

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

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "ben" <[email-masked]>
Date: Wed, 15 Aug 2001 19:22:37 -0400

Hi David,

>     them to the rightmost script and ask the user whether that's
what he/she

As much as both Tseng and I want your algorithm to work for the
benefit of the Chinese culture, I think you have over simplified the
problem by leaving out the "one to many" and "many to one" issue in
your algorithm.

> under <.traditional> and <.simplified> in your scheme.

I don't think that is my decision.  (By the way, I misinterpreted what
Adam was trying to say so thanks for pointing that out.)

Thanks
Ben Chan

---

From: "Edmon" <[email-masked]>
Date: Thu, 16 Aug 2001 10:29:05 -0400

Hi Ben

From: "ben" <[email-masked]>
>
> "ColorCentre.com" and "ColourCenter.com" is ok in English.  However,
> "<tc><tc><sc><sc><tc><sc>.com" is a recipe for disaster.

So, can you come up with one good reason why BE+AE (British English -
American English) is OK and TC+SC is not?

I have seen quite a number of brand names now beginning to have TC-SC mix in
HK.  My point is that TC and SC are no longer simply a straight mapping of
each other, or in technical terms a compatible character or simply a
different script.  Each character in the Chinese repertoire is becoming a
character of its own right, the line between TC-SC is starting to blur.
They are all "Chinese Characters".

> > Hi Ben,
> > Presently, I can have:
> >    ColorCentre.com
> > and someone else can have
> >
> >    ColourCenter.com
> >
> > I am mixing British-English and American-English.
> >
> > Are you saying that these two domain names should be mapped to
> >
> >    ColourCentre.com
> >    ColorCenter.com
> >
> > and all should be the same domain?
> >
> > From my perspective, this is the issue we are facing with TC/SC
> > mapping.
> > I respect that some registries and domain operators wish to have
> > TC=SC, but
> > I think, as a consumer, I wish to have the option to treat them
> > differently.
> >
> > Edmon
> >

---

From: "ben" <[email-masked]>
Date: Thu, 16 Aug 2001 11:32:47 -0400

Hi Edmon,

I could care less about other registries and what they do.

However, I do care about my own "Supreme CDN system" because this
system takes the benefits of others to combine into a supreme.  It is
to be implemented for the benefit of everyday ordinary people who will
be the user of CDNs.  My supreme system does not allow mixing unless
you can give me a good reason.  If I think you have a good reason,
then I will modify my draft.  Otherwise I will not.

Tell me how confusing "ColorColourColor.com" and
"CentreCenterCentre.com" can be.  Then multiply that confusion
exponentially due to the "one to many" mapping of TC/SC chinese (among
others)... and you have the reason why I do not allow mixing of TC and
SC in my supreme CDN system.

Thanks
Ben Chan

---

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

> I could care less about other registries and what they do.

Then there is no IETF issue for you.

...
> then I will modify my draft.

What draft?

---

From: [email-masked] <[email-masked]>
Date: Fri, 17 Aug 2001 00:15:53 +0800

Edmon:
            I will try to give some explaination althought my english is not
good. I can told to you straightly that if many Chinese people (including
Taiwan, HongKong & Mainland China)see your example and wishness, they will
be very angry to your description. Why ?
            In Twaiwan,  HongKong we use BIG5 code and many simplified
scripts can not be key-in and displayed in their system. Many people they
know traditional chinese characters but they don't know its corresponding
simplified characters.  Reversely, in mainland china people only know
simplified characters. The corresponding TC/SC has the same pronunciation
and meanning.  Todday people want to communicate each other, they regist a
domain name for some trade mark reasons , but the ML.COM system can not
provide the same chance to protect their rights. People in Taiwan regists a
TC name but he can not key-in to regist the corresponding SC name because he
even don't know how to do it . Then one day , some people in mainland china
they regist the corresponding SC name in SC.COM , it is the same meanning
and prouncing in TC.COM . What will be happen ?  You know that PRC and
Taiwan , even HongKong are different goverenment ,  the argument in
intellegent right is a big trouble.  The case is very like that you allow
one people to regist ABC.com and also allowed another people to regist
abc.com and told them  that is an option and chance . Are you like english
are treated in this way ? Why case folding is needed ? Only the history
reason ? Why full case alphabet must be mapped to ASCII ?
             Are you like to make trouble to us ?  That is why department of
China  information industry against chinese.COM so deeply.
             I don't care the mixing of TC/SC , but I care why we are forced
.....

L.M.Tseng

---

From: "ben" <[email-masked]>
Date: Thu, 16 Aug 2001 12:33:36 -0400

Hi Eric,

> Then there is no IETF issue for you.

My IETF issue is to get support for my "supreme CDN system" to be
implemented as a standard.  Do I have your support?

> > then I will modify my draft.

I said "draft", I did not say "Internet draft".

Thanks
Ben Chan

---

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

> implemented as a standard.  Do I have your support?

and

> I said "draft", I did not say "Internet draft".

What "supreme CDN system"? What draft?

---

From: "Edmon" <[email-masked]>
Date: Thu, 16 Aug 2001 13:26:20 -0400

Hi Tseng,

First of all, I am all for a standardized SC=TC.  But I would rather see
that it is given as an option for registries or zone operators to determine
because SC and TC characters are characters in their own right.

The only real argument I see about this is the DNSSEC issue Erik Nordmark
pointed out, but I can see that there are ways around it but it would mean
that we would have to slightly adjust DNSSEC which we have agreed is totally
outside of the scope of this wg.  So if we are forced to make a decision on
this without the liberty to adjust DNSSEC (which as far as last IETF meeting
some of it might even never see day of light), then it is a rather
unfortunate situation.

Please do not confuse my thinking as to me being against SC=TC, I am
expressing my concern as a consumer wishing to have a choice.  Also,
philosophically I believe they are different characters.

> and meanning.

That is the reason why we have unicode in the first place.  Also you have
pointed out a very good reason why TC and SC are different.  Many people
know TC and not SC and vice versa, so why and how would someone confuse a TC
domain with an SC domain?

> Todday people want to communicate each other, they regist a
> intellegent right is a big trouble.

That is why I champion the SC=TC option for registries.  The problem about
forcing TC=SC into Nameprep is that we will loose the option at all levels.
Even if I own <TC>.com I wont be able to distinguish <TC>.<TC>.com from
<SC>.<TC>.com or worse, if I am now called abc.com I wont be able to have
distinct sub-zones <TC>.abc.com and <SC>.abc.com.  That is the main problem
I see and as a group we should contemplate on this matter too, not just the
second level domains that are sold.

> The case is very like that you allow

I disagree to your analysis, TC and SC is rather like
Color and Colour AE and BE (American English and Bristish English)

so Color.com is different from Colour.com

and yes they are registered by two different parties.

>              I don't care the mixing of TC/SC , but I care why we are
forced
I dont really get your question here, but again I stress that I think it is
important to have a standardized TC-SC conversion mechanism, but we should
also allow individual zone operators to decide whether the TC=SC rule should
be applied.

Edmon

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 16 Aug 2001 13:45:58 -0400

Over dinner (in a chinese restaurant in the China Town district of London,
of course), a vendor (here nameless) offered his opinon that ASCII users
will enjoy the use of "$" as an alternative to "s" (or "S"), when "$" (and
POSIX shell meta-characters are added to the ACE-or-native-via-utf-* IDN
character repetorire.

Thus:

	www.johnnyca$h.com
	www.micro$oft.com

(Note: www.johnnycash.com is a site, operated by the Estate of Johnny Cash,
 and www.microsoft.com is a site, operated by the MicroSoft Corporation)

I was unamused. Vendor promotion of locally scoped "surprises" is infra dig.

The same vendor, and some others not associated with any known vendor or dns
operator, also advocates TC/SC equivalence rules by registrants, which as L.
M. Tseng notes, would not amuse users on the Mainland, in Taiwan, or in Hong
Kong.

It is not useful to continue down this path.

2^^(number-of-chars-in-name) non-equivalencies does not scale, and that is
only for simple case of 1-to-1 character mappings.

The equivalences for Chinese characters are not privately defined, at least
not interoperably.

Eric

---

From: Bill Manning <[email-masked]>
Date: Thu, 16 Aug 2001 11:23:20 -0700 (PDT)

% 
% Hi Eric,
% 
% > > I could care less about other registries and what they do.
% >
% > Then there is no IETF issue for you.
% >
% 
% My IETF issue is to get support for my "supreme CDN system" to be
% implemented as a standard.  Do I have your support?

	While I'll leave Eric to answer that question for himself,
	I am left cold by your attitude regarding IETF participation
	and consenses building. Until you are willing to learn from
	others and have responsible dialog, it is my opinion that
	you will not gain support for your flawed ideas.
	But, since you don't care about other registries, interoperability
	is not an issue... ergo, its not an IETF issue, your SCS is a closed,
	propriatary solution.  It will never be a standard.

% > ...
% > > then I will modify my draft.
% >
% > What draft?
% 
% I said "draft", I did not say "Internet draft".

	Again, what draft. Neither Eric or I mentioned "Internet Draft".
	Further evidence that your idea is closed and propriatary. Perhaps.
	
% Thanks
% Ben Chan

-- 
--bill

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 17 Aug 2001 02:34:05 +0800

Hi Prof Tseng,

I think this TC/SC issues have been discussed again and again. The only
contention is of course how to solve the the problem. I hope we can
agree that so long this TC/SC is been handled, the exact mechanism is
open for discussion.

I spend several hours discussing with eric chen, wenhui, deng xiang and
others on this in London and I hope they have brought back my
suggestions to you.

My stand on this is as I stated during the meeting. Nameprep must be
uniform. There should be no optional folding which would be done in some
but not in others. Not every application of domain names have the luxury
of user interface or asking the user for information (note: email
servers, digital certificate authorization etc).

Therefore, if TC/SC is to be done in Nameprep, then I would prefer it to
be done across the board. But of course, this would means languages
which uses Chinese script (like kanji and Hanja) would also do the
same folding.

This is why I suggested that TC/SC to be done on zone file level and not
Nameprep. For those who knows Chinese, TC/SC is not really a 2^n problem
so lets not continue this misconception (It is closer to a n*2 to n*4
opertionally). And the memory problem could be simplified by ultizing
some algorithm (since it is fairly structured) to reduce the memory
usage. It can be done and it have been done. (We done it for 2^n btw
with reasonable memory use).

Of course, ultimately, the decision would still lies on the document
authors to come to an agreement on the approach and consensus in the wg.
But lets not forget why we are doing IDN in the first place so lets not
get too carried away in our discussion.

In the meantime, I would like to recommend the authors for tsconv to
complete the draft. The tables mapping is not complete. I would suggest
submitting the draft to Unicode Consortium or some other code point
expert group for review if possible.

Thank you.

ps: No, I did not attend Eric Brunner's UTF-8 dinner. Both Marc and
myself are tied in meeting prepration. We are interested in the
discussion tho so if anyone keep notes, please post.

-James Seng

----- Original Message -----
From: "[email-masked]" <[email-masked]>
To: "Edmon" <[email-masked]>; "ben" <[email-masked]>;
<[email-masked]>
Sent: Friday, August 17, 2001 12:15 AM
Subject: Re: [idn] opting out of SC/TC equivalence

> > I have seen quite a number of brand names now beginning to have
TC-SC mix
> in

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 17 Aug 2001 02:39:27 +0800

Once again, wearing my co-chair hat, I need to cut this discussion on
"Supreme CDN". There is no Internet Draft, and neither is it in the core
interest. Hence, lets not waste working group bandwidth on this further.

Further discussion on Supreme CDN should be bring offline. Thanks.

Ben, it would also be worthwhile to look at "The Tao of IETF"
(http://www.ietf.org/tao.html) to get a understanding of how IETF
function. You should also read up RFC2026 on process.

-James Seng

----- Original Message -----
From: "Bill Manning" <[email-masked]>
To: "ben" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>;
"Edmon" <[email-masked]>; <[email-masked]>
Sent: Friday, August 17, 2001 2:23 AM
Subject: Re: [idn] opting out of SC/TC equivalence

---

From: "ben" <[email-masked]>
Date: Thu, 16 Aug 2001 16:37:39 -0400

Hi James / Bill / Eric,

I sincerely apologize for my young cocky attitude.
I will submit my draft as an internet draft and hope very much to have
all your support for my Supreme CDN system.

Thanks
Ben Chan

----- Original Message -----
From: "James Seng/Personal" <[email-masked]>
To: "Bill Manning" <[email-masked]>; "ben" <[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>;
"Edmon" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 16, 2001 2:39 PM
Subject: Re: [idn] opting out of SC/TC equivalence

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 17 Aug 2001 04:48:20 +0800

Ben,

Just like to make a clarification: I did not forbid the discussion of
supreme CDN because of your personality or attitude or whatever. It is
because of "Supreme CDN" as it is now is not within the core interest,
at least not yet. Therefore, please respect the working group process
and bring the discussion of supreme CDN offline.

Once you have an Internet Draft and gathered 7 supportors to demostrate
core interest, then we would welcome further discussion.

Aside, I strongly suggest reading RFC2026 on Internet Standard Process.
I recommend Tao of IETF also because it contains a lot of useful
information for newcomer to IETF (even tho you did not attend the
meeting itself).

Thank you.

-James Seng

----- Original Message -----
From: "ben" <[email-masked]>
To: "James Seng/Personal" <[email-masked]>; "Bill Manning"
<[email-masked]>
Cc: "Eric Brunner-Williams in Portland Maine" <[email-masked]>;
"Edmon" <[email-masked]>; <[email-masked]>
Sent: Friday, August 17, 2001 4:37 AM
Subject: Re: [idn] opting out of SC/TC equivalence

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 16 Aug 2001 17:03:56 -0400

Absent mechanism, your policy desires are as binding as those of the State
Legislature which abolished snowfall in that State.

---

From: "Edmon" <[email-masked]>
Date: Thu, 16 Aug 2001 18:06:52 -0400

Hi Everyone,

Tseng has convinced me over a couple of emals on the need for an SC=TC
equivalence for some characters.  I now think that some characters might
benefit from an across the border SC=TC equivalence.  However, I still think
that this rule should not be applied for all SC characters.  I will take
some time to work on CNNIC & TWNIC's list in their TSconv draft and see if I
could improve the list a bit.  I would actually like to work with the
authors of the TSconv draft on this too.

In general, I now think that some characters should be mapped as equivalent
(I will give it some more thought) such as:

the chinese characters: U+7D71 = U+7EDF (for those who know Chinese they are
the TC and SC characters for "unite"... loosely translated)

But others which are not really similar should remain individual characters,
such as:

the chinese characters: U+5C08 != U+4E13

Edmon

---

From: "ben" <[email-masked]>
Date: Fri, 17 Aug 2001 09:52:56 -0400

Hi James/Bill,

> propriatary solution.  It will never be a standard.

I have formally submitted my draft.  As James has suggested, I will
try to build up support off-line before I bring my "Supreme CDN
system" back to the public discussion.

I truly do want to apologize to the registries for saying stupid
things like "I don't care about the registries... I only care about
myself...".  I do want to learn how to build consenses as I am
starting to understand what interoperability is all about and the
importance of it.  I will email people privately to get support and I
hope that they can see beyond my past cocky attitude and look at my
idea for what it is worth.  With all humblenss, my idea is not only
not flawed, but if you take the time to understand it, you will find
that it indeed can be applied to solve many problems and issues we
have with CDNs.  I did not call it a Supreme for no reason.

I had a bad attitude... but my intentions had always been good.

Thanks
Ben Chan