Network Working Group                                        A. Sullivan
Internet-Draft                                                 Dyn, Inc.
Intended status: Informational                                 D. Thaler
Expires: December 7, 2012                                      Microsoft
                                                              O. Kolkman
                                                              NLnet Labs
                                                            June 5, 2012


 Principles for Unicode Code Point Inclusion in Labels in the DNS Root
               draft-sullivan-dns-zone-codepoint-pples-00

Abstract

   Traditionally, the management of the DNS root zone permitted only
   "alphabetic" labels.  As long as the root zone included only ASCII
   characters, and as long as there was only one form of a label, the
   restriction plainly meant that only the letters A-Z and a-z were
   permitted.  The advent of internationalized labels using IDNA2008
   presents some complications for the restriction.  One of the
   complications is the meaning of the term "alphabetic" when applied to
   the Unicode code points in U-labels.  This memo presents a set of
   principles that can be used to determine whether a Unicode code point
   may be wisely included in the repertoire of permissible code points
   in a U-label in a zone.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 7, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Sullivan, et al.        Expires December 7, 2012                [Page 1]


Internet-Draft       Root Zone Code Point Principles           June 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Background and Introduction . . . . . . . . . . . . . . . . . . 3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Conservatism Principle  . . . . . . . . . . . . . . . . . . . . 4
   3.  Inclusion Principle . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Simplicity Principle  . . . . . . . . . . . . . . . . . . . . . 4
   5.  Predictability Principle  . . . . . . . . . . . . . . . . . . . 5
   6.  Stability Principle . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Letter Principle  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   12. Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
























Sullivan, et al.        Expires December 7, 2012                [Page 2]


Internet-Draft       Root Zone Code Point Principles           June 2012


1.  Background and Introduction

   In recent communications ([IABCOMM1] and [IABCOMM2]), the IAB has
   emphasized the importance of conservatism in allocating labels
   conforming to IDNA2008 ([RFC5890], [RFC5891], [RFC5892], [RFC5893],
   [RFC5894], [RFC5895]) inside the root zone.  Traditional LDH-labels
   (see [RFC5890] for definitions of IDNA terms) in the root zone used
   only alphabetic characters (i.e., ASCII a-z or A-Z).  Matters are
   more complicated with U-labels, however.  The IAB communications
   recommended that U-labels permit only code points with a
   General_Category (gc) of Ll (Lowercase_Letter), Lo (Other_Letter), or
   Lm (Modifier_Letter), but noted that for practical considerations
   other code points might be permitted on a case-by-case basis.  In
   what follows we will use the Unicode notation; e.g., gc=Ll.

   The IAB recommendation does, however, present some problems that need
   to be addressed.  First, it is by no means clear that all of the code
   points with gc=Lo or gc=Lm and which are permitted under IDNA2008 are
   appropriate for the root zone.  To take but one example, the code
   point U+02BC MODIFIER LETTER APOSTROPHE has gc=Lm.  In practically
   every rendering (we are unaware of an exception), U+02BC is
   indistinguishable from U+2019 RIGHT SINGLE QUOTATION MARK, which has
   gc=Pf (Final_Punctuation).  U+02BC will also be read by large numbers
   of people as being the same character as U+0027 APOSTROPHE, which has
   gc=Po (Other_Punctuation).  U+02BC is PROTOCOL VALID (PVALID) under
   IDNA2008 (see [RFC5892]), whereas both other code points are
   DISALLOWED.  So, to begin with, it is plain that not every code point
   with gc in {Ll, Lo, Lm} is consistent with any conservatism
   principle.

   To make matters worse, some languages are dependent on code points
   with gc=Mc (Spacing_Mark) or gc=Mn (Nonspacing_Mark).  This
   dependency is particularly common in Indic languages, though not
   exclusive to them.  (At the risk of vastly oversimplifying, the
   overarching issue is mostly the interaction of complex writing
   systems and the way Unicode works.)  To restrict users of those
   languages only to code points with gc in {Ll, Lo, Lm} would be
   extremely limiting.  While DNS labels are not words, or sentences, or
   phrases (as noted in [RFC4690]), they are intended as useful
   mnemonics.  Mnemonics that diverge wildly from the usual conventions
   in a language are likely to attract strong objections, particularly
   in the root.  The objections might drag the discussion away from
   sound management of the shared DNS root zone and towards discussions
   of cultural hegemony.  That sort of discussion itself might present
   risks for the operation of the root zone.

   For reasons of sound management, it is not desirable to decide
   whether to permit a given code point only when an application



