Re: [idn]Re:[JET member 473] An ignorant question about TC<-> SC

[liana Ye <liana.ydisg@juno.com>]

> 
> > 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).
> > 
> > If we say matching of Uppercase/Lowercase English letter belong to
> > "matching of identifiers", what is different from 1-1 TC/SC ?
> 
> Because the 1-1 mappings of SC/TC are not part of any work by ISO or
> Unicode Consortium and because these bodies which work with 
> characters
> explicitly have told the IETF that only doing a partial solution is 
> NOT
> good. Just like the same bodies have not added mappings between 
> codepoints
> in parallell scripts in Eastern/Western Europe.
> 
> If it was possible to do such tables, I am a beliver that we would 
> have
> seen them. And even if it was possible, the Unicode Consortium would 
> not
> have told us that it is was not possible. Just because the tables 
> will be
> forever partial.
> 
> You say in this mail that it is better to have SC/TC mappings for 
> some
> codepoints, but not all. What do you think the users would say about 
> that?
> Is that really what you want?

You are mixing the user interface with engineering structure 
discussion here.  The final solution will be complelete solution
here, but with two layers.  The first layer is include 1-1TC/SC cases
as they are treated the same with upper/lower Latin cases, the second
layer handles n-1, 1-n cases.  I consider the [nameprep] is the first
layer, and is essential for  ANY IDN DRAFT  to suceed in handling 
Chinese. 

It is the TC/SC in [nameprep] is also bringing up what is the working
goal of this WG:
  
1.Will it deliver a subset of USC, as the current [nameprep] profile
  as the "Scope" of next working goal, as Dave's proposal implies?
 This will put 1-1, n-1 and 1-n TC/SC case all in layer 2, and is not a
 workable solution as many from Chinese groups have pointed out.

2. Deliver a subset of USC, include 1-1 TC/SC cases in   the current
 [nameprep] profile.  This will make  the East-West group discussion
 possible  for IDN architecture discussion at all.  I hope this is 
 a fair observation here.

This is also the "cost" Deng Xiang has broght up between option
1 and 2.  We are against option 1, that is the "economic cost " and
"scaling" choice (I believe) is refered by James, stemming out of 
option 1, which is the Unicode Consortium's recommendation 
I consider it is wrong.

It is obvious that John always thinks the whole issue is a layer 2
problem, and we are trying to say 1-1 TC/SC has been reduced to
layer 1 problem, and please think it over. 

Regards,

Liana

> 
> It is better to not have any table at all and ask the registrant to 
> do
> multiple registrations. This can happen explcitly or implicitly when 
> a
> request comes from the registrant all depending on the policy the 
> registry
> has on registrations.
> 
> This is how things have worked in DNS since it was invented. This is
> nothing new, or special for chinese characters.
> 
>     paf
> 
>