> > 1. AFAIK, JP does not want to match JSC-JTC pairs (if such pairs exists > > or such table can even be constructed). > > In TSCONV-01, we have took JSC-JTC pairs off.
Ok, so -00 tables is not updated yet. > For the benefit 1, people can use Kanji or Hanja to interconnet amoung TC > and SC. In other words, JP/KR users can access Chinese language IDN thru either TC or SC. But such TC-SC does not usually makes any sense. Therefore, when they key in TC and they got back SC, wouldnt they be confused? > For 2, TSCONV intend to reduce 2^n , every one do not have to register 2^n TC-SC is not a 2^n problem. TC-SC have basically around 2-4 variant in practice. Others nonsense variant can be constructed but it bears no meanings usually. > For 3, every one need reliable and predicable hostname resolving Yes agree, everyone ..."regardless of race, language or religion". (quoted from Singapore pleague :-) > > 3. TC/SC is not a 2^n problem. It is closer to n*2 to n*4 problem. > > Why is n*2 or n*4? It is possible maximum 2^n problem. Theortically. In practice, it is not. In engineering, we do trade off. If we have a 90% solution, then we need to consider if it is worthwhile to do the last 10% if the 90% effort and trouble it cost us. > > 5. I am wondering which authority in China, Japan and Korea is approving > > this table as stated in the draft. > > In the TSCONV-01, the authority is from > A Complete Ser of Simplified Chinese Characters > and > Dictonary of Chinese Characters Variant Thanks. In other words, it have been confirmed by China authority who does simplification and Taiwan dictionary group. Please clarify that in your draft. Stating "China, Japan and Korea" is at best misleading. Next questions then: 1. Who have confirmed it in Japan and Korea as stated in your draft. 2. You have two source. How you put it as one table? You did not use the table as-it-is in its original form right? 3. If you indeed combine the two sources into a single table, I presumed there would be many overlaps in the tables but still some conflicts. What about those conflicting cases and how have you deal with them? 3. Why did the authorities creates such tables in the first place? What is their written policy on the stablility of the tables and futures changes? What is the procedure for someone to add/delete/modifyt (if possible) such tables if someone thinks there is a need to update it? 4. Have it been go thru codepoint experts review by UTC or IRG etc? Standard questions which someone would ask...:-) very simply to the one asked about reordering. -James Seng
