財團法人台灣網路資訊中心因公出國人員報告書

九十七年四月十六日

報告人

 

陳式偉

楊禎葆

服務單位及職稱

資深工程師

工程師

出國期間

九十七年三月七日至

九十七年三月十六日

出國地點

美國 費城

出國事由

參加第七十一次 IETF費城會議

報告書內容應包含:

一、出國目的

二、考察、訪問過程

三、考察、訪問心得

四、建議意見

五、其他相關事項或資料

(內容超出一頁時,可由下頁寫起)

   

聲 明 欄

本出國報告書同意貴中心有權重製發行供相關研發目的之公開利用。

          授權人:                    (簽章)

附一、請以「A4」大小紙張,橫式編排。出國人員有數人者,依會議類別或考察項目,彙整提出報告。

註二、請於授權聲明欄簽章,授權本中心重製發行公開利用。


一、出國目的

第七十一次IETF會議於九十七年三月九日至九十七年三月十五日在美國費城舉行。此次會議為期六天,而中心參加之主要目的為參加 EAI WG (Working Group) 標準討論EAI (Email Address Internationalization ),及參加 DNS 相關之 WG 會議 (DNSEXTDNSOPIDN BOF),因為此會中日韓各 NIC 亦皆有與會,故同時利用本次 IETF 會期共同討論了 ICANN IDN 測試報告的結果匯整。

二、考察、訪問過程

此次會議雖期程共六天,行程安排,我們僅參加五天的會議,重點參加必要之 WG,所以共參加了三個 WG分別為 DNSEXTDNSOPIDN BOFEAI CJKT (中日韓台) ICANN IDN 討論會議。

本次會議由於航班的安排故我們早了會期一天到達了費城,在了解了週遭生活機能後,因為所住飯店與會場飯店有段距離,故同時也了解了會場位置及路線。

三、考察、訪問心得

 

DNSOP WG (Domain Name Service Operation)

上次 Working Group 會議討論了關於 IPv6 to IPv4 的穿透時的反解問題(draft-huston-6to4-reverse-dns-07.txt),並進行了 WG Last Call,本次會議時此篇 Draft 則巳成成了 RFC 5158

draft-ietf-dnsop-default-local-zones-04.txt 則統一介紹了 DNS 在實做時,若使用者沒有設定一些 local zones (: 127.0.0.1 Private/Multicast IP)DNS Server 應該自動加上去這些 zone,因為若沒有這些 zone Local Query都會跑到 Internet 上,造成流量及解析上的浪費。目前此 Draft 也巳進入了 Last Call 程序,預計最快下次都柏林會議即可成為 RFC

WG 也初步介紹了一些目前 active Draft,但是這些 Drfat 尚在 mailing list 討論中,會上也沒有什麼人對這幾篇 Draft 也有什麼意見,故主席表示日後再進行討論。

以及 Reolsver 可能影起的安全問題 (draft-ietf-dnsop-reflectors-are-evil-04.txt),另外也建議在新的 DNS 版本開發時,對於特殊用途的 IP 採用 Default zone 的方式來處理(draft-ietf-dnsop-default-local-zones-03.txt),因為這個問題主要是因為像 Private IP broadcast/multicast 等問題(包含 IPv6),這些問題影響了 Root Server 的查詢壓力。此外有四篇 Draft 進入了 Last Call 的狀態,分別是

draft-ietf-dnsop-as112-under-attack-help-help-01.txtdraft-ietf-dnsop-as112-ops-01.txtdraft-ietf-dnsop-respsize-08.txtdraft-ietf-dnsop-reverse-mapping-considerations-05.txt對於一些尚無普遍共識的 Draft 則先不予討論,待於 mailing list 上有相當探討後再列入日後議程來討論 (draft-larson-dnsop-trust-anchor-02.txtdraft-ietf-dnsop-resolver-priming-00.txt)

 

EAI WG (Email Address Internationalization Working Group)

這個 WG 是中心目前參加 IETF 會議中的重點項目,主要在討論 Email Local-Part 中使用 UTF8 編碼的一些方法,尤於影響層面蠻廣的,所以細節問題亦不少。重點如下:

1.          上次會議進入 Last Call UTF8HeaderSMTPEXTDSN將在本月內完成 Last Call,其中日期如下:

1.1      TWNIC 撰寫的 UTF8HDR: 2008-03-24結束Last Call。主要說明表頭 (mail headerMIME header) 的變動及處理原則。

