Network Working Group J. Klensin Internet-Draft February 18, 2008 Intended status: Informational Expires: August 21, 2008 Internationalized Domain Names: Alternatives to IDNA draft-klensin-idna-alternatives-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 as "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 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Internet protocol for internationalized domain names (IDNs) is documented in RFC 3490 and associated documents and commonly known as IDNA. While that protocol was being developed (and more recently), there were a number of alternate proposals and suggestions for different ways to do IDNs. IDNA was favored over those alternatives, but variations on them seem to keep reappearing with the suggestion that they are novel ideas. This memo describes some of those suggested alternatives and summarizes the reasons why they were not Klensin Expires August 21, 2008 [Page 1] Internet-Draft IDNA Alternatives February 2008 favored over IDNA. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Key IDNA Decision . . . . . . . . . . . . . . . . . . . . . 3 3. Matching versus Mapping . . . . . . . . . . . . . . . . . . . . 4 4. Other Suggestions for IDNs . . . . . . . . . . . . . . . . . . 4 4.1. An Alternate DNS Class . . . . . . . . . . . . . . . . . . 4 4.1.1. Description . . . . . . . . . . . . . . . . . . . . . . 4 4.1.2. Advantages . . . . . . . . . . . . . . . . . . . . . . 4 4.1.3. Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.4. Key Reasons for Rejection . . . . . . . . . . . . . . . 5 4.2. Phonetic Names . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Description . . . . . . . . . . . . . . . . . . . . . . 5 4.2.2. Advantages . . . . . . . . . . . . . . . . . . . . . . 5 4.2.3. Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.4. Key Reasons for Rejection . . . . . . . . . . . . . . . 5 4.3. TLD-Dependent Matching . . . . . . . . . . . . . . . . . . 5 4.3.1. Description . . . . . . . . . . . . . . . . . . . . . . 5 4.3.2. Advantages . . . . . . . . . . . . . . . . . . . . . . 5 4.3.3. Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 6 4.3.4. Key Reasons for Rejection . . . . . . . . . . . . . . . 6 4.4. Abandon Unicode . . . . . . . . . . . . . . . . . . . . . . 6 4.4.1. Description . . . . . . . . . . . . . . . . . . . . . . 6 4.4.2. Advantages . . . . . . . . . . . . . . . . . . . . . . 6 4.4.3. Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 6 4.4.4. Key Reasons for Rejection . . . . . . . . . . . . . . . 6 4.5. DNS Extension and Server-side Matching . . . . . . . . . . 6 4.5.1. Description . . . . . . . . . . . . . . . . . . . . . . 6 4.5.2. Advantages . . . . . . . . . . . . . . . . . . . . . . 7 4.5.3. Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 7 4.5.4. Key Reasons for Rejection . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Klensin Expires August 21, 2008 [Page 2] Internet-Draft IDNA Alternatives February 2008 1. Introduction The Internet protocol for internationalized domain names (IDNs) is documented in RFC 3490 [RFC3490] and associated documents[RFC3491] [RFC3492] [RFC3454] and commonly known as IDNA (Internationalizing Domain Names in Applications). While that protocol was being developed (and more recently), there were a number of alternate proposals and suggestions for different ways to do IDNs. IDNA was favored over those alternatives, but variations on them seem to keep reappearing with the suggestion that they are novel ideas. This memo describes some of those suggested alternatives and summarizes the reasons why they were not favored over IDNA. Section 4.1Section 4.3 While this document may be relevant to the discussion of IDNA revisions and updates, it is not expected to become the product of any IETF WG or other formal effort. This document assumes a reasonable understanding of the terminology used to describe IDNA. That terminology appears, in slightly different forms, in [RFC3490], [RFC4690], and [IDNA200X-Rationale]. The sections that immediately follow supply some general information and concepts that are key to putting the proposals that follow into an appropriate context. Then, Section 4 discusses each of the alternative in turn. 2. The Key IDNA Decision The key decision underlying IDNA was that implementation and deployment of IDNs should not require any changes to the DNS itself. Consequently, the basic DNS matching algorithm (case-insensitive mapping for ASCII characters, undefined mapping for most other strings) was to be unchanged and any characters in ordinary labels would have to by in ASCII and conform to the "hostname" (letter- digit-hyphen or LDH) rules. This decision was made for two reasons. The first was to reduce the risk of IDNs "breaking" the DNS, presumably to zero. The second was to permit faster deployment of IDNs and deployment on an application-by-applications basis, rather than requiring, in its most extreme form, a synchronized change across the Internet. While they differ by degree and most raise other problems, virtually all of the suggestions identified below would have required disruptive changes to the DNS of one sort or another. Consequently, once the "no DNS changes" decision was made, the vast majority of them were not seriously considered further. Klensin Expires August 21, 2008 [Page 3] Internet-Draft IDNA Alternatives February 2008 3. Matching versus Mapping ... To be supplied ... 4. Other Suggestions for IDNs This section contains a list of suggestions for the support of IDNs other than the IDNA protocol that eventually emerged. The alternatives do not appear in any particular order. Each subsection describing an alternative contains a description of that alternative, a discussion of its advantages and disadvantages, and a description of why IDNA was favored over it. 4.1. An Alternate DNS Class 4.1.1. Description The DNS supports a concept of "Class", essentially a separate DNS tree with the potential for some changed resolution rules. Classes have not been heavily used; the familiar DNS operates entirely in terms of "Class=IN" (for "Internet"). This proposal was built on the assumption that any IDN approach that attempted to accommodate non- ASCII strings by encoding them into ASCII would ultimately turn out to be problematic. Hence, it represented an attempt to move away from the "ASCII DNS" toward a fully international DNS, rather than patching non-ASCII characters onto the ASCII base. The general idea was to define a completely new Class, with non-ACII characters and operations on them fully defined, and migrate to it and away from Class=IN. As a server-based approach, it would support server-side matching and preservation of presentation distinctions. The suggestion was discussed in a long-expired Internet Draft[IDN-NewClass]. 4.1.2. Advantages The obvious advantage claimed for this proposal was that it would result in a fully-internationalized DNS, not one that was oriented toward ASCII but that had add-on support for other characters. 4.1.3. Drawbacks A new DNS Class would presumably take much longer to deploy, even with backward-compatibility mechanisms, than an application-only approach such as IDNA. In addition, while it was not so obvious when the Internet-Draft was written, it now seems clear that there is no Klensin Expires August 21, 2008 [Page 4] Internet-Draft IDNA Alternatives February 2008 such thing as a solution that is completely server-side in the same way that the IDNA approach is completely client-side. The client would still presumably have to provide some normalization and preprocessing. The server-side decisions about what to match and what to treat as distinct would probably also be very complex and controversial. 4.1.4. Key Reasons for Rejection This proposal was rejected by the IDN Working Group because it would have involved much more complex and time-consuming deployment problems than IDNA. 4.2. Phonetic Names 4.2.1. Description ... to be supplied ... 4.2.2. Advantages ... to be supplied ... 4.2.3. Drawbacks ... to be supplied ... 4.2.4. Key Reasons for Rejection ... to be supplied ... 4.3. TLD-Dependent Matching 4.3.1. Description There have been many proposals, most of them since RFC 3490 was published, to somehow condition the content, presentation, or matching rules for particular labels based in the particular top- level domain --presumably tied to a language-- in which the label was found. It is not believed that any of these suggestions have been written up in enough detail to permit a careful and critical evaluation of it, so the comments below apply more to this general class of proposals rather than to any particular one. 4.3.2. Advantages For some scripts, Unicode requires (or is believed by some language authorities to require) language-dependent rendering or matching Klensin Expires August 21, 2008 [Page 5] Internet-Draft IDNA Alternatives February 2008 rules. Some characters are essential to representation of the orthography of some languages in Unicode but are meaningless or dangerous in strings consisting of characters associated with other languages. If one could somehow identify the language associated with a particular label by examining its relationship to the DNS tree in which it were located, one could apply language-specific (rather than merely script-specific or context-dependent) rules to the interpretation and registration of labels. 4.3.3. Drawbacks This set of ideas are not feasible without very significant changes to the DNS. Not only are there difficulties in considering a label only the context of the fully-qualified name of which it is part, but complex questions arise about the practicality of rules of these types in the DNS administrative hierarchy in practice. The introduction of the DNAME RR introduces an additional complication, since a system examining a given label cannot know the tree from which it will be referenced. 4.3.4. Key Reasons for Rejection ... to be supplied ... 4.4. Abandon Unicode 4.4.1. Description ... to be supplied ... 4.4.2. Advantages ... to be supplied ... 4.4.3. Drawbacks ... to be supplied ... 4.4.4. Key Reasons for Rejection ... to be supplied ... 4.5. DNS Extension and Server-side Matching 4.5.1. Description ... to be supplied ... Klensin Expires August 21, 2008 [Page 6] Internet-Draft IDNA Alternatives February 2008 4.5.2. Advantages ... to be supplied ... 4.5.3. Drawbacks ... to be supplied ... 4.5.4. Key Reasons for Rejection ... to be supplied ... 5. IANA Considerations This document provides a historical perspective, not a protocol specification. It involves no actions for IANA. 6. Security Considerations While comments about some of the relative security implications and risks of different alternatives appear above, this document contains a historical perspective, not a protocol specification or proposal, and consequently has no security implications for the Internet other than, perhaps, the benefit of explaining why some alternatives should not be further considered or even introduced locally. 7. Acknowledgments ... Placeholder ... to be supplied ... 8. References 8.1. Normative References 8.2. Informative References [IDN-NewClass] Klensin, J., "Internationalizing the DNS -- A New Class", June 2002. [IDNA200X-Rationale] Klensin, J., Ed., "Internationalizing Domain Names for Applications (IDNA): Issues, Explanation, and Rationale", February 2008, . [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002. [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003. [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003. [RFC4690] Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and Recommendations for Internationalized Domain Names (IDNs)", RFC 4690, September 2006. Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john+ietf@jck.com Klensin Expires August 21, 2008 [Page 8] Internet-Draft IDNA Alternatives February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Klensin Expires August 21, 2008 [Page 9]