財團法人台灣網路資訊中心因公出國人員報告書
91年03 月 22日
|
報告人 姓 名 |
許乃文 |
服務單位及職稱 |
技術組組長 |
|
出國期間 |
91年 03 月 02日 至 91年 03月 08日 |
出國地點 |
泰國曼谷 |
|
出國事由 |
報告書內容應包含： 一、出國目的 二、考察、訪問過程 三、考察、訪問心得 四、建議意見 五、其他相關事項或資料 （內容超出一頁時，可由下頁寫起） |
||
|
授 權 聲 明 欄 |
本出國報告書同意貴中心有權重製發行供相關研發目的之公開利用。 授權人： （簽章） |
||
附一、請以「A4」大小紙張，橫式編排。出國人員有數人者，依會議類別或考察項目，彙整提出報告。
註二、請於授權聲明欄簽章，授權本中心重製發行公開利用。
一、出國目的
在目前IETF所採用之IDNA-NAMEPREP-ACE的標準架構下，中文網域名稱(包括日、韓的UNICODE
CJK碼點的網域名稱)繁簡問題一直沒有被考慮到。雖然TWNIC及CNNIC在整個過程中不斷的提出問題說明及技術解決方案，但一直都沒有被接受。為了在IETF
IDN工作小組last call之後能儘可能保障中文網域名稱使用者的權益，彌補IETF在IDN技術政策上的不足，因此特召開此次會議討論註冊政策上的解決方案，其能找出一個中、日、韓都能接受的解決方案，並提交相關的文件到IETF。
在亞太地區的Internet發展較歐美晚，尤其少部份國家/地區的網域名稱註冊才正要開始，為了協助這些NIC能順利運作該國家/地區的頂級域名及維持穩定的DNS，針對這些國家/地區舉辦了這一次的網域名稱運作經驗分享活動，其能在透過經驗分享的過程中帶領這些國家/地區的DNS管理者更快的提昇其能力，以促進整個Internet的穩定成長。
二、考察、訪問過程
此次
JET 會議排定在三月四日至六日召開，先由JPNIC及IETF報告現況，所有出席人員在經過討論後達成一致的共識，在各NIC所提出之中、日、韓之可註冊字元、建議代表字、異體字(繁簡字)等來合併成一個CJK域名註冊參考表，使用者可依其所註冊的網域名稱是屬於中、日、韓之範圍而據此參考表決定其網域名稱之保留網域名稱(其他人無法註冊)、並啟用原型域名、代表域名，以後可在原註冊者之需求下啟用原保留的域名，會議由IETF
IDN工作小組主席james協助完成共識，並在每天會議結束後將結論以電子郵件發給mailing list成員，主要是給無法參加者了解會議過程及結論，並可讓大家表示意見，隔天再依大家的意見再作細部討論。
在ccTLD
Name Server Operational experience的會議中由主席針對現有TLD的現況及DNS運作情形作一報告，再由krnic,jprs,twnic作DNS運作經驗分享。
三、考察、訪問心得
網域名稱註冊政策雖無法完全解決中文網域名稱繁簡的問題，但仍可作部份問題的排除，且也是一個在各單位間較容易取得共識的的地方，因此在會議中就針對註冊政策作深入討論，在會議討論過程中並不排除其他技術方案的配合。
Registration Policy Guideline for Chinese, Japanese and Korean
Guideline
The guideline is for all zone administrators, including but not limited to registry operators and registrars.
Domain names registered prior to the publication of this guideline should be reviewed for compliance with the guideline. If there are domain names that are in conflict with the guideline, zone administrators should make modification to conform to the guideline.
The main purpose of this guideline is to protect the interest of the registrants, to reduce confusion and avoid unnecessary dispute.
The CJK Variants is a very complex problem that requires many different layer of solutions. This guideline is just part of the component needed to solve the CJK Variant problem.
It should be noted that registration policy guideline alone is not sufficient to solve whole problem.
The first draft of the guideline covers only the CJK Han Ideograph codepoints. Future draft will extend this to kana and hangeul.
Moreover, this guideline is also extensible to other languages using the same principle.
Definitation
CJK Variants - covers TC/SC in Chinese, Japanese and Korean - covers CJK zVariant
Scope of the Registration Policy Guideline
1. Registration policy MUST comply with the IETF Standards. Language specific solutions SHOULD comply with the appropriate language standards.
2. Variants of CJK domain names MUST be handled in the registration policy conformed to this guideline.
3. Variants of CJK domain names MUST be reserved for or delegated to the same registrant.
The table comprises of the following columns: CJK Code, Chinese, Japanese and Korean. The first column will be sequence of CJK code points. The Chinese column will list the variant(s) of the corresponding CJK code, similarly Japanese and Korean.
CJK Code Chinese Japanese Korean
---------------------------------------------------
3400 3400 3400 3400
...
3402 *3402*/3502 3402 3402
....
3502 3502/*3402* 3502 3502
...
3602 *3602*/3702/3802 3602/*3603* 3602
...
3802 3802/*3602* 3802 3802
...
NB: The "/" defines there are more than one variant for that language.
NB2: The * represent the recommended codepoint
NB3: These code points are just examples...source for the variant have to be discussed later
During the registration process, the registrant will have to choose the language(s) of his registration. In some cases, the language may be pre-defined by the registry/registrar.
Then according to the language(s) chosen, another table will be generated, with the following column: CJK Code, Variant
CJK Code Variant (Assuming all CJK have been selected)
-----------------------------------------------------------------
3400 3400
...
3402 3502/*3402*
...
3502 *3402*/3502
...
3602 3702/3802/*3603*/*3602*
...
3802 3802/*3602*
...
Following this, the domain name reserved can be generated using this table. For example, if the following domain names is registered,
3400 3502 3602 . COM (assuming the registrant choose all CJK)
The reserved domain name is
(3400) (3402/3502) (3702/3802/3603/3602) . COM
and the recommend chinese version is
3400 3402 3602 . COM
and the recommend japanese version is
3400 3402 3603 . COM
In this example, 3 entries will be entered into the zone, the original form, the 2 recommended version and the rest of the variant will be reserved for the registrant.
Similarly, if the following domain name is registered by a registrant who choose only Japanese,
3400 3502 3602 . JP
then the reserved domain name is
(3400) (3502) (3603/3602) . JP
and the recommended version is
3400 3502 3603 . JP
In this example, 2 entries will be entered into the zone, the original form and the recommended version.
Registry/Registrar MUST reserve all variants of the domain names according to the algorithm described above. Only the registrant MAY choose to register more of his reserved variants.
DRP need not be changed even with this reservation policy. It is still based on the first-come-first-serve basis, whereby the first registrant will have the rights to all variants of his registered domain names.
3400 3402 3502 . COM (assuming Japanese)
The reserved version is
(3400) (3402) (3502) . COM
And the recommended version is
3400 3402 3502 . COM
Then it is possible that someone else register the
3400 3502 3502 . COM (assuming Chinese)
The reserved version is
(3400) (3402/3502) (3402/3502) . COM
minus the already registered version, ie, 3400 3402 3502 . COM
And the recommended version is
3400 3402 3402 . COM
If the recommended version is already registered or in reserved, then the registration must fail.
If the reserved sets have domain names already registered, then the reserve list will be minus the reserved list.
四、建議意見
1. 目前IETF的IDN解決方案已明確知道不能完全符合 CDN 的需求，在等待其他DNS Extensions WG 或Internet Resource Name Search Service BOF等之發展結果尚無法預期的情況下，透過註冊政策的Informational RFC也可達成我們部份的需求，雖這樣的結果不儘理想，但已是在各NIC都可接受的最佳境界。至於我們自己所要的技術解決方案仍需要在CDNC範圍內持續推動。
2. Keyword及IRNSS等working group是下一個要積極參與的組織，在這些name space一樣有中文繁簡的問題，但很多在IDN技術上不易解決的問題都可在這些較高層的服務項中順利解決。因此需在這些working group剛成立之初就要積極參與，充分表達中文的需求及解決方案。
五、其他相關事項或資料
有關會議議程、會議共識、會議中各項報告資料如附件。