抗議IETF即將通過有瑕疵的國際化域名技術標準

2001年12月中旬網際網路（以下簡稱網路）的技術規範組織IETF於美國鹽湖城聚會討論制定國際化域名（Internationalized Domain Name，簡稱IDN）標準的相關議題。2001年12月17日網路世界融合網路報（Network World Fusion）有一則相關報導。文中提到由於預期這個多語域名註冊服務將帶來大量商機，儘管還得等待一段時期，微軟等網路應用軟體供應商才能提供支援多語言域名服務的瀏覽器、電子郵件客端、及網路管理等軟體。眾多的域名註冊與登錄商莫不摩拳擦掌，積極佈局以獲取最大的利益。網路上最大的頂層域名 .com 的註冊商VeriSign早在一年前就已經開放多語域名註冊。VeriSign宣稱已經註冊了1百萬筆多語域名資料。文中也提到，雖然使用拼音文字的歐洲人對於IDN技術標準的發展表示滿意，但是，想要使用漢字域名的消費者，卻將面臨重大的問題。這套技術方案也沒有解決顯示亂碼的問題。

IETF認為改變域名系統只支援英文域名的傳統，可能會動搖網路基礎。因此，IETF的IDN工作群建議採用轉碼的方式，將多國語言域名，轉換成為英文域名，儲存於傳統的域名資料庫中。預期將通過三份規範草案文件，以規範客端（client）應用軟體支援域名轉換功能的基本架構。這個架構包括由多語言域名的前處理部件和轉碼的演算法。其基本構想乃是由使用者的客端應用軟體，將使用者輸入的域名字串，先轉成為Unicode字串（Unicode是與ISO共同發展的表達語言文字的電腦工業標準），再由轉碼演算法（稱為ASCII- Compatible Encoding，簡稱ACE）把Unicode字串轉換成為合法的英文域名（由英文字母、數字0-9、與短連接線等符號組成的字串，letter-digit-hyphen，簡稱LDH字串）。這個形同亂碼的LDH字串可以登錄在傳統的分散式英文域名資料庫，也可以由客端應用軟體送出給域名系統（Domain Name System，簡稱DNS）進行比對，以傳回對應的IP位址。

這個以Unicode為基礎的IDN技術之所以會給漢字世界帶來問題，其根源來自於Unicode組織當年在定義字碼的時候，決定以字形為基礎，將中日韓文使用到的漢字（簡稱CJK）統一在同一張碼表。也就是說，如果兩個字的字形（glyph）相同，即使這兩個字在不同國家的意義不一致，這兩個字就共用同一個字碼。例如「机」字，在中文，這個字是「機」字的簡寫；在日文，這個字卻是茶几的意思。然而，如果一個字在各國的字形各不相同，那麼，不論二者的差別有多細微，這兩個字形的Unicode字碼（codepoint）就不同。台灣使用的繁體字和中國通用的簡體字就常出現這個狀況，更遑論CJK文字混用的狀況了。例如「吳」、「說」、「悅」。吳字由於台灣、中國、日本的寫法略有差異，因此，共有三個不同的Unicode字碼；至於說、悅等字，台灣的兌字上端是正八，中國則慣用倒八，差異雖小，也都有各自的Unicode字碼。此外，一些偏旁簡化字（例如，「金」字邊的「銀」字），字形差異不大，對應的繁簡體的Unicode字碼卻也各不相同。

儘管有以上問題存在，但是，使用Unicode編碼的文章，具有同時兼容並蓄多國文字的好處。因此，一般預期Unicode的應用將會越來越普及。例如，常使用Windows 2000注音法的使用者，可能已經留意到在同音字的選項當中，不只簡體字已經在列，日本的漢字也在其中。

由於一個漢字會有多個不同的字形同時出現在Unicode碼表中。因此，一個漢字域名會對應許多個不同的Unicode字串，其個數會隨著域名長度成幾何級數成長。例如，由於「台」字有臺、台等兩種字形，「灣」、「學」兩字各有繁簡兩種不同字形。因此，台灣大學共對應2＊2＊2＝8個不同的Unicode字串。讀者不難想像得到，一個域名當中只要有10個字有2個以上的不同字形，就可以組合成1,000個不同的Unicode字串（2的10次方＝1,024）。

