Re: [idn] Summary of TS-SC discussion

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

Hi ! Hoffman:


> We have now rehashed every part of the question many times; maybe it
> is a good time to summarize.
>
> 1) Doing traditional-to-simplifed conversion must be done from a
> table; it cannot be done by algorithm.
>
            I  have  question .   Does  the ACE translation ( ACE-Z or RACE
..) can be done without  any UNICODE table ?
> 2) No widely-accepted official standard table yet exists. Multiple
> different tables exist.
           Does all table in proposed nasmeprep are all widely-accepted
official standard table ?
>
> 3) The same code points that would be converted in some domain name
> parts would not be converted in other domain name parts because the
> conversion is only appropriate for Chinese, not Korean or Japanese,
> which use the same code points. Thus, the language (not the script)
> must be known in order to do the conversion correctly.
>
          You have get the results from any Korean , Japan official
announcement ?  The language term is not treated in this WG , why you
annouce "all" scripts are "all language dependent" ?  If it is so, then all
scripts of UNICODE should not be treated in IDN.

> 4) There is no way to flag the language in name parts in a consistent
> way that end users would understand. Heuristics such as the TLD could
> be used, but doing so would cause some names to not be converted when
> they should be (such as a Chinese name part under .com) and would
> cause other names to be converted when they should not be (such as a
> Korean name part under a Chinese SLD). Hueristics such as language
> tagging would require that the end user tag each Chinese name part,
> and would not work at all with names that were cut and paste.
>
         Why the tag in MIME mail header and subject can be recognize the
language character typed-in and display them correctly ?  Does user of
E-mail tag each part of CJK characters ?
          Another question , why the IDN  domain name must be  IDN.COM , why
not it is ACE(ML-name.ML-company) ?

> 5) The problem can be definitively solved in zone files with multiple
> records. Some claim that this takes 2^length records, while others
> claim this takes 2 records.
>
         I  like to know  "Taiwan University"   台灣大學
                                  "Tsinghua University"  清華大學
can be solved by  2 records  in DNS zone table with TC/SC mixing ?

> 6) Until the system is deployed, we cannot tell how well the users
> will adapt. We (the "experts" on domain names) can make predictions
> about what typical users will and won't be able to do, but we simply
> don't know, and our past track record at predictions is not all that
> good.
>
> My conclusion from this is that we cannot standardize on
> traditional-to-simplified at this time with the protocols that are
> under discussion in the WG. We might be able to add this later after
> both a widely-accepted official standard table exists and a language
> tagging mechanism that makes sense to users is implemented.
>
> Neither IDNA nor nameprep preclude this potential future change, so
> we can move forward with them now, and leave the door open to this
> change, and other similar changes, in the future.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>
       Very sorry , I have too much questions in your conclusions.

L.M.Tseng,