<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>


<rfc category="info" ipr="trust200902" docName="draft-iab-dns-zone-codepoint-pples-00">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes" ?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes" ?>
  <?rfc compact="yes" ?>
  <?rfc subcompact="no" ?>
  <?rfc tocompact="yes" ?>
  <?rfc comments="yes" ?>
  <?rfc inline="yes" ?>
  <front>
    <title abbrev="DNS Zone Code Point Principles">Principles for
    Unicode Code Point Inclusion in Labels in the DNS</title>
    <author initials="A." surname="Sullivan" fullname="Andrew Sullivan">
      <organization>Dyn, Inc.</organization>
      <address>
        <postal>
          <street>150 Dow St</street>
          <city>Manchester</city>
          <region>NH</region>
          <code>03101</code>
          <country>U.S.A.</country>
        </postal>
        <email>asullivan@dyn.com</email>
      </address>
    </author>
    <author initials="D." surname="Thaler" fullname="Dave Thaler">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>One Microsoft Way</street>
          <city>Redmond</city>
          <region>WA</region>
          <code>98052</code>
          <country>U.S.A.</country>
        </postal>
        <email>dthaler@microsoft.com</email>
      </address>
    </author>
    <author fullname="John C Klensin" initials="J.C."
surname="Klensin" >
<!--      <organization /> -->
      <address>
        <postal>
          <street>1770 Massachusetts Ave, Ste 322</street>
          <city>Cambridge</city> <region>MA</region>
          <code>02140</code>
          <country>USA</country>
        </postal>
        <phone>+1 617 491 5735</phone>
        <!-- facsimile phone number and URI if appropriate -->
        <email>john-ietf@jck.com</email>
      </address>
    </author>
    <author initials="O." surname="Kolkman" fullname="Olaf Kolkman">
      <organization>NLnet Labs</organization>
      <address>
        <postal>
          <street>Science Park 400</street>
          <city>Amsterdam</city>
          <code>1098 XH</code>
          <country>The Netherlands</country>
        </postal>
        <email>olaf@NLnetLabs.nl</email>
      </address>
    </author>
    <date year="2012"/>
    <abstract>
      <t>
        IDNA makes available to DNS zone administrators a very wide
        range of Unicode code points.  Most operators of zones should
        probably not permit registration of U-labels using the entire
        range.  This is especially true of zones that accept
        registrations from outside parties, including (and most
        importantly) the root.  It is unfortunately not possible to
        generate algorithms to determine whether a code point is
        intrinsically safe to permit.  This memo presents a set of
        principles that can be used to guide the decision of whether a
        Unicode code point may be wisely included in the repertoire of
        permissible code points in a U-label in a zone.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t> 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 of important goals to consider when constructing
          such policies.  These include, for instance, possible visual
          confusability between two labels, possible confusion between
          Fully-Qualified Domain Names (FQDNs) and IP address literals,
          and other usability and accessibility issues.
      </t>
      <t> This document provides a set of principles that zone operators
          can use to construct their code point policies in order to
          improve usability and clarity and thereby reduce confusion.
      </t>

      <section title="Terminology" anchor="terms">
        <t>This document uses the following terms.</t>

        <t><list style="hanging">
        <t>LDH Label: a string consisting of ASCII letters, digits,
           and the hyphen, with additional restrictions as explained
           in Section 2.3.1 of <xref target="RFC5890" />.
        </t>

        <t>A-label: an LDH label that starts with "xn--" and
           meets all the IDNA requirements, with additional
           restrictions as explained in Section 2.3.2.1 of
           <xref target="RFC5890" />.
        </t>

        <t>U-label: a string of Unicode characters that meets all
           the IDNA requirements and includes at least one non-ASCII
           character, with additional restrictions as explained
           in Section 2.3.2.1 of <xref target="RFC5890" />.
        </t>

        <t>Public zone: in this document, a DNS zone that accepts
           registration requests from organizations outside the zone
           administrator's own organization.  (Whether the zone performs
           delegation is a separate question.  What is important is 
           the diversity of the registration-requesting community.)
           Note that under this definition, the root zone is a public
           zone, though one that has a unique function in the DNS.
        </t>

        <t>Character: a member of a set of elements used for the 
           organization, control, or representation of data.  See
           Section 2 of <xref target="RFC6365" /> for more details.
        </t>

        <t>Language: a way that humans communicate.  The use of language
           occurs in many forms, the most common of which are speech,
           writing, and signing. See
           Section 2 of <xref target="RFC6365" /> for more details.
        </t>

        <t>Rendering: the display of a string of text.  See
           Section 5 of <xref target="RFC6365" /> for more details.
        </t>

        <t>Script: a set of graphic characters used for the written
           form of one or more languages.  See
           Section 2 of <xref target="RFC6365" /> for more details.
        </t>

        <t>Writing system: a set of rules for using one or more scripts
           to write a particular language.  See
           Section 2 of <xref target="RFC6365" /> for more details.
        </t>
        </list></t>