由Unicode造成的漢字域名不唯一的情況，會帶來相當大的麻煩。第一個問題是授權（delegation）的問題，也就是說，註冊商究竟會將同一個名字的不同字形的版本授權給多少不同的對象呢？註冊者若要保障自己的域名的話，得一一註冊所有不同字形的組合呢？還是量力而為，在眾多的可能組合當中，選擇註冊其中幾組即可呢？

更麻煩的是，如果註冊商是外國公司，當一個域名重複註冊給不同註冊者的爭議發生的時候，消費者究竟要如何保障自己的權益呢？消費者得聘請律師越洋打官司呢？還是自認倒楣，換個名字算了呢

第二個問題是域名解析問題。如果一個域名所對應的不同的Unicode字串，授權給了數個註冊者，那麼，使用者在鍵入域名時，只要當中的一個字形輸入錯誤，就可能訪問到不同的網址。即使註冊商保證一個域名對應的所有Unicode字串不會授權給第二個註冊者，然而，如何把同一個域名的數十乃至數千個不同字形組成的Unicode字串都儲存到域名資料庫，在管理上並不是個小問題。IDN的技術方案帶來了這些問題，卻沒有提供答案。如果，域名資料庫中只儲存了一筆漢字域名的所有的Unicode字串的十分之一或更少，那麼，使用者輸入的漢字網址在域名系統中比對錯誤的機率，將會相當高。

幾年前，有多家廠商在缺乏解析中文網址的技術、也沒有共通的技術標準的情況下，逕自在國內販賣中文域名。當年有許多公司與個人在唯恐好名稱被佔用的恐慌心理下，只能一一付錢給這些廠商，卻得不到實質的服務。IETF IDN工作群利用Unicode為基礎的技術方案，固然能部分解決英文以外的拼音文字的國際化域名需求，卻繼承了Unicode為CJK漢字域名帶來的授權和解析等嚴重的問題。IETF如果貿然照案通過這IDN工作群擬定的技術方案，一個不利於中文域名市場的瑕疵商品，馬上就要由各家競逐商業利益的跨國註冊公司長驅直入國內市場。這種不穩定的域名服務，不僅對消費者（含註冊者和使用者）不公平，也不利於國內網路社會的正常發展。

雖然，IETF也在考慮在現有的網路域名系統之上，增加一層新的搜尋服務，以解決亞洲語言問題，以及其他域名相關的議題。這項域名搜尋服務稱為網路資源名稱搜尋服務（Internet Resource Name Search Service，簡稱IRNSS）。但是，要等到這項剛起步的標準發展成熟，預計得耗時1年以上。到時候，即使廠商願意修改他們的網路應用軟體，以支援IRNSS的相關標準，但是，等到這些軟體問世，也還得再經歷一段的時間。對於IDN技術方案即將為漢字網路世界帶來的混亂的消費者市場的危機，顯然遠水救不了近火。

國內有幾位密切注意IDN發展的專家與學者，和TWNIC共同合作，基於保護消費者的立場，除了多次在ICANN和IETF等組織提案與發言，解說這套以Unicode為基礎的方案，會為CJK地區帶來的的不利影響；並提供技術方案建議，試圖降低IDN工作群的技術方案將帶來的傷害。不過，在12月中旬的IETF會議，IDN工作群不顧這些建議與警告，投票通過關於IDN基本架構的三項技術文件，卻排除了我們的提案。依據IETF的程序，這些文件將會在工作群內先作最後公告（last call）。如果在工作群最後通告期限內，沒有會員提出異議的話，這些文件就會送進IESG。IESG審查之後，就進入IESG的最後公告。如果沒有意外的話，這些文件就完成了標準化程序。

在IDN工作群的多次討論過程中，我們雖然讓部分成員理解到，IDN技術方案會帶來CJK漢字域名的嚴重問題。但是，對於如何解決這個問題，卻沒有達成共識。除非消費群眾能在短期間內共同發出足夠宏亮的反對聲浪，很不幸地，這項會為我們帶來問題的技術方案，將在短期內被IETF接納成為技術標準。因此，我們呼籲，在這兩個最後通告期間內，請網友們共同在IETF的相關郵件表（mailing list）上，發出抗議的聲音。要求IETF在漢字域名問題得到解決之前，從IDN技術方案當中，暫時排除所有含有CJK漢字的域名，以維護漢字域名使用者的權益。