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

From: "ben" <[email-masked]>
Date: Fri, 10 Aug 2001 07:12:16 -0400

Actually, let me clarify what I agree with...

How one feels about this SC/TC equivalence problem really does depend
on which position one takes as decribed by John.

Thanks
Ben Chan

----- Original Message -----
From: "cc-www.com (Ben)" <[email-masked]>
To: "John C Klensin" <[email-masked]>; "Edmon"
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, August 10, 2001 6:51 AM
Subject: Re: [idn] opting out of SC/TC equivalence

Hi John,

I agree with what you said below.

Thanks
Ben Chan

----- Original Message -----
From: "John C Klensin" <[email-masked]>
To: "Edmon" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 09, 2001 11:03 AM
Subject: Re: [idn] opting out of SC/TC equivalence

--On Thursday, 09 August, 2001 10:36 -0400 Edmon
<[email-masked]> wrote:

> Which means that TLD dependent SC=TC should not create any
> problem on a user expectation stand point.
> If you know that typing <SC>.cn and <TC>.cn goes to the same
> place, it will happen no matter where you are connected to the
> network. But that doesnt mean that <SC>.tld and <TC>.tld must
> therefore go to the same place.
> There should be no compelling user expectation for this to
> happen.

Edmon,

Let me say to you --and the WG-- what I said to Dave Crocker
after our exchange of comments at the mike.  It seems to me that
the WG is singing one song, but dancing to a different tune.
There are, I think, two, perfectly reasonable, positions:

(i) The IDN effort is about identifiers and characters,
not about languages or even strings.

(ii) The IDN effort is about making it possible to put
non-English words and phrases into the DNS, just as it is
feasible to put English ones (with some constraints)
there today.

Now, if we really believe the first, then it is not clear how
much of nameprep is needed (somewhat less, I think, although
probably not zero).  But discussions of SC/TC equivalence, Arabic
non-spacing break characters, similarity of characters with
non-similar glyphs between languages, distinctions between CJK
contexts, similar characters in different scripts or blocks, and
so on, are all irrelevant and inappropriate -- those are _all_
conversations about words, languages, and the way language
phrases are written.

But many people --I would suggest a majority of those who care
about the IDN issue, independent of those explicitly represented
in the WG-- are interested in words and languages.  To the extent
that they really represent the requirement for this work, all of
the issues excluded above are important and cannot be excluded.
Your assertion about "no compelling user expectation" is, in that
context, false: a compelling user expectation has been asserted
by CNNIC and others.

And, if any of those language issues are part of the real
requirement, the WG is simply at risk of being irrelevant.  Not
wrong, but irrelevant.   If one reaches that conclusion, then
there is a procedural and responsibility question as to whether
the WG should (and can) report that it can't, within its charter,
do anything relevant or whether it is obligated to report
_something_ out anyway.

    john

---

From: [email-masked]
Date: Fri, 10 Aug 2001 12:24:21 -0700

You got my point wrong.  We are not in the same discussion 
space.  SC=TC discussion is only regarding font difference.  
The semantics are basicaly the same, but the reader groups 
are different.  It may be said, this is analogy to Latin uppercase
and lowercase folding.   As a registrant, if the choice is two 
places: SC+TC, then it is a reality already, we don't need this 
standard discussion right now.   And to Ben Chan also, 
 we have TLD are doing exactly the same thing:  .tw and .cn
too.  As a server provider, you may choose to display .tw in TC, and cn
in SC as an equivalent solution to your suggestion without
get into this WG.

Liana

On Fri, 10 Aug 2001 06:33:05 -0400 "Edmon" <[email-masked]> writes:
> From: <[email-masked]>
> > If I want two places, I can
> > take care of that by registering at two places.
> >
> 
> That is precisely my point.  If we force SC=TC into Nameprep I wont 
> be able
> to register the TC and SC as different domains.  I dont have a 
> choice.
> Edmon
>

---

From: "ben" <[email-masked]>
Date: Sat, 11 Aug 2001 16:50:22 -0400

> Hi, Ben,
>    .tw is used mostly by users who want TC characters,
> and .cn users mostly wants SC characters.  As a service