<!--
        <t>Terms relevant to IDNA2008 can be found in <xref target="RFC5890" />.  
           Other relevant internationalization terms are defined in <xref target="RFC6365" />.
        </t>
-->

        <t>This memo does not propose a protocol standard, and the use
           of words such as "should" follow the ordinary English meaning,
           and not that laid out in <xref target="RFC2119" />.
        </t>
      </section>
    </section>

    <section title="Background">
      <t>In recent communications (<xref target="IABCOMM1" /> and
      <xref target="IABCOMM2" />), the IAB has emphasized the
      importance of conservatism in allocating labels conforming to
      IDNA2008 (<xref target="RFC5890" />, <xref target="RFC5891" />,
      <xref target="RFC5892" />, <xref target="RFC5893" />, <xref
      target="RFC5894" />, <xref target="RFC5895" />) in DNS zones,
      and especially in the root
      zone.  Traditional LDH-labels 
<!-- DT: updated with Terminology section prior to here
      (see <xref target="RFC5890" /> for
      definitions of IDNA terms such as LDH-label, A-label, and U-label)
      <vspace blankLines="0"/><cref> JcK: the number of pointers to
         other documents here could easily send the reader on a merry
         chase.  Such chases discourage reading, especially for an
         ICANN-like audience.  So I think it is probably useful to be
         explicit about what definitions they can find where.</cref><vspace blankLines="0"/>
-->
      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.

<!--  <cref source="ajs@anvilwalrusden.com"> Since JcK hated it so much, the pseudo-math notation is replaced </cref> 
In what follows we will use the Unicode
      notation; e.g., gc=Ll. -->
      </t>

      <t>
<!-- DT: did a very minor rewording. We'll see how the rest of the discussion goes
         and then see what else is needed.

      <vspace blankLines="1"/><cref>JcK: The next few paragraphs need
         to be rewritten to be sure it is when we are talking about
         zones in general and when the topic is the root.   I haven't
         attempted that because I think the story will depend on the
         final organization of the material and how it is introduced. </cref><vspace blankLines="0"/>
-->
      The IAB recommendation does, however, leave some issues open
<!-- DT: Agreed, accepted.
      <vspace blankLines="0"/><cref>JcK: I think "problems" is
         incorrect and looking for trouble.  There may be better terms
         that "open issues" but that is the best I could come up with
         quickly.</cref><vspace blankLines="0"/>
-->
      that need to be addressed.  First, it is by no means clear that
      all of the code points with General_Category Lo or Lm and which
      are permitted under IDNA2008 are appropriate for a zone such as
      the root zone.  To take but one example, the code point U+02BC
      MODIFIER LETTER APOSTROPHE has a General_Category of Lm.  In
      practically every rendering (and we are unaware of an
      exception), U+02BC is indistinguishable from U+2019 RIGHT SINGLE
      QUOTATION MARK, which has a General_Category of 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 a General_Category of Po (Other_Punctuation).  U+02BC
      is PROTOCOL VALID (PVALID) under IDNA2008 (see <xref
      target="RFC5892" />), whereas both other code points are
      DISALLOWED.  So, to begin with, it is plain that not every code
      point with a General_Category of Ll, Lo, or Lm is consistent
      with the type of conservatism principle discussed in <xref
      target="conservatism"/> or the IAB recommendation.</t>

      <t>To make matters worse, some languages are dependent on code
      points with General_Category Mc (Spacing_Mark) or
      General_Category 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 General_Category of Ll, Lo, or Lm.
