One document matched: draft-lawrence-dispatch-sipforum-provider-alias-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc symrefs="yes" ?>

<?rfc strict="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<rfc docName="draft-lawrence-dispatch-sipforum-provider-alias-00"
     category="info"
     ipr="trust200902"
     >

  <front>
    <title abbrev="Provider Alias Number for SIP UA Config">
      Provider Alias Numbers for Session Initiation Protocol (SIP) User Agent Configuration 
    </title>

    <author initials= "S." surname="Lawrence" fullname="Scott Lawrence"
            role="editor"
            >
      <organization>Avaya, Inc.</organization>
      <address>
        <postal>
          <street>600 Technology Park</street>
          <city>Billerica</city>
          <region>MA</region> <code>01821</code>
          <country>USA</country>
        </postal>
        <phone>+1 978 288 5508</phone>
        <email>xmlscott@gmail.com</email>
      </address>
    </author>

    <author fullname="John Elwell" initials="J." surname="Elwell">
      <organization>Siemens Enterprise Communications</organization>
      <address>
        <phone>+44 1908 855608</phone>
        <email>john.elwell@siemens-enterprise.com</email>
      </address>
    </author> 

    <date month="March" day="22" year="2010" />

    <area>Real-Time Applications and Infrastructure</area>

    <workgroup>DISPATCH</workgroup>

    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>
        This document defines procedures for how a SIP User Agent can
        translate an identifier provided by a user into the SIP DNS domain
        name of a service provider.  The form of the user supplied
        identifier is constrained to values that can be entered using only
        a standard 12 key telephone keypad.
      </t>
      <t>
        This document is derived from work begun in the SIP Forum Technical
        Working Group User Agent Configuration Task Group.
      </t>
    </abstract>

  </front>

  <middle>
    <section anchor='introduction' title="Introduction">

      <t>
        Given the problem statement:

        <list style='empty'>
          <t>
            A user gets a new SIP User Agent (UA); it may be a hardware device
            or software.  Some User Agents have a user interface that can
            accept a username, password, and domain name.  Other devices, like
            Analog Telephony Adapters (ATAs), have no user interface other than
            that provided by an attached analog phone.  How does a
            non-technical user minimally configure it so that when it is
            started, something useful happens?
          </t>
        </list>
        The <xref target='draft-sipforum-user-agent-config'/> "Session
        Initiation Protocol (SIP) User Agent Configuration" specification
        provides a procedure for how a SIP User Agent locates, retrieves,
        and maintains current configuration information for a given SIP
        Service Provider.  However, it assumes that either:
        <list style='symbols'>
          <t>
            the UA to be configured is connected to a network whose DHCP
            (or DHCPv6) service provides the DNS Name of the SIP domain for
            which configuration is desired,
          </t>
        </list>
        or:
        <list style='symbols'>
          <t>
            the UA has a means by which the user can enter that SIP domain
            name. 
          </t>
        </list>

        Since some SIP UAs may have no more user interface than a standard
        12 key telephone keypad (the digits 0 through 9, '*', and '#'),
        entry of DNS names (see <xref target='RFC1034'/>), even for users
        comfortable with DNS names, is inconvenient at best.  This leaves
        the problem of configuring a UA to obtain configuration for a SIP
        service provider whose domain name is not provisioned by the local
        network.  This specification provides a means by which the UA can
        translate a value entered using only the standard telephone keypad
        into the DNS name of a SIP service provider; in the terminology of
        <xref target='draft-sipforum-user-agent-config'/>, the
        "Configuration Service Domain Name".
      </t>

    </section>

    <section anchor='terminology' title="Terminology">
      <t>
        The following terms are used in this document:

        <list style='hanging'>
          <t hangText='User Agent, UA'/>
          <t>
            As defined in <xref target='RFC3261'/>. Note that this includes
            any implementation of a User Agent. A SIP phone is a User
            Agent, but the term also encompasses any other entity that uses
            SIP (for example: for a text chat, for sharing a whiteboard or
            for fax).  
          </t>

          <t hangText='SIP Service Provider, Service Provider'/>
          <t>
            An entity that provides services to User Agents using the SIP protocol.  This
            specification requires that a Service Provider make configuration data and
            certain other information available in order to configure User Agents.
          </t>

          <t hangText='Configuration'/>
          <t>
            The set of information that establishes operational
            parameters for a particular User Agent. 
          </t>

          <t hangText='Configuration Service, CS'/>
          <t>
            The source of Configuration for User Agents.
          </t>

          <t anchor='config.service.domain' hangText='Configuration Service Domain'/>
          <t>
            The DNS name for the service from which a Configuration is requested.
          </t>

          <t anchor='provider.alias.number' 
             hangText='Provider Alias Number, PAN'/>
          <t>
            A string consisting of decimal digits used to identify a domain from which
            configuration is to be requested.
          </t>

        </list>

      </t>

      <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 <xref target= "RFC2119"/>.
      </t>

    </section>

    <section anchor='domain.discovery.numalias' title="Numeric Domain Alias Entry">
      <t>
        A UA MAY have an interface by which a string consisting only of
        decimal digits, called a Provider Alias Number (PAN), is provided
        by the user.  The PAN value is resolved to the Configuration
        Service Domain using the S-NAPTR (Simple NAPTR) DDDS application
        <xref target='RFC3958'/>.
      </t>

      <t>
        The lookup key for the S-NAPTR request is the Provider Alias Number
        concatenated with a fixed root suffix (for the purposes of this initial
        draft, the value ".pan.sipforum.org." is used) to form a DNS domain
        name.  The UA MUST make a DNS request for NAPTR records for that
        domain name.  From the returned records (see next paragraph), the
        UA MUST select the record whose Service field value is "SFUA.PAN";
        the Configuration Service Domain Name is the value found in the
        Replacement field of this record.
      </t>

      <t>
        The DNS for the fixed root MUST be configured such that at most one
        NAPTR record is returned for any given Provider Alias Number, and
        MUST be configured to return the Flag field set to "a", an empty
        Regular Expression field, and the Substitution value set to the
        Configuration Service Domain Name.
      </t>

      <section anchor='domain.discovery.numalias.example' title="Provider Alias Number Resolution Example">

        <t>
          Through some manual process, the UA has obtained the provider alias number
          "555".  To obtain the Configuration Service Domain Name, the UA constructs a DNS
          NAPTR request by appending the domain suffix ".pan.sipforum.org." to form the
          query key "555.pan.sipforum.org.", which returns the DNS record:

          <figure anchor='example.pan.naptr' title="PAN NAPTR Query Result">
            <artwork align="left">
              <![CDATA[
                       NAPTR  10 10 "a" "SFUA.PAN" "" "example.net."
              ]]>
            </artwork>
          </figure>

          The record with the service-field "SFUA.PAN" provides the DNS
          name "example.net." for the Configuration Service Domain Name.
        </t> 

      </section> <!-- domain.discovery.numalias.example -->

    </section> <!-- domain.discovery.numalias -->

    <section title='IANA Considerations'>
      <t>
        This document registers the following S-NAPTR application service
        tag in the registry defined by <xref target='RFC3958'/>
        "Domain-Based Application Service Location Using SRV RRs and the
        Dynamic Delegation Discovery Service (DDDS)":
      </t>

      <texttable>
        <ttcol align='left'/><ttcol align='left'/>
        <c>Application Service Tag</c><c>SFUA.PAN</c>
      </texttable>

    </section>

    <section title='Security Considerations'>
    <t>
      Because the mapping of the user-entered PAN value to Configuration Service Domain
      Name relies on a potentially unsecured DNS lookup, the UA SHOULD take steps to
      ensure that the correct provider has been found.
    </t>
    <t>
      If possible, the resulting Configuration Service Domain Name SHOULD be confirmed by
      the human user.
    </t>
    <t>
      Following the translation (specified in <xref
      target='draft-sipforum-user-agent-config'/>) of the Configuration Service Domain
      Name to the configuration request URL, the UA makes an https request for
      configuration data.  Because this request is https, it is made over TLS.  As the TLS
      server, the CS always provides a server certificate during the TLS handshake; if
      possible, the UA should validate that certificate and confirm that it contains the
      DNS name constructed from the PAN by concatenating the fixed root
      ("555.pan.sipforum.org" in the example in <xref
      target='domain.discovery.numalias.example'/>).  While it may not be possible to have
      the information needed to perform a full validation of the CS server certificate
      prior to the first configuration (for example, the UA may not have a current CA
      certificate for the CA that signs the CS server certificate), implementors are
      advised to provide for including that information in configuration data so that it
      can be used for subsequent reconfigurations; this narrows the window of
      vulnerability to the first configuration attempt.
    </t>

    </section>

  </middle>

  <back>
    <references title="Normative References">

      <reference anchor='RFC1034'>
        <front>
          <title abbrev='Domain Concepts and Facilities'>Domain names - concepts and facilities</title>
          <author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
          <organization>Information Sciences Institute (ISI)</organization></author>
        <date year='1987' day='1' month='November' /></front>

        <seriesInfo name='STD' value='13' />
        <seriesInfo name='RFC' value='1034' />
        <format type='TXT' octets='129180' target='ftp://ftp.isi.edu/in-notes/rfc1034.txt' />
      </reference>

      <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='ftp://ftp.isi.edu/in-notes/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>

      <reference anchor='RFC3261'>
        <front>
          <title>SIP: Session Initiation Protocol</title>
          <author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
          <organization /></author>
          <author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
          <organization /></author>
          <author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
          <organization /></author>
          <author initials='A.' surname='Johnston' fullname='A. Johnston'>
          <organization /></author>
          <author initials='J.' surname='Peterson' fullname='J. Peterson'>
          <organization /></author>
          <author initials='R.' surname='Sparks' fullname='R. Sparks'>
          <organization /></author>
          <author initials='M.' surname='Handley' fullname='M. Handley'>
          <organization /></author>
          <author initials='E.' surname='Schooler' fullname='E. Schooler'>
          <organization /></author>
          <date year='2002' month='June' />
          <abstract>
            <t>
              This document describes Session Initiation Protocol (SIP), an
              application-layer control (signaling) protocol for creating,
              modifying, and terminating sessions with one or more participants.
              These sessions include Internet telephone calls, multimedia
              distribution, and multimedia conferences. [STANDARDS
              TRACK]
            </t>
          </abstract>
        </front> 

        <seriesInfo name='RFC' value='3261' />
        <format type='TXT' octets='647976' target='ftp://ftp.rfc-editor.org/in-notes/rfc3261.txt' />
      </reference>

      <reference anchor='RFC3958'>
        <front>
          <title>Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)</title>
          <author initials='L.' surname='Daigle' fullname='L. Daigle'>
          <organization /></author>
          <author initials='A.' surname='Newton' fullname='A. Newton'>
          <organization /></author>
          <date year='2005' month='January' />
          <abstract>
            <t>
              This memo defines a generalized mechanism for application
              service naming that allows service location without relying on
              rigid domain naming conventions (so-called name hacks).  The
              proposal defines a Dynamic Delegation Discovery System (DDDS)
              Application to map domain name, application service name, and
              application protocol dynamically to target server and
              port. [STANDARDS TRACK]
            </t>
          </abstract>
        </front> 
        <seriesInfo name='RFC' value='3958' />
        <format type='TXT' octets='54568' target='ftp://ftp.rfc-editor.org/in-notes/rfc3958.txt' />
      </reference>


      <reference anchor="draft-sipforum-user-agent-config">
        <front>
          <title abbrev="SIP UA Configuration">
            Session Initiation Protocol User Agent Configuration
          </title>

          <author initials= "S." surname="Lawrence" fullname="Scott Lawrence"
                  role="editor"
                  >
            <organization>Avaya, Inc.</organization>
            <address>
              <postal>
                <street>600 Technology Park</street>
                <city>Billerica</city>
                <region>MA</region> <code>01821</code>
                <country>USA</country>
              </postal>
              <phone>+1 978 288 5508</phone>
              <email>xmlscott@gmail.com</email>
            </address>
          </author>
          <author fullname="John Elwell" initials="J." surname="Elwell">
            <organization>Siemens Enterprise Communications</organization>
            <address>
              <phone>+44 1908 855608</phone>
              <email>john.elwell@siemens-enterprise.com</email>
            </address>
          </author> 
          <date month="March" day="22" year="2010" />
          <area>Real-Time Applications and Infrastructure</area>
        </front>
        <format type='HTML' target='http://tools.ietf.org/html/draft-sipforum-user-agent-config'/>
      </reference>
    </references>
  </back>
</rfc>