Internet Engineering Task Force (IETF)                      B. Hoeneisen
Request for Comments: 6118                                       Ucom.ch
Updates: 3762, 3764, 3953, 4143, 4002,                      A. Mayrhofer
         4238, 4355, 4415, 4769, 4969,                           enum.at
         4979, 5028, 5278, 5333                               March 2011
Category: Standards Track
ISSN: 2070-1721


          Update of Legacy IANA Registrations of Enumservices

Abstract

   This document revises all Enumservices that were IANA registered
   under the now obsolete specification of the Enumservice registry
   defined in RFC 3761.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6118.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IESG Action  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Legacy Enumservice Registrations Converted to XML Chunks . . .  5
     4.1.  email:mailto . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  ems:mailto . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.3.  ems:tel  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.4.  fax:tel  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     4.5.  ft:ftp . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.6.  h323 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.7.  ical-access:http . . . . . . . . . . . . . . . . . . . . . 12
     4.8.  ical-access:https  . . . . . . . . . . . . . . . . . . . . 13
     4.9.  ical-sched:mailto  . . . . . . . . . . . . . . . . . . . . 14
     4.10. ifax:mailto  . . . . . . . . . . . . . . . . . . . . . . . 15
     4.11. im . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.12. mms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.13. mms:tel  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     4.14. pres . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     4.15. pstn:sip . . . . . . . . . . . . . . . . . . . . . . . . . 21
     4.16. pstn:tel . . . . . . . . . . . . . . . . . . . . . . . . . 22
     4.17. sip  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     4.18. sms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 24
     4.19. sms:tel  . . . . . . . . . . . . . . . . . . . . . . . . . 25
     4.20. unifmsg:http . . . . . . . . . . . . . . . . . . . . . . . 26
     4.21. unifmsg:https  . . . . . . . . . . . . . . . . . . . . . . 27
     4.22. unifmsg:sip  . . . . . . . . . . . . . . . . . . . . . . . 28
     4.23. unifmsg:sips . . . . . . . . . . . . . . . . . . . . . . . 29
     4.24. vcard  . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     4.25. videomsg:http  . . . . . . . . . . . . . . . . . . . . . . 31
     4.26. videomsg:https . . . . . . . . . . . . . . . . . . . . . . 32
     4.27. videomsg:sip . . . . . . . . . . . . . . . . . . . . . . . 33
     4.28. videomsg:sips  . . . . . . . . . . . . . . . . . . . . . . 34
     4.29. voice:tel  . . . . . . . . . . . . . . . . . . . . . . . . 35
     4.30. voicemsg:http  . . . . . . . . . . . . . . . . . . . . . . 37

     4.31. voicemsg:https . . . . . . . . . . . . . . . . . . . . . . 38
     4.32. voicemsg:sip . . . . . . . . . . . . . . . . . . . . . . . 39
     4.33. voicemsg:sips  . . . . . . . . . . . . . . . . . . . . . . 40
     4.34. voicemsg:tel . . . . . . . . . . . . . . . . . . . . . . . 41
     4.35. vpim:ldap  . . . . . . . . . . . . . . . . . . . . . . . . 42
     4.36. vpim:mailto  . . . . . . . . . . . . . . . . . . . . . . . 43
     4.37. web:http . . . . . . . . . . . . . . . . . . . . . . . . . 45
     4.38. web:https  . . . . . . . . . . . . . . . . . . . . . . . . 46
     4.39. xmpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 47
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 47
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 48
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 49
   Appendix A.  Former Content of the IANA Repository . . . . . . . . 49

1.  Introduction

   [RFC6117] has obsoleted the IANA registration section of [RFC3761].
   Since the IANA Enumservice registry contains various Enumservices
   registered under the regime of RFC 3761, those registrations do not
   conform to the new guidelines as specified in [RFC6117].  To ensure
   consistency among all Enumservice registrations at IANA, this
   document adds the (nowadays) missing elements to those legacy
   registrations.  Furthermore, all legacy Enumservice registrations are
   converted to the new XML-chunk format, and, where deemed necessary,
   minor editorial corrections are applied.

   However, this document only adds the missing elements to the XML
   chunks as specified in the IANA Considerations section of [RFC6117],
   but it does not complete the (nowadays) missing sections of the
   corresponding Enumservice Specifications.  In order to conform with
   the new registration regime as specified in [RFC6117], those
   Enumservice Specifications still have to be revised.

   It is important to note that this document does not update the
   functional specification of the concerned Enumservices.

   The following RFCs are updated by this document:

   o  [RFC3762]
   o  [RFC3764]
   o  [RFC3953]
   o  [RFC4143]
   o  [RFC4002]
   o  [RFC4238]
   o  [RFC4355]
   o  [RFC4415]
   o  [RFC4769]
   o  [RFC4969]
   o  [RFC4979]
   o  [RFC5028]
   o  [RFC5278]
   o  [RFC5333]

