Re: [idn] UTC recommendations on TC/SC

[=?big5?B?dHNlbmdsbUCtcLr0pKSk3y6kpKRqLnR3?= <tsenglm@cc.ncu.edu.tw>]

Hi ! Eric:
> > that it is not a required feature of nameprep, since multiple
registrations
> > will reasonably meet the user requirements. The latter point is based on
> > there being typically only two variant spellings: one TC and the other
SC.
>
> Earlier someone proposed, and eventually withdrew, a proposal to allow
> a character-by-character, registrant election of equivalency, which has
> combinatorial scaling properties. A vendor may also have advocated this.
> I had dinner with their CTO once and got indigestion.
>
> In any event, I can't imagine how a conversation in a code-point standards
> body ended with a paraphrasing of "multiple (zone) registrations
reasonably
> meet user requirements". It is as odd as an IETF conversation ending with
> the observation that "multiple code-point allocations reasonably meet the
> glyph <foo>'s requirements as a character in scripts <bar> and <baz>".
>
           Current  Letter-Digital-Hyphen DNS  can accept any case
caharacter string in zone file and query lable. It  hidden  to-lower-case
conversion in comparasing time.  The ACE approach let the case mapping
separated in registration time and query time. It must to select one in
equivalence set to be assigned as a standard representation.  Any  CJK
people can not understand why our character should be transformed to other's
character. So it is a big trouble to make concensus in  full scale TC/SC
mapping.
           As you point out there existed a combinatorial scaling problem in
TC/SC mixing if the  case-holding-like problem can not be solved.  In  the
TC/SC equivalence problem of chinese charaters , there are a small set of
them are more critical ,  some of them, especially PRC-SC , are
easy-to-confuse with TC  of  Japan, korean, abd Taiwan.  This part can be
easily checked by each ccNIC  in viewing the script font .  These common and
critical part are the necessary part of character mapping in nameprep.
Adding number of them will reduce the scale of TC/SC combination , but
reducing of them can keep  the flexibility for  different language using.
This is a typical name identifier problem.  All  CJK related NIC may  get
the concensus in knowing these two limitations.  It is not a problem of
language conversion,  it just to do fair for users.
          The value of domain name come from the easy-to-use that cause the
mass population  and the uniqeness of name let user like to keep it .  To
reduce the confusing  will be an important issue.
          To put all of TC/SC word conversion into IDN system is not
necessary and impossible in her large character base. But just to keep  all
TC/SC out of nameprep will be not a good solution too.  Why not try to find
only some easy-to-confusing character set and put them in character mapping
of nameprep ?

L.M.Tseng