Sullivan, et al.        Expires December 7, 2012                [Page 3]


Internet-Draft       Root Zone Code Point Principles           June 2012


   containing that code point is pending.  That approach reduces
   predictability and is bound to appear subject to special pleas.  It
   is better instead to come up with a set of principles for guiding
   decisions about code points.  These principles can then function as
   meta-rules, determining the rules for inclusion of any code point
   (from those permitted by IDNA) in labels in the root.  The principles
   might also be adopted by other zones that are shared by much of the
   Internet.  Such a set of principles follows in the sections below.
   Each section includes remarks on the extent to which the principle
   could be wisely adopted by zones other than the root.

1.1.  Terminology

   Terms relevant to IDNA2008 can be found in [RFC5890].  Other relevant
   internationalization terms are defined in [RFC6365].

   This memo does not propose a protocol standard, and the use of words
   like "should" follow the ordinary English meaning, and not that laid
   out in [RFC2119].


2.  Conservatism Principle

   The root zone is, by definition, the one DNS zone that must be shared
   by everybody.  Therefore, any decision to permit a code point in the
   root zone should be as conservative as practicable.  Doubts should
   always be resolved in favor of rejecting a code point for inclusion
   rather than in favor of including it, in order to minimize risk.

   This principle is easily (and wisely) adoptable by any zone.  It is
   also the one that is most likely to yield the safest result.


3.  Inclusion Principle

   Just as IDNA2008 starts from the principle that the Unicode range is
   excluded, and then adds code points according to derived properties
   of the code points, so the root zone should only permit inclusion of
   a code point if it is known to be safe.  The default treatment of a
   code point should be that it is excluded.

   This principle is easily (and wisely) adoptable by any zone.


4.  Simplicity Principle

   The rules for determining whether a code point is to be included
   should be simple enough that they are readily understood by someone



Sullivan, et al.        Expires December 7, 2012                [Page 4]


Internet-Draft       Root Zone Code Point Principles           June 2012


   with a moderate background in the DNS and Unicode issues.  This
   principle does not mean that a completely naive person needs to be
   able to understand the rationale for why a code point is included,
   but it does mean that the reason for inclusion of very peculiar code
   points, even if the code points are safe in themselves, will be too
   difficult to understand and will therefore be rejected.

   The meaning of "simple" or "readily understood" is context dependent.
   For instance, the root zone has to serve everyone in the world; for
   practical purposes, this means that the reasons for including a code
   point need to be comprehensible even to people who cannot use the
   script where the code point is found.  In a zone that permits a very
   small subset of Unicode characters (for instance, only those needed
   to write a single language) and that supports a clearly-delineated
   linguistic community (for instance, the speakers of a single language
   with well-understood written conventions), more complicated rules
   might be acceptable.


5.  Predictability Principle

   The rules for determining whether a code point is to be included
   should be predictable enough that those with the requisite
   understanding of DNS, IDNA, and Unicode would all generally reach the
   same conclusion.  This is not a requirement for algorithmic treatment
   of code points (the difficulties with the Unicode Letter and Mark
   categories illustrate why that would be too difficult).  It is rather
   to say that the consistent application of professional judgment is
   likely to yield the same results; combined with the principle in
   Section 2, when results are not predictable the anomalous code point
   would not be included.

   Just as in Section 4, this principle is not easily extended to zones
   lower than the root because what is predictable within a given
   language community is possibly very surprising across languages.


