ENUM P. Faltstrom
Internet-Draft Cisco Systems Inc
Expires: August 28, 2003 M. Mealling
VeriSign
February 27, 2003
The E.164 to URI DDDS Application (ENUM)
draft-ietf-enum-rfc2916bis-04.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 28, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document discusses the use of the Domain Name System (DNS) for
storage of E.164 numbers. More specifically, how DNS can be used for
identifying available services connected to one E.164 number. It
specifically obsoletes RFC 2916 to bring it in line with the Dynamic
Delegation Discovery System (DDDS) Application specification found in
the document series specified in RFC 3401. It is very important to
note that it is impossible to read and understand this document
without reading the documents discussed in RFC 3401.
Faltstrom & Mealling Expires August 28, 2003 [Page 1]
Internet-Draft ENUM February 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Use for these mechanisms for private dialing plans . . . . . 3
1.3 Application of local policy . . . . . . . . . . . . . . . . 3
2. The ENUM Application Specifications . . . . . . . . . . . . 5
2.1 Application Unique String . . . . . . . . . . . . . . . . . 5
2.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 5
2.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.2 Services Parameters . . . . . . . . . . . . . . . . . . . . 7
2.5 Partial E.164 Numbers . . . . . . . . . . . . . . . . . . . 8
2.6 What constitutes an 'Enum Resolver'? . . . . . . . . . . . . 8
3. Registration mechanism for Enumservices . . . . . . . . . . 10
3.1 Registration Requirements . . . . . . . . . . . . . . . . . 10
3.1.1 Functionality Requirement . . . . . . . . . . . . . . . . . 10
3.1.2 Naming requirement . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Security requirement . . . . . . . . . . . . . . . . . . . . 11
3.1.4 Publication Requirements . . . . . . . . . . . . . . . . . . 12
3.2 Registration procedure . . . . . . . . . . . . . . . . . . . 12
3.2.1 IANA Registration . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Registration Template . . . . . . . . . . . . . . . . . . . 12
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . 16
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
8. Changes since RFC 2916 . . . . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . 19
Non-normative references . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20
Full Copyright Statement . . . . . . . . . . . . . . . . . . 21
Faltstrom & Mealling Expires August 28, 2003 [Page 2]
Internet-Draft ENUM February 2003
1. Introduction
Through transformation of E.164 [4] numbers into DNS names and the
use of existing DNS services like delegation through NS records and
NAPTR records, one can look up what services are available for a
specific domain name in a decentralized way with distributed
management of the different levels in the lookup process.
The domain "e164.arpa" is being populated in order to provide the
infrastructure in DNS for storage of E.164 numbers. In order to
facilitate distributed operations, this domain is divided into
subdomains. Holders of E.164 numbers which want to be listed in DNS
should contact the appropriate zone administrator in order to be
listed, by examining the SOA resource record associated with the
zone, just like in normal DNS operations.
Of course, as with other domains, policies for such listings will be
controlled on a subdomain basis and may differ in different parts of
the world.
1.1 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.
All other capitalized terms are taken from the vocabulary found in
the DDDS algorithm specification found in RFC 3403 [1].
1.2 Use for these mechanisms for private dialing plans
This document specifies how "ENUM" works, that is how to handle
numbers allocated according to the ITU-T standard E.164. But, a
similar mechanism can be used also for other numbers, such as private
dialing plans. To implement that (a) the suffix MUST be selected,
MUST NOT be e164.arpa, MUST be known for all parties using the same
dialing plan (b) the application unique string SHOULD be the full
number as specified but without the leading '+'.
1.3 Application of local policy
The Order field in the NAPTR record specifies in what order the DNS
records are to be interpreted. This is because DNS does not
guarantee the order of records returned in the answer section of a
DNS packet. In most ENUM cases this isn't an issue because the
typical regular expression will be '!^.*$!' since the first query
often results in a terminal Rule.
Faltstrom & Mealling Expires August 28, 2003 [Page 3]
Internet-Draft ENUM February 2003
But there are other cases (non-terminal Rules) where two different
Rules both match the given Application Unique String. As each Rule
is evaluated within the algorithm, one may match a more significant
piece of the AUS than the other. For example, by using a non-
terminal NAPTR a given set of numbers is sent to some intranet
specific zone. Within that zone there are two Rules that state that
if a match is for the entire exchange and the service is SIP related
then the first, SIP-specific rule is used. But the other Rule
matches a longer piece of the AUS, specifying that for some other
service (instant messaging) that the Rule denotes a departmental
level service. If the shorter matching Rule comes before the longer
match, it can 'mask' the other rules. Thus, the order in which each
Rule is tested against the AUS is an important corner case that many
DDDS applications take advantage of.
In the case where the zone authority wishes to state that two Rules
have the same effect or are identical in usage, then the Order for
those records is set to the same value. In that case, the Preference
is used to specify a locally over-ridable suggestion by the zone
authority that one Rule might simply be better than another for some
reason.
For ENUM this specifies where a client is allowed to apply local
policy and where it is not. The Order field in the NAPTR is a
request from the holder of the E.164 number that the records be
handled in a specific way. The Preference field is merely a
suggestion from that E.164 holder that one record might be better
than another. A client implementing ENUM MUST adhere to the Order
field but can simply take the Preference value "on advisement" as
part of a client context specific selection method.
Faltstrom & Mealling Expires August 28, 2003 [Page 4]
Internet-Draft ENUM February 2003
2. The ENUM Application Specifications
This template defines the ENUM DDDS Application according to the
rules and requirements found in [1]. The DDDS database used by this
Application is found in [2] which is the document that defines the
NAPTR DNS Resource Record type.
2.1 Application Unique String
The Application Unique String is a fully qualified E.164 number minus
any non-digit characters except for the '+' character which appears
at the beginning of the number. The "+" is kept to provide a well
understood anchor for the AUS in order to distinguish it from other
telephone numbers that are not part of the E.164 namespace.
For example, the E.164 number could start out as "+1-770-923-9595".
To ensure that no syntactic sugar is allowed into the AUS, all non-
digits except for "+" are removed, yielding "+17709239595".
2.2 First Well Known Rule
The First Well Known Rule for this Application is the identity rule.
The output of this rule is the same as the input. This is because
the E.164 namespace and this Applications databases are organized in
such a way that it is possible to go directly from the name to the
smallest granularity of the namespace directly from the name itself.
Take the previous example, the AUS is "+17709239595". Applying the
First Well Known Rule produces the exact same string, "+17709239595".
2.3 Expected Output
The output of the last DDDS loop is a Uniform Resource Identifier in
its absolute form according to the 'absoluteURI' production in the
Collected ABNF found in RFC2396 [3].
2.4 Valid Databases
At present only one DDDS Database is specified for this Application.
"Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
Database" (RFC 3403) [2] specifies a DDDS Database that uses the
NAPTR DNS resource record to contain the rewrite rules. The Keys for
this database are encoded as domain-names.
The output of the First Well Known Rule for the ENUM Application is
the E.164 number minus all non-digit characters except for the +. In
order to convert this to a unique key in this Database the string is
converted into a domain-name according to this algorithm:
Faltstrom & Mealling Expires August 28, 2003 [Page 5]
Internet-Draft ENUM February 2003
1. Remove all characters with the exception of the digits. For
example, the First Well Known Rule produced the Key
"+4689761234". This step would simply remove the leading "+",
producing "4689761234".
2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4
3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4
4. Append the string ".e164.arpa" to the end. Example:
4.3.2.1.6.7.9.8.6.4.e164.arpa
This domain-name is used to request NAPTR records which may contain
the end result or, if the flags field is blank, produces new keys in
the form of domain-names from the DNS.
Some nameserver implementations attempt to be intelligent about items
that are inserted into the additional information section of a given
DNS response. For example, BIND will attempt to determine if it is
authoritative for a domain whenever it encodes one into a packet. If
it is, then it will insert any A records it finds for that domain
into the additional information section of the answer until the
packet reaches the maximum length allowed. It is therefore
potentially useful for a client to check for this additional
information. It is also easy to contemplate an ENUM enhanced
nameserver that understand the actual contents of the NAPTR records
it is serving and inserts more appropriate information into the
additional information section of the response. Thus, DNS servers
MAY interpret Flag values and use that information to include
appropriate resource records in the Additional Information portion of
the DNS packet. Clients are encouraged to check for additional
information but are not required to do so. See the Additional
Information Processing section of RFC 3403 [1], Section 4.2 for more
information on NAPTR records and the Additional Information section
of a DNS response packet.
The character set used to encode the substitution expression is UTF-
8. The allowed input characters are all those characters that are
allowed anywhere in an E.164 number. The characters allowed to be in
a Key are those that are currently defined for DNS domain-names.
2.4.1 Flags
This Database contains a field that contains flags that signal when
the DDDS algorithm has finished. At this time only one flag, "U", is
defined. This means that this Rule is the last one and that the
output of the Rule is a URI [3]. See RFC 3404 [2].
Faltstrom & Mealling Expires August 28, 2003 [Page 6]
Internet-Draft ENUM February 2003
If a client encounters a record with an unknown flag, it MUST ignore
it and move to the next Rule. This test takes precedence over any
ordering since flags can control the interpretation placed on fields.
A novel flag might change the interpretation of the regexp and/or
replacement fields such that it is impossible to determine if a
record matched a given target.
If this flag is not present then this rule is non-terminal. If a
Rule is non-terminal then clients MUST use the Key produced by this
Rewrite Rule as the new Key in the DDDS loop (i.e. causing the
client to query for new NAPTR records at the domain-name that is the
result of this Rule).
2.4.2 Services Parameters
Service Parameters for this Application take the following form and
are found in the Service field of the NAPTR record.
service_field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT)
subtype = 1*32(ALPHA / DIGIT)
In other words, a non-optional "E2U" (used to denote ENUM only
Rewrite Rules in order to mitigate record collisions) followed by 1
or more or more Enumservices which indicate what class of
functionality a given end point offers. Each Enumservice is
indicated by an initial '+' character.
2.4.2.1 ENUM Services
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. Note that there is no implicit mapping between
the textual string "type" or "subtype" in the grammar for the
Enumservice and URI schemes or protocols. The mapping, if any, have
to be made explicit in the specification for the Enumservice itself.
A registration of a specific Type also have to specify the Subtypes
allowed.
The only exception to the registration rule is for Types and Subtypes
used for experimental purposes, and those are to start with the facet
"X-". These elements are unregistered, experimental, and should be
used only with the active agreement of the parties exchanging them.
Faltstrom & Mealling Expires August 28, 2003 [Page 7]
Internet-Draft ENUM February 2003
The registration mechanism is specified in Section 3.
2.5 Partial E.164 Numbers
In certain circumstances a client may be presented with a telephone
number for which it cannot determine if that number is a fully
qualified E.164 number or not. This can easily happen in situations
where a client is attempting to learn about a number that is from a
dialing plan it isn't familiar with. In this case it is possible for
a client to inadvertently request NAPTR records for some intermediate
node within the e164.arpa tree.
While this may happen, whether or not the behavior is useful or
should be standardized is undefined at this time. Thus, ENUM clients
SHOULD NOT attempt to query for intermediate nodes within the
e164.arpa tree.
2.6 What constitutes an 'Enum Resolver'?
There has been some confusion over what exactly an ENUM Resolver
returns and what relation that has to the 'Note 1' section in RFC
3402. On first reading it seems as though it might be possible for
an ENUM Resolver to return two Rules. The answer to that depends on
which of two possible definitions you use for an ENUM Resolver:
The first type of resolver can be called an 'intelligent' resolver.
It understands its target application very well. In that case the
test done at the beginning of Step 4 in the algorithm is a very
complex one. It can include call backs to the calling thread, GUI
events, etc. Its at this point that a client can be presented with
the idea of "multiple Rules" because its at this step that Order is
understood relative to the other ordered records. In this case the
ENUM Resolver still returns one Rule to the calling application but
its smart enough internally that it can apply application specific
knowledge to the Rule selection test.
The other type of resolver can be called a 'dumb' or 'driven'
resolver. It is generic in the sense that there is no internal
application knowledge. It is run from the 'outside' by a smart
application that changes the selection criteria that are fed to the
ENUM Resolver before it starts its resolution task. It returns one
Rule only and the caller has to determine if that Rule is ok or not.
If it isn't then it re-runs the resolver with a new set of selection
criteria. Some might consider the combination of this dumb resolver
and the application that's driving it as some uber-ENUM-Resolver. In
that case it can "return more than one Rule" because it can simply
re-run the algorithm several times to collect an appropriate set of
Rules. But that uber-ENUM-Resolver is stretching the definition of
Faltstrom & Mealling Expires August 28, 2003 [Page 8]
Internet-Draft ENUM February 2003
an ENUM Resolver to the point of being unrecognizable.
The key point is that the Algorithm only returns one Rule.
Faltstrom & Mealling Expires August 28, 2003 [Page 9]
Internet-Draft ENUM February 2003
3. Registration mechanism for Enumservices
As specified in the ABNF found in Section 2.4.2, an 'enumservice' is
made up of 'types' and 'subtypes'. For any given 'type', the
allowable 'subtypes' must be specified in the registration. There is
currently no concept of a registered 'subtype' outside the scope of a
given 'type'. Thus the registration process uses the 'type' as its
main key within the IANA Registry. While the combination of each
type and all of its subtypes constitutes the allowed values for the
'enumservice' field, it is not sufficient to simply document those
values. A complete registration will also include the allowed URI
schemes, a functional specification, security considerations,
intended usage, and any other information needed to allow for
interoperability within ENUM. In order to be a registered ENUM
Service, the entire specification, including the template, requires
approval by the IESG and publication of the Enumservice registration
specification as an RFC either on the Standards Track or as a BCP.
3.1 Registration Requirements
Service registration proposals are all expected to conform to various
requirements laid out in the following sections.
3.1.1 Functionality Requirement
A registered Enumservice must be able to function as a selection
mechanism when choosing one NAPTR resource record from another. That
means that the registration MUST specify what is expected when using
that very NAPTR record, and the URI which is the outcome of the use
of it.
Specifically, a registered Enumservice MUST specify the URI scheme(s)
that may be used for the Enumservice, and, when needed, other
information which will have to be transfered into the URI resolution
process itself (LDAP DNs, transferring of the AUS into the resulting
URI, etc).
3.1.2 Naming requirement
The Enumservice MUST be unique in order to be useful as a selection
criteria. Since the Enumservice is made up of a type and a type-
dependent subtype, it is sufficient to require that the 'type' itself
be unique. The 'type' MUST be unique, conform to the ABNF specified
in Section 2.4.2, and MUST NOT start with the facet "X-" which is
reserved for experimental, private use.
The subtype, being dependent on the type, MUST be unique within a
given 'type'. It must conform to the ABNF specified in Section
Faltstrom & Mealling Expires August 28, 2003 [Page 10]
Internet-Draft ENUM February 2003
2.4.2, and MUST NOT start with the facet "X-" which is reserved for
experimental, private use. The subtype for one type MAY be the same
as a subtype for a different registered type but it is not sufficient
to simply reference another type's subtype. The function of each
subtype must be specified in the context of the type being
registered.
3.1.3 Security requirement
An analysis of security issues is required for all registered
Enumservices. (This is in accordance with the basic requirements for
all IETF protocols.)
All descriptions of security issues must be as accurate as possible
regardless of registration tree. In particular, a statement that
there are "no security issues associated with this Enumservice" must
not be confused with "the security issues associates with this
Enumservice have not been assessed".
There is no requirement that Enumservices registered must be secure
or completely free from risks. Nevertheless, all known security
risks must be identified in the registration of a Enumservice.
The security considerations section of all registrations is subject
to continuing evaluation and modification.
Some of the issues that should be looked at in a security analysis of
a Enumservice are:
1. Complex Enumservices may include provisions for directives that
institute actions on a user's resources. In many cases provision
can be made to specify arbitrary actions in an unrestricted
fashion which may then have devastating results. Especially if
there is a risk for a new ENUM lookup, and because of that an
infinite loop in the overall resolution process of the E.164.
2. Complex Enumservices may include provisions for directives that
institute actions which, while not directly harmful, may result
in disclosure of information that either facilitates a subsequent
attack or else violates the users privacy in some way.
3. An Enumservice might be targeted for applications that require
some sort of security assurance but do not provide the necessary
security mechanisms themselves. For example, a Enumservice could
be defined for storage of confidential medical information which
in turn requires an external confidentiality service.
Faltstrom & Mealling Expires August 28, 2003 [Page 11]
Internet-Draft ENUM February 2003
3.1.4 Publication Requirements
Proposals for Enumservices registered must be published as RFCs on
the Standards Track or as a BCP. IANA will retain copies of all
Enumservice registration proposals and "publish" them as part of the
ENUM Enumservice Registration tree itself.
3.2 Registration procedure
3.2.1 IANA Registration
Provided that the Enumservice has obtained the necessary approval,
and the RFC is published, IANA will register the Enumservice and make
the Enumservice registration available to the community in addition
to the RFC publication itself.
3.2.1.1 Location of ENUM Enumservice Registrations
Enumservice registrations will be published in the IANA repository
and made available via anonymous FTP at the following URI: "ftp://
ftp.iana.org/assignments/enum-services/".
3.2.1.2 Change Control
Change control of Enumservices stay with the IETF via the RFC
publication process. Especially, Enumservice registrations may not
be deleted; Enumservices which are no longer believed appropriate for
use can be declared OBSOLETE by publication of a new RFC and a change
to their "intended use" field; such Enumservice will be clearly
marked in the lists published by IANA.
3.2.2 Registration Template
Enumservice Type:
Enumservice Subtype(s):
URI Scheme(s):
Functional Specification:
Security considerations:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
Author:
Any other information that the author deems interesting:
Faltstrom & Mealling Expires August 28, 2003 [Page 12]
Internet-Draft ENUM February 2003
Note: In the case where a particular field has no value, that field
is left completely blank, especially in the case where a given type
has no subtypes.
Faltstrom & Mealling Expires August 28, 2003 [Page 13]
Internet-Draft ENUM February 2003
4. Examples
The examples below use theoretical services which uses Enumservices
which might not make sense, but they are still used for educational
purposes. For example, the protocol used is in some cases exactly
the the same string as the URI scheme. That was the specification in
RFC 2916, but this default specification of a Enumservice is no
longer allowed. All Enumservices need to be registered explicitly by
the procedure specified in section Section 3.
4.1 Example
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
IN NAPTR 10 100 "u" "E2U+sip"
"!^.*$!sip:info@example.com!" .
IN NAPTR 10 101 "u" "E2U+h323:voice"
"!^.*$!h323:info@example.com!" .
IN NAPTR 10 102 "u" "E2U+msg:mailto"
"!^.*$!mailto:info@example.com!" .
This describes that the domain 4.3.2.1.6.7.9.8.6.4.e164.arpa is
preferably contacted by SIP, secondly via H.323 for voice, and
thirdly by SMTP for messaging. Note that the tokens "sip", "msg",
"h323", "voice" and "mailto" are Types and Subtypes registered with
IANA, and they have no implicit connection with the protocols or URI
schemes with the same names.
In all cases, the next step in the resolution process is to use the
resolution mechanism for each of the protocols, (specified by the URI
schemes sip, h323 and mailto) to know what node to contact for each.
Faltstrom & Mealling Expires August 28, 2003 [Page 14]
Internet-Draft ENUM February 2003
5. IANA Considerations
This memo requests that the IANA delegate the E164.ARPA domain
following instructions to be provided by the IAB. Names within this
zone are to be delegated to parties according to the ITU
recommendation E.164. The names allocated should be hierarchic in
accordance with ITU Recommendation E.164, and the codes should
assigned in accordance with that Recommendation.
IAB is to coordinate with ITU-T TSB if the technical contact for the
domain e164.arpa is to change, as ITU-T TSB has an operational
working relationship with this technical contact which needs to be
reestablished.
Delegations in the zone e164.arpa (not delegations in delegated
domains of e164.arpa) should be done after Expert Review, and the
IESG will appoint a designated expert.
IANA is to create a registry for ENUM Enumservices as specified in
Section 3. Whenever a new ENUM Enumservice is registered by the RFC
process in the IETF, IANA is at the time of publication of the RFC to
register the Enumservice and add a pointer to the RFC itself.
Faltstrom & Mealling Expires August 28, 2003 [Page 15]
Internet-Draft ENUM February 2003
6. Security Considerations
As this system is built on top of DNS, one can not be sure that the
information one gets back from DNS is more secure than any DNS query.
To solve that, the use of DNSSEC [7] for securing and verifying zones
is to be recommended.
The caching in DNS can make the propagation time for a change take
the same amount of time as the time to live for the NAPTR records in
the zone that is changed. The use of this in an environment where
IP-addresses are for hire (for example, when using DHCP [8]) must
therefore be done very carefully.
There are a number of countries (and other numbering environments) in
which there are multiple providers of call routing and number/name-
translation services. In these areas, any system that permits users,
or putative agents for users, to change routing or supplier
information may provide incentives for changes that are actually
unauthorized (and, in some cases, for denial of legitimate change
requests). Such environments should be designed with adequate
mechanisms for identification and authentication of those requesting
changes and for authorization of those changes.
A large amount of Security Issues have to do with the resolution
process itself, and use of the URIs produced by the DDDS mechanism.
Those have to be specified in the registration of the ENUM
Enumservice used, as specified in Section 3.1.3.
Faltstrom & Mealling Expires August 28, 2003 [Page 16]
Internet-Draft ENUM February 2003
7. Acknowledgments
Support and ideas leading to RFC 2916 have come from people at
Ericsson, Bjorn Larsson and the group which implemented this scheme
in their lab to see that it worked. Input has also arrived from ITU-
T SG2, Working Party 1/2 (Numbering, Routing, Global Mobility and
Enumservice Definition), the ENUM working group in the IETF, John
Klensin and Leif Sunnegardh.
This update of RFC 2916 is created with specific input from: Randy
Bush, David Conrad, Richard Hill, Jon Peterson, Jim Reid, Joakim
Stralmark, Robert Walter and James Yu.
Faltstrom & Mealling Expires August 28, 2003 [Page 17]
Internet-Draft ENUM February 2003
8. Changes since RFC 2916
Part from clarifications in the text in this document, the major
changes are two:
The document uses an explicit DDDS algorithm, and not only NAPTR
resource records in an "ad-hoc" mode. In reality this doesn't imply
any changes in deployed base of applications, as the algorithm used
for ENUM resolution is exactly the same.
The format of the service field has changed. The old format was of
the form "example+E2U", while the new format is "E2U+example".
Reason for this change have to with the added subtypes in the
enumservice, the ability to support more than one enumservice per
NAPTR RR, and a general agreement in the IETF that the main selector
between different NAPTR with the same owner (E2U in this case) should
be first.
Faltstrom & Mealling Expires August 28, 2003 [Page 18]
Internet-Draft ENUM February 2003
Normative References
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The DNS Database", RFC 3403, February 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The URI Resolution Application", RFC 3404, February 2002.
[3] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] ITU-T, "The International Public Telecommunication Number Plan",
Recommendation E.164, May 1997.
Faltstrom & Mealling Expires August 28, 2003 [Page 19]
Internet-Draft ENUM February 2003
Non-normative references
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS Standard", RFC 3401, February 2002.
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, February 2002.
[7] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
Authors' Addresses
Patrik Faltstrom
Cisco Systems Inc
Ledasa
273 71 Lovestad
Sweden
EMail: paf@cisco.com
URI: http://www.cisco.com
Michael Mealling
VeriSign
21345 Ridgetop Circle
Sterling, VA 20166
US
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
Faltstrom & Mealling Expires August 28, 2003 [Page 20]
Internet-Draft ENUM February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Faltstrom & Mealling Expires August 28, 2003 [Page 21]
