4.18.  sms:mailto

    <record>
      <!-- sms:mailto -->
      <class>Application-Based, Common</class>
      <type>sms</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>
          SMS 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, SMS 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.19.  sms:tel

    <record>
      <!-- sms:tel -->
      <class>Application-Based, Common</class>
      <type>sms</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 Short Message
          Service (SMS) [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>
    </record>

4.20.  unifmsg:http

    <record>
      <!-- unifmsg:http -->
      <class>Application-Based, Common</class>
      <type>unifmsg</type>
      <subtype>http</subtype>
      <urischeme>http</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified by
          the associated URI scheme is capable of being a source of
          information.
        </paragraph>
        <paragraph>
          Note that the kind of information retrieved can be manifold.
          Usually, contacting a resource by an 'http:' [11] URI
          provides a document.  This document can contain references
          that will trigger the download of many different kinds of
          information, such as text, audio, video, executable code, or
          even video message files.  Thus, one cannot be more specific
          about the kind of information expected when contacting the
          resource.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5278"/>, Section 3.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Don_Troshynski"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Implementers should review a non-exclusive list of examples
          in Section 7 of <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.21.  unifmsg:https

    <record>
      <!-- unifmsg:https -->
      <class>Application-Based, Common</class>
      <type>unifmsg</type>
      <subtype>https</subtype>
      <urischeme>https</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified by
          the associated URI scheme is capable of being a source of
          information, which can be contacted using TLS or the Secure
          Socket Layer protocol.
        </paragraph>
        <paragraph>
          Note that the kind of information retrieved can be manifold.
          Usually, contacting a resource by an 'https:' [12] URI
          provides a document.  This document can contain references
          that will trigger the download of many different kinds of
          information, such as text, audio, video, executable code, or
          even video message files.  Thus, one cannot be more specific
          about the kind of information expected when contacting the
          resource.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5278"/>, Section 3.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Don_Troshynski"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Implementers should review a non-exclusive list of examples
          in Section 7 of <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.22.  unifmsg:sip

     <record>
       <!-- unifmsg:sip -->
       <class>Application-Based, Common</class>
       <type>unifmsg</type>
       <subtype>sip</subtype>
       <urischeme>sip</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource identified can
           be addressed by the associated URI scheme in order to
           initiate a unified communication session to a unified
           messaging system.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
         <xref type="person" data="Don_Troshynski"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Implementers should review a non-exclusive list of examples
           in Section 7 of <xref type="rfc" data="rfc5278"/>.
         </paragraph>
       </additionalinfo>
     </record>

4.23.  unifmsg:sips

     <record>
       <!-- unifmsg:sips -->
       <class>Application-Based, Common</class>
       <type>unifmsg</type>
       <subtype>sips</subtype>
       <urischeme>sips</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource identified can
           be addressed by the associated URI scheme in order to
           initiate a unified communication session to a unified
           messaging system.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
         <xref type="person" data="Don_Troshynski"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Implementers should review a non-exclusive list of examples
           in Section 7 of <xref type="rfc" data="rfc5278"/>.
         </paragraph>
       </additionalinfo>
     </record>

4.24.  vcard

    <record>
      <!-- vcard -->
      <class>Data Type-Based</class>
      <type>vcard</type>
      <!-- No subtype -->
      <urischeme>http</urischeme>
      <urischeme>https</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource
          identified is a plain vCard, according to RFC2426,
          which may be accessed using HTTP / HTTPS [7].
        </paragraph>
        <paragraph>
          Clients fetching the vCard from the resource
          indicated should expect access to be
          restricted.  Additionally, the comprehension of the
          data provided may vary depending on the client's
          identity.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4969"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc4969"/>, Section 5.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4969"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Alexander_Mayrhofer"/>
      </requesters>
    </record>

4.25.  videomsg:http

    <record>
      <!-- videomsg:http -->
      <class>Application-Based, Common</class>
      <type>videomsg</type>
      <subtype>http</subtype>
      <urischeme>http</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified by
          the associated URI scheme is capable of being a source of
          information.
        </paragraph>
        <paragraph>
          Note that the kind of information retrieved can be manifold.
          Usually, contacting a resource by an 'http:' [11] URI
          provides a document.  This document can contain references
          that will trigger the download of many different kinds of
          information, such as text, audio, video, executable code, or
          even video message files.  Thus, one cannot be more specific
          about the kind of information expected when contacting the
          resource.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5278"/>, Section 3.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Don_Troshynski"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Implementers should review a non-exclusive list of examples
          in Section 7 of <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.26.  videomsg:https

    <record>
      <!-- videomsg:https -->
      <class>Application-Based, Common</class>
      <type>videomsg</type>
      <subtype>https</subtype>
      <urischeme>https</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified by
          the associated URI scheme is capable of being a source of
          information, which can be contacted using TLS or the Secure
          Socket Layer protocol.
        </paragraph>
        <paragraph>
          Note that the kind of information retrieved can be manifold.
          Usually, contacting a resource by an 'https:' [12] URI
          provides a document.  This document can contain references
          that will trigger the download of many different kinds of
          information, such as text, audio, video, executable code, or
          even video message files.  Thus, one cannot be more specific
          about the kind of information expected when contacting the
          resource.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5278"/>, Section 3.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Don_Troshynski"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Implementers should review a non-exclusive list of examples
          in Section 7 of <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.27.  videomsg:sip

     <record>
       <!-- videomsg:sip -->
       <class>Application-Based, Common</class>
       <type>videomsg</type>
       <subtype>sip</subtype>
       <urischeme>sip</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource identified can
           be addressed by the associated URI scheme in order to
           initiate a video communication session to a video messaging
           system.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
         <xref type="person" data="Don_Troshynski"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Implementers should review a non-exclusive list of examples
           in Section 7 of <xref type="rfc" data="rfc5278"/>.
         </paragraph>
       </additionalinfo>
     </record>

4.28.  videomsg:sips

     <record>
       <!-- videomsg:sips -->
       <class>Application-Based, Common</class>
       <type>videomsg</type>
       <subtype>sips</subtype>
       <urischeme>sips</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource identified can
           be addressed by the associated URI scheme in order to
           initiate a video communication session to a video messaging
           system.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
         <xref type="person" data="Don_Troshynski"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Implementers should review a non-exclusive list of examples
           in Section 7 of <xref type="rfc" data="rfc5278"/>.
         </paragraph>
       </additionalinfo>
     </record>

4.29.  voice:tel

    <record>
      <!-- voice:tel -->
      <class>Application-Based, Common</class>
      <type>voice</type>
      <subtype>tel</subtype>
      <urischeme>tel</urischeme>
      <functionalspec>
        <paragraph>
          The kind of communication indicated by this
          Enumservice is "Interactive Voice".  From a protocol
          perspective, this communication is expected to
          involve bidirectional media streams carrying audio
          data.
        </paragraph>
        <paragraph>
          A client may imply that the person controlling
          population of a NAPTR holding this Enumservice
          indicates their capability to engage in an
          interactive voice session when contacted using the
          URI generated by this NAPTR.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc4415"/>, Section 5.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc4415"/> (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>
          This Enumservice indicates that the person
          responsible for the NAPTR is accessible via the PSTN
          (Public Switched Telephone Network) or PLMN (Public
          Land Mobile Network) using the value of the
          generated URI.
        </paragraph>
        <paragraph>The kind of subsystem required to initiate a
          Voice Enumservice with this Subtype is a "Dialler".
          This is a subsystem that either provides a local

          connection to the PSTN or PLMN, or that provides an
          indirect connection to those networks.  The
          subsystem will use the telephone number held in the
          generated URI to place a voice call.  The voice call
          is placed to a network that uses E.164 numbers to
          route calls to an appropriate destination.
        </paragraph>
        <paragraph>
          Note that the PSTN/PLMN connection may be
          indirect.  The end user receiving this NAPTR may
          have a relationship with a Communications Service
          Provider that accepts call initiation requests from
          that subsystem using an IP-based protocol such as
          SIP or H.323, and places the call to the PSTN using
          a remote gateway service.  In this case, the Provider
          may either accept requests using "tel:" URIs or has
          a defined mechanism to convert "tel:" URI values
          into a "protocol-native" form.
        </paragraph>
        <paragraph>
          The "tel:" URI value SHOULD be fully qualified
          (using the "global phone number" form of RFC 3966
          [10]).  A "local phone number" as defined in that
          document SHOULD NOT be used unless the controller of
          the zone in which the NAPTR appears is sure that it
          can be distinguished unambiguously by all clients
          that can access the resource record and that a call
          from their network access points can be routed to
          that destination.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc4415"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.30.  voicemsg:http

    <record>
      <!-- voicemsg:http -->
      <class>Application-Based, Common</class>
      <type>voicemsg</type>
      <subtype>http</subtype>
      <urischeme>http</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified by
          the associated URI scheme is capable of being a source of
          information.
        </paragraph>
        <paragraph>
          Note that the kind of information retrieved can be manifold.
          Usually, contacting a resource by an 'http:' [11] URI
          provides a document.  This document can contain references
          that will trigger the download of many different kinds of
          information, such as text, audio, video, executable code, or
          even voice message files.  Thus, one cannot be more specific
          about the kind of information expected when contacting the
          resource.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5278"/>, Section 3.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Don_Troshynski"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Implementers should review a non-exclusive list of examples
          in Section 7 of <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.31.  voicemsg:https

    <record>
      <!-- voicemsg:https -->
      <class>Application-Based, Common</class>
      <type>voicemsg</type>
      <subtype>https</subtype>
      <urischeme>https</urischeme>
      <functionalspec>
        <paragraph>
          This Enumservice indicates that the resource identified by
          the associated URI scheme is capable of being a source of
          information, which can be contacted using TLS or the Secure
          Socket Layer protocol.
        </paragraph>
        <paragraph>
          Note that the kind of information retrieved can be manifold.
          Usually, contacting a resource by an 'https:' [12] URI
          provides a document.  This document can contain references
          that will trigger the download of many different kinds of
          information, such as text, audio, video, executable code, or
          even voice message files.  Thus, one cannot be more specific
          about the kind of information expected when contacting the
          resource.
        </paragraph>
        <paragraph>
          References are contained in <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5278"/>, Section 3.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
        <xref type="rfc" data="RFC 6118"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Jason_Livingood"/>
        <xref type="person" data="Don_Troshynski"/>
      </requesters>
      <additionalinfo>
        <paragraph>
          Implementers should review a non-exclusive list of examples
          in Section 7 of <xref type="rfc" data="rfc5278"/>.
        </paragraph>
      </additionalinfo>
    </record>

4.32.  voicemsg:sip

     <record>
       <!-- voicemsg:sip -->
       <class>Application-Based, Common</class>
       <type>voicemsg</type>
       <subtype>sip</subtype>
       <urischeme>sip</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource identified can
           be addressed by the associated URI scheme in order to
           initiate a voice communication session to a voice messaging
           system.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
         <xref type="person" data="Don_Troshynski"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Implementers should review a non-exclusive list of examples
           in Section 7 of <xref type="rfc" data="rfc5278"/>.
         </paragraph>
       </additionalinfo>
     </record>

4.33.  voicemsg:sips

     <record>
       <!-- voicemsg:sips -->
       <class>Application-Based, Common</class>
       <type>voicemsg</type>
       <subtype>sips</subtype>
       <urischeme>sips</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource identified can
           be addressed by the associated URI scheme in order to
           initiate a voice communication session to a voice messaging
           system.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
         <xref type="person" data="Don_Troshynski"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Implementers should review a non-exclusive list of examples
           in Section 7 of <xref type="rfc" data="rfc5278"/>.
         </paragraph>
       </additionalinfo>
     </record>

4.34.  voicemsg:tel

     <record>
       <!-- voicemsg:tel -->
       <class>Application-Based, Common</class>
       <type>voicemsg</type>
       <subtype>tel</subtype>
       <urischeme>tel</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource identified can
           be addressed by the associated URI scheme in order to
           initiate a voice communication session to a voice messaging
           system.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jason_Livingood"/>
         <xref type="person" data="Don_Troshynski"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Implementers should review a non-exclusive list of examples
           in Section 7 of <xref type="rfc" data="rfc5278"/>.
         </paragraph>
       </additionalinfo>
     </record>

4.35.  vpim:ldap

     <record>
       <!-- vpim:ldap -->
       <class>Data Type-Based</class>
       <type>vpim</type>
       <subtype>ldap</subtype>
       <urischeme>ldap</urischeme>
       <functionalspec>
         See <xref type="rfc" data="rfc4238"/>, Section 3.2 - 3.3.
       </functionalspec>
       <security>
         <paragraph>
           Malicious Redirection:
           One of the fundamental dangers related to any
           service such as this is that a malicious entry in a
           resolver's database will cause clients to resolve
           the E.164 into the wrong LDAP URI.  The possible
           intent may be to cause the client to connect to a
           rogue LDAP server and retrieve (or fail to retrieve)
           a resource containing fraudulent or damaging
           information.
         </paragraph>
         <paragraph>
           Denial of Service:
           By removing the URI to which the E.164 maps, a
           malicious intruder may remove the client's ability
           to access the LDAP directory server.
         </paragraph>
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4238"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Greg_Vaudreuil"/>
       </requesters>
     </record>

4.36.  vpim:mailto

     <record>
       <!-- vpim:mailto -->
       <class>Data Type-Based</class>
       <type>vpim</type>
       <subtype>mailto</subtype>
       <urischeme>mailto</urischeme>
       <functionalspec>
         See <xref type="rfc" data="rfc4238"/>, Section 4.2 - 4.4.
       </functionalspec>
       <security>
         <paragraph>
           Malicious Redirection:
           One of the fundamental dangers related to any
           service such as this is that a malicious entry in a
           resolver's database will cause clients to resolve
           the E.164 into the wrong email URI.  The possible
           intent may be to cause the client to send the
           information to an incorrect destination.
         </paragraph>
         <paragraph>
           Denial of Service:
           By removing the URI to which the E.164 maps, a
           malicious intruder may remove the client's ability
           to access the resource.
         </paragraph>
         <paragraph>
           Unsolicited Bulk Email:
           The exposure of email addresses through the ENUM
           service provides a bulk mailer access to large
           numbers of email addresses where only the telephone
           number was previously known.
         </paragraph>
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4238"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Greg_Vaudreuil"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Error Conditions:
         </paragraph>
         <paragraph>

           E.164 number not in the numbering plan
         </paragraph>
         <paragraph>
           E.164 number in the numbering plan, but no
           URIs exist for that number
         </paragraph>
         <paragraph>
           E2U+vpim:mailto Service unavailable of email
           addresses where only the telephone number was
           previously known.
         </paragraph>
       </additionalinfo>
     </record>

4.37.  web:http

     <record>
       <!-- web:http -->
       <class>Application-Based, Common</class>
       <type>web</type>
       <subtype>http</subtype>
       <urischeme>http</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource
           identified by the associated URI is capable
           of being a source of information.  It has to be
           noted that the kind of information retrieved can be
           manifold.  Usually, contacting a resource by an
           "http:" URI provides a document.  This document can
           contain references that will trigger download of
           many different kinds of information, like audio or
           video or executable code.  Thus, one cannot be more
           specific about the kind of information that can be
           expected when contacting the resource.
         </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.38.  web:https

     <record>
       <!-- web:https -->
       <class>Application-Based, Common</class>
       <type>web</type>
       <subtype>https</subtype>
       <urischeme>https</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource
           identified by the associated URI is capable
           of being a source of information, which can be
           contacted by using TLS or the Secure Socket Layer
           protocol.  It has to be noted that the kind of
           information retrieved can be manifold.  Usually,
           contacting a resource by an "https:" URI provides a
           document.  This document can contain all different
           kinds of information, like audio or video or
           executable code.  Thus, one cannot be more specific
           what information to expect when contacting the
           resource.
         </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.39.  xmpp

     <record>
       <!-- xmpp -->
       <class>Protocol-Based</class>
       <type>xmpp</type>
       <!-- No subtype -->
       <urischeme>xmpp</urischeme>
       <functionalspec>
         <paragraph>
           This Enumservice indicates that the resource
           identified is an XMPP entity.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4979"/>, Section 6.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4979"/> (updated by RFC 6118)
         <xref type="rfc" data="RFC 6118"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Alexander_Mayrhofer"/>
       </requesters>
     </record>

5.  IANA Considerations

   IANA replaced all legacy Enumservice Registrations as per Section 4.

6.  Security Considerations

   Since this document does not introduce any technology or protocol,
   there are no security issues to be considered for this document
   itself.

7.  Acknowledgements

   The authors would like to thank the following people who have
   provided feedback or significant contributions to the development of
   this document: Jari Arkko, Scott Bradner, Gonzalo Camarillo, Alfred
   Hoenes, Ari Keranen, and Alexey Melnikov.

8.  References

8.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3761]  Faltstrom, P. and M. Mealling, "The E.164 to Uniform
              Resource Identifiers (URI) Dynamic Delegation Discovery
              System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [RFC3762]  Levin, O., "Telephone Number Mapping (ENUM) Service
              Registration for H.323", RFC 3762, April 2004.

   [RFC3764]  Peterson, J., "enumservice registration for Session
              Initiation Protocol (SIP) Addresses-of-Record", RFC 3764,
              April 2004.

   [RFC3953]  Peterson, J., "Telephone Number Mapping (ENUM) Service
              Registration for Presence Services", RFC 3953,
              January 2005.

   [RFC4002]  Brandner, R., Conroy, L., and R. Stastny, "IANA
              Registration for Enumservice 'web' and 'ft'", RFC 4002,
              February 2005.

   [RFC4143]  Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail
              (IFAX) Service of ENUM", RFC 4143, November 2005.

   [RFC4238]  Vaudreuil, G., "Voice Message Routing Service", RFC 4238,
              October 2005.

   [RFC4355]  Brandner, R., Conroy, L., and R. Stastny, "IANA
              Registration for Enumservices email, fax, mms, ems, and
              sms", RFC 4355, January 2006.

   [RFC4415]  Brandner, R., Conroy, L., and R. Stastny, "IANA
              Registration for Enumservice Voice", RFC 4415,
              February 2006.

   [RFC4769]  Livingood, J. and R. Shockey, "IANA Registration for an
              Enumservice Containing Public Switched Telephone Network
              (PSTN) Signaling Information", RFC 4769, November 2006.

   [RFC4969]  Mayrhofer, A., "IANA Registration for vCard Enumservice",
              RFC 4969, August 2007.

   [RFC4979]  Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'",
              RFC 4979, August 2007.

   [RFC5028]  Mahy, R., "A Telephone Number Mapping (ENUM) Service
              Registration for Instant Messaging (IM) Services",
              RFC 5028, October 2007.

   [RFC5278]  Livingood, J. and D. Troshynski, "IANA Registration of
              Enumservices for Voice and Video Messaging", RFC 5278,
              July 2008.

   [RFC5333]  Mahy, R. and B. Hoeneisen, "IANA Registration of
              Enumservices for Internet Calendaring", RFC 5333,
              October 2009.

   [RFC6117]  Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
              Registration of Enumservices: Guide, Template, and IANA
              Considerations", RFC 6117, March 2011.

8.2.  Informative References

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.