"used mostly" is not good enough.  Either they use all TC or all SC.
If not, then there must be a SC/TC equivalence

> provider, you can display .tw as .taiwan in TC, and display
> .cn as .china in SC character set.   When people click on
> the URL, you send out .tw to DNS instead of .taiwan in TC.
> This way you can provide what the user wants to see
> without bother DNS.

Yes, you are correct that .tw is the same as <.taiwan> and .cn is the
same as <.china>- BUT ONLY if the either the ISP or the client
downloaded special software.  Also, TC and SC are used interchangeably
regardless of country so <.taiwan> does not mean TC and <.china> does
not mean SC.  That is the whole point of TC<->SC equivalence.

Thanks
Ben Chan

>
> Liana
>
> On Sat, 11 Aug 2001 09:54:56 -0400 "ben" <[email-masked]> writes:
> > Hi Liana,
> >
> > I am not sure I understand what you are trying to say.
> >
> > Thanks
> > Ben Chan
> >
> >
> > To: <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>;
> > <[email-masked]>
> > Sent: Friday, August 10, 2001 3:24 PM
> > too.  As a server provider, you may choose to display .tw in TC,
and
> > cn

---

From: [email-masked]
Date: Sun, 12 Aug 2001 04:06:43 -0700

Agree.  That is the reason we have to do this standard.

Liana

---

From: "ben" <[email-masked]>
Date: Tue, 14 Aug 2001 16:55:11 -0400

>  1. What is SLD?  It is easier  for a reader to see it's definition
> before abbreviation.

For the benefit of everyone, SLD is "second level domain". 

Thanks
Ben Chan

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 15 Aug 2001 06:54:35 -0400

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, August 15, 2001 2:11 AM
>To: ben; Adam M. Costello; [email-masked]
>       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 composing labels of "mixed" Unicode code points is believed to be a key
problem, that's an issue with current draft documents being developed and
discussed in this WG -- which clearly permit this method of composition.  If
such a composition method doesn't make sense in a particular local context,
it likely won't be widely used to create labels in that local context -- but
that doesn't imply that the conventions of the local context should be
applied everywhere else.

This WG shouldn't attempt to produce solutions particular to a specific name
space.  The end result should be applicable to _any_ name space.

<Scott/>

---

From: [email-masked]
Date: Thu, 16 Aug 2001 12:05:25 -0700

It looks like that I have to do more explaination
on this "force SC/TC" into [nameprep] issue.  Reference
to the last message I have sent for the model:

	[nameprep]			ACE
GB > SC Unicode 
Big5>SC Unicode			ACE encoding > Tagged-ACE
Mixed Unicode > SC Unicode	
Latin Case folding
JIS > SC Unicode
KSC > TC Unicode
ISCII > Indic Unicode

For the display part of this model, the users do have choices
on what they want to see, and recall that [nameprep] is used as
a database, you have both referencing access through IDNA:

received		de-ACE & referred 		output
ACE		[nameprep]

Tagged-ACE	SC Unicode >GB			GB
		SC Unicode > TC Unicode > Big5	Big5	
		SC Unicode > TC Unicode 	select 2 SC only >Mixed Unicode
		SC Unicode > JIS		JIS

fre-casefolded.com 				PutDiacriticMarkBack.com
		TC Unicode > KSC		KSC
		Indic Unicode 			Indic Unicode 

Edmon:
Thank you for the reminder.

Liana

On Thu, 16 Aug 2001 13:26:20 -0400 "Edmon" <[email-masked]> writes:
> 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.
> 
> 
> From: "[email-masked]" <[email-masked]>
> >             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.
> 
> 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
> > 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.
> 
> 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
> > 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 ?
> 
> 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.
> 
> 
> >              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
> > .....
> >
> 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: [email-masked]
Date: Thu, 16 Aug 2001 14:34:31 -0700

On Thu, 16 Aug 2001 05:45:33 +0100 David Hopwood
<[email-masked]> writes:
> 
> I think that that way lies pointless complication and unnecessary 
> delay
> in finalizing the standard, for a feature that is only of minor 
> benefit
> to users. 