1.2      CNNIC 撰寫的SMTPEXT: 2預計008-03-24 結束Last Call說明 EAI ESMTP 的處理原則及配套的 ALT-ADDRESS

1.3      Alex. Melnikov撰寫的 DSN 2008-03-19

2.          本次會議經由表決,決定了由 JPRS 撰寫的Downgrade巳可以進入Last Call 階段。並將 Downgrade 中關於 DKIM 的部份拉出來單獨成章,以便克服DKIM一直卡住 Downgrade 之狀況。

3.          Randall Gellens 報告了此次 POP3 Draft 更新後的一些差異點,其中最大的差異是取消 upgrade 之處理程序,並強調 POP3 在收信時,若信箱為 EAI-aware 信箱,但是 MUA 並不支援 EAI 時, POP3 Server 需要幫 Client 進行 Downgrade 轉換。

4.          Randall Gellens 同時也報告了 mailing-list draft 的更新項目,mailing-list 即一般我們說的郵件列表,與列表相關的 RFC EAI WG 下的修改情形,而這一篇草案其實只是 UTF8Header 的延續。

5.          IRI (Internationalized Resource Identifiers) 草案是 WG 新的草案 (-00),主要介紹在 EAI email address 規格 <UTF8@UTF8 <ASCII@ASCII>> 的設計下,一般常用的 mailto: 上如何呈現的問題,由於這篇草案是 EAI WG 新的一篇草案,故與會者討的亦較多,而多數則站在支持的立場上。草案的 IRI 設計在現在的 Broswer/MUA 上皆能有效實現。

6.          會議上亦討論了 WG 是否需要其他新的草案的需求,依據上次溫哥華會議的決議,及上述第二點的描述,WG 決定將 JPRS draft-fujiwara-eai-downgraded- display-00 列入核心草案之一;而為因應現在 WG 之發展,在多數 Server 端的草案確定後,同時亦需一個 Client 端來配合,Afilias 公司的 Ernie Dainow 表示他們願意完善這個草案。

7.          會議最後討論了關於 EAI 的互連測試,WG 預計在下次愛爾蘭的都柏林會議做一個實機的展示,這個需要 design team 成員的互相配合,由 TWNIC/CNNIC/JPRS 來進行這個 demo,並且在本次會議後各相關成員即需開始準備。而這個測試在 IETF 而言,也是從Informative RFC 進展到Experimental RFC 重要的一個階段,代表者原始的設計的實現問題。

8.          原本預計的 WG recharter 問題本次會議並未討論到,預計在下次會議的實機測試後將進行(Recharter 代表的是 WG 工作方向的改變)

9.          Working Group 希望可以在今年底達成任務,讓所有的 Draft RFC 化,以完成 Email UTF8 化之目的。

 

由於 EAI Working Group 巳成立二年了,這兩年來除了 framework 成為了 RFC 外,預計下次會議前,會再有另外三篇新的 RFCChair 也特別提醒大家,下次會議將進行實機測試,各相關參與人員請提早準備。

下次 IETF 會議將於七月底於愛爾蘭的都柏林舉行,對於本次會議未決之事項先於 mailing-list 上討論之,若仍未決於下次會議再進行討論與決議。
 
 

DNSEXT WG (Domain Name System Operations)

