"ENUM Implementation Issues and Experiences", Lawrence Conroy, Kazunori Fujiwara, 14-Feb-08. ( bytes)
This document captures experience in implementing systems based on the ENUM protocol, and experience of ENUM data that have been created by others. As such, it clarifies the ENUM and DDDS standards. Its aim is to help others by reporting what is "out there" and the potential pitfalls in interpreting the set of documents that specify the protocol.
"IANA Registration of Enumservices: Guide, Template and IANA Considerations", Bernie Hoeneisen, Alexander Mayrhofer, Jason Livingood, 8-May-08. ( bytes)
This document specifies a revision of the IANA registry for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservices and its Registration Documents.
"A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services", Rohan Mahy, 10-Mar-08. ( bytes)
This document registers a Telephone Number Mapping (ENUM) service for Internet Calendaring Services. Specifically, this document focuses on provisioning 'mailto:' (iMIP) and 'http:' (CalDAV) URIs in ENUM.
"The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM", Jason Livingood, 3-Dec-07. ( bytes)
This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa" as defined in RFC3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees).
"IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata' URI type 'pstn'", Richard Shockey, 5-Oct-07. ( bytes)
This document registers the Enumservice 'pstn' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761[1] and registers a new URI type 'pstndata:' according to the URI registration procedure in RFC 4395 [15]. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). The pstndata URI is created to facilitate this transfer, however this URI may be used to transport other PSTN data in the future.
"Combined User and Infrastructure ENUM in the e164.arpa tree", Michael Haberler, Otmar Lendl, Richard Stastny, 22-Oct-07. ( bytes)
This memo defines an interim solution for Infrastructure ENUM to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after approval and implementation of the long-term solution.
"ENUM Requirement for EDNS0 Support", Jim Reid, Lawrence Conroy, 6-Sep-06. ( bytes)
Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761.
"The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Scott Bradner, Lawrence Conroy, Kazunori Fujiwara, 31-Mar-08. ( bytes)
This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761.
"IANA Registration for Enumservice UNUSED", Richard Stastny, Lawrence Conroy, Jim Reid, 29-Mar-08. ( bytes)
This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early".
"ENUM-based Softswitch Requirement", JoonHyung Lim, Weon Kim, ChanKi Park, Lawrence Conroy, 28-Apr-08. ( bytes)
This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean VoIP carriers, gained during the ENUM pre- commercial trial hosted by National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of on-going commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls.
"IANA Registration of Enumservices for Voice and Video Messaging", Jason Livingood, Donald Troshynski, 2-May-08. ( bytes)
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types; "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type.
"IANA Registrations of Enumservice "sms:smpp" and URI Scheme "smpp"", James Yu, 8-May-08. ( bytes)
This document updates RFC 4355 by registering a new enumservice subtype "smpp" under the existing type "sms" using the URI scheme "smpp" as per the IANA registration process defined in RFC 3761 and draft-ietf-enum-enumservices-guide-07 and registers a new URI scheme "smpp" according to the URI registration procedure in RFC 4395. This enumservice subtype indicates that the remote resource identified by the URI can receive short messages using the Short Message Peer-to-Peer Protocol (SMPP).

IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

Return to Internet-Draft directory.

Return to IETF home page.