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

[=?UTF-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>]

Hi!  Fältström :
       Please read it completely again,  I  just  talk  how to reduce the
confusing of mixing scripts by release partial set of CJK  to different area
by virtual using and update them step by step.
If  you want the IDN fail in confusing and no conversion of  CJK , you can
by-pass it.

> >                We talk the version , updating and how to keep backward
> > compatible.
> > And you give a good example:
Let's assume that the table day one include the following characters:
{A,B,C,D,E,F,G,H,c}
We agree that the first simple equivalence rules for 1-1 mapping maps is
A->B and the reason for mapping are they have different font shape but with
the same meanning. the second  1-1 mapping is  c->C  because they are
easy-to-confuse not only in meannig but also in similar shape. Let us also
assume G,H are reserved  , because they are not frequently used and can not
type-in from input methods.

This means that the following characters are available for domain name in
REGISTRATION and zone file : {B,C,D,E,F} , user can select A,c , but in
registration time, he will be noted  A->B , c->C . He can use A as B
virtually if the mapping rule applied , but the primary and actual name is
B.

{G,H} is  "reserved",  so they are "forbidden" in using now . Reserved them
just to reduced the set size to check the equivalence mapping now.

> You start talking about "confusion", and that is a term which this WG has
> defined being out of scope.
             Out of scope just mean to neglect and assume they are
non-exist, We know it is not true,  it just ask you must focus now and
solved them later. But if the later term is a fatal error in the proposed
system , it will not work well.

 Comparing to the above two set, the 1-1 mapping let {A,c} is not allowed
in zone  table.
>
> Wrong. When a user want to register something with 'A', 'B' will be
> registered. This means that when a user types A, he will get a match on B.
{ A ,c } will be present in registration data table , but it will be telled
that A will be  treated as B and c is treated as C .  If  you  use
reversable ACE , only  B and C  are corresponding created in  zone file.
> When a user types 'c', he will match 'C'.
> Only 'B' and 'C' is registered.
> > {G ,H} are also not in the registration table
> No, because they are forbidden (I guess).
>
It is like to let {A,G,H,c} are limited to use for further extension.
> Wrong. A and c are already included in the mapping tables, to B and C
> respectively.
     A and c are in mapping table now . But now we want to let A and B are
treated as different in some furture time and keep {C,c} the same.
If A are allowed only virtually used , you have further chance to move  A
into  the zone file for different address mapping.  In a non IDN-aware
system , they will found B is exist but A are not.

> No. That is completely wrong!
 I  suggest you cold down to think how to expansion and update the table.
You will not take keyword as a actual domain name in name mapping.

 After A.example.com is allowed in registration table and you can also let
it to
be assigned as B.example.com  for backward compatible first .
> No.
>
 Then the virtually used  "A" can be changed  to a real location in zone
file as needed in furture and can be available to  use as Address RR for
others .

L.M.Tseng