DNSEXT IETF 是一個巳相當長久的 Working Group,主要因為 DNS 協議是 Internet 重要的標準,沒有 DNS Internet 將會寸步難行,所以 IETF 長久以來都對 DNSEXT 投注了相當的關注,此 WG 對中心而言亦相當重要。DNSEXT WG 此次會議關於 DNAME ( DNAME-clarify Draft ) 有一個很重要的修改,新版的 2919bis 版本調整了 DNAME 回應時的 CNAME TTL=0 修改成同 DNAME TTL,此調整主要因應 ICANN IDN TLD 之相關需求,相信日後可以看到相關效果的出現。DNS Cookie Draft 則強調在 EDNS0 下應用 Cookie 的關念,來加強 DNS 的安全性及查詢的相關認證,並且讓 DNS 查詢具有穿透 NAT 的能力,不過這個 Draft 所強調的精神和一般的 DNS 概念存在一些狀況,與會者多認為 DNS 是一個開放性的系統,過於複雜或違反傳統的方式是較難被接受的。dnssec-bis-updates Draft 則是一份對 RFC 4035 (DNSSEC) 的修正,主要調整一些設置,讓 DNSSEC 可以更完整,Client Resolver 在支援 SEC 的情況下,透過設定 DNS 封包的 CD bit 來使用 DNSSEC 的相關查詢,而Server 則在對應的配置下進行回應。而另一篇相關的 DNSSEC Draft 則選用了 SHA 的加密演算來做為 NSEC3 記錄的 Key 值。draft-ietf-dnsext-dns-protocol-profile-01這篇 Draft 則是介紹了新版的 DNS 實作方案,不過這個版本的 DNS Server 因違反了太多傳統,故遭到了與會者多數 Comments 的反對,例如,其所提出的 Authoritative Server 概念,因為違反了開放性的原則,故大多數人皆不同意,其他建議新的 DNS 版本都應支援 EDNS0,雖立意良好,但是在現有的 Internet 的環境媢磟I上有困難;至於 Stub Resolver/Recursive Resolver 也遭受到了反對,唯大家認為這個 Draft 所提出的概念改善了 DNS 部份問題,但是因對現在的 DNS 架構衝突太大,故不看好本篇之構想。draft‐ietf‐dnsext‐axfr‐clarify‐07.txt 則是一篇對 AXFR 使用 UDP 的草案,因為舊的 RFC 1034 1035 建議使用TCP來進行同步工作,不過本於 UDP 協議的特性,快而有效的情況下,若網路環境允許,可以使用 UDP 的封包方式來進行同步,除了加快同步速度外,對 Server 的負擔也會較輕。

 

IDN BOF (Internationalized Domain Name BOF)

此次IDN BOF 會議主要目的是成立Internationalized Domain Name Working Group及討論未來IDN WG的目標。重開IDN WG 是希望在IDN Application領域上多使力,比較上次的IDN WG較偏向IDN Protocol的制定有所不同,有關新WG的議題範圍在會議上被提及,如Phishingtoturial 等是否納入,仍待大家釐清與確認。

幾個主要的Key Issues IDN WG 會議被討論:
n         IDN revision: John Klensin介紹三個主要關注議題,
    ()有關重要符號及字串是否須排除或不排除於IDN的規範。
()一些字串會被認知為不好的目的,有可能威脅Root的運作。
()修正讓人confuse Terminology,避免造成混淆。
()有關先前IDNA2003架構之定義,例如Unicode版本問題、其中有不易瞭解或不易延展檢核的問題,需要有再討論修訂的必要。
 
n         共同Key Goals是希望達成有關Unicode版本問題的解決方案、更易懂的IDN以促進發展、更容易為local接受調整,及討論未來可能衍生的問題等。
 
n         IDNABIS-TABLES: Faltstorm提出的draft,其目的為指定一確認algorithm規則,以決定code points in unicode characher set以納入International Domain Name
 
n         IDNA-BIDI: Alvestrand提出draft,其目的是希望使用指定之邏輯由右至左(right-to-left)之字串於International Domain Names中。
 
本次IETF71會議後將再成立IDN WG,對於IDN的標準、相關應用程式開發、網域註冊單位和註冊者及各界使用者的反應,都將是關注的議題,本中心於IDN標準及其應用已研究數年,並已有商業化系統提供服務,建議未來應積極持續參與IDN WG,以及時提供相關修改意見及掌握IDN未來發展。
 

IDN Evaluation

International Domain Name(IDN)標準通過已4年,目前有超過40個網域名稱註冊單位(Domain Name Registries)提供第二層(Second Level Domain, SLD) IDN服務。並經過許多的努力及更新,目前大部分的網頁瀏覽器(Web Browser)大多已支援IDN服務,顯示在 IDN之需求持續成長,近年Internet Corporation for Assigned Names and Number (ICANN)亦考慮開放頂級網域名稱Top Level Domain (TLD)之使用,同時ICANN200810月開始提供IDN網頁及IDN郵件伺服器環境之IDN TLD Evaluation測試,TWNIC亦積極參與ICANN相關測試網頁建置及IDN郵件測試工作。

 

目前已有阿拉伯語系國家對於IDN做出測試報告,並於去年12月發表「International Domain Name Top Level Domain Evaluation and Test Report」,對於目前網路上各主流之Mail Client and Web Browser應用於阿拉伯文的支援情況表列冊測試個案,進行比較與測試以反映現況,相關報告請參考連結http://www.arabic-domains.org/docs/IDN-ADNPP-Report.pdf

 