Are there any decisions on the architectural and relationship 
between all these drafts?  I thought it is an open question.  
Please enlight me.

In the case of guessing a web site name, if a user can't 
> find
> the name immediately then he/she will just use a search engine, and 
> the
> search engine will work regardless of what script is used. In other 
> cases,
> domain-name-based identifiers such as email addresses and URIs can't
> realistically be guessed, so will come from either:
> 

Are you suggesting an IDN hostname search engine below  
a current DNS search engine?  So for most "mixed script" 
of your definition would have to go through two searches to 
find its hostname?

Liana

---

From: [email-masked]
Date: Thu, 16 Aug 2001 16:55:15 -0700

[email-masked] wrote:

>So, use of alphabetic case folding does not imply anything about whether
>TC and SC should be folded; that's a separate decision. There's a
>"slippery slope" argument here: if TC/SC are folded, why not Latin <->
>Cyrillic transliteration (used for Serbo-Croatian or in Azerbaijan, for
>example), or any of the other cases where a language can be written in
>more than one script? I see that later in your post you suggest Kanji/SC
>and other foldings.

You have read this correctly.  It is not a "slippery slope" argument,
it is what we can do to finalize IDN without any additional search 
engine complication. Here is a graphic view:

Application  >	IDNA  use [nameprep]  
		do extended case folding >   tag-ACE  > DNS

Liana

---

From: [email-masked]
Date: Thu, 16 Aug 2001 18:36:35 -0700

On Thu, 16 Aug 2001 08:03:25 +0100 David Hopwood
<[email-masked]> writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> [email-masked] wrote:
> > So, the proposal is:
> > 
> >         [nameprep]                      ACE
> > GB > SC Unicode
> > Big5>SC Unicode                 ACE encoding
> > There are limited number of standards which is referenced
> > by Unicode standard, where we can allow limited number of
> > them to make into [nameprep].
> 
> Why would we want or need to make any restriction on other charsets 
> that
> can be mapped into Unicode? A name is assumed to be expressible as a
> sequence of Unicode characters; that's all that is required. 

Because there are large existing user base using particular 
national standard, and the users do not want download 
anything large and they do not want to use.  For example,
the users in China are happy with their GB coded software.
In such a case, it is the server doing the IDN.  Other new
users can use a new IDN, Unicode enabled software directly.

> nameprep
> is a step that is applied to labels *after* expressing them in that 
> way
> (so that if a label contains both alphabetic and ideographic or 
> syllabic
> characters, for example, case folding will apply to the alphabetic
> characters). There is no difference in treatment of labels according 
> to
> which charset they may originally have been encoded as.

So, there will not be any consideration for CJK users as it was
in DNS system?

> 
> The only technical requirement needed to make this work is that 
> nameprep
> folds at least canonically equivalent strings, so that there are no
> artificial differences introduced by transcoding, and so that
> NFC-normalizing transcoders can be used (as recommended by the W3C
> character model).
> 

What is your definition of "artificial differences"?  Could you give me
some specific examples?

Liana

> 
> In any case, do we have a concensus on the following point: that any
> TC/SC folding will not be implemented in nameprep? ('nameprep' here
> refers to whatever client-side canonicalization algorithm is applied
> automatically to all names.) That is the only thing we need to 
> decide
> about TC/SC equivalence as far as the protocol definition is 
> concerned.
> 
> - -- 
> 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
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
> 
> iQEVAwUBO3twITkCAxeYt5gVAQGCrgf8CbjaVd8ihghg7QZSpeDg5zGBXq+NuJgz
> scgLo+1d1L/xyVMqXP6INqashL7nCMYn8NslwGMgzk9N8NAvXvV81KE0qdOuGhMq
> BMM2tCexcIFsg35llJGA1m0B7CHtDQYLXW4HxfD19d+KVfE6A7f2TMlAUQobR5zB
> A/CcQ7X1aWomXKAqM6hZ+3K9RCOeGTijSqYjM00T3ArfmSxiBRUXPUVxaBjcmLd/
> GbE4wydLWEMyItxCOFg/wT7yw4nqar9WVZ9xT0JhLMcIuNt8ImN7j6PCY/Oudd8G
> yfBwaJxQGltt10i3Yr+bBff8+Zr6FuCaoV1yJ9KEzYvijbm7Ix2Mgw==
> =OXdg
> -----END PGP SIGNATURE-----
> 
>

