Combined User and Infrastructure ENUM in the e164.arpa Tree
RFC 5527
Network Working Group M. Haberler
Request for Comments: 5527 IPA
Category: Informational O. Lendl
enum.at
R. Stastny
Unaffiliated
May 2009
Combined User and Infrastructure ENUM in the e164.arpa Tree
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
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 memo defines an interim solution for Infrastructure ENUM in
order to allow a combined User and Infrastructure ENUM implementation
in e164.arpa as a national choice. This interim solution will be
deprecated after implementation of the long-term solution.
Haberler, et al. Informational [Page 1]
RFC 5527 Combined User and Infrastructure ENUM May 2009
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Interim Solution ................................................3
4. The Algorithm ...................................................4
5. Determining the Position of the Branch ..........................5
6. Transition to the Long-Term Solution ............................6
7. Examples ........................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
1. Introduction
ENUM (E.164 Number Mapping, [RFC3761]) is a system that transforms
E.164 numbers [E164] into domain names and then queries the DNS
(Domain Name Service) [RFC1034] for NAPTR (Naming Authority Pointer)
records [RFC3401] in order to look up which services are available
for a specific domain name.
ENUM, as defined in RFC 3761 (User ENUM), is not well suited for the
purpose of interconnection by carriers and voice-service providers,
as can be seen by the use of various private tree arrangements based
on ENUM mechanisms.
Infrastructure ENUM is defined as the use of the technology in RFC
3761 [RFC3761] by the carrier-of-record (voice service provider)
[RFC5067] for a specific E.164 number [E164] in order to publish a
mapping of this telephone number to one or more Uniform Resource
Identifiers (URIs) [RFC3986].
Other voice service providers can query the DNS for this mapping and
use the resulting URIs as input into their call-routing algorithm.
These URIs are separate from any URIs that the end-user who registers
an E.164 number in ENUM may wish to associate with that E.164 number.
The requirements, terms, and definitions for Infrastructure ENUM are
defined in [RFC5067].
Using the same E.164 number to domain mapping techniques for other
applications under a different, internationally agreed-upon apex
(instead of e164.arpa) is straightforward on the technical side.
This process of defining the Dynamic Delegation Discovery System
(DDDS) [RFC3401] application for Infrastructure ENUM is defined in
[RFC5526]. This is the long-term solution.
Haberler, et al. Informational [Page 2]
RFC 5527 Combined User and Infrastructure ENUM May 2009
This document presents an interim solution for Infrastructure ENUM
and a mechanism for transitioning to the long-term solution. The
interim solution is based on establishing a branch in the e164.arpa
tree, which resolvers may locate by following the algorithm described
in Section 4. The location of the branch is dependent upon country-
code length, and thus resolvers must determine the position of the
branch based on the method described in Section 5. Finally,
Section 6 provides a way that implementations following the
procedures of Sections 4 and 5 may be seamlessly redirected to the
Show full document text