IDN Evaluation 計畫是由Japan Registry Services Co.(JPRS)China Network Information Center(CNNIC)National Information Development Agency of Korea(NIDA)Taiwan Network Information Center(TWNIC)共同發起測試,目的是evaluate目前網路使用之主要網頁瀏覽器(Web Browsers)及郵件收發軟體(Mail Clients)支援IDN的程度,並彙整四個組織及文字(Japanese, Simple Chinese, Traditional Chinese, Korea)測試結果,總結比較四個報告以提供Internet社群及 ICANN作為參考。

 

測試期間由20081月中旬開始至3月底,期間經APRICOT2008台北會議聚集,討論協商初步之測試結果,以確認問題並重新定義統一terminology用語,同時討論規範相關測試環境,並交換意見有關統計報告之呈現方式。

 

測試個案為四個組織共同研擬決定的,目的是要以相同意義的IDN網址,以不同語言呈現,比較於在相同的廠牌Web BrowserMail Clients下,各IDN語系在其各語系支援的Web BrowserMail Clients版本搭配之差異。

 

Web BrowserIDN支援之測試,有以下測試的方法與程序:

(1)   直接輸入IDN網址於網址列,測試是否連結ICANN IDN網頁並檢視IDN URL之顯示。

(2)   測試是否可存入網址列(Bookmarked IDN URL)及歷史網址列中(History Saved IDN URL)

(3)   測試是否可再次造訪網址列/歷史網址列(Revisit Bookmarked/History Saved IDN URL)

(4)   撰寫測試網頁,測試IDN URL 連結狀況。

(5)   測試是否顯示URLStatus Bar

(6)   連結後是否可存入網址列(Bookmarked IDN URL)及歷史網址列中(History Saved IDN URL)

(7)   連結是否可再次造訪網址列/歷史網址列(Revisit Bookmarked/History Saved IDN URL)

 

Mail ClientsIDN支援之測試,有以下測試的方法與程序:

(1) 直接輸入IDN郵件地址於收信者,測試是否可以顯示(Input mail address string at the To box)

(2) 測試是否可寄出IDN郵件地址(Displayed mail address at the To box)

(3) 測試是否可儲存IDN郵件地址於通訊錄(Address book saved mail address string)

(3)   測試是否可由通訊錄中將IDN郵件地址叫出(Address input from address book)

(4)   撰寫測試郵件,測試IDN URL 連結狀況。

(5)   測試是否顯示URLStatus Bar(Link display in status bar)

(6)   Click後是否可連結並顯示(Displayed URL at the address bar / To box After clicking)

 

IETF 71會議於美國費城舉辦期間,TWNIC與其他三組織共同討論彙整資料,得出以下初步結論:

n          Web Browsers方面: 網路上幾個主要的Web Browser IE7Opera9Firefox2Safari3支援IDN情況較好,同時測試到版本愈舊愈不支援IDN,如IE6就支援IDN較少。

n          Mail Clients方面: 幾個使用較多的郵件收發軟體如Outlook2007Opera9支援IDN的情況較好,但Outlook ExpressThunderbird2較少支援IDN

n          Web Mail方面: 目前測試三家使用者較常使用的Web MailGmailYahoo MailLive Hotmail皆較不支援IDN

 

    此整合之報告將公佈於APTLD IDN Mailing ListICANN IDN wiki Moderators' Mailing List,以徵詢網路各界之建議與意見,故建議本中心未來應持續主動參與IDN後續測試項目活動,並提供台灣實地之使用經驗給Internet社群參考,為Internet盡點心力,並為未來IDN TLD的開放預先做好準備。
 
 

四、建議意見

1.         持續追踪 mailing list 上之討論及配合事項。
2.         可適時將中心所實作之 EAI 環境適時回報至 EAI Design Team
3.         2919Bis 巳定案,中心可適合相對配合並關切 ICANN 方面 IDN TLD 的發展。
4.         EAI 的互連測試為下次 IETF 重點,中心需投注相對人力配合。
5.         IDN 測試各方仍需多連絡及整理結果。
 

 

五、其他相關事項或資料

有關第七十一次IETF會議議程及相關會議資料請參考(Agenda/ Session/ Presentations)

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=7