---

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

Pardon me:

> While I am incline to (a) (altho I have not hear any formal complain
> that multilingual naming is out-of-scope), (b) is an option I am
prepare
> to take if this is the consensus of the wg.

Correction: I have formal note (not really complain) from wg members
that multilingual naming is out-of-scope.

-James Seng

---

From: [email-masked]
Date: Fri, 17 Aug 2001 12:35:10 -0700

Hi, James and all:

After some sleep, I am ready to type more.

I am proposing a [nameprep] case folding table for Chinese
where 
+ means concatenation, 
Px means xth radical in Latin letters.

zho-
Unicode    	Unicode    Big5      	GB	StepCode
TC	   	SC	    TC         	SC       Pinyin+tone+P1+P2

So the TC to SC mapping is embeded in, and IDNA can 
decide on how long the StepCode is needed to register
a unique name and the pre-registered form is kept at 
zonefile level. So the name can be over 63 octect limit without
burden other protocols. 

For Japanese, replace Pinyin with Romaji.  So there are
cases that one Unicode Kanji will have 3-4 Romaji entries.
(This is allowed for zho- table too.) Thus:

jap-
Unicode    	JIS		StepCode
Kana		Kana		Kunrei 
Kanji   		Kanji	   	Kunrei +P1 Kunrei +P2 Kunrei

Where Romaji shall use Kunrei system since it is the adopted
system by Unicode naming.

For IDNA processing: using radicals code in pre-registered
form, and register the short form (by truncate radical code) to keep
the name under 63-octect. 
	
I do not suggest Han characters for Vietnanese, since they seem
happy with the script using many tones.  While tone mapping can
be done in a similar way with Arabic.   But the option is open
for Vietnanese, since they can create a similar mapping table if
they can show an official adoption for a Romanization mapping.

Liana Ye