<!-- DT: done.
      <vspace blankLines="0"/><cref>JcK: Unless we are trying to make
         the point "unless you have already read the Unicode spec and
         understand the way it is constructed, including the
         pseudo-mathematical languages, go play elsewhere" the use of
         that writing style is not helpful.  Please consider following
         the IDNA2008 spec and say, e.g., "... code points with
         general category Ll, Lc, or Lm."</cref><vspace blankLines="0"/>
-->
      would be extremely limiting.  While DNS labels are not words, or
      sentences, or phrases (as noted in <xref target="RFC4690" />),
      they are intended to support 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 DNS zone in question and towards discussions
      of cultural hegemony.  That sort of discussion itself might
      present risks for the operation of the zone.</t>

      <t>Many of the issues above turn out to be relevant to all
      public zones.
<!--
      so-called "public" zones - that is, zones that accept
      registration requests from organizations outside the zone
      administrator's own organization.  (For the purposes of the
      present discussion, whether the zone performs delegation is less
      important.  What is instead important is the diversity of
      the registration-requesting community.)  
-->
      Moreover, the overall
      issue of developing a policy for code point permission is common
      to all zones that accept A-labels or U-labels for registration.
      As section 4.2.4 of <xref target="RFC5891" /> says, every
      registry at every level of the DNS is "expected to establish
      policies about label registrations."</t>

      <t>For reasons of sound management, it is not desirable to
      decide whether to permit a given code point only when an
      application 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 the
      rules governing acceptance of code points in advance.</t>
      
      <t>As is evident from the foregoing discussion about the Letter
      and Mark categories, it is simply not possible to make code
      point decisions algorithmically.  If it were possible to develop
      such an algorithm, it would already exist: the DNS is hardly
      unique in needing to impose restrictions on code points while
      accommodating many different linguistic communities.  Rules
      can nevertheless be made sensibly by using overarching
      principles to guide the rule-making.  These principles function
      as meta-rules, guiding the establishment of rules for inclusion
      of any code point (from those permitted by IDNA) in labels in a
      given zone.</t>

    <section title="Less-restrictive Rules Going Down the DNS Tree">
<!-- DT: Accepted, but reversed order per later comments.

       <t><cref>JcK: This paragraph is really important and its alpha predecessor
          was lost in the introductory material.  I suggest pulling it
          into a separate subsection and rewriting a bit to something
          like the following.  It might even be pulled out into a new
          Section 2 with renumbering - matter of taste.</cref></t>
-->

      <t>A set of principles derived from the above ideas follows in
         <xref target="allzones" /> 
         through <xref target="root" /> below.  Such principles fall
         into three categories.  Some principles apply to every DNS
         zone.  Some additional principles apply to all public zones,
         including the root zone.  Finally, other principles apply
         only to the root zone.  This means that zones higher in the
         DNS tree tend to have more restrictive rules (since
         additional principles apply), and zones lower in the DNS tree
         tend to have less restrictive rules, since they are used
         within a more narrow context.  In general, the relevant
         context for a principle is that of the zone, not that of a
         given subset of the user community; for the root zone, for
         example, the context is "the entire Internet population".
      
