[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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" <edmon@neteka.com> 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: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>
> >             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
> 
>