6.  Stability Principle

   Once a code point is permitted, it is at least very hard to stop
   permitting that code point.  In general, 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 as time and experience
   indicates that inclusion of such a code point is both safe and
   consistent with these principles.

   This principle likely extends to every delegation-centric domain: if
   one delegation is permitted to use a code point, it is very hard to



Sullivan, et al.        Expires December 7, 2012                [Page 5]


Internet-Draft       Root Zone Code Point Principles           June 2012


   see why others might not.


7.  Letter Principle

   In keeping with the spirit of the note in [RFC1123] that top-level
   labels "will be alphabetic", the rules should not include code points
   that are not normally used to write words, or 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 include only letters.
   But it is a restriction that expands the possible class of included
   code points beyond the Unicode letters, but only expands so far as to
   include the things that are normally used the way letters are.  Under
   this principle, code points with (for example) gc=Mn might be
   included -- but only those that are used to write words and not (for
   instance) musical symbols.  This principle should be applied as
   narrowly as possible; as [RFC4690] says, "While DNS labels may
   conveniently be used to express words in many circumstances, the goal
   is not to express words (or sentences or phrases), but to permit the
   creation of unambiguous labels with good mnemonic value."

   Because the root zone must be shared by everyone, this principle is
   more important in it than in zones that are intended for use by
   clearly-defined linguistic communities.


8.  Conclusion

   The foregoing principles could be applied generally when considering
   any range of Unicode code points for possible inclusion in the root
   zone.  It is worth observing that doing anything (especially in light
   of Section 6) implicitly disadvantages communities with a writing
   system not yet well understood and not represented in the technical
   and policy communities involved in the discussion.  That disadvantage
   is to be guarded against as much as practical, but is effectively
   impossible to prevent (while still taking action) in light of
   imperfect human knowledge.


9.  Security Considerations

   The principles outlined in this memo are partly intended to reduce
   the possibility of confusion among different labels.  While these
   principles may contribute to reduction of risk, they are not
   sufficient to provide a comprehensive internationalization policy for
   zone management.





Sullivan, et al.        Expires December 7, 2012                [Page 6]


Internet-Draft       Root Zone Code Point Principles           June 2012


10.  IANA Considerations

   None.  RFC Editor: this section may be removed on publication.


11.  Acknowledgements

   The authors thank the participants in the IAB Internationalization
   programme for the discussion of the ideas in this memo.


12.  Informative References

   [IABCOMM1]
              Internet Architecture Board, "IAB Statement: 'The
              interpretation of rules in the ICANN gTLD Applicant
              Guidebook.'", February 2012.

   [IABCOMM2]
              Internet Architecture Board, "Response to ICANN questions
              concerning 'The interpretation of rules in the ICANN gTLD
              Applicant Guidebook'", March 2012.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4690]  Klensin, J., Faltstrom, P., Karp, C., and IAB, "Review and
              Recommendations for Internationalized Domain Names
              (IDNs)", RFC 4690, September 2006.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891, August 2010.

   [RFC5892]  Faltstrom, P., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, August 2010.

   [RFC5893]  Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5893, August 2010.




Sullivan, et al.        Expires December 7, 2012                [Page 7]


Internet-Draft       Root Zone Code Point Principles           June 2012


   [RFC5894]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Background, Explanation, and
              Rationale", RFC 5894, August 2010.

   [RFC5895]  Resnick, P. and P. Hoffman, "Mapping Characters for
              Internationalized Domain Names in Applications (IDNA)
              2008", RFC 5895, September 2010.

   [RFC6365]  Hoffman, P. and J. Klensin, "Terminology Used in
              Internationalization in the IETF", BCP 166, RFC 6365,
              September 2011.


Authors' Addresses

   Andrew Sullivan
   Dyn, Inc.
   150 Dow St
   Manchester, NH  03101
   U.S.A.

   Email: asullivan@dyn.com


   Dave Thaler
   Microsoft
   One Microsoft Way
   Redmond, WA  98052
   U.S.A.

   Email: dthaler@microsoft.com


   Olaf Kolkman
   NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   The Netherlands

   Email: olaf@NLnetLabs.nl











Sullivan, et al.        Expires December 7, 2012                [Page 8]