Network Working Group Y. Yoneya Internet-Draft JPRS Expires: Aug 20, 2005 Feb 20, 2005 IDN aware application implementation guideline draft-yoneya-idn-app-guideline-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Since IDN Standards [RFC3490-3492] were published, some of gTLDs and ccTLDs began IDN registration and resolution service. Furthermore, many major Web browsers became IDN aware. IDNs seem to be popularized soon. Meanwhile, IDN introduces huge number of characters which can represent domain name, so it increases human misreading of domain name with similar looking characters. This issue was discussed deeply during IDN standardization and service development, and as a result, JET Guideline [RFC3743] and ICANN IDN Guideline [ICANN-IDN] was published. Even if TLD registries comply such guidelines, bad-faith guys may use IDNs to deceive human eyes with similar looking characters. To protect users from such deceiver, implementation guideline for how to handle IDNs at the User Interface level is important. This document is intended to be such guideline for application implementers. 1. Introduction IDN Standards allows using any sequence of non-prohibited Unicode characters to compose Internationalized domain name. It have to be considered as technical margin, and have to be recognized unlimited use of IDN specification will cause confusion of users. JET Guideline and ICANN IDN Guideline were developped to decrease such confusion, but bad-faith guys are still possible to use such IDN specification to deceive Internet users. Through IDN experiences, to decrease such confusion, importance of additional User Interface level support is recognized. 2. IDN aware application implementation guideline [ At this moment, this guideline is narrowing its scope to Web browsers. ] 2.1 Visibility support If user typed and / or copy-and-pasted URI included Internationalized character(s) in domain name part, then displayed URI should be colored or have icon like HTTPS access. If the terminal doesn't have color or attribute capability, then displayed URI should be Punycode as a default. Having toggle switch to display IDN and Punycode in address bar will be helpful. 2.2 Introduce additional mapping Some of mathematical operators have the same shape with ASCII punctuations which have special meaning in many protocols. Those characters may be "map"ped to ASCII characters. U+2212 -> U+002D U+2215 -> U+002F U+2236 -> U+003A If applications don't want to against protocol specification, those characters should be displayed strongly distinguishable form or color or code such as %-encoding. 2.3 Introduce additional prohibit characters At this moment, there is no significant advantage to use symbolic characters in IDN. Treating such characters as "prohibited" in NAMEPREP [RFC3491] stage won't be a serious problem. Followings may be treated as "prohibited" in applications. U+2000-U+2AFF: Punctuations, Symbols, Marks, and so on. U+3200-U+32FF: Enclosed CJK Letters and Months U+3300-U+33FF: CJK Compatibility If applications don't want to against protocol specification, those characters should be displayed strongly distinguishable form or color or code such as %-encoding. 2.4 IDN Language Table reference [ TBD. some sort of table lookup mechanism for IDN Language Table will be helpful ] 3. References [RFC3454] P. Hoffman and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC3490] P. Faltstrom, P. Hoffman, and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3491] P. Hoffman, and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3492] A. Costello, "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC3743] K. Konishi, K. Huang, H. Qian, and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, April 2004. [ICANN-IDN] Internet Corporation for Assigned Names and Numbers, "Guidelines for the Implementation of Internationalized Domain Names, Version 1.0", June 2003. 4. Security considerations See "Security Considerations" section in STRINGPREP [RFC3454]. 5. Author's Address Yoshiro YONEYA Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065, JAPAN yone@jprs.co.jp Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.