2.  Terminology

   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 [RFC2119].

3.  IESG Action

   According to [RFC3761], any Enumservice registration had to be
   published as a Standards Track, Experimental, or BCP (Best Current
   Practice) RFC.  [RFC6117] no longer has this requirement, i.e.,
   "Specification Required", which implies the use of a Designated
   Expert [RFC5226], is sufficient.

   This document changes the approval requirement for updates to
   Enumservice registrations to Specification Required, whereby the
   specification and request are reviewed by a Designated Expert as
   described in [RFC6117].

4.  Legacy Enumservice Registrations Converted to XML Chunks

   In the following, the legacy Enumservice Registrations are converted
   to XML chunks that include the new elements introduced by [RFC6117].

   (Note that references in Sections 4.1 - 4.39 refer to the references
   section within the respective Enumservice Specification.)

4.1.  email:mailto

     <record>
       <!-- email:mailto -->
       <class>Application-Based, Common</class>
       <type>email</type>
       <subtype>mailto</subtype>
       <urischeme>mailto</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource can be
           addressed by the associated URI in order to send an
           email.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4355"/>, Section 6.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>

       </requesters>
     </record>

4.2.  ems:mailto

    <record>
      <!-- ems:mailto -->
      <class>Application-Based, Common</class>
      <type>ems</type>
      <subtype>mailto</subtype>
      <urischeme>mailto</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource
          identified by the associated URI is capable
          of receiving a message using an email protocol.
        </paragraph>
        <paragraph>
          EMS content is sent over SMTP using the format
          specified by TS 23.140 [15] Section 8.4.4 and TS
          26.140 [16] Section 4, as an MMS message.  Within
          such a message, EMS content is carried as either a
          text or application/octet-stream MIME sub-part (see
          TS 26.140 [16], Section 4.1).
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4355"/>.
        </paragraph>
      </functionalspec>
      <security>
        <paragraph>
          There are no specific security issues with this
          Enumservice.  However, the general considerations of
          Section 6 of <xref type="rfc" data="rfc4355"/> apply.
        </paragraph>
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rudolf_Brandner"/>
        <xref type="person" data="Lawrence_Conroy"/>
        <xref type="person" data="Richard_Stastny"/>
      </requesters>
    </record>

4.3.  ems:tel

    <record>
      <!-- ems:tel -->
      <class>Application-Based, Common</class>
      <type>ems</type>
      <subtype>tel</subtype>
      <urischeme>tel</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource
          identified by the associated URI is capable
          of receiving a message using the Enhanced Message
          Service (EMS) [14].
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4355"/>.
        </paragraph>
      </functionalspec>
      <security>
        <paragraph>
          There are no specific security issues with this
          Enumservice.  However, the general considerations of
          Section 6 of <xref type="rfc" data="rfc4355"/> apply.
        </paragraph>
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rudolf_Brandner"/>
        <xref type="person" data="Lawrence_Conroy"/>
        <xref type="person" data="Richard_Stastny"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Note that an indication of EMS can be taken as
          implying that the recipient is capable of receiving
          SMS messages at this address as well.
        </paragraph>
      </additionalinfo>
    </record>

4.4.  fax:tel

    <record>
      <!-- fax:tel -->
      <class>Application-Based, Subset</class>
      <type>fax</type>
      <subtype>tel</subtype>
      <urischeme>tel</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource
          identified by the associated URI is capable
          of being contacted to provide a communication
          session during which facsimile documents can be
          sent.
        </paragraph>
        <paragraph>
          A client selecting this NAPTR will have support
          for generating and sending facsimile documents to
          the recipient using the PSTN session and transfer
          protocols specified in [12] and [13] in
          <xref type="rfc" data="rfc4355"/> -
          in short, they will have a fax program with a local
          or shared PSTN access over which they can send
          faxes.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4355"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc4355"/>, Section 6.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rudolf_Brandner"/>
        <xref type="person" data="Lawrence_Conroy"/>
        <xref type="person" data="Richard_Stastny"/>
      </requesters>
    </record>

