ENUM -- Telephone Number Mapping B. Hoeneisen Working Group SWITCH Internet-Draft A. Mayrhofer Updates: 3762, 3764, 3953, 4143, enum.at 4002, 4238, 4355, 4415, 4769, May 20, 2008 4969, 4979, 5028 (if approved) Intended status: Standards Track Expires: November 21, 2008 Update of legacy IANA Registrations of Enumservices draft-hoeneisen-enum-enumservices-transition-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 21, 2008. Abstract This document specifies a revision of all Enumservices that have been registered at IANA under the nowadays obsolete regime of [RFC3761]. It mainly adds the new fields to the IANA Registration Template as specified in [I-D.ietf-enum-enumservices-guide], and makes at the same time some corrections of editorial nature. Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 1]
Internet-Draft Update legacy Enumservice Registrations May 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 3.1. Enumservice Registrations . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Former Content of the IANA Repository . . . . . . . . 19 Appendix B. Document Changelog . . . . . . . . . . . . . . . . . 19 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 2]
Internet-Draft Update legacy Enumservice Registrations May 2008 1. Introduction [I-D.ietf-enum-enumservices-guide] has obsoleted the IANA registration section of [RFC3761]. In the IANA registry for Enumservices, there are several entries that had been made under RFC 3761 regime. Those do not conform to the new guidelines as specified in [I-D.ietf-enum-enumservices-guide]. To ensure consistency among the Enumservice registrations, the document adds the new fields to the existing IANA registrations and makes some editorial corrections at the same time. However, this document does only add the missing fields from the IANA Registration Template as specified in the IANA Considerations of [I-D.ietf-enum-enumservices-guide], but does not complete the (nowadays) missing sections of the corresponding Registration Documents. These documents have to be revised in order to conform with the new regime for Enumservice registrations as specified in [I-D.ietf-enum-enumservices-guide]. This document updates the following RFCs: 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 [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]. 3. IANA Considerations Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 3]
Internet-Draft Update legacy Enumservice Registrations May 2008 3.1. Enumservice Registrations IANA replaces the existing Enumservice Registrations by the following: [Note for RFC Editor: Please replace any instance of RFCTHIS with the RFC number of this document before publication] Assigned Enumservice Values --------------------------- email:mailto o Enumservice Class: Application-based, Common o Enumservice Type: "email" o Enumservice Subtype: "mailto" o URI Scheme(s): 'mailto' o Functional Specification: * This Enumservice indicates that the resource can be addressed by the associated URI in order to send an email. o Security Considerations: See Section 6 of [RFC4355] o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A ems:mailto o Enumservice Class: Application-based, Common o Enumservice Type: "ems" o Enumservice Subtype: "mailto" o URI Scheme(s): 'mailto' o Functional Specification: * This Enumservice indicates that the resource identified by the associated URI 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]. Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 4]
Internet-Draft Update legacy Enumservice Registrations May 2008 o Security Considerations: * There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of [RFC4355] apply. o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A ems:tel o Enumservice Class: Application-based, Common o Enumservice Type: "ems" o Enumservice Subtype: "tel" o URI Scheme(s): 'tel' o Functional Specification: * 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 [RFC4355]). o Security Considerations: * There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of [RFC4355] apply. o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: * 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. fax:tel o Enumservice Class: Application-based, Subset o Enumservice Type: "fax" o Enumservice Subtype: "tel" o URI Scheme(s): 'tel' o Functional Specification: * 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 Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 5]
Internet-Draft Update legacy Enumservice Registrations May 2008 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. o Security Considerations: See Section 6 of [RFC4355] o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A ft:ftp o Enumservice Class: Application-based, Subset o Enumservice Type: "ft" o Enumservice Subtype: "ftp" o URI Scheme(s): 'ftp' o Functional Specification: * 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. o Security Considerations: See Section 5 of [RFC4002] o Intended Usage: COMMON o Registration Document(s): * [RFC4002] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A h323 o Enumservice Class: Protocol-based o Enumservice Type: "h323" o Enumservice Subtype: N/A o URI Scheme(s): 'h323' o Functional Specification: See Section 3 of [RFC3762] o Security Considerations: See section 5 of [RFC3762] o Intended Usage: COMMON o Registration Document(s): * [RFC3762] (Updated by RFCTHIS) * [RFCTHIS] Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 6]
Internet-Draft Update legacy Enumservice Registrations May 2008 o Author(s): Orit Levin o Further Information: N/A ical:access o Enumservice Class: Data- / Format-based o Enumservice Type: "ical" o Enumservice Subtype: "access" o URI Scheme(s): 'http', 'https' o Functional Specification: * This Enumservice indicates that the resource identified is a URI used for Internet Calendaring which is available to access a user's calendar (for example free/busy status). Supported URI Schemes are 'http:' or 'https:' URIs for the CalDAV [7] protocol. o Security Considerations: See Section 3 of [RFC-ietf-enum-calendar- service-04.txt] o Intended Usage: COMMON o Registration Document(s): * [RFC-ietf-enum-calendar-service-04.txt] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Author: Rohan Mahy o Further Information: N/A ical:sched o Enumservice Class: Data- / Format-based o Enumservice Type: "ical" o Enumservice Subtype: "sched" o URI Scheme(s): 'mailto', 'http', 'https' o Functional Specification: * This Enumservice indicates that the resource identified is a URI used for scheduling using Internet Calendaring. Supported URI Schemes are the 'mailto:' URI for the iMIP [6] protocol, and 'http:' or 'https:' URIs for a planned scheduling extension [15] to the CalDAV [7] protocol. o Security Considerations: See Section 3 of [RFC-ietf-enum-calendar- service-04.txt] o Intended Usage: COMMON o Registration Document(s): * [RFC-ietf-enum-calendar-service-04.txt] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rohan Mahy o Further Information: N/A Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 7]
Internet-Draft Update legacy Enumservice Registrations May 2008 ifax:mailto o Enumservice Class: Application-based, Subset o Enumservice Type: "ifax" o Enumservice Subtype: "mailto" o URI Scheme(s): 'mailto' o Functional Specification: See Section 1 of [RFC4143] o Security Considerations: See Section 3 of [RFC4143] o Intended Usage: COMMON o Registration Document(s): * [RFC3413] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Kiyoshi Toyoda, Dave Crocker o Further Information: * The URI Scheme is "mailto" because facsimile is a profile of standard Internet mail and uses standard Internet mail addressing. im o Enumservice Class: Application-based, Common o Enumservice Type: "im" o Enumservice Subtype: N/A o URI Scheme(s): 'im' o Functional Specification: * This Enumservice indicates that the resource identified is an 'im:' URI. The 'im:' URI scheme does not identify any particular protocol that will be used to handle instant messaging receipt or delivery, rather the mechanism in RFC3861 [4] is used to discover whether an IM protocol supported by the party querying ENUM is also supported by the target resource. o Security Considerations: See Section 3 of [RFC5028] o Intended Usage: COMMON o Registration Document(s): * [RFC5028] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rohan Mahy o Further Information: N/A mms:mailto o Enumservice Class: Application-based, Common o Enumservice Type: "mms" o Enumservice Subtype: "mailto" Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 8]
Internet-Draft Update legacy Enumservice Registrations May 2008 o URI Scheme(s): 'mailto' o Functional Specification: * This Enumservice indicates that the resource identified by the associated URI 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 specialized header fields carried in the SMTP message exchanges. The header fields used in such MMSE are described in detail in [17]. * For references see [RFC4355] o Security Considerations: * There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of [RFC4355] apply. o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: * 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. mms:tel o Enumservice Class: Application-based, Common o Enumservice Type: "mms" o Enumservice Subtype: "tel" o URI Scheme(s): 'tel' o Functional Specification: Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 9]
Internet-Draft Update legacy Enumservice Registrations May 2008 * This Enumservice indicates that the resource identified by the associated URI is capable of receiving a message using the Multimedia Messaging Service (MMS) [15]. * For references see [RFC4355]. o Security Considerations: * There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of [RFC4355] apply. * For references see [RFC4355]. o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: * 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 be tariff differences in using the MMS rather than using the SMS or EMS. pres o Enumservice Class: Application-based, Common o Enumservice Type: "pres" o Enumservice Subtype: N/A o URI Scheme(s): 'pres' o Functional Specification: See Section 4 of [RFC3953] o Security Considerations: See Section 6 of [RFC3953] o Intended Usage: COMMON o Registration Document(s): * [RFC3953] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Jon Peterson o Further Information: See Section 3 of [RFC3953] pstn:sip o Enumservice Class: Application-based, Subset (??) Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 10]
Internet-Draft Update legacy Enumservice Registrations May 2008 o Enumservice Type: "pstn" o Enumservice Subtype: "sip" o URI Scheme(s): 'sip' o Functional Specification: * 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. o Security Considerations: See Section 7 of [RFC4769] o Intended Usage: COMMON o Registration Document(s): * [RFC4769] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Jason Livingood, Richard Shockey o Further Information: * A Number Portability Dip Indicator (npdi) should be used in practice (see examples below in Section 4 of [RFC4769]). pstn:tel o Enumservice Class: Application-based, Ancillary o Enumservice Type: "pstn" o Enumservice Subtype: "tel" o URI Scheme(s): 'tel' o Functional Specification: * 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]. o Security Considerations: See Section 7 of [RFC4769] o Intended Usage: COMMON o Registration Document(s): * [RFC4769] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Jason Livingood, Richard Shockey o Further Information: * A Number Portability Dip Indicator (npdi) should be used in practice (see examples below in Section 4 of [RFC4769]). sip o Enumservice Class: Protocol-based o Enumservice Type: "sip" Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 11]
Internet-Draft Update legacy Enumservice Registrations May 2008 o Enumservice Subtype: N/A o URI Scheme(s): 'sip', 'sips' o Functional Specification: See Section 4 of [RFC3764] o Security Considerations: See Section 6 of [RFC3764] o Intended Usage: COMMON o Registration Document(s): * [RFC3764] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Jon Peterson o Further Information: See Section 3 of [RFC3764] sms:mailto o Enumservice Class: Application-based, Common o Enumservice Type: "sms" o Enumservice Subtype: "mailto" o URI Scheme(s): 'mailto' o Functional Specification: * This Enumservice indicates that the resource identified by the associated URI 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, 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]. o Security Considerations: * There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of [RFC4355] apply. o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A sms:tel o Enumservice Class: Application-based, Common o Enumservice Type: "sms" o Enumservice Subtype: "tel" o URI Scheme(s): 'tel' Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 12]
Internet-Draft Update legacy Enumservice Registrations May 2008 o Functional Specification: * 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 [RFC4355]. o Security Considerations: * There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of [RFC4355] apply. o Intended Usage: COMMON o Registration Document(s): * [RFC4355] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A vcard o Enumservice Class: Data- / Format-based o Enumservice Type: "vcard" o Enumservice Subtype: N/A o URI Scheme(s): 'http', 'https' o Functional Specification: * This Enumservice indicates that the resource identified is a plain vCard, according to RFC2426, 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. o Security Considerations: See Section 5 [RFC4969] o Intended Usage: COMMON o Registration Document(s): * [RFC4969] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Alexander Mayrhofer o Further Information: voice:tel o Enumservice Class: Application-based, Common o Enumservice Type: "voice" o Enumservice Subtype: "tel" o URI Scheme(s): 'tel' o Functional Specification: Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 13]
Internet-Draft Update legacy Enumservice Registrations May 2008 * 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. o Security Considerations: See Section 5 of [RFC4415] o Intended Usage: COMMON o Registration Document(s): * [RFC4415] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: * 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. * The kind of subsystem required to initiate a Voice Enumservice with this Subtype is a "Dialler". This is a subsystem that either provides a local connection to the PSTN or PLMN, or that provides an indirect connection to those networks. The subsystem will use the telephone number held in the generated URI to place a voice call. The voice call is placed to a network that uses E.164 numbers to route calls to an appropriate destination. * 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. * 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. vpim:ldap Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 14]
Internet-Draft Update legacy Enumservice Registrations May 2008 o Enumservice Class: Application-based, Common (??) o Enumservice Type: "vpim" o Enumservice Subtype: "ldap" o URI Scheme(s): 'ldap' o Functional Specification: See Sections 3.2 - 3.3 of [RFC4238] o Security Considerations: * 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. * 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. o Intended Usage: COMMON o Registration Document(s): * [RFC4238] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Greg Vaudreuil o Further Information: N/A vpim:mailto o Enumservice Class: Application-based, Common o Enumservice Type: "vpim" o Enumservice Subtype: "mailto" o URI Scheme(s): 'mailto' o Functional Specification: See Sections 4.2 - 4.4 of [RFC4238] o Security Considerations: * 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. * 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. * Unsolicited Bulk Email: The exposure of email addresses through the ENUM service provides a bulk mailer access to large numbers of email addresses where only the telephone number was previously known. Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 15]
Internet-Draft Update legacy Enumservice Registrations May 2008 o Intended Usage: COMMON o Registration Document(s): * [RFC4238] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Greg Vaudreuil o Further Information: * Error Conditions: + E.164 number not in the numbering plan + E.164 number in the numbering plan, but no URIs exist for that number + E2U+vpim:mailto Service unavailable of email addresses where only the telephone number was previously known. web:http o Enumservice Class: Application-based, Common o Enumservice Type: "web" o Enumservice Subtype: "http" o URI Scheme(s): 'http' o Functional Specification: * 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. o Security Considerations: See Section 5 of [RFC4002] o Intended Usage: COMMON o Registration Document(s): * [RFC4002] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A web:https o Enumservice Class: Application-based, Common o Enumservice Type: "web" o Enumservice Subtype: "https" o URI Scheme(s): 'https' o Functional Specification: Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 16]
Internet-Draft Update legacy Enumservice Registrations May 2008 * 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. o Security Considerations: See Section 5 of [RFC4002] o Intended Usage: COMMON o Registration Document(s): * [RFC4002] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Rudolf Brandner, Lawrence Conroy, Richard Stastny o Further Information: N/A xmpp o Enumservice Class: Protocol-based o Enumservice Type: "xmpp" o Enumservice Subtype: N/A o URI Scheme(s): 'xmpp' o Functional Specification: * This Enumservice indicates that the resource identified is an XMPP entity. o Security Considerations: See Section 6 of [RFC4979] o Intended Usage: COMMON o Registration Document(s): * [RFC4979] (Updated by RFCTHIS) * [RFCTHIS] o Author(s): Alexander Mayrhofer o Further Information: N/A 4. Security Considerations Since this document does not introduce any technology or protocol, there are no security issues to be considered for this document itself. 5. Acknowledgements The authors would like to thank Alfred Hoenes for his prompt feedback to this document. Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 17]
Internet-Draft Update legacy Enumservice Registrations May 2008 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [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-10 (work in progress), May 2008. [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 Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information", RFC 4769, November 2006. Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 18]
Internet-Draft Update legacy Enumservice Registrations May 2008 [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. [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 Todo: Copy-Paste from existing IANA Repository Appendix B. Document Changelog [RFC Editor: This section is to be removed before publication] draft-hoeneisen-enum-enumservices-transition-00: 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 Acknowledgements 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 o bernie: Sorted alphabetically o bernie: All URI Schemes without colon o alex: Added classification Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 19]
Internet-Draft Update legacy Enumservice Registrations May 2008 Appendix C. Open Issues [RFC Editor: This section should be empty before publication] o How can these Enumservices be changed in future? o Authors of Enumservices to review the changes o Maybe get rid of quotes in Type, Subtype and URI Scheme o Maybe change presentation of prose parts (quotes, colons) Authors' Addresses Bernie Hoeneisen SWITCH Werdstrasse 2 CH-8004 Zuerich Switzerland Phone: +41 44 268 1515 Email: bernhard.hoeneisen@switch.ch, bernie@ietf.hoeneisen.ch URI: http://www.switch.ch/ Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria Phone: +43 1 5056416 34 Email: alexander.mayrhofer@enum.at URI: http://www.enum.at/ Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 20]
Internet-Draft Update legacy Enumservice Registrations May 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Hoeneisen & Mayrhofer Expires November 21, 2008 [Page 21]