Subject: [idn] Traditional and Simplified Chinese Conversion-v03.txt

From: "xiang deng" <[email-masked]>
Date: Thu, 22 Nov 2001 04:16:45 +0800

Dear IETF&IDN WG:
 
    Attachment is our draft about Traditional and Simplified 
Chinese Conversion[Version03], which defines the requirement 
of Chinese domain name and a proposed solution.
    Thanks for any suggestions and comments!
 
Li Ming Tseng, Deng Xiang, Ho Jan-Ming, Xiaodong LEE, Kenny huang, 
Wenhui zhang, HSU NAI-WEN, Sun Guonian, Erin Chen, Zhang Hong

CNNIC&TWNIC&CDNC

---

From: YangWoo Ko <[email-masked]>
Date: Thu, 22 Nov 2001 11:53:11 +0900

On Thu, Nov 22, 2001 at 04:16:45AM +0800, xiang deng wrote:
> <draft-ietf-idn-tsconv-03.txt>                         Deng xiang
> (snip)
> 3. Problems
> (snip)
> [4] Multiple possible periods (e.g. U+3002 , U+2022, U+FF0E) 
> In Mainland China, there is a different period other than dot. While 
> user input Chinese domain name, he/she types the delimiter of domain 
> name, and he/she will certainly get period (such as: U+3002).
> In Taiwan Chinese IME, user might type or copy and paste U+2022 or 
> U+FF0E as the delimiter.
> (snip)

Dear Deng Xiang,

I know that "existence of different periods other than dot" may cause
problem for Chinese IME users, but it is a "Traditional and Simplified
Chinese Conversion" issue. You'd better not mix them up into one long
draft. I'd like to propose you remove "multiple periods" issue out of
this draft and make an another draft for it.

Regards

-- 
/*------------------------------------------------
YangWoo Ko : [email-masked]
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/

---

From: YangWoo Ko <[email-masked]>
Date: Thu, 22 Nov 2001 12:46:18 +0900

On Thu, Nov 22, 2001 at 04:16:45AM +0800, xiang deng wrote:
> 4. Description of the solution
> 4.1 Encoding Procedure
> 2). HSE indicates to encode the TC/SC variants in accordance with 
> the settings in the Application (e.g. supporting SC  or supporting TC), 
> which are in the Complete Set of Simplified Characters table. To encode 
> a Chinese character into (HSE, Flag) form and save flags for every 
> character to mark TC or SC. (Flag=0 means the original form of the 
> Chinese character is SC, similarly, Flag=1 means TC). 
>   a.If the Application is set to support the SC, the TCs in the CDN will
>     be converted to the corresponding SC with flag 1, i.e. (SC, 1) and 
>     SCs will be encoded into (SC,0)
>   b.If the Application is set to support the TC, the SCs in the CDN will
>     be convert to the corresponding TC with flag 0, i.e. (TC, 0) and TCs
>     will be encoded into (TC,1)

Dear Deng Xiang,

I have two questions regarding so-called "setting" (or user preference).

What is the default value for "the settings in the Application" ?
"supporting SC" or "supporting TC" ? 

What is your recommendation for those who are not Chinese ? Especially,
for Korean / Japanese and for Western people who never knows Han ?

Regards

---

From: YangWoo Ko <[email-masked]>
Date: Thu, 22 Nov 2001 13:00:28 +0900

Dear Deng Xiang,

I have one question and one recommendation regarding validation.

Question is;
Is there any reason putting validation after NAMEPREP ? Why not before
NAMEPREP ?

Recommendation is;
As validation starts after completion of HSE, for the sake of clear
understanding, description for validation should include how to deal 
with codes which are changed and flagged by HSE.

Regards

---

From: "xiang deng" <[email-masked]>
Date: Fri, 23 Nov 2001 15:33:43 +0800

Hello Ko:

Sent: Thursday, November 22, 2001 11:46 AM, YangWoo Ko

> "supporting SC" or "supporting TC" ? 

It depends on user.

> for Korean / Japanese and for Western people who never knows Han ?

For Korean/Japanese, the setting is "supporting TC". But user still can set
"supporting SC",  but the system could not support to display it.

For western people, if his system support Chinese character, he can choose
the one which can display correctly. 
If his system don't support Chinese character, this setting isn't necessary.

Regards
Deng xiang

---

From: "xiang deng" <[email-masked]>
Date: Fri, 23 Nov 2001 16:08:23 +0800

Hello Ko:

> Is there any reason putting validation after NAMEPREP ? Why not before

Nameprep is to do Mapping, Normalize, Prohibit. And the function of
Validation is like Prohibit, the difference is that Prohibit is refuse character,
the Validation is refuse wrong combinatorial CDNs. So Validation should
after Prohibit.

> with codes which are changed and flagged by HSE.

Thanks for your recommendation.
Validation is for checking validity of CDNs.
How to deal with codes with flag is the program implementation. It isn't 
a big problem for a programmer.

Regards
Deng xiang

---

From: "xiang deng" <[email-masked]>
Date: Fri, 23 Nov 2001 18:41:30 +0800

Hello Ko:

> this draft and make an another draft for it.
 
Thanks, It's a good suggestion.
The draft include three parts:  first one is user requirements. Because the 
different periods always confuse users while they use the CDNs in applications.
It's one of user's requirements of CDN, If writing a new draft will certainly 
make people confuse it.

Regards
Deng xiang