4.5.  ft:ftp

     <record>
       <!-- ft:ftp -->
       <class>Application-Based, Subset</class>
       <type>ft</type>
       <subtype>ftp</subtype>
       <urischeme>ftp</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource
           identified by the associated URI is a file
           service from which a file or file listing can be
           retrieved.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4002"/>, Section 5.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4002"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>

4.6.  h323

     <record>
       <!-- h323 -->
       <class>Protocol-Based</class>
       <type>h323</type>
       <!-- No subtype -->
       <urischeme>h323</urischeme>
       <functionalspec>
         See <xref type="rfc" data="rfc3762"/>, Section 3.
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc3762"/>, Section 5.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc3762"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Orit_Levin"/>
       </requesters>
     </record>

4.7.  ical-access:http

    <record>
      <!-- ical-access:http -->
      <class>Application-Based, Common</class>
      <type>ical-access</type>
      <subtype>http</subtype>
      <urischeme>http</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified
          can be addressed by the associated URI in order to access
          a user's calendar (for example free/busy status) using
          the CalDAV [7] protocol for Internet calendaring.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5333"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5333"/>, Section 4.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5333"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rohan_Mahy"/>
      </requesters>
    </record>

4.8.  ical-access:https

    <record>
      <!-- ical-access:https -->
      <class>Application-Based, Common</class>
      <type>ical-access</type>
      <subtype>https</subtype>
      <urischeme>https</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified
          can be addressed by the associated URI in order to access
          a user's calendar (for example free/busy status) using
          the CalDAV [7] protocol for Internet calendaring.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5333"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5333"/>, Section 4.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5333"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rohan_Mahy"/>
      </requesters>
    </record>

4.9.  ical-sched:mailto

    <record>
      <!-- ical-sched:mailto -->
      <class>Application-Based, Common</class>
      <type>ical-sched</type>
      <subtype>mailto</subtype>
      <urischeme>mailto</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified
          can be addressed by the associated URI used for
          scheduling using Internet calendaring via Internet mail
          with the iMIP [6] protocol.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5333"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5333"/>, Section 4.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5333"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rohan_Mahy"/>
      </requesters>
    </record>

4.10.  ifax:mailto

     <record>
       <!-- ifax:mailto -->
       <class>Application-Based, Subset</class>
       <type>ifax</type>
       <subtype>mailto</subtype>
       <urischeme>mailto</urischeme>
       <functionalspec>
         See <xref type="rfc" data="rfc4143"/>, Section 1.
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4143"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4143"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Kiyoshi_Toyoda"/>
         <xref type="person" data="Dave_Crocker"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           The URI Scheme is 'mailto' because facsimile is a
           profile of standard Internet mail and uses standard
           Internet mail addressing.
         </paragraph>
       </additionalinfo>
     </record>

4.11.  im

    <record>
      <!-- im -->
      <class>Application-Based, Common</class>
      <type>im</type>
      <!-- No subtype -->
      <urischeme>im</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource
          identified is an 'im:' URI.  The 'im:' URI scheme
          does not identify any particular protocol that will
          be used to handle instant messaging receipt or
          delivery, rather the mechanism in RFC 3861 [4] is
          used to discover whether an IM protocol supported by
          the party querying ENUM is also supported by the
          target resource.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5028"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5028"/>, Section 3.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5028"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rohan_Mahy"/>
      </requesters>
    </record>

