[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hoeneisen-enum-enumservices-transition) 00 01 02 03 04 05 06 RFC 6118

ENUM -- Telephone Number Mapping                            B. Hoeneisen
Working Group                                                   Swisscom
Internet-Draft                                              A. Mayrhofer
Updates: 3762, 3764, 3953, 4143,                                 enum.at
4002, 4238, 4355, 4415, 4769,                               Sep 16, 2009
4969, 4979, 5028, 5278, 5333
(if approved)
Intended status: BCP
Expires: March 20, 2010


          Update of legacy IANA Registrations of Enumservices
               draft-ietf-enum-enumservices-transition-03

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  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.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 20, 2010.

Copyright Notice



Hoeneisen & Mayrhofer    Expires March 20, 2010                 [Page 1]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

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


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



Hoeneisen & Mayrhofer    Expires March 20, 2010                 [Page 2]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


     4.24. vcard  . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     4.25. videomsg:http  . . . . . . . . . . . . . . . . . . . . . . 31
     4.26. videomsg:https . . . . . . . . . . . . . . . . . . . . . . 32
     4.27. videomsg:sip . . . . . . . . . . . . . . . . . . . . . . . 33
     4.28. videomsg:sips  . . . . . . . . . . . . . . . . . . . . . . 34
     4.29. voice:tel  . . . . . . . . . . . . . . . . . . . . . . . . 35
     4.30. voicemsg:http  . . . . . . . . . . . . . . . . . . . . . . 37
     4.31. voicemsg:https . . . . . . . . . . . . . . . . . . . . . . 38
     4.32. voicemsg:sip . . . . . . . . . . . . . . . . . . . . . . . 39
     4.33. voicemsg:sips  . . . . . . . . . . . . . . . . . . . . . . 40
     4.34. voicemsg:tel . . . . . . . . . . . . . . . . . . . . . . . 41
     4.35. vpim:ldap  . . . . . . . . . . . . . . . . . . . . . . . . 42
     4.36. vpim:mailto  . . . . . . . . . . . . . . . . . . . . . . . 43
     4.37. web:http . . . . . . . . . . . . . . . . . . . . . . . . . 45
     4.38. web:https  . . . . . . . . . . . . . . . . . . . . . . . . 46
     4.39. xmpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 47

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 47

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47

   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 48

   Appendix A.  Former Content of the IANA Repository . . . . . . . . 49

   Appendix B.  Document Changelog  . . . . . . . . . . . . . . . . . 66

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68





















Hoeneisen & Mayrhofer    Expires March 20, 2010                 [Page 3]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


1.  Introduction

   [I-D.ietf-enum-enumservices-guide] 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 [I-D.ietf-enum-enumservices-guide].  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 does only add the missing elements to the XML
   chunks as specified in the IANA Considerations section of
   [I-D.ietf-enum-enumservices-guide], but does not complete the
   (nowadays) missing sections of the corresponding Enumservice
   Specifications.  In order to conform with the new registration regime
   as specified in [I-D.ietf-enum-enumservices-guide], 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  [I-D.ietf-enum-calendar-service]


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    Expires March 20, 2010                 [Page 4]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


3.  IESG Action

   According to [RFC3761], any Enumservice registration had to be
   published as RFC on the Standards Track, Experimental RFC, or as a
   BCP.  [I-D.ietf-enum-enumservices-guide] no longer has this
   requirement, i.e.  "Expert Review" and "Specification Required" are
   sufficient.  As any update to an existing specification must have at
   least the same Maturity Level (see [RFC2026]) as the document it
   updates, an IETF action (approval of this document) is required to
   override this requirement.

   This document changes the approval required for updates of
   Enumservice registrations to Specification Required including that
   the specification and request are reviewed by a Designated Expert as
   described in [I-D.ietf-enum-enumservices-guide].


4.  Legacy Enumservice Registrations Converted to XML Chunks

   In the following the legacy Enumservice Registrations converted to
   XML chunks including the new elements introduced by
   [I-D.ietf-enum-enumservices-guide]:


      [Note for RFC Editor: Please replace any instance of RFCTHIS with
      the RFC number of this document before publication]

























Hoeneisen & Mayrhofer    Expires March 20, 2010                 [Page 5]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>






















Hoeneisen & Mayrhofer    Expires March 20, 2010                 [Page 6]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
           For references see <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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>







Hoeneisen & Mayrhofer    Expires March 20, 2010                 [Page 7]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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] (For reference see
           <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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                 [Page 8]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4355"/>, Section 6.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4355"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>










Hoeneisen & Mayrhofer    Expires March 20, 2010                 [Page 9]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>





















Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 10]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Orit_Levin"/>
       </requesters>
     </record>




























Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 11]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


