GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6118

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.

Hoeneisen & Mayrhofer Standards Track [Page 1] RFC 6118 Update Legacy Enumservice Registrations March 2011

 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

Hoeneisen & Mayrhofer Standards Track [Page 2] RFC 6118 Update Legacy Enumservice Registrations March 2011

   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

Hoeneisen & Mayrhofer Standards Track [Page 3] RFC 6118 Update Legacy Enumservice Registrations March 2011

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

Hoeneisen & Mayrhofer Standards Track [Page 4] RFC 6118 Update Legacy Enumservice Registrations March 2011

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"/>

Hoeneisen & Mayrhofer Standards Track [Page 5] RFC 6118 Update Legacy Enumservice Registrations March 2011

     </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>

Hoeneisen & Mayrhofer Standards Track [Page 6] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 7] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 8] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 9] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 10] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 11] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 12] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 13] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 14] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 15] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 16] RFC 6118 Update Legacy Enumservice Registrations March 2011

      <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>

Hoeneisen & Mayrhofer Standards Track [Page 17] RFC 6118 Update Legacy Enumservice Registrations March 2011

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

Hoeneisen & Mayrhofer Standards Track [Page 18] RFC 6118 Update Legacy Enumservice Registrations March 2011

        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>

Hoeneisen & Mayrhofer Standards Track [Page 19] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 20] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 21] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 22] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 23] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 24] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 25] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 26] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 27] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 28] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 29] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 30] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 31] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 32] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 33] RFC 6118 Update Legacy Enumservice Registrations March 2011

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

Hoeneisen & Mayrhofer Standards Track [Page 34] RFC 6118 Update Legacy Enumservice Registrations March 2011

        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>

Hoeneisen & Mayrhofer Standards Track [Page 35] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 36] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 37] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 38] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 39] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 40] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 41] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 42] RFC 6118 Update Legacy Enumservice Registrations March 2011

         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>

Hoeneisen & Mayrhofer Standards Track [Page 43] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 44] RFC 6118 Update Legacy Enumservice Registrations March 2011

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>

Hoeneisen & Mayrhofer Standards Track [Page 45] RFC 6118 Update Legacy Enumservice Registrations March 2011

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.

Hoeneisen & Mayrhofer Standards Track [Page 46] RFC 6118 Update Legacy Enumservice Registrations March 2011

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.

Hoeneisen & Mayrhofer Standards Track [Page 47] RFC 6118 Update Legacy Enumservice Registrations March 2011

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

Hoeneisen & Mayrhofer Standards Track [Page 48] RFC 6118 Update Legacy Enumservice Registrations March 2011

Appendix A. Former Content of the IANA Repository

Enumservice Registrations

(last updated 2009-10-13)

Registries included below: - Enumservice Registrations

Registry Name: Enumservice Registrations Reference: [RFC3761] Registration Procedures: Require an RFC approved by the IESG

Note: Enumservice specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned.

Registry: Service Name: "H323"

    URI Scheme(s): "h323:"
    Functional Specification:
       See Section "3. The E2U+H323 ENUM Service" of [RFC3762]
    Security considerations:
       see section "5. Security Considerations" of [RFC3762]
    Intended usage: COMMON
    Author: Orit Levin
    [RFC3762]

Service Name: "SIP"

    Type(s): "SIP"
    Subtype(s): N/A
    URI Scheme(s): "sip", "sips:"
    Functional Specification: see Section 4 of [RFC3764]
    Security considerations: see Section 6 of [RFC3764]
    Intended usage: COMMON
    Author: Jon Peterson (jon.peterson&neustar.biz)
    Any other information that the author deems interesting:
       see Section 3 of [RFC3764]
    [RFC3764]

Hoeneisen & Mayrhofer Standards Track [Page 49] RFC 6118 Update Legacy Enumservice Registrations March 2011

Service Name: "ifax"

   Type: "ifax"
   Subtype: "mailto"
   URI Scheme: "mailto"
      The URI Scheme is "mailto" because facsimile is a profile of
      standard Internet mail and uses standard Internet mail
      addressing.
   Functional Specification: see section 1 of [RFC4143]
   Security Considerations: see section 3 of [RFC4143]
   Intended usage: COMMON
   Author: Kiyoshi Toyoda(toyoda.kiyoshi&jp.panasonic.com)
           Dave Crocker(dcrocker&brandenburg.com)
   [RFC4143]

