One document matched: draft-klensin-idna-alternatives-00.txt
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, <http://www.ietf.org/internet-drafts/
Klensin Expires August 21, 2008 [Page 7]
Internet-Draft IDNA Alternatives February 2008
draft-klensin-idnabis-issues-06.txt>.
[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]
| PAFTECH AB 2003-2024 | 2024-04-23 19:35:58 |