One document matched: draft-jennings-dispatch-npa-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="no" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="info" docName="draft-jennings-dispatch-npa-00" ipr="trust200902">
  <front>
    <title abbrev="Numeric Provider Alias">Numeric Provider Alias
    (NPA)</title>

    <author fullname="Cullen Jennings" initials="C." surname="Jennings">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>170 West Tasman Drive</street>

          <city>San Jose</city>

          <region>CA</region>

          <code>95134</code>

          <country>USA</country>
        </postal>

        <phone>+1 408 421-9990</phone>

        <email>fluffy@cisco.com</email>
      </address>
    </author>

    <date day="4" month="July" year="2010" />

    <area>APPS</area>

    <abstract>
      <t>
        This draft proposes a modification to
        draft-lawrence-dispatch-sipforum-provider-alias (PAN). The PAN draft
        proposes a mechanism for a phone to take a short numeric identifier that
        identifies a phone service provider and look it up in DNS to find the
        address of the configuration server for that service provider. </t>
      <t>
        The problem with PAN is that it requires a specific organization,
        sipforum.org, to become a registrar for the PAN. This will add
        signifiant cost to obtaining them as the expected quantity of PAN is
        low. This draft proposes a minor modification to the PAN draft. Instead
        of using the sipforum as a new registrar, why not just use the
        registrars that already exist for DNS names. This ensure a long term
        stable unique allocation of PAN with the advantages of not having the
        IETF allocating a monopoly to one particular organization. </t>

    </abstract>
  </front>

  <middle>
    <section title="Proposal">

      <t>
        Currently section 3.1 of the PAN draft proposes to construct a domain
        name from PAN by taking the PAN and prepending it to the string
        ".pan.sipforum.org". So a PAN of 555 would result in a NAPTR lookup of
        the "555.pan.sipforum.org". In the following sections, some alternative
        proposal are made.
      </t>

      <section title=" Simple Single TLD">
        <t>
        The domain is formed by prepending "pan" and appending ".org" to the PAN
        so the PAN of 555 would result in a domain of "pan555.org". Organization
        get a PAN by just getting the domain name in the normal manner.
        </t>

      </section>
      <section title="Multiple TLD">
        <t>
          The domain is formed by  prepending "pan" and appending a TLD
          based on the first digit of PAN where if the first digit is 1, then "
          .com" is used and if the digit is 2, then ".net" and so on. So the PAN
          of 2555 would result in a domain name of "pan2555.net".
        </t>
      </section>
      <section title=" Encoded URI">
        <t> 
          The domain is formed by treating each pair of numeric digits as base
          10 encoded version of the upper case character in the domain
          string. So a domain iii.ca would be converted to upper case III.CA
          which is ascii characters 73 73 73 46 67 65 so the PAN would be
          737373466765.
        </t>
      </section>
      <section title="Compressed encoded URI">
        <t>
          A small table of of common occurring sequences of characters in domain
          names is created and used as a dictionary for a simple way to
          compress any URI into a decimal string.
        </t>

      </section>
    </section>

    <section title="Discussion">
      <t> 
        The above proposal represent a range of complexity and generality. Some
        will result in larger PAN numbers than others and some result in more or
        less code. Some can only using a single TLD (Top Level Domain) while
        others could work with many or all TLDs.
        </t>
        <t>
          User clearly have no problem with 10 to 15 digit long phone numbers so
          it's hard to see a 15 digit PAN being a problem for a user to
          enter. All of these have significant advantages over allocating
          sipforum.org as the root of the registration. The processes for
          ensuring uniqueness of normal DNS names are well understood as well as
          managing changes in ownership, resolution of disputes, and so
          on. Replicating all this work inside of the a new organization is
          expensive. Some casual and likely uninformed estimates have put it in
          the range multiple hundreds of thousands of dollars to run over a a
          few year time scale. There is unlikely to be more than 1000 domains
          using PANs if they are expensive.
      </t>
      <t> 
        It would be nice to have a single digit checksum on the PAN. This can
        significantly improve the user experience when an entry error is made.
      </t>
      <t>
        Making a minimum allowable length for PAN will help reduce land grabs of
        very short PANs.
      </t>
      <t>
        A generalized numeric encoding for URI will likely have widespread uses
        as devices with very limited user interfaces become more common. For
        example, some digital clocks today make the user set the time using a
        single button. It's not fun but it's possible. Devices like the Apple
        iTV have a nice user interface for entering a multi digit number using a
        remote with just 6 buttons.
      </t>

    </section>
  </middle>

  <back>
    <!--
        <references title="Normative References">
        </references>
    -->
  </back>
</rfc>