Service Name: "pres"

   URI Scheme(s): "pres:"
   Functional Specification: see Section 4 of [RFC3953]
   Security considerations: see Section 6 of [RFC3953]
   Intended usage: COMMON
   Author: Jon Peterson (jon.peterson&neustar.biz)
   Any other information that the author deems interesting:
      See Section 3 of [RFC3953]
   [RFC3953]

Service Name: "web"

   Type: "web"
   Subtype: "http"
   URI Scheme: 'http:'
   Functional Specification:
      This ENUMservice indicates that the resource identified by the
      associated URI scheme 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 can not be more specific about the kind of information that
      can be expected when contacting the resource.
   Security Considerations:
      See section 5 of [RFC4002].
   Intended Usage: COMMON
   Authors:
      Rudolf Brandner (rudolf.brandner&siemens.com)
      Lawrence Conroy (lwc&roke.co.uk)
      Richard Stastny (richard.stastny&oefeg.at)
   Any other information the author deems interesting:  None
   [RFC4002]

Hoeneisen & Mayrhofer Standards Track [Page 50] RFC 6118 Update Legacy Enumservice Registrations March 2011

Service Name: "web"

   Type: "web"
   Subtype: "https"
   URI Scheme: 'https:'
   Functional Specification:
      This ENUMservice indicates that the resource identified by the
      associated URI scheme is capable of being a source of
      information, which can be contacted by using TLS or 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 kind of information, like audio or
      video or executable code.  Thus, one can not be more specific
      what information to expect when contacting the resource.
   Security Considerations:
      See section 5 of [RFC4002].
   Intended Usage: COMMON
   Authors:
      Rudolf Brandner (rudolf.brandner&siemens.com)
      Lawrence Conroy (lwc&roke.co.uk)
      Richard Stastny (richard.stastny&oefeg.at)
   Any other information the author deems interesting:  None
   [RFC4002]

Service Name: "ft"

   Type: "ft"
   Subtype: "ftp"
   URI Scheme: 'ftp:'
   Functional Specification:
      This ENUMservice indicates that the resource identified by the
      associated URI scheme is a file service from which a file or
      file listing can be retrieved.
   Security Considerations:
      See section 5 of [RFC4002].
   Intended Usage: COMMON
   Authors:
      Rudolf Brandner (rudolf.brandner&siemens.com)
      Lawrence Conroy (lwc&roke.co.uk)
      Richard Stastny (richard.stastny&oefeg.at)
   Any other information the author deems interesting: None
   [RFC4002]

Hoeneisen & Mayrhofer Standards Track [Page 51] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "email"

  Enumservice Type: "email"
  Enumservice Subtype: "mailto"
  URI Scheme: 'mailto:'
  Functional Specification:
     This Enumservice indicates that the remote resource can be
     addressed by the associated URI scheme in order to send an
     email.
  Security Considerations:
     See Section 6 of [RFC4355]
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see [RFC4355])
  Any other information the author deems interesting:
     None

Enumservice Name: "fax"

  Enumservice Type: "fax"
  Enumservice Subtype: "tel"
  URI Scheme: 'tel:'
  Functional Specification:
     This Enumservice indicates that the resource identified by the
     associated URI scheme is capable of being contacted to provide
     a communication session during which facsimile documents can be
     sent.
     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
     [RFC4355]  - in short, they will have a fax
     program with a local or shared PSTN access over which they can
     send faxes.
  Security Considerations:
     See Section 6 of [RFC4355]
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see  [RFC4355])
  Any other information the author deems interesting:
     None

Hoeneisen & Mayrhofer Standards Track [Page 52] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "sms"

  Enumservice Type: "sms"
  Enumservice Subtypes: "tel"
  URI Scheme: 'tel:'
  Functional Specification:
     This Enumservice indicates that the resource identified by the
     associated URI scheme is capable of receiving a message using
     the Short Message Service (SMS) [14] in [RFC4355].
  Security Considerations:
     There are no specific security issues with this Enumservice.
     However, the general considerations of Section 6 apply.
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see [RFC4355])
  Any other information the author deems interesting:
     None