<!-- DT: pending discussion, but I've moved the definition of "public zone"
         prominently to the front

      <vspace blankLines="0"/><cref>JcK: I think the above is ok, although
         I've rewritten it a bit.  However, if you want to include
         non-public zones, I think there there are really four cases:
         root/TLD, SLD (or highest level zone at which a [DNS]
         delegation boundary does not also represent a administrative
         authority change (intermediate/structural doamins like CO.UK
         are more like TLDs than SLDs); public zones below the SLD
         level; and non-public zones (SLDs or below unless associated
         with local/fake TLDs that do not appear in the public root).</cref>
-->

<!-- DT: I agree, reordered.

      <vspace blankLines="0"/><cref>Despite the ICANN present-day obsession
          with TLDs and the root, I also think it would be lots
          easier to get the points here across clearly if we explained
          the broadest-applicability rules ("any zone") first, then
          the narrowed things toward the root with each higher level
          being "all of the prior rule, plus additional restrictions".
          Follow the categories of the IAB presentation, but not
          necessarily the ordering - good order for a  high-level
          presentation is not necessarily good order for a document.</cref>          
-->
      </t>
   </section>

    </section>

    <section title="Principles applicable to all zones"
             anchor="allzones">
      
      <section title="Longevity Principle" anchor="longevity">
        <t>Unicode properties of a code point ought to be stable
        across the versions of Unicode that users of the zone are
        likely to have installed.  Because it is possible for the
        properties of a code point to change between Unicode versions,
        a good way to predict such stability is to ensure that a code
        point has in fact been stable for multiple successive versions
        of Unicode.  This principle is related to the Stability
        Principle in <xref target="stability" />.</t>

        <t>The more diverse the community using the zone, the greater
        the importance of following this principle.  The policy for a
        leaf zone in the DNS might only require stability across two
        Unicode versions, wereas a more public zone might require
        stability across four or more releases before the code point's
        properties are considered long-lived and stable.</t>
      </section>

      <section title="Usability Principle" anchor="usability">
        <t>Every zone administrator should be sensitive to the
        potential use of a code point to be permitted, and to be as
        cautious as practical in permitting code points in the zone.
        The Conservatism Principle outlined in <xref
        target="conservatism" /> is in general a good idea, though
        less conservatism may be appropriate in the case of
        well-delineated and less-diverse user communities.  Zone
        administrators should especially consider whether a candidate
        code point could be used maliciously or could present
        difficulty if the code point is encountered outside the usual
        linguistic circumstances.</t>
      </section>
    </section>

    <section title="Principles applicable to all public zones"
            anchor="PublicPrinciples"> 

      <section title="Conservatism Principle" anchor="conservatism">
        <t>Public zones are, by definition, zones that are shared by
        different groups of people.  Therefore, any decision to permit
        a code point in a public zone (including the root) 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.</t>
      </section>
    
      <section title="Inclusion Principle" anchor="inclusion">
        <t>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 a public zone should
        only permit inclusion of a code point if it is known to be
        "safe" in terms of usability and confusability within the
        context of that zone.  

<!-- DT: Agree, reworded
      <vspace blankLines="0"/><cref>JcK: "Safety" may be a
         zone-specific context.  Get far enough down in the tree and
         any label permitted by RFC 2181 may be "safe".</cref><vspace blankLines="0"/>
-->

      The default treatment of a code point should be that it
        is excluded.  

<!-- DT: I don't think such a note is needed but have no objection if
         some else feels strongly.

      <vspace blankLines="0"/><cref>JcK: Might be worth noting here
         that Inclusion is also the basis for the ICANN IDN guidelines
         for SLD names and giving a reference.</cref><vspace blankLines="0"/>
-->
      </t>
      </section>

      <section title="Simplicity Principle" anchor="simplicity">
        <t>The rules for determining whether a code point is to be
           included should be simple enough that they are readily
           understood by someone 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 such code points will therefore be rejected.</t>

        <t>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 constrained subset of Unicode characters
           (for instance, only those needed to write a single alphabetic
           language) 

<!-- DT: changed "very small" to "constrained"
      <vspace blankLines="0"/><cref>JcK: If one includes Chinese, we
         aren't talking about a "very small subset". </cref><vspace blankLines="0"/>
-->
           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.  Compare this principle with the Usability
           Principle in <xref target="usability" />.
        </t>
      </section>

      <section title="Predictability Principle" anchor="predictability">
        <t>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 will
        usually reach the same conclusion.  This is not a requirement
        for algorithmic treatment of code points; as previously noted,
        that is not possible.  It is rather to say that the consistent
        application of professional judgment is likely to yield the same
        results; combined with the principle in <xref target="conservatism"
        />, when results are not predictable the anomalous code point
        would not be permitted.</t>

        <t>Just as in <xref target="simplicity" />, this principle
        tends to cause more restriction the more diverse the community
        using the zone; it is most restrictive for the root zone.
        This is because what is predictable within a given language
        community is possibly very surprising across languages.</t>
      </section>

      <section title="Stability Principle" anchor="stability">
        <t>Once a code point is permitted, it is at least very hard to
        stop permitting that code point.  In public zones (including
        the root), 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.</t>
      </section>

    </section>

    <section title="Principle specific to the root zone"
            anchor="root"> 

      <section title="Letter Principle" anchor="letters">
        <t>In keeping with the spirit of the note in <xref
        target="RFC1123" /> that top-level labels "will be
        alphabetic", U-labels in the root zone should exclude 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.  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) General_Category Mn
        (Nonspacing_Mark) 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
        <xref target="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."

<!-- DT: hopefully addressed above
      <vspace blankLines="0"/><cref>JcK: See comments supra about {TLD,
         SLD, other public, any} and note that ICANN's guidelines and
         the historic IANA rules apply the LDH principle variation to
         public SLDs.  If one used the narrowing approach I recommend,
         you'd probably have "LDH Principle" for SLDs (at least) and
         then note that it is further narrowed into the Letter
         Principle for the root.</cref>
-->
        </t>

<!-- DT: my take is that yes the root zone excludes such things.
         But the Letter Principle isn't applicable to "all public zones".
         Of course some public zones can apply it to their zone too,
         but it's not a core principle for such zones.

      <vspace blankLines="0"/><cref>You need to be
         careful about how much you hand wave here because the letter
         Principle and even the LDH one exclude SRV records and
         similar stuff as well as, e.g., entering UTF-8 in private
         zones. </cref>
      </t>
-->
      </section>
    </section>

    <section title="Conclusion">

      <t>The principles outlined in this document can be applied when
         considering any range of Unicode code points for possible
         inclusion in a DNS zone.  It is worth observing that doing
         anything (especially in light of <xref target="stability" />)
         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.

<!-- DT: Agree.  Reworded
      <vspace blankLines="0"/><cref>JcK: Note that this is entirely
         about the root.  Needs to be rewritten.</cref><vspace blankLines="0"/> 
-->
      </t>
    </section>

    <section title="Security Considerations">
      <t>The principles outlined in this memo are intended to improve
         usability and clarity and thereby reduce 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.
<!-- DT: Agree.  Reworded.
      <vspace blankLines="0"/><cref>JcK: I don't think this is just
         about the elusive "confusion" and that "partly" above doesn't
         help.  I think they also increase usability and
         accessibility.  They also reduce the chance of confusion
         between FQDNs and IP addresses, which is, by many readings of
         the 1123 text, where the "must be alphabetic" rule came from
         (not actually true, more of a useful side effect of other
         decisions).  Can we say something like "improve usability and
         clarity and thereby somewhat reduce confusion..." or words to
         that effect?</cref><vspace blankLines="0"/>
-->
     </t>
    </section>

    <section title="IANA Considerations">
      <t>None.  RFC Editor: this section may be removed on
      publication.

<!-- DT: Agree we should ignore that here.
      <vspace blankLines="0"/><cref>JcK: NTIA _very_ clearly intends
         that IANA refuse to delegate anything from the root that does
         not conform to rules/principes like this.  I think we can
         safely ignore that and leave "IANA Considerations" out, but
         we should at least be aware of it. </cref><vspace blankLines="0"/>
-->
      </t>
    </section>

    <section title="Acknowledgements">
      <t>The authors thank the participants in the IAB
      Internationalization programme for the discussion of the ideas
      in this memo.  Marc Blanchet made specific comments.</t>
    </section>
  </middle>
  <back>
    <references title="Informative References">

<!-- BEGIN INCLUDED references file draft-sullivan-dns-zone-codepoint-pples-01alpha.xml-informative -->


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='IABCOMM1'>

<front>
<title>IAB Statement: 'The interpretation of rules in the ICANN gTLD Applicant Guidebook.'</title>
<author>
<organization>Internet Architecture Board</organization>
<address>
<email>iab@iab.org</email></address></author>
<date year='2012' month='February' /></front>

<format type='TXT' target='http://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook/' />
</reference>

<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='IABCOMM2'>

<front>
<title>Response to ICANN questions concerning 'The interpretation of rules in the ICANN gTLD Applicant Guidebook'</title>
<author>
<organization>Internet Architecture Board</organization>
<address>
<email>iab@iab.org</email></address></author>
<date year='2012' month='March' /></front>

<format type='TXT' target='http://www.iab.org/documents/correspondence-reports-documents/2012-2/iab-statement-the-interpretation-of-rules-in-the-icann-gtld-applicant-guidebook/' />
</reference>

<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC1123'>

<front>
<title>Requirements for Internet Hosts - Application and Support</title>
<author initials='R.' surname='Braden' fullname='Robert Braden'>
<organization>University of Southern California (USC), Information Sciences Institute</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292-6695</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone>
<email>Braden@ISI.EDU</email></address></author>
<date year='1989' month='October' /></front>

<seriesInfo name='STD' value='3' />
<seriesInfo name='RFC' value='1123' />
<format type='TXT' octets='245503' target='http://www.rfc-editor.org/rfc/rfc1123.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC2119'>

<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC4690'>

<front>
<title>Review and Recommendations for Internationalized Domain Names (IDNs)</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<author>
<organization>IAB</organization></author>
<date year='2006' month='September' />
<abstract>
<t>This note describes issues raised by the deployment and use of Internationalized Domain Names.  It describes problems both at the time of registration and for use of those names in the DNS.  It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF.  In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) 
standard and its supporting tables, based on experience gained since those standards were completed.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='4690' />
<format type='TXT' octets='100929' target='http://www.rfc-editor.org/rfc/rfc4690.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC5890'>

