|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## ENUMwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 12, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## ENUMwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## ENUMwg
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the ENUM working group -- updated on December 7, 2005 --
is reported below.
|
|
|
|
The Telephone Number Mapping (ENUM)
working group has defined a DNS-based architecture and protocol
[RFC 3761]
by which an E.164 number, as defined in ITU Recommendation
E.164, can be expressed as a Fully Qualified Domain Name in a specific
Internet Infrastructure domain defined for this purpose (e164.arpa).
Background:
E.164 numbers are globally unique, language independent identifiers for
resources on Public Telecommunication Networks that can support many
different services and protocols. There is an emerging desire for
network operators to utilize aspects of
RFC 3761 to discover points of
interconnection necessary to terminate communications sessions
identified by a E164 number,in addition to identifying end point
protocols and services.
Working Group Revised Goals and Scope:
|
|
| 1. |
The working group will update RFC 3761 and advance to Draft Standard.
|
| 2. |
The working group will examine and document the use of RFC 3761 to
facilitate network interconnection for services using E.164 addressing.
The working group will coordinate its activities with other IETF working
groups, existing or to be chartered, that are investigating elements of
peering and or interconnection for VoIP or other services that typically
use E.164 addressing.
|
| 3. |
The working group will continue examine and document various aspects
of ENUM administrative and /or operational procedures irrespective of
whether e164.arpa domain is used.
|
| 4. |
The working group will also examine the use of RFC 3761 technology
for storing and delivering other information about services addressed by
E.164 numbers, for example PSTN call routing and signaling data.
|
| 5. |
The Working Group will continue to maintain appropriate contact and
liaison with other standards bodies and groups, specifically ITU-T SG2,
to provide technical or educational information and address, as needed,
issues related to the use of the E.164 numbering plan for services on IP
networks. In addition the Working Group will continue to encourage the
exchange of technical information within the emerging global ENUM
community as well as documentation on practical experiences with
implementations, alternate technology uses and the administration and
provisioning of RFC 3761.
|
| 6. |
As described in RFC 3761, the IETF documents and registers the
Enumservices. While extant, it is the ENUM working group that performs
the technical review and development of the Enumservices for the
Internet community. The working group determines whether to advance them
and how to progress them technically. Coordination with other WGs will
be taken into account on these.
|
|
|
Other than Enumservices, all proposed deliverables of the working group
will be discussed with and approved by the Area Directors, who may
require wider review due to the broad impact of the subject.
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## ENUMwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## ENUMwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
enum-branch-
location-record-03
Dead
Jun 12, 2007
(10 p.)
[pdf(2)]
[html]
|
O. Lendl |
|
The ENUM Branch Location Record |
|
This documents defines an extension to the E.164 Number Mapping
(ENUM) algorithm by adding a mapping step which indicates where the
ENUM tree for a specific ENUM application is located. A new DNS
record (IEBL, the Infrastructure ENUM Branch Location record) is
defined which provides an interim solution for the Infrastructure
ENUM tree location.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
ietf-enum-edns0-00
AD Evaluation::
Revised ID Needed
Jun 26, 2006
(16 p.)
[pdf(2)]
[html]
|
L. Conroy
J. Reid |
|
ENUM Requirement for EDNS0 Support |
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.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
enum-unused-04
AD Evaluation::
Revised ID Needed
Mar 29, 2008
(16 p.)
[pdf(2)]
[html]
|
R. Stastny
L. Conroy
J. Reid |
|
IANA Registration for Enumservice UNUSED |
|
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".
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
enum-softswitch-
req-02
AD Evaluation
Apr 28, 2008
(17 p.)
[pdf(2)]
[html]
|
J. Lim
W. Kim
C. Park
L. Conroy |
|
ENUM-based Softswitch Requirement |
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.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
enum-vmsg-02
AD Evaluation
Apr 16, 2008
(21 p.)
[pdf(2)]
[html]
|
J. Livingood
D. Troshynski |
|
IANA Registration of Enumservices for Voice and Video Messaging |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
enum-void-02
IESG Evaluation::
Revised ID Needed
Oct 19, 2005
(19 p.)
[pdf(2)]
[html]
|
R. Stastny
L. Conroy
J. Reid |
| IANA Registration for Enumservice VOID |
|
This document registers the Enumservice 'void' using the URI schemes
'mailto:' and '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 assigned for
communications service. When such an indication is provided, an ENUM
client can detect calls that will fail "early".
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## ENUMwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
enum-
enumservice-
sms-smpp-01
ID Exists
May 8, 2008
(12 p.)
[pdf(2)]
[html]
|
J. Yu |
|
IANA Registrations of Enumservice "sms:smpp" and "smpp" URI |
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).
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
##
##
##
##
##
## ENUMwg
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
kaplan-enum-
source-uri-00
ID Exists
Dec 11, 2007
(8 p.)
[pdf(2)]
[html]
|
H. Kaplan
R. Walter
R. Gopal
T. Creighton |
|
DNS Extension for ENUM Source-URI |
|
This document defines a specific DNS extension, based on the EDNS0
OPT RR, for an ENUM query to include the source URI which caused the
ENUM request. This is useful, for example, to specify the
originating SIP or TEL URI from a SIP request which triggered the
ENUM query, so the ENUM server can provide a different response.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC3482
02/2003
(30 p.)
[html]
[pdf(2)] |
M. Foster
T. McGarry
J. Yu |
ENUM |
|
Number Portability in the Global Switched Telephone Network (GSTN): An Overview |
|
This document provides an overview of E.164 telephone number
portability (NP) in the Global Switched Telephone Network (GSTN).
NP is a regulatory imperative seeking to liberalize local telephony
service competition, by enabling end-users to retain telephone
numbers while changing service providers. NP changes the fundamental
nature of a dialed E.164 number from a hierarchical physical routing
address to a virtual address, thereby requiring the transparent
translation of the later to the former. In addition, there are
various regulatory constraints that establish relevant parameters for
NP implementation, most of which are not network technology specific.
Consequently, the implementation of NP behavior consistent with
applicable regulatory constraints, as well as the need for
interoperation with the existing GSTN NP implementations, are
relevant topics for numerous areas of IP telephony works-in-progress
with the IETF.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC4114
06/2005
(17 p.)
[html]
[pdf(2)] |
S. Hollenbeck |
ENUM |
|
E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) |
|
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of E.164
numbers that represent domain names stored in a shared central
repository. Specified in XML, this mapping extends the EPP domain
name mapping to provide additional features required for the
provisioning of E.164 numbers.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC4415
02/2006
(8 p.)
[html]
[pdf(2)] |
R. Brandner
L. Conroy
R. Stastny |
ENUM |
|
IANA Registration for Enumservice Voice |
|
This document registers the Enumservice "voice" (which has a defined
subtype "tel"), as per the IANA registration process defined in the
ENUM specification RFC 3761. This service indicates that the contact
held in the generated Uniform Resource Identifier (URI) can be used
to initiate an interactive voice (audio) call.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC4725
11/2006
(17 p.)
[html]
[pdf(2)] |
A. Mayrhofer
B. Hoeneisen |
ENUM |
|
ENUM Validation Architecture |
|
An ENUM domain name is tightly coupled with the underlying E.164
number. The process of verifying whether or not the Registrant of an
ENUM domain name is identical to the Assignee of the corresponding
E.164 number is commonly called "validation". This document
describes validation requirements and a high-level architecture for
an ENUM validation infrastructure.
|
|
|
|
|
|
|
|
|
|
|
| | | |
RFC4969
08/2007
(7 p.)
[html]
[pdf(2)] |
A. Mayrhofer |
ENUM |
|
IANA Registration for vCard Enumservice |
This memo registers the Enumservice "vCard" using the URI schemes
"http" and "https". This Enumservice is to be used to refer from an
ENUM domain name to a vCard instance describing the user of the
respective E.164 number.
Information gathered from those vCards could be used before, during,
or after inbound or outbound communication takes place. For example,
a callee might be presented with the name and association of the
caller before picking up the call.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC4979
08/2007
(7 p.)
[html]
[pdf(2)] |
A. Mayrhofer |
ENUM |
|
IANA Registration for Enumservice 'XMPP' |
|
This document requests IANA registration of an Enumservice for XMPP,
the Extensible Messaging and Presence Protocol. This Enumservice
specifically allows the use of 'xmpp' Uniform Resource Identifiers
(URIs) in the context of E.164 Number Mapping (ENUM).
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC5076
12/2007
(24 p.)
[html]
[pdf(2)] |
B. Hoeneisen |
ENUM |
|
ENUM Validation Information Mapping
for the Extensible Provisioning Protocol |
|
This document describes an Extensible Provisioning Protocol (EPP)
extension framework for mapping information about the validation
process that has been applied for the E.164 number (or number range)
that the E.164 Number Mapping (ENUM) domain name is based on.
Specified in the Extensible Markup Language (XML), this mapping
extends the EPP domain name mapping to provide an additional feature
required for the provisioning of ENUM Domain Names.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
| | | |
RFC5105
12/2007
(17 p.)
[html]
[pdf(2)] |
O. Lendl |
ENUM |
|
ENUM Validation Token Format Definition |
|
An ENUM domain name is tightly coupled with the underlying E.164
number. The process of verifying whether the Registrant of an ENUM
domain name is identical to the Assignee of the corresponding E.164
number is commonly called "validation". This document describes a
signed XML data format -- the Validation Token -- with which
Validation Entities can convey successful completion of a validation
procedure in a secure fashion.
|
|
|
| |
| Up List |
Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