Enumservice Name: "sms"

  Enumservice Type: "sms"
  Enumservice Subtypes: "mailto"
  URI Scheme: 'mailto:'
  Functional Specification:
     This Enumservice indicates that the resource identified by the
     associated URI scheme is capable of receiving a message using
     an email protocol.
     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 (for
     references see [RFC4355]), 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)
     For references see [RFC4355].
  Security Considerations:
     There are no specific security issues with this Enumservice.
     However, the general considerations of Section 6 apply, see
     [RFC4355].
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see [RFC4355])
  Any other information the author deems interesting:
     None

Hoeneisen & Mayrhofer Standards Track [Page 53] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "ems"

  Enumservice Type: "ems"
  Enumservice Subtype: "tel"
  URI Scheme: 'tel:'
  Functional Specification:
     This Enumservice indicates that the resource identified by the
     associated URI scheme is capable of receiving a message using
     the Enhanced Message Service (EMS) [14] (For reference see
     [RFC4355]).
  Security Considerations:
     There are no specific security issues with this Enumservice.
     However, the general considerations of Section 6 apply.
     See [RFC4355]
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see [RFC4355])
  Any other information the author deems interesting:
     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.

Enumservice Name: "ems"

  Enumservice Type: "ems"
  Enumservice Subtypes: "mailto"
  URI Scheme: 'mailto:'
  Functional Specification:
     This Enumservice indicates that the resource identified by the
     associated URI scheme is capable of receiving a message using
     an email protocol.
     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).
     For references see [RFC4355]
  Security Considerations:
     There are no specific security issues with this Enumservice.
     However, the general considerations of Section 6 of [RFC4355]
     apply.
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see [RFC4355])
  Any other information the author deems interesting:
     None

Hoeneisen & Mayrhofer Standards Track [Page 54] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "mms"

  Enumservice Type: "mms"
  Enumservice Subtype: "tel"
  URI Scheme: 'tel:'
  Functional Specification:
     This Enumservice indicates that the resource identified by the
     associated URI scheme is capable of receiving a message using
     the Multimedia Messaging Service (MMS) [15].
     For references see [RFC4355]
  Security Considerations:
     There are no specific security issues with this Enumservice.
     However, the general considerations of Section 6 of [RFC4355]
     apply.
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see [RFC4355])
  Any other information the author deems interesting:
     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.

Enumservice Name: "mms"

  Enumservice Type: "mms"
  Enumservice Subtypes: "mailto"
  URI Scheme: 'mailto:'
  Functional Specification:
     This Enumservice indicates that the resource identified by the
     associated URI scheme is capable of receiving a message using
     an email protocol.
     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.
     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
     specialised headers carried in the SMTP message exchanges.
     The headers used in such MMSE are described in detail in [17].
     For references see [RFC4355]

Hoeneisen & Mayrhofer Standards Track [Page 55] RFC 6118 Update Legacy Enumservice Registrations March 2011

  Security Considerations:
     There are no specific security issues with this Enumservice.
     However, the general considerations of Section 6 of [RFC4355]
     apply.
  Intended Usage: COMMON
  Authors:
     Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author
     contact detail see [RFC4355])
  Any other information the author deems interesting:
     The MMS Architecture describes an interface between the MMSE and
     "legacy messaging systems" (labelled as MM3) which 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.

Service Name: E.164 to VPIM MailTo: URL

  URI Type: "Mailto:"
  Type: VPIM
  Subtype: MAILTO
  Functional Specification: See section 4.2 through 4.4 of [RFC4238]
  Intended Usage: COMMON
  Author: Greg Vaudreuil (gregv&ieee.org)
  Error Conditions:
     o E.164 number not in the numbering plan
     o E.164 number in the numbering plan, but no URLs exist for that
       number
     o E2U+VPIM:Mailto Service unavailable
  Security Considerations:
     o 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 URL.
       The possible intent may be to cause the client to send the
       information to an incorrect destination.
     o Denial of Service
       By removing the URL to which the E.164 maps, a malicious
       intruder may remove the client's ability to access the
       resource.
     o 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.

Hoeneisen & Mayrhofer Standards Track [Page 56] RFC 6118 Update Legacy Enumservice Registrations March 2011

Service Name: E.164 to VPIM LDAP URL

  URI Type: "LDAP:"
  Type: VPIM
  Subtype: LDAP
  Functional Specification: See section 3.2 through 3.3 of [RFC4238]
  Intended Usage: COMMON
  Author: Greg Vaudreuil (gregv&ieee.org)
  Security Considerations:
     o 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 URL.  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.
     o Denial of Service
       By removing the URL to which the E.164 maps, a
       malicious intruder may remove the client's ability to
       access the LDAP directory server.

