<?xml version="1.0" encoding="us-ascii"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
]>

<?rfc compact="yes" ?>

<rfc category="std" docName="draft-yoneya-dns-variant-label-rr-01" ipr="trust200902">
  <front>
    <title abbrev="VL RR">Variant Label Resource Record</title>

    <author fullname="Yoshiro Yoneya" initials="Y" surname="Yoneya">
      <organization>JPRS</organization>
      <address>
        <postal>
          <street>Chiyoda First Bldg. East 13F</street>
          <street>3-8-1 Nishi-Kanda</street>
          <city>Chiyoda-ku</city>
          <region>Tokyo</region>
          <code>101-0065</code>
          <country>Japan</country>
        </postal>
        <phone>+81 3 5215 8451</phone>
        <email>yoshiro.yoneya@jprs.co.jp</email>
      </address>
    </author>

    <date day="25" month="February" year="2013"/>

    <abstract>
      <t>
        Definition and operation of variant domain names are differ
        from zone administrators, and there is no generic rules,
        therefore, in general, it is hard to guess variant labels for
        end users and / or applications.  Meanwhile, zone
        administrators are understanding all variant labels list
        because they generate variant labels and activate them
        according to rules they defined.  Thus, if there is a
        mechanism that end users and / or applications can obtain
        variant labels list from zone administrators, then it would be
        useful.  The Variant Labels Resource Record (VL RR) provides
        such variant labels list for that purpose.
      </t>
    </abstract>

  </front>

  <middle>
    <section title="Introduction">
      <t>
        Some of the zone administrators such as TLD registries that
        accepting IDNs are bundling variants as a package.  Also, in
        conjunction with the deployment of IDN TLDs, consideration of
        Variant IDN TLD is in progress.  It is hard to guess variant
        labels list from short string that does not have context like
        domain name, because definition of variants are differ from
        languages even though using the same script.  The zone
        administrators such as registries have complete list of
        variant labels for a label, so if they have mechanism to
        provide the list, end users and / or applications can obtain
        variant labels list without guessing.  The Variant Labels
        Resource Record (VL RR) is a new DNS RR that provides variant
        labels for a label.
      </t>
    </section>

    <section title="Definition of VL RR">
      <t>
        VL RR format is as follows:
      </t>
      <figure><artwork><![CDATA[
variant1 TTL IN VL priority1 variant1.
                   priority2 variant2.
                   priority3 variant3.
      ]]></artwork></figure>
      <t>
        Here, the variant1 is a left most label in a query name, the
        variant1, variant2 and the variant3 are the list of activated 
        (delegated) variant labels for the variant1.  Variant label
        which is not activated must not be listed.  The values of 
        right hand side can be listed multiple times as RRset like other
        RRs.  Period at the end can't be omitted.  If the variant label
        is IDN, then it must be written in A-label <xref target="RFC5890"/>.  
        The priority1, priority2 and priority3 are the integer numbers
        which indicate priorities for the variant1, variant2 and
        variant3 respectively.  The smallest number means that the
        variant label is the canonical label.
      </t>
      <t>
        All variant labels must be defined inside of one zone, and
        they can't refer labels outside of the zone.  See <xref
        target="examples"/> for examples.
      </t>
      <t>
        The VL RR can't set to the zone apex in child zone.  This means
        that VL RR for zone apex must be set in parent zone.
      </t>
    </section>

    <section title="Behaviour of full resolvers">
      <t>
        The full resolvers send VL RR query to the authoritative DNS
        server(s) for the FQDN which is generated from the query name
        omitting left most label (parent zone authoritative DNS
        server(s)) and get response.  The full resolvers may cache the
        response during the TTL time.
      </t>
    </section>

    <section title="Behaviour of authoritative DNS servers">
      <t>
        The authoritative DNS servers must ignore VL RR which is set
        to the zone apex in child zone.  The authoritative DNS servers 
        respond NXDOMAIN for queries to non-existent label.  The 
        authoritative DNS servers respond VL RRset for queries to 
        existing label if it has VL RRs, or respond NOERROR for queries 
        to existing label if it does not have VL RRs.
      </t>
      <t>
        The full resolvers which is not VL RR capable can't send
        queries to the parent zone's authoritative DNS server(s),
        therefore, it can't obtain VL RR for the zone apex actively.
        Thus, parent zone's authoritative DNS server(s) should respond
        VL RRset in additional section when it respond NS RRset.
      </t>
    </section>

    <section title="Behaviour of applications">
      <t>
        The applications treat a label with most small number priority
        as a canonical label from list of variant labels obtained by
        the query.  Other labels may be displayed to the users as list
        of variant labels.
      </t>
    </section>

    <section title="Issues of VL RR">
      <t>
        The VL RR increases volume of large zone such as TLD
        registries have.  This will impact zone generation and / or
        zone transfer time.
      </t>
      <t>
        Deployment of VL RR capable applications will increases queries
        to Root zone or TLD zones.  This will impact Root / TLD
        authoritative servers in performance and / or bandwidth.
      </t>
      <t>
        The zone administrators who will introduce VL RR are
        recommended to have enough assessment previously with
        recognition above.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
        IANA is required to assign VL RR type and number.
      </t>
    </section>

    <section title="Security Considerations">
      <t>
        Because the VL RR can set many variant labels, it can be 
        a source of DNS amplifier attack.  The zone administrators 
        can avoid this issue by suppressing number of activating 
        variant labels appropriately.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative references">
      &rfc5890;
    </references>

    <section title="Examples" anchor="examples">
      <t>
        A word "International Academy" in Simplified Chinese consists
        from 4 Hanji characters and each character has a few variants. 
        Following codepoint (U+XXXX means Unicode codepoint XXXX) list 
        shows canonical Simplified Chinese Hanji character and its
        variants.
      </t>
      <t><list style="hanging">
        <t hangText="U+56FD"/>
          <t>U+570B U+56EF U+5700</t>
        <t hangText="U+9645"/>
          <t>U+969B</t>
        <t hangText="U+5B66"/>
          <t>U+5B78 U+6588</t>
        <t hangText="U+4F1A"/>
          <t>U+6703</t>
      </list></t>
      <t>
        In this example, the word "International Academy" produces 48
        variant labels, but mixture of Simplified and Traditional
        Hanji in a label is unrealistic, so the zone administrator 
        will reduce activated variant labels into two (all Simplified 
        and all Traditional).
      </t>
      <t>
        Thus, VL RR definition for this example becomes as follows:
      </t>
      <figure><artwork><![CDATA[
xn--6oq05q1ydn21f  IN VL  0  xn--6oq05q1ydn21f.
                   IN VL 10  xn--9csw6hk7lo31c.
xn--9csw6hk7lo31c  IN VL  0  xn--6oq05q1ydn21f.
                   IN VL 10  xn--9csw6hk7lo31c.
      ]]></artwork></figure>
      <t>
        Note that no other (not activated) variant labels appear in
        the zone.
      </t>
    </section>

    <section title="Change Log" anchor="changes">
      <section title="Changes since -00">
        <t>
          <list style="symbols">
            <t>
              Some editorial collections.
            </t>
            <t>
	      Explicitly described that VL RR must be set to activated
	      labels.
            </t>
            <t>
              Add Appendix A for examples.
            </t>
          </list>
        </t>
      </section>
    </section>

  </back>
</rfc>
