< draft-iab-dns-zone-codepoint-pples-01.txt   draft-iab-dns-zone-codepoint-pples-02.txt >
Network Working Group A. Sullivan Network Working Group A. Sullivan
Internet-Draft Dyn, Inc. Internet-Draft Dyn, Inc.
Intended status: Informational D. Thaler Intended status: Informational D. Thaler
Expires: June 7, 2013 Microsoft Expires: August 3, 2013 Microsoft
J. Klensin J. Klensin
O. Kolkman O. Kolkman
NLnet Labs NLnet Labs
December 4, 2012 January 30, 2013
Principles for Unicode Code Point Inclusion in Labels in the DNS Principles for Unicode Code Point Inclusion in Labels in the DNS
draft-iab-dns-zone-codepoint-pples-01 draft-iab-dns-zone-codepoint-pples-02
Abstract Abstract
IDNA makes available to DNS zone administrators a very wide range of IDNA makes available to DNS zone administrators a very wide range of
Unicode code points. Most operators of zones should probably not Unicode code points. Most operators of zones should probably not
permit registration of U-labels using the entire range. This is permit registration of U-labels using the entire range. This is
especially true of zones that accept registrations across especially true of zones that accept registrations across
organizational boundaries, such as top-level domains and, most organizational boundaries, such as top-level domains and, most
importantly, the root. It is unfortunately not possible to generate importantly, the root. It is unfortunately not possible to generate
algorithms to determine whether permitting a code point presents a algorithms to determine whether permitting a code point presents a
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 7, 2013. This Internet-Draft will expire on August 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 8 skipping to change at page 3, line 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. IAB Members at the Time of This Writing . . . . . . . . . . . 10 11. IAB Members at the Time of This Writing . . . . . . . . . . . 10
12. Informative References . . . . . . . . . . . . . . . . . . . . 10 12. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Operators of a DNS zone need to set policies around what Unicode code Operators of a DNS zone need to set policies around what Unicode code
points are allowed in labels in that zone. Typically there a number points are allowed in labels in that zone. Typically there are a
of important goals to consider when constructing such policies. number of important goals to consider when constructing such
These include, for instance, possible visual confusability between policies. These include, for instance, avoiding possible visual
two labels, possible confusion between Fully-Qualified Domain Names confusability between two labels, avoiding possible confusion between
(FQDNs) and IP address literals, and other usability and Fully-Qualified Domain Names (FQDNs) and IP address literals,
accessibility issues. accessibility to the disabled (see [WCAG20] for some discussion in a
web context), and other usability issues.
This document provides a set of principles that zone operators can This document provides a set of principles that zone operators can
use to construct their code point policies in order to improve use to construct their code point policies in order to improve
usability and clarity and thereby reduce confusion. usability and clarity and thereby reduce confusion.
1.1. Terminology 1.1. Terminology
This document uses the following terms. This document uses the following terms.
A-label: an LDH label that starts with "xn--" and meets all the A-label: an LDH label that starts with "xn--" and meets all the
skipping to change at page 8, line 37 skipping to change at page 8, line 37
the list of code points to be permitted should change very slowly, if the list of code points to be permitted should change very slowly, if
at all, and usually only in the direction of permitting an addition at all, and usually only in the direction of permitting an addition
as time and experience indicates that inclusion of such a code point as time and experience indicates that inclusion of such a code point
is both safe and consistent with these principles. is both safe and consistent with these principles.
5. Principle Specific to the Root Zone 5. Principle Specific to the Root Zone
5.1. Letter Principle 5.1. Letter Principle
There is a note in [RFC1123] that top-level labels "will be There is a note in [RFC1123] that top-level labels "will be
alphabetic". In the absensce of widespread agreement about the force alphabetic". In the absence of widespread agreement about the force
of that note, prudence suggests that U-labels in the root zone should of that note, prudence suggests that U-labels in the root zone should
exclude code points that are not normally used to write words, or exclude code points that are not normally used to write words, or
that are in some cases normally used for purposes other than writing that are in some cases normally used for purposes other than writing
words. This is not the same as using Unicode's General_Category to words. This is not the same as using Unicode's General_Category to
include only letters. It is a restriction that expands the possible include only letters. It is a restriction that expands the possible
class of included code points beyond the Unicode letters, but only class of included code points beyond the Unicode letters, but only
expands so far as to include the things that are normally used to expands so far as to include the things that are normally used to
create words. Under this principle, code points with (for example) create words. Under this principle, code points with (for example)
General_Category Mn (Nonspacing_Mark) might be included -- but only General_Category Mn (Nonspacing_Mark) might be included -- but only
those that are used to write words and not (for instance) musical those that are used to write words and not (for instance) musical
skipping to change at page 12, line 5 skipping to change at page 11, line 43
Internationalized Domain Names in Applications (IDNA) Internationalized Domain Names in Applications (IDNA)
2008", RFC 5895, September 2010. 2008", RFC 5895, September 2010.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. September 2011.
[UTR36] Davis, M. and M. Suignard, "Unicode Security [UTR36] Davis, M. and M. Suignard, "Unicode Security
Considerations", Unicode Technical Report #36, July 2012. Considerations", Unicode Technical Report #36, July 2012.
[WCAG20] "Web Content Accessibility Guidelines (WCAG) 2.0",
December 2008.
Authors' Addresses Authors' Addresses
Andrew Sullivan Andrew Sullivan
Dyn, Inc. Dyn, Inc.
150 Dow St 150 Dow St
Manchester, NH 03101 Manchester, NH 03101
U.S.A. U.S.A.
Email: asullivan@dyn.com Email: asullivan@dyn.com
 End of changes. 8 change blocks. 
12 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/