<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC5891'>

<front>
<title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is the revised protocol definition for Internationalized Domain Names (IDNs).  The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents.  This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself.  IDNA is only meant for processing domain names, not free text. [STANDARDS-TRAC
K]</t></abstract></front>

<seriesInfo name='RFC' value='5891' />
<format type='TXT' octets='38105' target='http://www.rfc-editor.org/rfc/rfc5891.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC5892'>

<front>
<title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).&lt;/t>&lt;t> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5892' />
<format type='TXT' octets='187370' target='http://www.rfc-editor.org/rfc/rfc5892.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC5893'>

<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges.  This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5893' />
<format type='TXT' octets='38870' target='http://www.rfc-editor.org/rfc/rfc5893.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC5894'>

<front>
<title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed.  During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode.  Some of these issues require tuning of the existing protocols and the tables on which they depend.  This document provides an overview of a revised system and provides explanatory material for its components.  This document is not an Internet Standards
 Track specification; it is published for informational purposes.</t></abstract></front>

<seriesInfo name='RFC' value='5894' />
<format type='TXT' octets='115174' target='http://www.rfc-editor.org/rfc/rfc5894.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC5895'>

<front>
<title>Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<date year='2010' month='September' />
<abstract>
<t>In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS).  The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the 
result of user input.  This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>

<seriesInfo name='RFC' value='5895' />
<format type='TXT' octets='16556' target='http://www.rfc-editor.org/rfc/rfc5895.txt' />
</reference>


<?xml version='1.0' encoding='UTF-8'?>

<reference anchor='RFC6365'>

<front>
<title>Terminology Used in Internationalization in the IETF</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2011' month='September' />
<abstract>
<t>This document provides a list of terms used in the IETF when discussing internationalization.  The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants.  This memo documents an Internet Best Current Practice.</t></abstract></front>

<seriesInfo name='BCP' value='166' />
<seriesInfo name='RFC' value='6365' />
<format type='TXT' octets='103155' target='http://www.rfc-editor.org/rfc/rfc6365.txt' />
</reference>

<!-- END INCLUDED references file draft-sullivan-dns-zone-codepoint-pples-01alpha.xml-informative -->
    </references>
  </back>
</rfc>
