ENUM L. Conroy
Internet-Draft RMRL
Intended status: Best Current K. Fujiwara
Practice JPRS
Expires: August 17, 2008 February 14, 2008
ENUM Implementation Issues and Experiences
<draft-ietf-enum-experiences-09.txt>
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 August 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Conroy & Fujiwara Expires August 17, 2008 [Page 1]
Internet-Draft ENUM Experiences February 2008
Abstract
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.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Document Goal . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Changes since last version . . . . . . . . . . . . . . . . 4
3. Character Sets and ENUM . . . . . . . . . . . . . . . . . . . 6
3.1. Character Sets - Non-ASCII considered harmful . . . . . . 6
3.2. Case Sensitivity . . . . . . . . . . . . . . . . . . . . . 8
3.3. Regexp field delimiter . . . . . . . . . . . . . . . . . . 8
3.4. Regexp Meta-character Issue . . . . . . . . . . . . . . . 9
4. Unsupported NAPTRs . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Non-compliant client behaviour . . . . . . . . . . . . . . 10
5. ORDER/PRIORITY Processing . . . . . . . . . . . . . . . . . . 12
5.1. Order/Priority values - general processing . . . . . . . . 12
5.2. Use of Order and Preference fields . . . . . . . . . . . . 13
5.3. NAPTRs with identical ORDER/PRIORITY values . . . . . . . 13
5.3.1. Compound NAPTRs and implicit ORDER/REFERENCE Values . 14
5.4. Processing Order value across Domains . . . . . . . . . . 14
6. Non-Terminal NAPTR Processing . . . . . . . . . . . . . . . . 16
6.1. Non-Terminal NAPTRs - necessity . . . . . . . . . . . . . 16
6.2. Non-Terminal NAPTRs - considerations . . . . . . . . . . . 17
6.2.1. Non-Terminal NAPTRs - general . . . . . . . . . . . . 17
6.2.2. Non-Terminal NAPTRs - loop detection and response . . 17
6.2.3. Field content in Non-Terminal NAPTRs . . . . . . . . . 17
7. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 21
7.1. Services field syntax . . . . . . . . . . . . . . . . . . 21
8. Collected Implications for ENUM Provisioning . . . . . . . . . 22
9. Collected Implications for ENUM Clients . . . . . . . . . . . 24
9.1. Non-terminal NAPTR processing . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Conroy & Fujiwara Expires August 17, 2008 [Page 2]
Internet-Draft ENUM Experiences February 2008
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 [17].
Conroy & Fujiwara Expires August 17, 2008 [Page 3]
Internet-Draft ENUM Experiences February 2008
2. Introduction
2.1. Document Goal
The goal of this document is to clarify the ENUM and DDDS standards,
and to advise implementers on the pitfalls that they may find. It
highlights areas where ENUM implementations have differed over
interpretation of the standards documents, or have outright failed to
implement some features as specified.
As well as clarifications to standards text, this document also
mentions potential choices that can be made, in an attempt to help to
foster interworking between components that use this protocol. The
reader is reminded that others may make different choices.
The core specifications for the E.164 Number Mapping (ENUM) protocol
([1]) and the Dynamic Delegation Discovery System (DDDS, [2] [18] [3]
[4] [5]) are defined elsewhere. Unfortunately, this document cannot
provide an overview of the specifications, so the reader is assumed
to have read and understood the complete set of ENUM normative
documents.
ENUM is a user of the Domain Name System (DNS). It is also important
for ENUM implementers to carry out a thorough analysis of all of the
existing DNS standard documents to understand what services are
provided to ENUM, and the load that ENUM provisioning and queries
will place on DNS.
A great deal of the rationale for making the choices listed in this
document is available to those who explore the standards. The trick
of course is in understanding those standards and the subtle
implications that are involved in some of their features. In almost
all cases, the choices presented here are merely selections from
values that are permissible within the standards.
2.2. Changes since last version
----[RFC Editor: This section to be removed before publication]----
V7-V8: Minor textual changes have been made as a result of GEN-ART
and LC comments. The IANA requirement has been clarified, as has
non-terminal loop detection. Several cases of non-compliant
behaviour have been made explicit; these were implied but not stated
in earlier versions.
V6-V7: The previous version classified its advice in terms of
potential clarifications to standards, reminders of existing
standards, advice on encountered client and provisioning
(mis-)behaviours, and recommendations to improve interworking. Each
Conroy & Fujiwara Expires August 17, 2008 [Page 4]
Internet-Draft ENUM Experiences February 2008
proposal was "tagged" to show the kind of recommendation made. These
hints have been removed in this version; they didn't help. This
document supports implementers of ENUM clients that consume E2U NAPTR
data published in DNS, and those who design systems to provision data
into those zones, by helping them make choices on values and
implementation strategies. To make this clearer, this version has
collected the recommendations for Provisioning systems and Clients in
their own sections.
Conroy & Fujiwara Expires August 17, 2008 [Page 5]
Internet-Draft ENUM Experiences February 2008
3. Character Sets and ENUM
3.1. Character Sets - Non-ASCII considered harmful
RFC 3761 and RFC 3403 ([1] and [2]) specify respectively that ENUM
and NAPTRs support Unicode using the UTF-8 encoding defined in [6].
This raises an issue where implementations use "single byte" string
processing routines. If there are multi-byte characters within an
ENUM NAPTR, incorrect processing may well result from these UTF-8
unaware systems.
The UTF-8 encoding has a "US-ASCII equivalent range", so that all
characters in US-ASCII [19] from 0x00 to 0x7F hexadecimal have an
identity map to the UTF-8 encoding; the encodings are the same. In
UTF-8, characters with Unicode code points above this range will be
encoded using more than one byte, all of which will be in the range
0x80 to 0xFF hexadecimal. Thus it is important to consider the
different fields of a NAPTR and whether or not multi-byte characters
can or should appear in them.
In addition, characters in the "non-printable" portion of US-ASCII
(0x00 to 0x1F hexadecimal, plus 0x7F hexadecimal) are "difficult".
Although NAPTRs are processed by machine, they may sometimes need to
be written in a "human readable" form. Specifically, if NAPTR
content is shown to an end user so that he or she may choose, it is
imperative that the content is human readable. Thus it is unwise to
use non-printable characters even if they lie within the US-ASCII
range; the ENUM client may have good reason to reject NAPTRs that
include these characters as they cannot readily be presented to an
end-user.
There are two numeric fields in a NAPTR; the ORDER and PREFERENCE/
PRIORITY fields. As these contain binary values, no risk is involved
as string processing should not be applied to them. The string-based
fields are the Flags, Services, and Regexp fields. The Replacement
field holds an uncompressed domain name encoded according to the
standard DNS mechanism [7][8]. Internationalized Domain Name (IDN)
can be supported (as specified in [9], [10], and [11]). Any such IDN
MUST be further encoded using Punycode [11]. As the Replacement
field holds a domain name that is not subject to replacement or
modification (other than Punycode processing), it is not of concern
here.
Taking the string fields in turn, the Flags field contains characters
that indicate the disposition of the NAPTR. This may be empty, in
which case the NAPTR is "non-terminal", or it may include a flag
character as specified in RFC 3761. These characters all fall into
the printable US-ASCII equivalent range, so multi-byte characters
Conroy & Fujiwara Expires August 17, 2008 [Page 6]
Internet-Draft ENUM Experiences February 2008
cannot occur.
The Services field includes the DDDS Application identifier ("E2U")
used for ENUM, the '+' character used to separate Enumservices and
this application identifier, and a set of Enumservice identifiers,
any of which may embed the ':' separator character. In section 2.4.2
of RFC 3761 these identifier tokens are specified as 1*32 ALPHA/
DIGIT, so there is no possibility of non-ASCII characters in the
Services field.
The Regexp field is more complex. It forms a sed-like substitution
expression, defined in [2], and consists of two sub-fields:
o the POSIX Extended Regular Expression (ERE) sub-field [12]
o a replacement (Repl) sub-field [2].
Additionally, RFC 3403 specifies that a flag character may be
appended, but the only flag currently defined there (the 'i' case
insensitivity flag) is not appropriate for ENUM - see later in this
document.
The ERE sub-field matches against the "Application Unique String";
for ENUM, this is defined in RFC 3761 to consist of digit characters,
with an initial '+' character. It is similar to a global-number-
digits production of a tel: URI, as specified in [13], but with
visual-separators removed. In short, it is a telephone number (see
[14]) in restricted format. All of these characters fall into the
US-ASCII equivalent range of UTF-8 encoding, as do the characters
significant to the ERE processing. Thus, for ENUM, there will be no
multi-byte characters within this sub-field.
The Repl sub-field can include a mixture of explicit text used to
construct a URI and characters significant to the substitution
expression, as defined in RFC 3403. Whilst the latter set all fall
into the US-ASCII equivalent range of UTF-8 encoding, this might not
be the case for all conceivable text used to construct a URI.
Presence of multi-byte characters could complicate URI generation and
processing routines.
URI generic syntax is defined in [15] as a sequence of characters
chosen from a limited subset of the repertoire of US-ASCII
characters. The current URIs use the standard URI character escaping
rules specified in the URI generic syntax, and so any multi-byte
characters will be pre-processed; they will not occur in the explicit
text used to construct a URI within the Repl sub-field. However, the
Internationalized Resource Identifier (IRI) is defined in [16] as
extending the syntax of URIs, and specifies a mapping from an IRI to
Conroy & Fujiwara Expires August 17, 2008 [Page 7]
Internet-Draft ENUM Experiences February 2008
a URI. IRI syntax allows characters with multi-byte UTF-8 encoding.
Given that this is the only place within an ENUM NAPTR where such
multi-byte encodings might reasonably be found, a simple solution is
to use the mapping method specified in section 3.1 of [16] to convert
any IRI into its equivalent URI.
This process consists of two elements; the domain part of an IRI MUST
be processed using Punycode if it has a non-ASCII domain name, and
the remainder MUST be processed using the extended escaping rules
specified in the IRI document if it contains characters outside the
normal URI repertoire. Using this process, there will be no non-
ASCII characters in any part of any URI, even if it has been
converted from an IRI that contains such characters.
From the analysis just given, it is possible to remove any
requirement to process characters outside the US-ASCII equivalent
range by adding very few restrictions. There is no obvious benefit
in providing characters outside this range. Handling multi-byte
characters complicates development and operation of client programs,
and many existing programs do not include such support.
As the gain from permitting characters outside the US-ASCII
equivalent range is unclear, and the costs of multi-byte character
processing are very clear, ENUM NAPTRs SHOULD NOT include characters
outside the printable US-ASCII equivalent range.
3.2. Case Sensitivity
The only place where NAPTR field content is case sensitive is in any
static text in the Repl sub-field of the Regexp field. Everywhere
else, case insensitive processing can be used.
The case insensitivity flag ('i') could be added at the end of the
Regexp field. However, in ENUM, the ERE sub-field operates on a
string defined as the '+' character, followed by a sequence of digit
characters. This flag is redundant for E2U NAPTRs, as it does not
act on the Repl sub-field contents.
Thus the case sensitivity flag is inappropriate for ENUM, and SHOULD
NOT be provisioned into E2U NAPTRs.
3.3. Regexp field delimiter
It is not possible to select a delimiter character that cannot appear
in one of the sub-fields. The '!' character is used as a delimiter
in all of the examples in RFC 3403 and in RFC 3761. It is the only
character seen in existing zones, and a number of different client
Conroy & Fujiwara Expires August 17, 2008 [Page 8]
Internet-Draft ENUM Experiences February 2008
implementations are still "hardwired" to expect this character as a
delimiter.
The '!' character cannot appear in the ERE sub-field. It may appear
in the content of some URIs, as it is a valid character (e.g. in http
URLs). If it is embedded in the static text of the Repl sub-field,
then that instance MUST be escaped using the standard technique
proposed in section RFC 3402; a backslash character (U+005C) should
be inserted before it in the string. Otherwise, a client may attempt
to process this as a standard delimiter and interpret the Repl sub-
field contents differently from the system that provisioned it.
3.4. Regexp Meta-character Issue
In ENUM, the ERE sub-field may include a literal character '+', as
the Application Unique String on which it operates includes this.
However, if it is present, then '+' MUST be escaped using a single
backslash character (to produce the sub-string U+005C U+002B), as '+'
is a meta-character in POSIX Extended Regular Expression syntax.
Not escaping the '+' character produces an invalid ERE, but is a
common mistake. Even standards have given incorrect examples; the
obsolete RFC 2916 [20] (Section 3.4.3 example 3) has this problem.
For example, the following NAPTR example is incorrect:
* IN NAPTR 100 10 "u" "E2U+sip" "!^+4655(.*)$!sip:\1@example.net!" .
This example MUST be written as:
* IN NAPTR 100 10 "u" "E2U+sip" "!^\+4655(.*)$!sip:\1@example.net!" .
Conroy & Fujiwara Expires August 17, 2008 [Page 9]
Internet-Draft ENUM Experiences February 2008
4. Unsupported NAPTRs
An ENUM client MAY discard a NAPTR received in response to an ENUM
query because:
o the NAPTR is syntactically or semantically incorrect,
o the NAPTR has a different (non-empty) DDDS Application identifier
from the 'E2U' used in ENUM,
o the ENUM client does not recognise the Enumservice held in that
NAPTR,
o the ENUM client has local knowledge that the URI that would be
generated by processing the NAPTR is not supported, or
o the end user has specified that this Enumservice is not to be
considered.
These conditions SHOULD NOT cause the whole ENUM query to terminate,
and processing SHOULD continue with the next NAPTR in the returned
Resource Record Set (RRSet).
When an ENUM client encounters a compound NAPTR (i.e. one containing
more than one Enumservice - see also Section 5.3.1) and cannot
process or cannot recognise one of the Enumservices within it, that
ENUM client SHOULD ignore this Enumservice and continue with the next
Enumservice within this NAPTR's Services field, discarding the NAPTR
only if it cannot handle any of the Enumservices contained. These
conditions SHOULD NOT be considered errors.
If a problem is detected when processing an ENUM query across
multiple domains (by following non-terminal NAPTR references), then
the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
continue at the next NAPTR after the non-terminal NAPTR that referred
to the domain in which the problem would have occurred. See
Section 6.2.2 for more details.
4.1. Non-compliant client behaviour
From experience monitoring current ENUM clients, a number of non-
compliant behaviours have been detected. These behaviours are
incorrect, but may be encountered in still operational client
implementations.
ENUM clients have been known to discard NAPTRs in which the Services
field holds more than one Enumservice.
Conroy & Fujiwara Expires August 17, 2008 [Page 10]
Internet-Draft ENUM Experiences February 2008
ENUM Clients have also been known to discard NAPTRs with a non-
trivial ("non-greedy") ERE sub-field expression (i.e. ones that are
not similar to "^.*$").
ENUM Clients have been known to discard NAPTRs that do not use '!' as
their Regexp delimiter character.
ENUM clients have been known to discard NAPTRs in which the delimiter
is NOT the last character in the Regexp field.
ENUM Clients have been known to discard NAPTRs with an empty Flags
field (i.e. "non-terminal" NAPTRs).
ENUM clients have been known to ignore the ORDER field value
entirely, sorting the NAPTRs in an RRSet based solely on the
PREFERENCE/PRIORITY field values.
Conroy & Fujiwara Expires August 17, 2008 [Page 11]
Internet-Draft ENUM Experiences February 2008
5. ORDER/PRIORITY Processing
5.1. Order/Priority values - general processing
RFC 3761 and RFC 3403 state that the ENUM client MUST sort the NAPTRs
using the ORDER field value ("lowest value is first") and SHOULD
order the NAPTRs using the PREFERENCE/PRIORITY field value as the
minor sort term (again, lowest value first). The NAPTRs in the
sorted list must be processed in order. Subsequent NAPTRs with worse
ORDER values must only be dealt with once the current ones with a
better ORDER value have been processed.
However, this stated behaviour is a simplification. ENUM clients may
not behave this way in practice, and so there may appear to be a
conflict between the specification and practice. For example, ENUM
clients will be incapable of using most NAPTRs as they do not support
the Enumservice specified (and the URI generated by those NAPTRs).
As such, they will discard the "unusable" NAPTRs and continue with
processing the "next best" NAPTR in the list.
Also, the end user may have pre-specified his or her own preference
for services to be used. Thus, an end user may specify that he or
she would prefer to use contacts with a "sip" Enumservice, and then
those with "email:mailto" service, and is not interested in any other
options. Thus the sorted list as proposed by the Registrant (and
published via ENUM) may be reordered. For example, a NAPTR with a
"sip" Enumservice may have a worse ORDER field value, and yet is
chosen before a NAPTR with an "h323" Enumservice and a better ORDER
value. This may occur even if the node the end user controls is
capable of handling other Enumservices.
ENUM clients may also include the end user "in the decision loop",
offering the end user the choice from a list of possible NAPTRs.
Given that the ORDER field value is the major sort term, one would
expect a conforming ENUM client to present only those NAPTRs with a
better ORDER field value as choices. However, if all the options
presented had been rejected, then the ENUM client might offer those
with the "next best" ORDER field value, and so on. As this may be
confusing for the end user, some clients simply offer all of the
available NAPTRs as options to the end user for his or her selection
at once.
In summary, some ENUM clients will take into account the Services
field value along with the ORDER and PREFERENCE/PRIORITY field
values, and may consider the preferences of the end user.
The Registrant and the ENUM zone provisioning system he or she uses
must be aware of this and SHOULD NOT rely on ENUM clients taking
Conroy & Fujiwara Expires August 17, 2008 [Page 12]
Internet-Draft ENUM Experiences February 2008
account of the value of the ORDER and the PREFERENCE/PRIORITY fields.
Specifically, it is unsafe to assume that a ENUM client will not
consider another NAPTR until it has discarded one with a better ORDER
value. The instruction (in RFC 3403 section 4.1 and section 8) may
or may not be followed strictly by different ENUM clients for
perfectly justifiable reasons.
Where the ENUM client presents a list of possible URLs to the end
user for his or her choice, it SHOULD attempt to keep as close as
possible to the ORDER and PREFERENCE/PRIORITY values specified by the
Registrant. However, a Registrant SHOULD place into his or her zone
only contacts that he or she is willing to support; even those with
the worst ORDER and PREFERENCE/PRIORITY values MAY be selected by an
end user.
5.2. Use of Order and Preference fields
NAPTRs in ENUM zones that hold incorrect ORDER values can cause major
problems. RFC 3403 highlights that having both ORDER and PREFERENCE/
PRIORITY fields is a historical artefact of the NAPTR resource record
type. It is reasonable to have a common default value for the ORDER
field, relying on the PREFERENCE/PRIORITY field to indicate the
preferred sort.
We have noticed a number of ENUM domains with NAPTRs that have
identical PREFERENCE/PRIORITY field values and different ORDER
values. This may be the result of an ENUM zone provisioning system
"bug" or a misunderstanding over the uses of the two fields.
To clarify, the ORDER field value is the major sort term, and the
PREFERENCE/PRIORITY field value is the minor sort term. Thus one
should expect to have a set of NAPTRs in a zone with identical ORDER
field values and different PREFERENCE/PRIORITY field values; not the
other way around.
To avoid these common mistakes, it is recommended that ENUM NAPTRs
SHOULD hold a default value in their ORDER field.
5.3. NAPTRs with identical ORDER/PRIORITY values
From experience, there are zones that hold discrete NAPTRs with
identical ORDER and identical PREFERENCE/PRIORITY field values. This
will lead to indeterminate client behaviour and so SHOULD NOT
normally occur.
Such a condition indicates that these NAPTRs are truly identical in
priority, and there is no preference between the services these
Conroy & Fujiwara Expires August 17, 2008 [Page 13]
Internet-Draft ENUM Experiences February 2008
NAPTRs offer. Implementers SHOULD NOT assume that the DNS will
deliver NAPTRs within an RRSet in a particular sequence.
Multiple NAPTRs with identical ORDER and identical PREFERENCE/
PRIORITY field values SHOULD NOT be provisioned into an RRSet, unless
the intent is that these NAPTRs are truly identical in priority and
there is no preference between them.
Some ENUM client implementations have considered this case to be an
error, and have rejected such duplicates entirely. Others have
attempted to further randomise the order in which such duplicates are
processed. Thus use of such duplicate NAPTRs is unwise, as client
implementations exist that will behave in different ways.
5.3.1. Compound NAPTRs and implicit ORDER/REFERENCE Values
With RFC 3761, it is possible to have more than one Enumservice
associated with a single NAPTR. Of course, the Enumservices share
the same Regexp field and so generate the same URI. Such a
"compound" NAPTR could well be used to indicate, for example, a
mobile phone that supports both "voice:tel" and "sms:tel"
Enumservices.
The services field in that case would be "E2U+voice:tel+sms:tel".
A Compound NAPTR can be treated as a set of NAPTRs each holding a
single Enumservice. These reconstructed NAPTRs share the same ORDER
and PREFERENCE/PRIORITY field values but should be treated as if each
had a logically different priority. In this case the reconstructed
NAPTR holding the leftmost Enumservice within the Compound NAPTR has
a better priority, and the reconstructed NAPTR holding the rightmost
Enumservice has the worst priority in this set.
To avoid indeterminate behaviour, it is recommended that ENUM clients
SHOULD process the Enumservices within a compound NAPTR in a left to
right sequence. ENUM provisioning systems SHOULD assume that such a
processing order will be used and provision the Enumservices within a
compound NAPTR accordingly.
5.4. Processing Order value across Domains
Using a different ORDER field value in different domains is
unimportant for most queries. However, DDDS includes a mechanism for
continuing a search for NAPTRs in another domain by including a
reference to that other domain in a "non-terminal" NAPTR. The
treatment of non-terminal NAPTRs is covered in the next section, but
if these are supported then it does have a bearing on the way that
ORDER and PREFERENCE/PRIORITY field values are processed.
Conroy & Fujiwara Expires August 17, 2008 [Page 14]
Internet-Draft ENUM Experiences February 2008
Two main questions remain from the specifications of DDDS and RFC
3761:
o If there is a different (lower) order field value in a domain
referred to by a non-terminal NAPTR, then does this mean that the
ENUM client discards any remaining NAPTRs in the referring RRSet?
o Conversely, if the domain referred to by a non-terminal NAPTR
contains entries that only have a higher ORDER field value, then
does the ENUM client ignore those NAPTRs in the referenced domain?
Whilst one interpretation of RFC 3761 is that the answer to both
questions is "yes", this is not the way that those examples of non-
terminal NAPTRs that do exist (and those ENUM clients that support
them) seem to be designed.
In keeping with the interpretation made so far, ENUM implementations
MUST consider the ORDER and PREFERENCE/PRIORITY values only within
the context of the domain currently being processed in an ENUM query.
These values MUST be discarded when processing other RRSets in the
query.
Conroy & Fujiwara Expires August 17, 2008 [Page 15]
Internet-Draft ENUM Experiences February 2008
6. Non-Terminal NAPTR Processing
6.1. Non-Terminal NAPTRs - necessity
Consider an ENUM RRSet that contains a non-terminal NAPTR record.
This non-terminal NAPTR holds, as its target, another domain that has
a set of NAPTRs. In effect, this is similar to the non-terminal
NAPTR being replaced by the NAPTRs contained in the domain to which
it points.
It is possible to have a non-terminal NAPTR in a domain that is,
itself, pointed to by another non-terminal NAPTR. Thus a set of
domains forms a "chain", and the list of NAPTRs to be considered is
the set of all NAPTRs contained in all of the domains in that chain.
For an ENUM management system to support non-terminal NAPTRs, it is
necessary for it to be able to analyse, validate and (where needed)
correct not only the NAPTRs in its current ENUM domain but also those
referenced by non-terminal NAPTRs in other domains. If the domains
pointed to have non-terminal NAPTRs of their own, the management
system will have to check each of the referenced domains in turn, as
their contents forms part of the result of a query on the "main" ENUM
domain. The domain content in the referenced domains may well not be
under the control of the ENUM management system, and so it may not be
possible to correct any errors in those RRSets. This is both complex
and prone to error in the management system design, and any reported
errors in validation may well be non-intuitive for users.
For an ENUM client, supporting non-terminal NAPTRs can also be
difficult. Processing non-terminal NAPTRs causes a set of sequential
DNS queries that can take an indeterminate time, and requires extra
resources and complexity to handle fault conditions like non-terminal
loops. The indeterminacy of response time makes ENUM supported
Telephony Applications difficult (such as in an "ENUM-aware" PBX),
whilst the added complexity and resources needed makes support
problematic in embedded devices like "ENUM-aware" mobile phones.
Given that, in principle, a non-terminal NAPTR can be replaced by the
NAPTRs in the domain to which it points, support of non-terminal
NAPTRs is not needed and non-terminal NAPTRs may not be useful.
Furthermore, some existing ENUM clients do not support non-terminal
NAPTRs and ignore them if received.
To avoid interoperability problems, some kind of acceptable advice is
needed on non-terminal NAPTRs. As current support is limited, non-
terminal NAPTRs SHOULD NOT be used in ENUM unless it is clear that
all ENUM clients this environment supports can process these.
Conroy & Fujiwara Expires August 17, 2008 [Page 16]
Internet-Draft ENUM Experiences February 2008
6.2. Non-Terminal NAPTRs - considerations
The following specific issues need to be considered if non-terminal
NAPTRs are to be supported in a particular environment. These issues
are gleaned from experience, and indicate the kinds of conditions
that should be considered before support for non-terminal NAPTRs is
contemplated. Note that these issues are in addition to the point
just mentioned on ENUM provisioning or management system complexity
and the potential for that management system to have no control over
the zone contents to which non-terminal NAPTRs in its managed zones
refer.
6.2.1. Non-Terminal NAPTRs - general
As mentioned earlier, a non-terminal NAPTR in one RRSet refers to the
NAPTRs contained in another domain. The NAPTRs in the domain
referred to by the non-terminal NAPTR may have a different ORDER
value from that in the referring non-terminal NAPTR. See Section 5.4
for details.
6.2.2. Non-Terminal NAPTRs - loop detection and response
Where a chain of non-terminal NAPTRs refers back to a domain already
traversed in the current query, this implies a "non-terminal" or
referential loop. An implementation MAY treat a chain of more than 5
domains traversed during a single ENUM query as an indication that a
self-referential loop has been entered.
There are many techniques that can be used to detect such a loop, but
the simple approach of counting the number of domains queried in the
current ENUM query suffices.
Where a loop has been detected, processing SHOULD continue at the
next NAPTR in the referring domain (i.e. after the non-terminal NAPTR
that included the reference that triggered the loop detection).
6.2.3. Field content in Non-Terminal NAPTRs
The set of specifications defining DDDS and its applications are
complex and multi-layered. This reflects the flexibility that the
system provides, but it does mean that some of the specifications
need clarification as to their interpretation, particularly where
non-terminal rules are concerned.
6.2.3.1. Flags field content with Non-Terminal NAPTRs
RFC 3761, section 2.4.1 states that the only flag character valid for
use with the "E2U" DDDS Application is 'u'. The flag 'u' is defined
Conroy & Fujiwara Expires August 17, 2008 [Page 17]
Internet-Draft ENUM Experiences February 2008
(in RFC 3404 [4], section 4.3) thus: 'The "u" flag means that the
output of the Rule is a URI'.
RFC 3761 section 2.4.1 also states that an empty Flags field
indicates a non-terminal NAPTR. This is also the case for other DDDS
Application specifications, such as that specified in RFC 3404. One
could well argue that this is a feature potentially common to all
DDDS Applications, and so might have been specified in RFC 3402 or
RFC 3403.
The Flags field will be empty in non-terminal NAPTRs encountered in
ENUM processing. ENUM does not have any other way to indicate a non-
terminal NAPTR.
6.2.3.2. Services field content with Non-Terminal NAPTRs
Furthermore, RFC 3761 states that any Enumservice Specification
requires definition of the URI that is the expected output of this
Enumservice. This means that, at present, there is no way to specify
an Enumservice that is non-terminal; such a non-terminal NAPTR has,
by definition, no URI as its expected output, instead returning a key
(DNS domain name) that is to be used in the "next round" of DDDS
processing.
This in turn means that a non-terminal NAPTR cannot hold a valid
(non-empty) Services field when used in ENUM. Section 2.4.2 of RFC
3761 specifies the syntax for this field content, and requires at
least one element of type <servicespec> (i.e. at least one
Enumservice identifier). Given that there cannot be a non-terminal
Enumservice (and so no such Registered Enumservice identifier), this
syntax cannot be met with a non-terminal NAPTR; there are no non-
terminal Enumservices to put into this field.
A reasonable interpretation of the specifications is that for a non-
terminal NAPTR, the Services field must also be empty. This appears
to be the approach taken by those clients that do either process non-
terminal NAPTRs or check the validity of the fields.
In keeping with existing implementations, in a non-terminal NAPTR
encountered in an ENUM query, the Services field SHOULD be empty, and
clients SHOULD ignore any content it contains.
6.2.3.3. Regular Expression and Replacement field content with Non-
terminal NAPTRs
The descriptive text in section 4.1 of RFC 3403 is intended to
explain how the fields are to be used in a NAPTR. However, the
descriptions associated with the Regexp and Replacement elements have
Conroy & Fujiwara Expires August 17, 2008 [Page 18]
Internet-Draft ENUM Experiences February 2008
led to some confusion over which of these should be considered when
dealing with non-terminal NAPTRs.
RFC 3403 is specific; these two elements are mutually exclusive.
This means that if the Regexp element is not empty then the
Replacement element must be empty, and vice versa. However, is does
not specify which is used with terminal and non-terminal rules.
The descriptive text of section 4.1 of RFC 3403 for the NAPTR
Replacement element shows that this element holds an uncompressed
domain name. Thus it is clear that this element cannot be used to
deliver the terminal string for any DDDS application that does not
have a domain name as its intended terminal output.
However, the first paragraph of descriptive text for the NAPTR Regexp
element has led to some confusion. It appears that the Regexp
element is to be used to find "the next domain name to lookup". This
might be interpreted as meaning that a client program processing the
DDDS application could need to examine each non-terminal NAPTR to
decide whether the Regexp element or instead the Replacement element
were to be used to construct the key (a domain name) to be used next
in non-terminal rule processing.
Given that a NAPTR holding a terminal rule (a "terminal NAPTR") must
use the Substitution expression field to generate the expected output
of that DDDS application, the Regexp element is also used in such
rules. Indeed, unless that DDDS application has a domain name as its
terminal output, the Regexp element is the only possibility.
Thus from the descriptive text of this section, a Replacement element
can be used only in NAPTRs holding a non-terminal rule (a "non-
terminal NAPTR") unless that DDDS Application has a domain name as
its terminal output, whilst the alternative Regexp element may be
used either to generate a domain name as the next key to be used in
the non-terminal case, or to generate the output of the DDDS
application.
Note that each DDDS Application is free to specify the set of flags
to be used with that application. This includes specifying whether a
particular flag is associated with a terminal or non-terminal rule,
and also to specify the interpretation of an empty Flags field (i.e.
whether this is to be interpreted as a terminal or non-terminal rule,
and if it is terminal, then the expected output). ENUM (as specified
in section 2.4.1 of RFC 3761) uses only the 'u' flag, with an empty
Flags field indicating a non-terminal NAPTR.
The general case in which a client program must check which of the
two elements to use in non-terminal NAPTR processing complicates
Conroy & Fujiwara Expires August 17, 2008 [Page 19]
Internet-Draft ENUM Experiences February 2008
implementation, and this interpretation has NOT been made in current
ENUM implementations. It would be useful to define exactly when a
client program can expect to process the Regexp element and when to
expect to process the Replacement element, if only to improve
robustness.
In keeping with current implementations (and all other DDDS
applications other than the URN-specific example in RFC 3404), a non-
terminal NAPTR MUST include its target domain in the (non-empty)
Replacement field. This field MUST be interpreted as holding the
domain name that forms the next key output from this non-terminal
rule. Similarly, the Regexp field SHOULD be empty in a non-terminal
NAPTR encountered in ENUM processing, and ENUM clients MUST ignore
its content.
Conroy & Fujiwara Expires August 17, 2008 [Page 20]
Internet-Draft ENUM Experiences February 2008
7. Backwards Compatibility
7.1. Services field syntax
RFC 3761 is the current standard for the syntax for NAPTRs supporting
the ENUM DDDS application. This obsoletes the original specification
that was given in RFC 2916. There has been a change to the syntax of
the Services field of the NAPTR that reflects a refinement of the
concept of ENUM processing.
As defined in RFC 3403, there is now a single identifier that
indicates the DDDS Application. In the obsolete specification (RFC
2915), there were zero or more "Resolution Service" identifiers (the
equivalent of the DDDS Application). The same identifier string is
defined in both RFC 3761 and in the old RFC 2916 specifications for
the DDDS identifier or the Resolution Service; "E2U".
Also, RFC 3761 defines at least one but potentially several
Enumservice sub-fields; in the obsolete specification, only one
"protocol" sub-field was allowed.
In many ways, the most important change for implementations is that
the order of the sub-fields has been reversed. RFC 3761 specifies
that the DDDS Application identifier is the leftmost sub-field,
followed by one or more Enumservice sub-fields, each separated by the
'+' character delimiter. RFC 2916 specified that the protocol sub-
field was the leftmost, followed by the '+' delimiter, in turn
followed by the "E2U" resolution service tag.
RFC 2915 and RFC 2916 have been obsoleted by RFC 3401 - RFC 3404 and
by RFC 3761. However, RFC 3824 [21] suggests that ENUM clients
should be prepared to accept NAPTRs with the obsolete syntax. Thus,
an ENUM client implementation may have to deal with both forms. This
need not be difficult. For example, an implementation could process
the Services field into a set of tokens, and expect exactly one of
these tokens to be "E2U". In this way, the ENUM client might be
designed to handle both the old and the current forms without added
complexity.
To facilitate this method, IANA should reject any request to register
an Enumservice with the label "E2U".
To summarise, ENUM clients MUST support ENUM NAPTRs according to RFC
3761 syntax. ENUM clients SHOULD also support ENUM NAPTRs according
to the obsolete syntax of RFC 2916; there are still zones that hold
"old" syntax NAPTRs. ENUM zones MUST NOT be provisioned with NAPTRs
according to the obsolete form, and MUST be provisioned with NAPTRs
in which the Services field is according to RFC 3761.
Conroy & Fujiwara Expires August 17, 2008 [Page 21]
Internet-Draft ENUM Experiences February 2008
8. Collected Implications for ENUM Provisioning
ENUM NAPTRs SHOULD NOT include characters outside the printable US-
ASCII equivalent range (U+0020 to U+007E) unless it is clear that all
ENUM clients they are designed to support will be able correctly to
process such characters. If ENUM zone provisioning systems require
non-ASCII characters, these systems SHOULD encode the non-ASCII data
to emit only US-ASCII characters by applying the appropriate
mechanism ([11], [16]). Non-printable characters SHOULD NOT be used,
as ENUM clients may need to present NAPTR content in a human-readable
form.
The case sensitivity flag ('i') is inappropriate for ENUM, and SHOULD
NOT not be provisioned into the Regexp field of E2U NAPTRs.
ENUM zone provisioning systems SHOULD use '!' (U+0021) as their
Regexp delimiter character.
If the Regexp delimiter is a character in the static text of the Repl
sub-field, it MUST be "escaped" using the escaped-delimiter
production of the BNF specification shown in section 3.2 of RFC 3402
(i.e. "\!", U+005C U+0021).
If present in the ERE sub-field of an ENUM NAPTR, the literal
character '+' MUST be escaped as "\+" (i.e. U+005C U+002B).
The Registrant and the ENUM zone provisioning system he or she uses
SHOULD NOT rely on ENUM clients taking strict account of the value of
the ORDER and the PREFERENCE/PRIORITY fields in ENUM NAPTRs. Thus, a
Registrant SHOULD place into his or her zone only contacts that he or
she is willing to support; even those with the worst ORDER and
PREFERENCE/PRIORITY values MAY be selected by an end user.
Many apparent mistakes in ORDER and PREFERENCE/PRIORITY values have
been detected in provisioned ENUM zones. To avoid these common
mistakes, provisioning systems SHOULD NOT use different ORDER field
values for NAPTRs in a Resource Record Set (RRSet). To generalise,
all ENUM NAPTRs SHOULD hold a default value in their ORDER field. A
value of "100" is recommended, as it seems to be used in most
provisioned domains.
Multiple NAPTRs with identical ORDER and identical PREFERENCE/
PRIORITY field values SHOULD NOT be provisioned into an RRSet, unless
the intent is that these NAPTRs are truly identical and there is no
preference between them. Implementers SHOULD NOT assume that the DNS
will deliver NAPTRs within an RRSet in a particular sequence.
An ENUM zone provisioning system SHOULD assume that, if it generates
Conroy & Fujiwara Expires August 17, 2008 [Page 22]
Internet-Draft ENUM Experiences February 2008
compound NAPTRs, the Enumservices will normally be processed in left
to right order within such NAPTRs.
ENUM zone provisioning systems SHOULD assume that, once a non-
terminal NAPTR has been selected for processing, the ORDER field
value in a domain referred to by that non-terminal NAPTR will be
considered only within the context of that referenced domain (i.e.
the ORDER value will be used only to sort within the current RRSet,
and will not be used in the processing of NAPTRs in any other RRSet).
Whilst this client behaviour is non-compliant, ENUM provisioning
systems and their users should be aware that some ENUM Clients have
been detected with poor (or no) support for non-trivial ERE sub-field
expressions.
ENUM provisioning systems SHOULD be cautious in the use of multiple
Backreference patterns in the Repl sub-field of NAPTRs they
provision. Some Clients have limited buffer space for character
expansion when generating URIs.
As current support is limited, non-terminal NAPTRs SHOULD NOT be
provisioned in ENUM zones unless it is clear that all ENUM clients
this environment supports can process these.
When populating a set of domains with NAPTRs, ENUM zone provisioning
systems SHOULD NOT configure non-terminal NAPTRs so that more than 5
such NAPTRs will be processed in an ENUM query.
In a non-terminal NAPTR encountered in an ENUM query (i.e. one with
an empty Flags field), the Services field SHOULD be empty.
A non-terminal NAPTR MUST include its target domain in the (non-
empty) Replacement field. This field MUST be interpreted as holding
the domain name that forms the next key output from this non-terminal
rule. The Regexp field MUST be empty in a non-terminal NAPTR
intended to be encountered during an ENUM query.
ENUM zones MUST NOT be provisioned with NAPTRs according to the
obsolete form, and MUST be provisioned with NAPTRs in which the
services field is according to RFC 3761.
Conroy & Fujiwara Expires August 17, 2008 [Page 23]
Internet-Draft ENUM Experiences February 2008
9. Collected Implications for ENUM Clients
ENUM clients SHOULD NOT discard NAPTRs in which they detect
characters outside the US-ASCII "printable" range (0x20 to 0x7E
hexadecimal).
ENUM Clients MAY discard NAPTRs that have octets in the Flags,
Services, or Regexp fields that have byte values outside the US-ASCII
equivalent range (i.e. byte values above 0x7F). Clients MUST be
ready to encounter NAPTRs with such values without failure.
ENUM clients SHOULD NOT assume that the delimiter is the last
character of the Regexp field.
ENUM clients SHOULD discard NAPTRs that have more or less than 3
unescaped instances of the delimiter character within the Regexp
field.
Each ENUM client MAY reorder the NAPTRs it receives only to match an
explicit preference pre-specified by its end user.
Where the ENUM client presents a list of possible URLs to the end
user for his or her choice, it MAY present all NAPTRs, not just the
ones with the highest currently unprocessed ORDER field value. The
client SHOULD attempt to keep as close as possible to the ORDER and
PREFERENCE/PRIORITY values specified by the Registrant.
ENUM clients SHOULD accept all NAPTRs with identical ORDER and
identical PREFERENCE/PRIORITY field values, and process them in the
sequence in which they appear in the DNS response. (There is no
benefit in further randomising the order in which these are
processed, as intervening DNS Servers might have done this already).
ENUM clients receiving compound NAPTRs (i.e. ones with more than one
Enumservice) SHOULD process these Enumservices using a left-to-right
sort ordering, so that the first Enumservice to be processed will be
the leftmost one, and the last will be the rightmost one.
ENUM clients SHOULD consider the ORDER field value only when sorting
NAPTRs within a single RRSet. The ORDER field value SHOULD NOT be
taken into account when processing NAPTRs across a sequence of DNS
queries created by traversal of non-terminal NAPTR references.
ENUM Clients MUST be ready to process NAPTRs that use a different
character from '!' as their Regexp Delimiter without failure.
ENUM Clients MUST be ready to process NAPTRs that have non-trivial
patterns in their ERE sub-field values without failure.
Conroy & Fujiwara Expires August 17, 2008 [Page 24]
Internet-Draft ENUM Experiences February 2008
ENUM Clients MUST be ready to process NAPTRs with a DDDS Application
identifier other than 'E2U' without failure.
ENUM Clients MUST be ready to process NAPTRs with many copies of a
Backreference pattern within the Repl sub-field without failure.
If a NAPTR is discarded, this SHOULD NOT cause the whole ENUM query
to terminate and processing SHOULD continue with the next NAPTR in
the returned Resource Record Set (RRSet).
When an ENUM client encounters a compound NAPTR (i.e. one containing
more than one Enumservice) and cannot process or cannot recognise one
of the Enumservices within it, that ENUM client SHOULD ignore this
Enumservice and continue with the next Enumservice within this
NAPTR's Services field, discarding the NAPTR only if it cannot handle
any of the Enumservices contained. These conditions SHOULD NOT be
considered errors.
9.1. Non-terminal NAPTR processing
ENUM Clients MUST be ready to process NAPTRs with an empty Flags
field ("non-terminal" NAPTRs) without failure. More generally, non-
terminal NAPTR processing SHOULD be implented, but ENUM clients MAY
discard non-terminal NAPTRs they encounter.
ENUM clients SHOULD ignore any content of the Services field when
encountering a non-terminal NAPTR with an empty Flags field.
ENUM clients receiving a non-terminal NAPTR with an empty Flags field
MUST treat the Replacement field as holding the domain name to be
used in the next round of the ENUM query. An ENUM client MUST
discard such a non-terminal NAPTR if the Replacement field is empty
or does not contain a valid domain name. By definition, it follows
that the Regexp field will be empty in such a non-terminal NAPTR, and
MUST be ignored by ENUM clients
If a problem is detected when processing an ENUM query across
multiple domains (by following non-terminal NAPTR references), then
the ENUM query SHOULD NOT be abandoned, but instead processing SHOULD
continue at the next NAPTR after the non-terminal NAPTR that referred
to the domain in which the problem would have occurred.
If all NAPTRs in a domain traversed as a result of a reference in a
non-terminal NAPTR have been discarded, then the ENUM client SHOULD
continue its processing with the next NAPTR in the "referring" RRSet
(i.e. the one including the non-terminal NAPTR that caused the
traversal).
Conroy & Fujiwara Expires August 17, 2008 [Page 25]
Internet-Draft ENUM Experiences February 2008
ENUM clients MAY consider a chain of more than 5 "non-terminal"
NAPTRs traversed in a single ENUM query as an indication that a
referential loop has been entered.
Where a domain is about to be entered as the result of a reference in
a non-terminal NAPTR, and the ENUM client has detected a potential
referential loop, then the client SHOULD discard the non-terminal
NAPTR from its processing and continue with the next NAPTR in its
list. It SHOULD NOT make the DNS query indicated by that non-
terminal NAPTR.
ENUM clients MUST support ENUM NAPTRs according to RFC 3761 syntax.
ENUM clients SHOULD also support ENUM NAPTRs according to the
obsolete syntax of RFC 2916; there are still zones that hold "old"
syntax NAPTRs.
Conroy & Fujiwara Expires August 17, 2008 [Page 26]
Internet-Draft ENUM Experiences February 2008
10. Security Considerations
In addition to the security implications of recommendations in this
document, those in the basic use of ENUM (and specified in the
normative documents for this protocol) should be considered as well;
this document does not negate those in any way.
The clarifications throughout this document are intended only as
that; clarifications of text in the normative documents. They do not
appear to have any security implications above those mentioned in the
normative documents.
The suggestions in Section 3, Section 5, and Section 7 do not appear
to have any security considerations (either positive or negative).
The suggestions in Section 6.2.2 are a valid approach to a known
security threat. It does not open an advantage to an attacker in
causing excess processing or memory usage in the client. It does,
however, mean that an ENUM client will traverse a "tight loop" of
non-terminal NAPTRs in two domains 5 times before the client detects
this as a loop; this does introduce slightly higher processing load
than would be provided using other methods, but avoids the risks they
incur.
The use of "non-greedy" regular expressions with Backreference
patterns in the Repl sub-field, whilst it is a standard feature of
DDDS, does create the potential for buffer overrun attacks.
Provisioning system designers SHOULD be aware of this and SHOULD
limit the repeated use of Backreference replacement patterns.
Conversely, ENUM client implementers SHOULD avoid using fixed
character buffers when generating URIs from Repl sub-fields that
include Backreference patterns, and MUST avoid failure in the case of
buffer exhaustion.
Conroy & Fujiwara Expires August 17, 2008 [Page 27]
Internet-Draft ENUM Experiences February 2008
11. IANA Considerations
This document includes one IANA consideration. This is the
suggestion (in Section 7.1) that no-one should be allowed to register
an Enumservice with any of its identifying tags set to "E2U".
IANA MUST NOT register an Enumservice with any of its identifying
tags set to "E2U". Any such requests SHALL be rejected.
Conroy & Fujiwara Expires August 17, 2008 [Page 28]
Internet-Draft ENUM Experiences February 2008
12. Acknowledgements
We would like to thank the various development teams who implemented
ENUM (both creation systems and clients) and who read the normative
documents differently - without these differences it would have been
harder for us all to develop robust clients and suitably conservative
management systems. We would also thank those who allowed us to
check their implementations to explore behaviour; their trust and
help were much appreciated.
In particular, thanks to Richard Stastny for his hard work on a
similar task TS 102 172 [22] under the aegis of ETSI, and for
supporting some of the ENUM implementations that exist today.
Finally, thanks for the dedication of Michael Mealling in giving us
such detailed DDDS specifications, without which the ENUM development
effort would have had a less rigourous framework on which to build.
This document reflects how complex a system it is: Without the
intricacy of RFC 3401 - RFC 3404 and the work that went into them, it
could have been very difficult to ensure interoperability.
Conroy & Fujiwara Expires August 17, 2008 [Page 29]
Internet-Draft ENUM Experiences February 2008
13. References
13.1. Normative References
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405,
October 2002.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[7] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[8] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[9] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[10] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile
for Internationalized Domain Names (IDN)", RFC 3491,
March 2003.
[11] Costello, A., "Punycode: A Bootstring encoding of Unicode for
Internationalized Domain Names in Applications (IDNA)",
RFC 3492, March 2003.
[12] Institute of Electrical and Electronics Engineers, "Information
Technology - Portable Operating System Interface (POSIX) - Part
2: Shell and Utilities (Vol. 1)", IEEE Standard 1003.2,
January 1993.
Conroy & Fujiwara Expires August 17, 2008 [Page 30]
Internet-Draft ENUM Experiences February 2008
[13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[14] ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164, February 2005.
[15] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[16] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
13.2. Informative References
[17] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[18] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[19] American National Standards Institute, "Coded Character Set -
7-bit American Standard Code for Information Interchange",
ANSI X3.4, 1986.
[20] Faltstrom, P., "E.164 number and DNS", RFC 2916,
September 2000.
[21] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
numbers with the Session Initiation Protocol (SIP)", RFC 3824,
June 2004.
[22] ETSI, "Minimum Requirements for Interoperability of European
ENUM Implementations", ETSI TS 102 172, October 2004.
Conroy & Fujiwara Expires August 17, 2008 [Page 31]
Internet-Draft ENUM Experiences February 2008
Authors' Addresses
Lawrence Conroy
Roke Manor Research
Roke Manor
Old Salisbury Lane
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lconroy@insensate.co.uk
URI: http://www.sienum.co.uk
Kazunori Fujiwara
Japan Registry Service Co., Ltd.
Chiyoda First Bldg. East 13F
3-8-1 Nishi-Kanda Chiyoda-ku
Tokyo 101-0165
JAPAN
Email: fujiwara@jprs.co.jp
URI: http://jprs.jp/en/
Conroy & Fujiwara Expires August 17, 2008 [Page 32]
Internet-Draft ENUM Experiences February 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Conroy & Fujiwara Expires August 17, 2008 [Page 33]
