ENUM Working Group                                                J. Yu
   Internet Draft                                                  NeuStar
   Document: draft-ietf-enum-enumservice-sms-smpp-01.txt          May 2008
   Category: Standards Track
   
   
                      IANA Registrations of Enumservice
                       "sms:smpp" and URI Scheme "smpp"
                 draft-ietf-enum-enumservice-sms-smpp-01.txt
   
   Status of this Memo
   
      By submitting this Internet-Draft, each author represents that any
      applicable patent or other IPR claims of which he or she is aware
      have been or will be disclosed, and any of which he or she becomes
      aware will be disclosed, in accordance with Section 6 of BCP 79.
   
      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.
   
      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."
   
      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt.
   
      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.
   
      This Internet-Draft will expire on November 7, 2008.
   
      Copyright Notice
   
         Copyright (C) The IETF Trust (2008).
   
   
   Abstract
   
      This document updates RFC 4355 by registering a new enumservice
      subtype "smpp" under the existing type "sms" using the URI scheme
      "smpp" as per the IANA registration process defined in RFC 3761 and
      draft-ietf-enum-enumservices-guide-07 and registers a new URI scheme
      "smpp" according to the URI registration procedure in RFC 4395.
   
      This enumservice subtype indicates that the remote resource
      identified by the URI can receive short messages using the Short
      Message Peer-to-Peer Protocol (SMPP).
   
   
   
   
                  Standards Track - Expires November 7, 2008            1
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
   Table of Contents
   
      1.   Conventions Used in this Document  . . . . . . . . . . . .  2
      2.   Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  2
      3.   Introduction . . . . . . . . . . . . . . . . . . . . . . .  3
      4.   Formal Syntax  . . . . . . . . . . . . . . . . . . . . . .  4
      5.   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  4
      6.   Example  . . . . . . . . . . . . . . . . . . . . . . . . .  6
      7.   Security Considerations  . . . . . . . . . . . . . . . . .  7
      8.   IANA Considerations  . . . . . . . . . . . . . . . . . . .  7
      8.1  IANA Registration for Enumservice "sms:smpp" . . . . . . .  7
      8.2  IANA Registration for URI Scheme "smpp"  . . . . . . . . .  8
      9.   References . . . . . . . . . . . . . . . . . . . . . . . . 10
      9.1  Normative References . . . . . . . . . . . . . . . . . . . 10
      9.2  Informative References . . . . . . . . . . . . . . . . . . 10
   
   
   1. Conventions Used in this Document
   
      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 BCP 14, RFC 2119 [1].
   
   
   2. Abbreviations
   
      3GPP      3rd Generation Partnership Project
      BNF       Backus-Naur Form
      DNS       Domain Name System
      GPRS      General Packet Radio Service
      GSM       Global System for Mobile communications
      GW        Gateway
      HLR       Home Location Register
      ID        Identifier; Identity
      IM        Immediate Messaging; Instant Messaging
      ITU-T     International Telecommunication Union-Telecommunication
      MNP       Mobile Number Portability
      MSC       Mobile-services Switching Center
      NAPTR     Naming Authority Pointer
      RR        Resource Record
      SC        Service Center
      SGSN      Serving GPRS Support Node
      SMPP      Short Message Peer-to-Peer Protocol
      SMS       Short Message Service
      SMS-GMSC  Gateway MSC for SMS
      SMS-IWMSC Interworking MSC for SMS
      SMSC      Short Message Service Center
      SRV       Service
      SS7       Signaling System Number 7
      URI       Uniform Resource Identifier
      VPN       Virtual Private Network
   
   
                  Standards Track - Expires November 7, 2008            2
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
   3. Introduction
   
      ENUM (E.164 Number Mapping) [2] is a system that transforms
      E.164 [10] telephone numbers into domain names and then uses
      the Domain Name System (DNS) [11] and Naming Authority Pointer
      (NAPTR) [3] resource records (RRs) to query for the services
      or resources that are available for a specific domain name.
   
      This document updates RFC 4355 [4] by registering a new enumservice
      subtype "smpp" under the existing type "sms" using the URI scheme
      "smpp" as per the IANA registration process defined in RFC 3761 [2]
      and draft-ietf-enum-enumservices-guide-07 [12] and registers a new
      URI scheme "smpp" according to the URI registration procedure in RFC
      4395 [5].
   
      This enumservice subtype indicates that the remote resource
      identified by the URI can receive short messages using the Short
      Message Peer-to-Peer Protocol (SMPP) [13].
   
      The purpose of the registered enumservice subtype and URI
      scheme is to enable service providers to exchange the short
      message traffic over IP using the widely supported SMPP.
   
      SMPP sessions can be established over TCP/IP or X.25 [14]
      connections.  This document discusses only the TCP/IP case.
      Several radio access technologies are used by the mobile networks
      worldwide, the way the Global system for Mobile Communications
      (GSM) systems handle the short message delivery [15,16] is used in
      this document to simplify the discussions.
   
      For a mobile-originated short message, the Mobile-services
      Switching Center (MSC) or Serving GPRS Support Node (SGSN) that
      serves the sender submits the short message to the Service Center
      (SC) in the sender's home network via the Interworking MSC for
      Short Message Service (SMS-IWMSC).  A successful short message
      delivery to a mobile user involves the SC and Gateway MSC for Short
      Message Service (SMS-GMSC) in the sender's home network that
      queries the Home Location Register (HLR) in the receiver's home
      network via Signaling System Number 7 (SS7) to retrieve information
      about the MSC and/or SGSN that currently serve(s) the receiver
      followed by the short message delivery to the MSC or SGSN via SS7.
      This document uses the Short Message Service Center (SMSC) to avoid
      mentioning the SMS-GMSC, SMS-IWMSC and SC to simplify the
      discussions.
   
   
   
   
   
                  Standards Track - Expires November 7, 2008            3
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
   4. Formal Syntax
   
      RFC 4355 [4] allows subtypes be defined under the type "sms".  This
      document proposes a new subtype "smpp" so the enumservice is
      "sms:smpp".
   
      The syntax specification using the augmented Backus-Naur Form (BNF)
      as described in RFC 5234 [6] for the "smpp" URI can be found in
      Section 8.2.
   
   
   5. Use Cases
   
      There are at least five use cases where some network entities in
      the mobile networks that deal with short message submission or
      delivery may want to retrieve the "smpp" URI via ENUM queries so as
      to deliver the short messages via SMPP/IP instead of SS7.
   
      a. An SMS hub provider that receives a short message from the
        originating network can send an ENUM query to retrieve the
        "smpp" URI for the destination mobile telephone number.   If the
        destination mobile telephone number is served by a mobile
        operator (identified by the information in the host part of the
        URI) that uses this SMS hub provider's service, the SMS hub
        provider can use the information in the "smpp" URI to terminate
        the short message via SMPP/IP.   If the destination mobile
        telephone number is served by a mobile operator that does not
        use this SMS hub provider's service, the SMS hub provider simply
        forwards the short message to the SMS hub provider that can
        reach the destination mobile operator.
   
      b. The SMSC in the sender's home network that receives a short
        message from the sender can send an ENUM query to see if the
        home operator that serves the destination mobile telephone
        number has an SMS Gateway (GW) (e.g., SMS Router [17] or IP-SM-
        GW in [18,19,20]) that can receive all the mobile-terminated
        short messages via SMPP/IP.  If the "smpp" URI is found and SMPP
        sessions with the remote resource are allowed, the short message
        is delivered to the SMS Gateway via SMPP/IP.  Otherwise, the
        SMSC handles the short message as is done today except that it
        may send the ENUM query as is described in case #c after it
        receives the positive response from the HLR.
   
      c. The SMSC in the sender's home network that has queried the HLR
        associated with the destination mobile telephone number and
        received the E.164 number associated with the MSC and/or SGSN
        that currently serve(s) the destination mobile telephone number
        can send an ENUM query to see if the MSC or SGSN can receive the
   
                  Standards Track - Expires November 7, 2008            4
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
        short messages via SMPP/IP.  If the "smpp" URI is found and SMPP
        sessions with the remote resource are allowed, the short message
        is delivered via SMPP/IP.  Otherwise, the short message is
        delivered via SS7.
   
      d. The SMS GW mentioned in case #b above that receives an incoming
        short message via SS7 or IP and wants to send the short message
        to the MSC or SGSN that currently serves the destination mobile
        telephone number can send an ENUM query to see if that MSC or
        SGSN can receive the short messages via SMPP/IP.  If the "smpp"
        URI is found and SMPP sessions with the remote resource are
        allowed, the short message is delivered via SMPP/IP.  Otherwise,
        the short message is delivered via SS7.  Certainly, the SMS GW
        can deliver the message via IP if the terminating device
        supports the capabilities specified in [18,19,20].
   
      e. The MSC or SGSN serving the sender can use the E.164 number
        associated with the sender's home SMSC to send an ENUM query to
        see if that SMSC can receive short messages via SMPP/IP.  If the
        "smpp" URI is found and SMPP sessions with the remote resource
        are allowed, the short message is delivered via SMPP/IP.
        Otherwise, the short message is delivered via SS7.
   
      ENUM queries may not be needed for countries that do not support
      mobile number portability (MNP) because the prefix of the
      destination mobile telephone number or the E.164 numbers associated
      with the MSC, SGSN and SMSC and locally provisioned data together
      may be sufficient to identify the remote entity/resource and
      whether the remote entity/resource supports SMPP/IP.  When the
      destination mobile telephone number is subject to MNP and ENUM
      provides MNP-corrected responses, the querier can use an ENUM query
      to see if the response contains the "smpp" URI.
   
      For the five cases above, case #a is the most likely case to happen
      because the SMS hub providers currently use SMPP to communicate
      with the originating SMSC, with each other, and/or with the
      destination SMS GW.  But they currently use local or remote
      databases and/or other operator-specific information to identify
      the destination operator and the destination SMS GW.
   
      More and more operators may deploy SMS GWs to receive all incoming
      mobile-terminated short messages for reasons stated in [17] or for
      delivering the messages over IP [18,19,20].  When that happens,
      more SMSCs may send ENUM queries to see if they can retrieve the
      "smpp" URI in the ENUM responses so as to deliver the short
      messages via SMPP/IP without querying the HLR and delivering the
   
   
                  Standards Track - Expires November 7, 2008            5
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
      short messages via SS7.  [18,19,20] discuss and specify how short
      messages can be delivered to the terminating devices over IP when
      the terminating devices support SMS over IP or Immediate Messaging
      (IM) after the SMS GW (e.g., IP-SM-GW) receives the short messages
      from the SMSCs over SS7.  Since the SMSCs are more likely to
      support SMPP rather than Session Initiation Protocol (SIP) [7], the
      SMS GW can advertise its ability to receive short messages over
      SMPP/IP via ENUM.  Using SIP to receive the short messages from the
      SMSCs at the SMS GW that can deliver the messages to the
      terminating devices via SIP is outside the scope of this document.
   
      Cases #c, #d and #e may happen when many MSCs and SGSNs support
      SMPP/IP.
   
      An SMPP message is acknowledged immediately when received;
      therefore, the SMPP mechanism that requests for notification on
      actual message delivery should be used so as not to impact the
      message delivery status reporting mechanism that is available when
      the short message is delivered via SS7.
   
   
   6. Example
   
      $ORIGIN 4.3.2.1.4.3.4.1.7.5.1.example.net.
          NAPTR 10 100 "u" "E2U+sms:smpp"
               "!^.*!smpp:smsgw.mnoX.example.com!" .
   
      In this example, an "smpp" URI is returned in the ENUM response.
      The querying node, if supporting SMPP and having established
      business relationship and prior exchange of security information
      (e.g., system ID and password for SMPP session setup) with the
      remote domain for sending the short messages via SMPP, can first
      query to see if any Service (SRV) RR [21] can be retrieved via DNS
      for
   
          _smpp._tcp.smsgw.mnoX.example.com.
   
      The querying node selects an SRV RR based on [21] if more than one
      SRV RRs are retrieved and uses the host name in the "Target" field
      of the SRV RR to retrieve the IP address via DNS.  If no SRV RR can
      be found, it retrieves the IP address of "smsgw.mnoX.example.com"
      via DNS.  It then establishes the SMPP session over TCP/IP, if not
      yet established, and sends the short message via SMPP to that IP
      address.  If an SRV RR is retrieved and selected, the port number in
      the SRV RR is used for the TCP connection.  Otherwise, the default
      port number of 2775 is used.
   
   
   
   
   
                  Standards Track - Expires November 7, 2008            6
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
   7. Security Considerations
   
      Please see the discussions on security considerations for the
      registrations of Enumservice "sms:smpp" and URI scheme "smpp" in
      Sections 8.1 and 8.2 respectively.
   
   
   8. IANA Considerations
   
      This document registers the "smpp" Enumservice using the subtype
      "smpp" under the existing type "sms" in the Enumservice registry
      described in the IANA considerations in RFC 3761 [2] and draft-ietf-
      enum-enumservices-guide-07 [12].   This document also registers with
      the IANA the "smpp" URI scheme per RFC 4395 [5].  Details of the two
      registrations can be found in Sections 8.1 and 8.2 below.
   
   
   8.1. IANA Registration for Enumservice "sms:smpp"
   
      Enumservice Name: smpp
   
      Enumservice Class: Common Application
   
      Enumservice Type: sms
   
      Enumservice subtype: smpp
   
      URI scheme: smpp
   
      Functional Specification: This Enumservice indicates that the
        resource identified by the associated URI is capable of receiving
        short messages using the SMPP protocol [13].
   
      Security Considerations: Use of the "sms:smpp" Enumservice shall
        either be within a service provider's internal network, or on a
        private basis between one or more parties.  It is assumed that
        this Enumservice is used in an environment where entities are
        trusted and general public or attackers are not supposed to have
        access to the DNS RRs containing the "smpp" URI.
   
        The initial purpose of this Enumservice and the "smpp" URI is to
        indicate that the remote resource can receive short messages using
        SMPP.  It is recommended that only the <hostport> appears in the
        URI.  If the <userinfo> is present, it is recommended that it
        contains the international telephone number with the leading "+"
        so as not to convey user-specific information in the "smpp" URI.
   
      Intended Usage: COMMON
   
      Registration Document: This document contains all the information
        needed for the registration of this enumservice subtype.
   
                  Standards Track - Expires November 7, 2008            7
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
   
      Author: James Yu (see Author's Address Section for author contact
        detail)
   
      Further Information: See Section 5 of this document.
   
   
   8.2. IANA Registration for URI Scheme "smpp"
   
      URI scheme name: smpp
   
      Status: Permanent
   
        SMPP is used by network entities operated by the
        carriers/operators, inter-carrier vendors and service providers.
        Use of this URI should be either be within a service provider's or
        carrier's/operator's internal network, or on a private basis
        between one or more parties using a variety of security mechanisms
        to prevent general public access.   The DNS RRs that contain this
        URI and are to be returned in ENUM responses should not be part of
        the e164.arpa zone or any other portion of the Internet DNS tree.
   
      URI scheme syntax:
   
        smpp-uri       = "smpp:" [userinfo "@"] hostport
                           *(";" uri-param) [headers]
        userinfo       = user / telephone-subscriber
        uri-param      = user-param / other-param
        user-param     = "user=" ( "phone" / other-user )
   
        <hostport>, <headers>, <user>, <other-param> and <other-user> are
        imported from RFC 3261 [7].  <telephone-subscriber> is imported
        from RFC 3966 [8].
   
      URI scheme semantics: "user=phone" must be present when <telephone-
        subscriber> appears in the <userinfo> of the URI.  The default TCP
        port number for SMPP is 2775.  If a port number appears in the
        <hostport>, that port number should be used.
   
        The initial purpose of an "smpp" URI is to return the host
        information in the "smpp" URI in an ENUM response to identify the
        remote resource that can receive short messages via SMPP/IP.
        This URI is not intended to be used in other protocols (e.g., SIP
        Request-URI) for addressing and routing purposes, at least for the
        purpose of this document.  The URI scheme syntax provides an
        extension mechanism to add parameters and header fields in the
        future for other uses of this URI.
   
      Encoding considerations: US-ASCII characters are included in the URI
        without any conversion.   Non-US-ASCII characters MUST be percent-
        encoded as described in Section 2.1 of RFC 3986 [9].
   
   
   
                  Standards Track - Expires November 7, 2008            8
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
      Intended usage: An "smpp" URI identifies a remote resource that can
        receive short messages using the SMPP protocol.  The <hostport> of
        the URI can be used to locate the IP address of that remote
        resource.  Please see Section 6 of this document for an example on
        how the host name in the <hostport> of the URI is used to locate
        the IP address.
   
      Applications/protocols that use this URL scheme name: The "smpp" URI
        is intended to be used by entities that communicate with each
        other using the SMPP protocol.  An entity that has a short message
        to deliver and wants to find out if the remote entity that deals
        with the destination telephone number or associated with a
        telephone number can be reached via SMPP/IP, can make an ENUM
        query to see if such a URI is returned in the ENUM response.
   
      Interoperability considerations:  The URI is designed to be used
        specifically for nodes in trusted systems that query private ENUM
        implementations (e.g., Carrier ENUM).
   
      Security considerations: The initial use of the "smpp" URI is for
        Enumservice "sms:smpp" where the <"hostport> in the "smpp" URI
        identifies the remote resource that can receive short messages
        over SMPP/IP.  It is recommended that only the <hostport> appears
        in the URI.  If the <userinfo> is present, it is recommended that
        it contains the international telephone number with the leading
        "+" so as not to convey user-specific information in the "smpp"
        URI.
   
        Frame Relay and Virtual Private Network (VPN) connections are
        usually used to establish the SMPP sessions and each SMPP session
        is authorized by verifying the System ID and password at session
        setup time.   Those security related measures should be used.
   
      Contact: See the Author's Address Section of this document for
        author's contact information.
   
      Author/change controller: This URI scheme is registered under the
        IETF tree.  As such, the IETF maintains change control.
   
      References: See Sections 5 and 8.1 of this document and [13] and
      [15] in Section 9 of this document.
   
   
   
   
   
   
   
   
   
   
   
   
                  Standards Track - Expires November 7, 2008            9
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
   9. References
   
   
   9.1. Normative References
   
       [1] S. Bradner, "Key Words for Use in RFCs to Indicate Requirement
           Levels", BCP 14, RFC 2119, March 1997.
   
       [2] P. Faltstrom and M. Mealling, "The E.164 to Uniform Resource
           Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
           Application (ENUM)", RFC 3761, April 2004.
   
       [3] M. Mealling, "Dynamic Delegation Discovery System (DDDS) Part
           Four: The Uniform Resource Identifiers (URI)", RFC 3404,
           October 2002.
   
       [4] R. Brandner, et al., "IANA Registration for Enumservices email,
           fax, mms, ems, and sms", RFC 4355, January 2006.
   
       [5] T. Hansen, et al., "Guidelines and Registration Procedures for
           New URI Schemes", RFC 4395, February 2006.
   
       [6] D. Crocker and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.
   
       [7] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation
           Protocol", June 2002.
   
       [8] H. Schulzrinne, "The tel URI for Telephone Numbers", RFC 3966,
           December 2004.
   
       [9] T. Berners-Lee, et al., "Uniform Resource Identifiers (URI):
           Generic Syntax", RFC 3986, January 2005.
   
   
   9.2. Informative References
   
      [10] ITU-T, "The International Public Telecommunication Numbering
           Plan", Recommendation E.164, May 1997.
   
      [11] P. Mockapetris, "Domain Names - Concepts and Facilities", STD
           13, RFC 1034, November 1987.
   
      [12] B. Hoeneisen, et al., "IANA Registration of Enumservices:
           Guide, Template and IANA Considerations", draft-ietf-enum-
           enumservices-guide-08, March 2008.
   
      [13] SMS Forum, "Short Message Peer-to-Peer Protocol (SMPP)
           Specification Version 5.0 ", February 19, 2003.
   
      [14] ITU-T Recommendation X.25, "Interface between Data Terminal
           Equipment (DTE) and Data Circuit-terminating Equipment (DCE)
   
   
                  Standards Track - Expires November 7, 2008           10
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
           for terminals operating in the packet mode and connected to
           public data networks by dedicated circuit", October 1996.
   
      [15] 3GPP TS 23.040 v7.0.1, "3rd Generation Partnership Project;
           Technical Specification Group Core Network and Terminals;
           Technical realization of the Short Message Service (SMS)
           (Release 7)", March 2007.
   
      [16] 3GPP TS 29.002 v7.9.0, "3rd Generation Partnership Project;
           Technical Specification Group Core Network and Terminals;
           Mobile Application Part (MAP specification; (Release 7)",
           September 2007.
   
      [17] 3GPP TS 23.840 v7.1.0, "3rd Generation Partnership Project;
           Technical Specification Group Core Network and Terminals; Study
           into routeing of MT-SMs via the HPLMN; (Release 7)", March
           2007.
   
      [18] 3GPP TS 24.341 v7.2.0, "3rd Generation Partnership Project;
           Technical Specification Group Core Network and Terminals;
           Support of SMS over IP networks; Stage 3 (Release 7)", December
           2007.
   
      [19] 3GPP TR 23.811 v8.0.0, "3rd Generation Partnership Project;
           Technical Specification Group Core Network and Terminals;
           Service Level Interworking for Messaging Services; Stage 2
           (Release 8)", March 2008.
   
      [20] 3GPP TS 23.204 v7.5.0, "3rd Generation Partnership Project;
           Technical Specification Group Services and System Aspects;
           Support of Short Message Service (SMS) over generic 3GPP
           Internet Protocol (IP) access; Stage 2 (Release 7)", March
           2008.
   
      [21] A. Gulbrandsen, et al., "A DNS RR for specifying the location
           of services (DNS SRV)", RFC 2782, February 2000.
   
   
   Author's Address
   
      James Yu
      NeuStar, Inc.
      46000 Center Oak Plaza
      Sterling, VA 20166
      U.S.A.
      Phone: +1-571-434-5572
      Email: james.yu@neustar.biz
   
   
   
   
   
   
   
                  Standards Track - Expires November 7, 2008           11
                      IANA Registrations for Enumservice         May 2008
                       "sms:smpp" and URI Scheme "smpp"
   
   Full Copyright Statement
   
      Copyright (C) The IETF Trust (2008).
   
      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.
   
      This document and the information contained herein are provided on
      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
      IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
      ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
      FOR A PARTICULAR PURPOSE.
   
   
   Intellectual Property
   
      The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology described
      in this document or the extent to which any license under such
      rights might or might not be available; nor does it represent that
      it has made any independent effort to identify any such rights.
      Information on the procedures with respect to rights in RFC
      documents can be found in BCP 78 and BCP 79.
   
      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr.
   
      The IETF invites any interested party to bring to its attention any
      copyrights, patents or patent applications, or other proprietary
      rights that may cover technology that may be required to implement
      this standard.  Please address the information to the IETF at ietf-
      ipr@ietf.org.
   
   
   Acknowledgment
   
      Funding for the RFC Editor function is provided by the IETF
      Administrative Support Activity (IASA).
   
   
   
   
   
   
   
                  Standards Track - Expires November 7, 2008           12