4.12.  mms:mailto

    <record>
      <!-- mms:mailto -->
      <class>Application-Based, Common</class>
      <type>mms</type>
      <subtype>mailto</subtype>
      <urischeme>mailto</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource
          identified by the associated URI is capable
          of receiving a message using an email protocol.
        </paragraph>
        <paragraph>
          MMS messages are sent over SMTP using the format
          specified by TS 23.140 [15] Section 8.4.4 and TS
          26.140 [16] Section 4.
        </paragraph>
        <paragraph>
          Within and between MMS Environments (MMSE,
          network infrastructures that support the MultiMedia
          Service), other pieces of state data (for example,
          charging-significant information) are exchanged
          between MMS Relay Servers.  Thus, although these
          servers use SMTP as the "bearer" for their
          application exchanges, they map their internal state
          to specialized header fields carried in the SMTP message
          exchanges.  The header fields used in such MMSE are
          described in detail in [17].
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4355"/>.
        </paragraph>
      </functionalspec>
      <security>
        <paragraph>
          There are no specific security issues with this
          Enumservice.  However, the general considerations of
          Section 6 of <xref type="rfc" data="rfc4355"/> apply.
        </paragraph>
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>

        <xref type="person" data="Rudolf_Brandner"/>
        <xref type="person" data="Lawrence_Conroy"/>
        <xref type="person" data="Richard_Stastny"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          The MMS Architecture describes an interface
          between the MMSE and "legacy messaging systems"
          (labelled as MM3) that accepts "standard" SMTP
          messages.  Thus, although the MMS Relay Server that
          supports this interface appears as a standard SMTP
          server from the perspective of an Internet-based
          mail server, it acts as a gateway and translator,
          adding the internal state data that is used within
          and between the MMS Environments.  This mechanism is
          described in [17], which also includes references to
          the specifications agreed by those bodies
          responsible for the design of the MMS.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4355"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.13.  mms:tel

    <record>
      <!-- mms:tel -->
      <class>Application-Based, Common</class>
      <type>mms</type>
      <subtype>tel</subtype>
      <urischeme>tel</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource
          identified by the associated URI is capable
          of receiving a message using the Multimedia
          Messaging Service (MMS) [15].
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4355"/>.
        </paragraph>
      </functionalspec>
      <security>
        <paragraph>
          There are no specific security issues with this
          Enumservice.  However, the general considerations of
          Section 6 of <xref type="rfc" data="rfc4355"/> apply.
        </paragraph>
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4355"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rudolf_Brandner"/>
        <xref type="person" data="Lawrence_Conroy"/>
        <xref type="person" data="Richard_Stastny"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Note that MMS can be used as an alternative to
          deliver an SMS RP-DATA RPDU if, for example, the
          SMS bearer is not supported.  If an entry includes
          this Enumservice, then in effect this can be taken
          as implying that the recipient is capable of
          receiving EMS or SMS messages at this address.  Such
          choices on the end system design do have two small
          caveats; whilst in practice all terminals supporting
          MMS today support SMS as well, it might not
          necessarily be the case in the future, and there may

          be tariff differences in using the MMS rather than
          using the SMS or EMS.
        </paragraph>
      </additionalinfo>
    </record>

4.14.  pres

     <record>
       <!-- pres -->
       <class>Application-Based, Common</class>
       <type>pres</type>
       <!-- No subtype -->
       <urischeme>pres</urischeme>
       <functionalspec>
         See <xref type="rfc" data="rfc3953"/>, Section 4.
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc3953"/>, Section 6.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc3953"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jon_Peterson"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           See <xref type="rfc" data="rfc3953"/>, Section 3.
         </paragraph>
       </additionalinfo>
     </record>

4.15.  pstn:sip

     <record>
       <!-- pstn:sip -->
       <class>Application-Based, Common</class>
       <type>pstn</type>
       <subtype>sip</subtype>
       <urischeme>sip</urischeme>
       <functionalspec>
         <paragraph>
           These Enumservices indicate that the
           resource identified can be addressed by the
           associated URI in order to initiate a
           telecommunication session, which may include two-way
           voice or other communications, to the PSTN.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4769"/>, Section 7.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4769"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Richard_Shockey"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           A Number Portability Dip Indicator (npdi) should
           be used in practice
           (see <xref type="rfc" data="rfc4769"/>, Section 4).
         </paragraph>
       </additionalinfo>
     </record>

4.16.  pstn:tel

    <record>
      <!-- pstn:tel -->
      <class>Application-Based, Ancillary</class>
      <type>pstn</type>
      <subtype>tel</subtype>
      <urischeme>tel</urischeme>
      <functionalspec>
        <paragraph>
          These Enumservices indicate that the
          resource identified can be addressed by the
          associated URI in order to initiate a
          telecommunication session, which may include two-way
          voice or other communications, to the PSTN.  These
          URIs may contain number portability data as
          specified in RFC4694 [10].
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4769"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc4769"/>, Section 7.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4769"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Richard_Shockey"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          A Number Portability Dip Indicator (npdi) should
          be used in practice
          (see <xref type="rfc" data="rfc4769"/>, Section 4).
        </paragraph>
      </additionalinfo>
    </record>

4.17.  sip

     <record>
       <!-- sip -->
       <class>Protocol-Based</class>
       <type>sip</type>
       <!-- No subtype -->
       <urischeme>sip</urischeme>
       <urischeme>sips</urischeme>
       <functionalspec>
         See <xref type="rfc" data="rfc3764"/>, Section 4.
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc3764"/>, Section 6.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc3764"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jon_Peterson"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           See <xref type="rfc" data="rfc3764"/>, Section 3.
         </paragraph>
       </additionalinfo>
     </record>