Enumservice Name: "voice"

  Enumservice Type: "voice"
  Enumservice Subtype: "tel"
  URI Scheme: 'tel:'
  Functional Specification:
     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.
     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.
  Security Considerations:
     See Section 5 of [RFC4415]
  Intended Usage: COMMON
  Authors:  Rudolf Brandner, Lawrence Conroy, Richard Stastny (for
            author contact detail see Authors' Addresses section)
  Any other information the author deems interesting:
   o 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.
   o The kind of subsystem required to initiate a Voice Enumservice
     with this sub-type 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

Hoeneisen & Mayrhofer Standards Track [Page 57] RFC 6118 Update Legacy Enumservice Registrations March 2011

     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.
   o 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.
   o The "tel:" URI value SHOULD be fully qualified (using the
     "global phone number" form of RFC3966 [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.

Enumservice Name: "pstn"

  Enumservice Type: "pstn"
  Enumservice Subtype: "tel"
  URI Scheme: 'tel:'
  Functional Specification:
     These Enumservices indicate that the remote resource identified
     can be addressed by the associated URI scheme 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 RFC 4694 [10].
  Security Considerations: See Section 7 of [RFC4769].
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Richard Shockey (richard.shockey&neustar.biz)
  Any other information the author deems interesting:
     A Number Portability Dip Indicator (npdi) should be used in
     practice (see examples below in Section 4 of [RFC4769]).

Hoeneisen & Mayrhofer Standards Track [Page 58] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "pstn"

  Enumservice Type: "pstn"
  Enumservice Subtype: "sip"
  URI Scheme: 'sip:'
  Functional Specification:
     These Enumservices indicate that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a telecommunication session, which may include two-way
     voice or other communications, to the PSTN.
  Security Considerations: See Section 7 of [RFC4769].
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Richard Shockey (richard.shockey&neustar.biz)
  Any other information the author deems interesting:
     A Number Portability Dip Indicator (npdi) should be used in
     practice (see examples below in Section 4 of [RFC4769]).

Enumservice Name: "vCard"

  Enumservice Name: "vCard"
  Enumservice Type: "vcard"
  Enumservice Subtype: n/a
  URI Schemes: "http", "https"
  Functional Specification:
     This Enumservice indicates that the resource identified is a
     plain vCard, according to RFC 2426, which may be accessed using
     HTTP/ HTTPS [7].
     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.
  Security Considerations: see Section 5 [RFC4969]
  Intended Usage: COMMON
  Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at>

Enumservice Name: "XMPP"

  Enumservice Type: "xmpp"
  Enumservice Subtype: n/a
  URI Schemes: "xmpp"
  Functional Specification:
     This Enumservice indicates that the resource identified is an
     XMPP entity.
  Security Considerations: see Section 6 of [RFC4979]
  Intended Usage: COMMON
  Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at>

Hoeneisen & Mayrhofer Standards Track [Page 59] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "im"

  Enumservice Type: "im"
  Enumservice Subtypes: N/A
  URI scheme(s): "im:"
  Functional Specification:
     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.
  Security considerations: See section 3 of [RFC5028]
  Intended usage: COMMON
  Author: Rohan Mahy (rohan&ekabal.com)

Enumservice Name: "voicemsg"

  Enumservice Type: "voicemsg"
  Enumservice Subtypes: "sip"
  URI Schemes: 'sip:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a voice communication session to a voice messaging
     system.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "voicemsg"

  Enumservice Type: "voicemsg"
  Enumservice Subtypes: "sips"
  URI Schemes: 'sips:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a voice communication session to a voice messaging
     system.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)

Hoeneisen & Mayrhofer Standards Track [Page 60] RFC 6118 Update Legacy Enumservice Registrations March 2011

  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "voicemsg"

  Enumservice Type: "voicemsg"
  Enumservice Subtype: "tel"
  URI Schemes: 'tel:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a voice communication session to a voice messaging
     system.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "voicemsg"

  Enumservice Type: "voicemsg"
  Enumservice Subtype: "http"
  URI Schemes: 'http:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     by the associated URI scheme is capable of being a source of
     information.
     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.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Hoeneisen & Mayrhofer Standards Track [Page 61] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "voicemsg"

  Enumservice Type: "voicemsg"
  Enumservice Subtype: "https"
  URI Schemes: 'https:'
  Functional Specification:
     This Enumservice indicates that the remote 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.
     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.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "videomsg"

  Enumservice Type: "videomsg"
  Enumservice Subtypes: "sip"
  URI Schemes: 'sip:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a video communication session to a video messaging
     system.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Hoeneisen & Mayrhofer Standards Track [Page 62] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "videomsg"

  Enumservice Type: "videomsg"
  Enumservice Subtypes: "sips"
  URI Schemes: 'sips:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a video communication session to a video messaging
     system.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "videomsg"

  Enumservice Type: "videomsg"
  Enumservice Subtype: "http"
  URI Schemes: 'http:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     by the associated URI scheme is capable of being a source of
     information.
     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.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Hoeneisen & Mayrhofer Standards Track [Page 63] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "videomsg"

  Enumservice Type: "videomsg"
  Enumservice Subtype: "https"
  URI Schemes: 'https:'
  Functional Specification:
     This Enumservice indicates that the remote 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.
     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.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "unifmsg"

  Enumservice Type: "unifmsg"
  Enumservice Subtypes: "sip"
  URI Schemes: 'sip:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a unified communication session to a unified messaging
     system.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Hoeneisen & Mayrhofer Standards Track [Page 64] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "unifmsg"

  Enumservice Type: "unifmsg"
  Enumservice Subtypes: "sips"
  URI Schemes: 'sips:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     can be addressed by the associated URI scheme in order to
     initiate a unified communication session to a unified messaging
     system.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "unifmsg"

  Enumservice Type: "unifmsg"
  Enumservice Subtype: "http"
  URI Schemes: 'http:'
  Functional Specification:
     This Enumservice indicates that the remote resource identified
     by the associated URI scheme is capable of being a source of
     information.
     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.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Hoeneisen & Mayrhofer Standards Track [Page 65] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "unifmsg"

  Enumservice Type: "unifmsg"
  Enumservice Subtype: "https"
  URI Schemes: 'https:'
  Functional Specification:
     This Enumservice indicates that the remote 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.
     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.
  Security Considerations: See Section 3 of [RFC5278]
  Intended Usage: COMMON
  Authors:
     Jason Livingood (jason_livingood&cable.comcast.com)
     Don Troshynski (dtroshynski&acmepacket.com)
  Any other information the author deems interesting:
     Implementers should review a non-exclusive list of examples
     below in Section 7 of [RFC5278]

Enumservice Name: "ical-sched"

  Enumservice Type: "ical-sched"
  Enumservice Subtypes: "mailto"
  URI scheme(s): 'mailto:'
  Functional Specification:
     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.
  Security considerations: See Section 4 of [RFC5333].
  Intended usage: COMMON
  Author:
     Rohan Mahy (rohan&ekabal.com)

Hoeneisen & Mayrhofer Standards Track [Page 66] RFC 6118 Update Legacy Enumservice Registrations March 2011

Enumservice Name: "ical-access"

  Enumservice Type: "ical-access"
  Enumservice Subtypes: "http"
  URI scheme(s): 'http:'
  Functional Specification:
     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.
  Security considerations: See Section 4 of [RFC5333].
  Intended usage: COMMON
  Author:
     Rohan Mahy (rohan&ekabal.com)

Enumservice Name: "ical-access"

  Enumservice Type: "ical-access"
  Enumservice Subtypes: "https"
  URI scheme(s): 'https:'
  Functional Specification:
     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.
  Security considerations: See Section 4 of [RFC5333].
  Intended usage: COMMON
  Author:
     Rohan Mahy (rohan&ekabal.com)

Hoeneisen & Mayrhofer Standards Track [Page 67] RFC 6118 Update Legacy Enumservice Registrations March 2011

Authors' Addresses

 Bernie Hoeneisen
 Ucom Standards Track Solutions GmbH
 CH-8000 Zuerich
 Switzerland
 Phone: +41 44 500 52 44
 EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
 URI:   http://www.ucom.ch/
 Alexander Mayrhofer
 enum.at GmbH
 Karlsplatz 1/9
 Wien  A-1010
 Austria
 Phone: +43 1 5056416 34
 EMail: alexander.mayrhofer@enum.at
 URI:   http://www.enum.at/

Hoeneisen & Mayrhofer Standards Track [Page 68]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6118.txt · Last modified: 2011/03/12 01:37 (external edit)