4.7.  ical-access:http

    <record>
      <!-- ical-access:http -->
      <class>Data Type-Based</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>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5333"/>, Section 4.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5333"/> (updated by RFCTHIS)
        <xref type="rfc" data="rfcTHIS"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rohan_Mahy"/>
      </requesters>
    </record>























Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 12]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


4.8.  ical-access:https

    <record>
      <!-- ical-access:https -->
      <class>Data Type-Based</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>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5333"/>, Section 4.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5333"/> (updated by RFCTHIS)
        <xref type="rfc" data="rfcTHIS"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rohan_Mahy"/>
      </requesters>
    </record>























Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 13]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


4.9.  ical-sched:mailto

    <record>
      <!-- ical-sched:mailto -->
      <class>Data Type-Based</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>
      </functionalspec>
      <security>
        See <xref type="rfc" data="rfc5333"/>, Section 4.
      </security>
      <usage>COMMON</usage>
      <registrationdocs>
        <xref type="rfc" data="rfc5333"/> (updated by RFCTHIS)
        <xref type="rfc" data="rfcTHIS"/>
      </registrationdocs>
      <requesters>
        <xref type="person" data="Rohan_Mahy"/>
      </requesters>
    </record>























Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 14]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 15]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFC3861 [4] is
           used to discover whether an IM protocol supported by
           the party querying ENUM is also supported by the
           target resource.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5028"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5028"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rohan_Mahy"/>
       </requesters>
     </record>



















Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 16]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
           For references see <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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 17]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


         <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) 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.
         </paragraph>
       </additionalinfo>
     </record>






























Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 18]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
           For references see <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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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 de 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    Expires March 20, 2010                [Page 19]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


           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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jon_Peterson"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           See <xref type="rfc" data="rfc3953"/>, Section 3.
         </paragraph>
       </additionalinfo>
     </record>












Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 20]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 21]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4769"/>, Section 7.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4769"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 22]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


4.17.  sip

     <record>
       <!-- sip -->
       <class>Protocol-Based</class>
       <type>sip</type>
       <!-- No subtype -->
       <urischeme>sip, 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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Jon_Peterson"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           See <xref type="rfc" data="rfc3764"/>, Section 3.
         </paragraph>
       </additionalinfo>
     </record>























Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 23]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
           For references see <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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>







Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 24]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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] 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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>

















Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 25]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 26]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 27]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 28]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 29]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


4.24.  vcard

     <record>
       <!-- vcard -->
       <class>Data Type-Based</class>
       <type>vcard</type>
       <!-- No subtype -->
       <urischeme>http, 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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4969"/>, Section 5.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4969"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Alexander_Mayrhofer"/>
       </requesters>
     </record>

















Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 30]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 31]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 32]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 33]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 34]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 35]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


           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 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.
         </paragraph>
       </additionalinfo>
     </record>



















Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 36]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 37]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc5278"/>, Section 3.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc5278"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 38]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 39]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 40]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </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    Expires March 20, 2010                [Page 41]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


4.35.  vpim:ldap

     <record>
       <!-- vpim:ldap -->
       <class>Application-Based, Common</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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Greg_Vaudreuil"/>
       </requesters>
     </record>












Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 42]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


4.36.  vpim:mailto

     <record>
       <!-- vpim:mailto -->
       <class>Application-Based, Common</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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Greg_Vaudreuil"/>
       </requesters>
       <additionalinfo>
         <paragraph>
           Error Conditions:
         </paragraph>
         <paragraph>



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 43]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


           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    Expires March 20, 2010                [Page 44]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 can not 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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>














Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 45]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 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.
         </paragraph>
       </functionalspec>
       <security>
         See <xref type="rfc" data="rfc4002"/>, Section 5.
       </security>
       <usage>COMMON</usage>
       <registrationdocs>
         <xref type="rfc" data="rfc4002"/> (updated by RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Rudolf_Brandner"/>
         <xref type="person" data="Lawrence_Conroy"/>
         <xref type="person" data="Richard_Stastny"/>
       </requesters>
     </record>













Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 46]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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 RFCTHIS)
         <xref type="rfc" data="rfcTHIS"/>
       </registrationdocs>
       <requesters>
         <xref type="person" data="Alexander_Mayrhofer"/>
       </requesters>
     </record>


5.  IANA Considerations

   IANA are to replace 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: Alfred Hoenes, and Scott Bradner





Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 47]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