On Fri, 17 Aug 2001 17:05:34 +0800 "James Seng/Personal" <[email-masked]>
writes:
> Dear Prof Tseng,
> 
> > Hi James,
> >              I  think you can display these chinese characters in 
> your
> > system, so you can make
> > the explaination , and  tell me the answer how to treat them ?
> > TC(�? , SC(�?
> > TC(�?,  SC(�?
> 
> These example stated at first level simplication of chinese by 
> radical.
> They are equivalent in most context of Chinese language so I think we
> can both agree on this. And yes, it is not handled in current
> normalization or nameprep.
> 
> How can we solve this? Many ways, each one with its pros and cons. I
> will provide some suggestions but I am sure there are other ways:
> 
> 1. Do it inside Normalization Form KC (Standard Track)
> 
> Speak to the Unicode Consortium, convience them that these two 
> ideograph
> are equivalent and put into NFKC. This will go directly into 
> Nameprep so
> long Unicode Consortium agree with it since Nameprep just uses the 
> code
> points from Unicode Consortium.
> 
> The people at Unicode Consortium would probably question if these
> ideograph are equivalent in Kanji and Hanja or olden Vietnamese so we
> need to prepare for that.
> 
> Pros: it would be part of Nameprep standard. And if NFKC accept 
> this, it
> would also solve in other I18N efforts in future, and not just IDN.
> 
> Cons: we need to go thru the review process in Unicode Consortium.
> 
> 2. Do this "optional folding" pre-Nameprep (Informational based)
> 
> We would define these mappings within IETF, but published it as
> Informational based as an optional folding for Chinese system only.
> 
> Pros: We do this within IETF with probably assistant from other group
> for review. It also open Nameprep for localized foldings depending on
> other set.
> 
> Cons: It may be difficult to determine what optional folding rules
> should apply for a name. A Japanese (or Cyrillic) names could be 
> entered
> using GBK for example and which rules do we apply? And who has 
> priority
> to decide what folding mechanism? The registrant of the name or the 
> user
> of the name? Is 中国.com a Chinese domain name "zhongguo.com" 
> referring to
> China.com or is it a Japanese domain name "chugoku.com" referring to
> another place in Japan?
> 
> 3. Do this in the zonefile (Best Current Practice?)
> 
> We would define these mappings in the zonefile for DNS and hence
> irregardless how the user type it in, they will end up with the same
> resource records.
> 
> Pros: It is an opertional issues for Chinese domain names. 
> Registrant of
> names would controll what is equivalent and what is not and that may 
> be
> defined as a policy on a per-zone basis.
> 
> Cons: There would be multiples entries in the zonefiles but they can 
> be
> solve by software implementation to generate these entries on 
> loading.
> 
> Therefore, there are many solutions to the TC/SC problem. Which path 
> to
> take would depend on the tsconv author decision and the wg 
> consensus. No
> solution is perfect and it is all engineering trade-off.
> 
> Speaking for myself, I would love to see this get done in (1) 
> because it
> means it will solve it for other protocol, not just domain names in
> future. But I am not sure how to address Unicode Consortium concern. 
> I
> am strongly against (2) approach because it will solve the problem by
> creating other problems. Implementation experience have been proven 
> to
> be very headache to maintain and 'guess' optional foldings to be
> applied. I believe (3) is a reasonable approach altho not a perfect
> solution either.
> 
> > They are  the same chinese characters in pairs but they are coded 
> with
> > different  UNICODE .
> > Does they are like the problems of   " fi " ?
> > And  tell me  why  ａ　Ａ　should  be mapped to ASCII  "a" or 
> "A" ?
> 
> Problems like "fi" and "a" vs "A" are handled in Nameprep not because
> IETF decided so, but rather the code points from Unicode Consortium 
> have
> these mappings/normalization.
> 
> IETF is not in the business to define codepoint because we are not
> script or language expert. We leave it to other groups who have more
> expertise and we reference their work. Thus, this question is most
> appropriate ask to the Unicode Consortium, and not in this WG.
> 
> > I don't expect  this WG to solve all the equivalence of TC/SC. I 
> just
> want
> > to know what is the guideline to reduce the confusing troubles in
> nameprep ?
> > Why so amall set of  PRC simplified quick-written scripts are not 
> case
> > folding problem ?
> 
> God knows I agree with you. :-)
> 
> But this is a question which this WG have no answer for since it
> references it code points from other place.
> 
> -James Seng
>

---

From: [email-masked]
Date: Fri, 31 Aug 2001 01:58:43 -0700

You are correct in either/or not both as current ASCII
world.  If we go IDN, a good webpage can display 
IDN or send it out after [nameprep] it.  If you do not 
let TC/SC mapping into [nameprep], all the
 internationalized <Chinese>.com can only use the 
current cut and paste feature with ASCII version, 
which is uniform for everyone.  If you
do let TC/SC into [nameprep] it can have limited 
TC/SC rate, which is good enough for a lot of people. 
This is up to TSCON's definition listing.  Users will
treat technology with a little salt in it.  When a user 
application decide to translate a URL before it is 
displayed or sent out, cut and paste can have a good
 chance to be [nameprep].  Isn't this IDN's goal?  Or
are you thinking of changing everything into UTF-8?

If we follow John's keyword searching scheme, then 
<Chinese>.com has to go through another level of 
guessing stage.  Then it will be impossible for 
<Chinese>.com to get cut and paste feature.  Because  
this becomes an AI technique issue not a font 
display issue any more.  We are dealing with identifiers
not artistics expresstions of an address.  Chinese 
has a lot of aritistry, but hostname is not a place for 
that TC/SC perfection.  

Liana

On Fri, 31 Aug 2001 08:42:15 +0200 Harald Tveit Alvestrand
<[email-masked]> writes:
> to my mind, it seems that you can have keyword search with 
> near-perfect 
> TC/SC equivalence, OR cut-and-paste URLs and email addresses without 
> TC/SC 
> equivalence.
> 
> Not both in the same part of the user interface at the same time.
> 
> --On 30. august 2001 14:55 -0700 [email-masked] wrote:
> 
> > To the keyword type of solutions, it is good for name
> > registration only.  It is slow and painful, a good toy to
> > study with, but not good to use as day to day tool,
> > especially unthinkable if I want cut and paste type of
> > URL implementation.  So, I am agaist keyword search
> > type of e-mail addresses, but still interested in
> > any solutions to guess how it can be implemented in
> > English.
> 
>

---

From: [email-masked]
Date: Fri, 31 Aug 2001 11:30:46 -0700

I do have a proposal, but it is not complete. I am 
waiting for references to be arrived from US mail.

The relevent part of the proposal of this discussion
has two parts: Using script tags to patrol certain 
range of UCS which is relevent to that scripts.  This
is posted a few days ago, no one seems to care
about.

The second relevent part of this discussion is a 
relational database model of [nameprep], I had
three postings on it too.  Nobody seems care about it 
either.  Why do I want to talk more about it?

Talking about scoping of this WG? which is defined
in [RFC 2825].  Please check it. 

To answer John's question:

>And, unless whatever is done is isolated -- through procedures,
>structure, or layering-- in a way that is robust, accessible to
>all users of URLs based in the Chinese language, and that does
>not fragment the Internet, we also need to be sure that the
>tables and mechanisms that do SC/TC equivalence don't
>accidentally map Kanji or Hangul into SC.
>
>   john
>

A part of the database table look like this:

Unicode	     Unicode    GB	  BIG5     Chinese		Unicode   KSC    Korean		
CJK	     TC	              		StepCode	Hangul		StepCode

For some rows Korean does not use, which would be empty.
This is one search operation for mapping and ACE encoding!
And this will take care of Kanji, Greek and Cyrillic mapping too.

When IETF accepting this model and let local standards have
direct access of [nameprep] the GB<=>BIG5 mapping takes
care of TC/SC mapping table. 

Liana

On Wed, 29 Aug 2001 07:07:57 -0700 Dave Crocker <[email-masked]>
writes:
> At 01:20 AM 8/29/2001, Harald Tveit Alvestrand wrote:
> >--On 28. august 2001 13:40 -0700 [email-masked] wrote:
> >>    I happend to have an idea that 1100 half size
> >>code point may solve part of the problem and another 200
> >>TC/SC listing completes it.  This can be used in [nameprep].
> >>What do you think?
> >
> >I would be happy to see a complete proposal.
> 
> 
> Excuse me, but I had the impression that solving this problem was 
> rather 
> clearly outside of the requirements for this working group.
> 
> At a minimum, it would be very helpful to get explicit resolution 
> about the 
> requirement to solve this, in this working group, as well as the 
> requirement to solve it immediately, rather than consider it for a 
> later 
> version of the working group effort.
> 
> d/
> 
> 
> ----------
> Dave Crocker  <mailto:[email-masked]>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464
> 
>

---

From: [email-masked]
Date: Fri, 31 Aug 2001 11:44:27 -0700

That is the requirement, and we can make a new 
architecture proposal, and let Latin script go 
forward for ML.com in a timely maner, and let
CJK works on their own Tagged conversion,
reversion, display, and TC/SC procedures. 
The proposed architecture has no conflict with
the work already done in this group.

Anyway, you CAN deliever this ML.com and chuck
our input .  The world is not going to stop without
any of us.

Liana

On Wed, 29 Aug 2001 20:45:05 +0900 Martin Duerst <[email-masked]> writes:
> At 07:31 01/08/29 -0400, John C Klensin wrote:
> No problem for Hangul, which is a completely different script.
> But for most Hanja (ideographs as used in Korea) and many Kanji
> (only many because some are already the same as SC, and in
> some cases, Japan has it's own simplifications), there is
> absolutely no chance to be successful (i.e. only map SC/TC,
> but not Hanja or Kanji). If that's the requirement (and I
> agree it is), then we don't have to continue the discussion.
> Sorry if I disappoint anybody :-(.
> 
> Regards,   Martin.
>

---

From: [email-masked]
Date: Fri, 31 Aug 2001 15:18:14 -0700

Hi, Paf:

This exactly the type of question the CJK unification likes to
resolve for CJK domains.  That is the reason we argue for
not releasing [nameprep] prematurely until we know what
is the first step to be released without damage the long 
term goal of IDN. 

And that is the reason, Chinese only distribute numbers
in their domain registration. 

Liana

On Fri, 31 Aug 2001 22:40:00 +0200 =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=
<[email-masked]> writes:
> --On 2001-09-01 00.44 +0800
> "=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
> <[email-masked]> wrote:
> 
> >            As Patrik F?¤ltstr?¶m  described , if it is a 
> mechanism in
> > UNICODE consosium , then they have the version update procedures 
> and IDNA
> > also treat  the version update in UNICODE , why it can not be 
> updated step
> > by step  to  increse it ?
> 
> Very simple answer.
> 
> Let's assume that the table day one include the following 
> characters:
> 
> A
> B
> C
> D
> E
> F
> 
> We agree that the simple equivalence rules for 1-1 mapping maps 
> A->B.
> 
> This means that the following characters are available for domain 
> name
> registration:
> 
> B
> C
> D
> E
> F
> 
> People register domainames such as:
> 
> B.example.com.
> C.example.com.
> D.example.com.
> E.example.com.
> F.example.com.
> 
> Five different people register these five domains, which are 
> different.
> 
> If one type in A.example.com in the browser, nameprep will map that 
> name to
> B.example.com. So, A.example.com and B.example.com are treated as 
> "the same
> domain".
> 
> Now, let's say that we increase the size of that table, and decide 
> that D
> and E are equivalent, so D->E mapping should be added.
> 
> This means that only the following characters are allowed:
> 
> B
> C
> E
> F
> 
> The domains D.example.com and E.example.com are equivalent.
> 
> Now the questions, and I want you to answer them. Short answers are
> required:
> 
> (1) Should the holder of D.example.com or the holder of 
> E.example.com be
> forced to give back his domain?
> 
> (2) Who is making that descision?
> 
> (3) Who will tell the domain name holder that he is not allowed to 
> have his
> domain anymore?
> 
>      paf
>

---

From: [email-masked]
Date: Fri, 31 Aug 2001 20:36:02 -0700

Hi, Prof. Tseng:

The first step of our solution is to open [nameprep] 
to let local standards in for easy code exchange.  This
is an equal access issue.  The best place to demonstrate
such a feature is the "cut and paste" of an IDN URL 
e-mail entry.  It shall be a universal treatment at the end.

The second step is to define the ranges of different
user groups who need their primary script tag.  No 
mix scripts is allowed at this stage.  But we can take 
wish list.  For example, English may wish to include
Greek, Korean may want Hanja on its wish list. 
 That way, we can identify conflicts of codepoints and 
possible confusion of codepoints, and start with a 
careful first step.  A survey on the existing registered 
names for possible conflict when Unicode is 
used for limited scripts is helpful to start a clean first
deployment of [nameprep].  

Someone wants to lunch an unmature version of
 [nameprep] are very smart.  They probally have put 
a lot of money behind this working group already , where 
we are just a decoration voices to lead people believing
 that this is an open discussion, democratic process.
 Meanwhile, when we started to speak out, they are pressing
the group to rush out a premature version,  so that they 
can get ahead of [nameprep] and make the future upgrade 
very hard for others, so CJK at a great disadvantage on 
this.  The Chinese domains using numbers for their names
at this time for globle consideration would be trashed.

My feeling on this, there are more politics and money 
then technical issues hidden behind us.  I am not an
expert on any of this, even I can point out feasible solutions,
why they can not see it.  Why the "Scope of this  WG" is
so tight on them is beyong me.  As a user, we have been 
waiting for years, why suddenly, a few months of extension 
making so many people nervous?  Even Microsoft has 
sliping their published product delievery dates as long as 
6 months, why such a multitude complexing issue has 
to be pushed to a rushing date?????????????

So your first step TC/SC simple mapping in [nameprep]
which should be on the same footing with Latin case
folding being pushed away by all kind of nonsense 
argurments.  I think we are too naive.  We are better to be 
prepared to leave this discussion and bring the whole
 thing onto the news media, and let the public to be the 
judge. 

Liana

The third step is to let safe range go online for ML.com.

On Fri, 31 Aug 2001 18:08:13 +0800
=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?=
<[email-masked]> writes:
> Hi !  Liana:
>         I have the same feeling . We try  to solve these SC/TC 
> problem step
> by step and  to reduce the complexity.  As John had pointed-out in 
> this
> listing , sometimes many scripts-only term  will be expand to 
> lanaguage-term
> and let some one to neglect the key-point.  1-1 mapping will reduce 
> the
> complexity like mixing case of alphabet that will reduce the number 
> of
> non-necessary registration and confusing of using.
>         No one try to translate TC/SC in DNS. Even an expert of 
> chinese
> language also can not resolve  the different local naming  and habit 
> of
> personal name in different Province of China.  The PRC-SC is the 
> frequently
> used characters in chinese language, some of them can be 
> differentiated by
> different shape, but a little of them is easy-to-confuse ,  such as 
> TC(é ?
> SC(é¢?  SC (ç»?  TC (çµ?. James seems avoid to answer what is the 
> first step
> to solution.
>         If the easy-to-confuse characters can be reduced . Even a 
> little ,
> that is better than nothing to do.  Reducing the number of 
> easy-to-confuse
> characters in nameprep is a better help to CJK users.
>         Always to point out the complexity of chinese language and 
> never to
> solve some problem step by step is not a coorect approach in 
> engineering.
> 
> L.M.Tseng
> To: <[email-masked]>
> Sent: Friday, August 31, 2001 4:02 PM
> > Hi, James,
> >   That was a miscommunication on my part, that I did not
> > amend, since I did not see anyone care about except
> > Martin, which I have answered indirectly.  This is
> > realy two issues. One is one-to-one TC/SC mapping
> > in [nameprep]. With this part, we shall include GB, Big5,
> > and a few other standards representing local access
> > directly to [nameprep] and speeding up hostname
> > translation.  This is my 20% effort for 80% TC/SC cases
> > arguing for. [nameprep] shall only do one-to-one
> > mapping, no guessing or second try shall be there at
> > all.
> >
> > Another issue is direct mapping to StepCode part of
> > the proposal which is mixed up in that short
> > communication.  StepCode has Pinyin for each radical
> > already for SC character set.   More work is needed
> > to check against with larger character set such as Big5
> > and Unicode.   I thought if some published listing may
> > help out for Kanji and Hanja to encode,  just an idea to
> > throw out to be criticized, it does not mean to play with
> > TC/SC AI treatment in [nameprep].   After that, I was a
> > little regret, since  if the current architecture of [nameprep]
> > does not change,  I am putting up more work for nothing.
> >
> > Liana
> >
> > On Fri, 31 Aug 2001 12:50:45 +0800 "James Seng/Personal" 
> <[email-masked]>
> > writes:
> > > Iiana,
> > >
> > > I am not comment on other parts but your presumation that TC/SC 
> can
> > > be
> > > done by radical equivalence simplification is unfortunately
> > > misplaced.
> > > No doubts there are *some* cases whereby TC->SC can be done by
> > > changing
> > > radicals, it is not rule of the thumb.
> > >
> > > Once again, you may want to read the problems with TC-SC paper by
> > > Jack
> > > Halpern at http://www.basistech.com/articles/C2C.html first on 
> basic
> > > difficulties of TC/SC in general.
> > > http://playground.i-dns.net/one/onec_sum.htm (also by Jack)
> > > describes
> > > the more specific difficulties of doing TC-SC in Domain Names.
> > >
> > > -James Seng
> > >
> > > > As to TC/SC, I think the problem can be divided into two
> > > > levels. One level is the mechanical, one-to-one.  They are
> > > > the majority and bothering  the readers.  The minority as many
> > > > have said those n-to-1problem, normally one of them is
> > > > the major one, and the other are minor ones.  There are
> > > > always exceptions!!!  So to benefit the majority, the way to 
> deal
> > > > with it is to come up with an arbitary one-to-one, and let 
> Chinese
> > > > to fight which one is the major one!   The same principle is
> > > > applied to decomposition of a Hanja and Kanji.  When there
> > > > is a base, the rest will follow , the application will have
> > > > something to conform to.
> > >
> > >
> >
>