8.  Normative References

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

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

   [I-D.ietf-enum-enumservices-guide]
              Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
              Registration of Enumservices: Guide, Template and IANA
              Considerations", draft-ietf-enum-enumservices-guide-17
              (work in progress), August 2009.

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

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

   [RFC4002]  Brandner, R., Conroy, L., and R. Stastny, "IANA
              Registration for Enumservice 'web' and 'ft'", RFC 4002,
              February 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



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 48]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


              Enumservice Containing Public Switched Telephone Network
              (PSTN) Signaling Information", RFC 4769, November 2006.

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

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

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

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

   [I-D.ietf-enum-calendar-service]
              Mahy, R., "A Telephone Number Mapping (ENUM) Service
              Registration for Internet  Calendaring Services",
              draft-ietf-enum-calendar-service-04 (work in progress),
              March 2008.


Appendix A.  Former Content of the IANA Repository


Enumservice Registrations

(last updated 2009-09-15)

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:



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 49]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


        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]

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:



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 50]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


       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]

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:



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 51]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


       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]

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



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 52]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   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: "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])



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 53]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   Any other information the author deems interesting:
      None

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:



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 54]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


      None

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.



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 55]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


      The headers used in such MMSE are described in detail in [17].
      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:
      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



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 56]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


        of email addresses where only the telephone number was
        previously known.

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



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 57]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


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

Enumservice Name: "pstn"
   Enumservice Type: "pstn"
   Enumservice Subtype: "sip"
   URI Scheme: 'sip:'
   Functional Specification:
      These Enumservices indicate that the remote resource identified



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 58]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


      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>

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



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 59]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


      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)
   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:'



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 60]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   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]

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.



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 61]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


      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]

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:



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 62]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


      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]

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)



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 63]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   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]

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.



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 64]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


      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]

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.



Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 65]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   Security considerations: See Section 4 of
      [RFC-ietf-enum-calendar-service-04].
   Intended usage: COMMON
   Author:
      Rohan Mahy (rohan&ekabal.com)

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
      [RFC-ietf-enum-calendar-service-04].
   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
      [RFC-ietf-enum-calendar-service-04].
   Intended usage: COMMON
   Author:
      Rohan Mahy (rohan&ekabal.com)



Appendix B.  Document Changelog

   [RFC Editor: This section is to be removed before publication]

   draft-ietf-enum-enumservices-transition-03:
   o  bernie: Added fixed calendaring Enumservices (RFC 5333)
   o  bernie: Updated my author's address
   o  bernie: made own sub-section for each registration





Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 66]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   o  bernie: Split XML Chunk section and IANA Considerations section
   o  bernie: other editorial changes, e.g. existing -> legacy

   draft-ietf-enum-enumservices-transition-02:
   o  bernie: Temporarily removed calendaring Enumservices (will be
      added again, once these are fixed)
   o  bernie: added current state of IANA repository

   draft-ietf-enum-enumservices-transition-01:
   o  bernie: Added 13 new Enumservices (RFC 5278)
   o  bernie: Updated 'Open Issues' section
   o  bernie: Updated ipr attribute to 'pre5378Trust200902' according to
      http://www.ietf.org/mail-archive/web/syslog/current/msg02333.html
   o  alex: Added missing classifications
   o  alex: Editorial improvements
   o  bernie: More editorials
   o  bernie: Changed status to bcp, to avoid downref problem with
      enumservice-guide
   o  bernie: Rewrite of IESG Action

   draft-ietf-enum-enumservices-transition-00:
   o  bernie: Updated affiliation: Switch -> Swisscom
   o  bernie: Revised all Enumservices to the form of XML chunks
   o  bernie: Added statement for IESG Actions to downgrade existing all
      Enumservice specifications
   o  bernie: Updated 'Open Issues' section

   draft-hoeneisen-enum-enumservices-transition-01:
   o  bernie: Fixed wrong reference

   draft-hoeneisen-enum-enumservices-transition-01:
   o  bernie: integrated feedback from Alfred Hoenes
      *  Typos / corrections
      *  Removed the words "remote" and "scheme" in existing
         registrations
      *  changed "URL" to "URI" in existing registrations
      *  changed "headers" to "header fields" in existing "mms:mailto"
         registration
   o  bernie: Added Acknowledgments section

   draft-hoeneisen-enum-enumservices-transition-00:
   o  bernie: Initial version
   o  bernie: Imported and adjusted existing IANA Enumservice
      registrations
   o  bernie: Removed Name and added Class fields
   o  bernie: Put caption to each Enumservice





Hoeneisen & Mayrhofer    Expires March 20, 2010                [Page 67]

Internet-Draft   Update legacy Enumservice Registrations        Sep 2009


   o  bernie: Sorted alphabetically
   o  bernie: All URI Schemes without colon
   o  alex: Added classification


Authors' Addresses

   Bernie Hoeneisen
   Swisscom
   CH-8000 Zuerich
   Switzerland

   Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT swisscom.com)
   URI:   http://www.swisscom.com/


   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    Expires March 20, 2010                [Page 68]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/