One document matched: draft-ietf-enum-experiences-07.txt
Differences from draft-ietf-enum-experiences-06.txt
ENUM L. Conroy
Internet-Draft RMRL
Intended status: Informational K. Fujiwara
Expires: September 21, 2007 JPRS
March 20, 2007
ENUM Implementation Issues and Experiences
<draft-ietf-enum-experiences-07.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 September 21, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Conroy & Fujiwara Expires September 21, 2007 [Page 1]
Internet-Draft ENUM Experiences March 2007
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 is advisory, and produced as a help to others
in 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 . . . . . . . . . . . . . . . . . . . 5
3.1. Character Sets - Non-ASCII considered harmful . . . . . . 5
3.2. Case Sensitivity . . . . . . . . . . . . . . . . . . . . . 8
3.3. RegExp field delimiter . . . . . . . . . . . . . . . . . . 8
3.4. RegExp Meta-character Issue . . . . . . . . . . . . . . . 9
4. ORDER/PRIORITY Processing . . . . . . . . . . . . . . . . . . 11
4.1. Order/Priority values - general processing . . . . . . . . 11
4.2. NAPTRs with identical ORDER/PRIORITY values . . . . . . . 13
4.2.1. Compound NAPTRs and implicit ORDER/REFERENCE Values . 14
4.3. Compound NAPTR Processing . . . . . . . . . . . . . . . . 14
4.4. Processing Order value across Domains . . . . . . . . . . 15
5. Non-Terminal NAPTR Processing . . . . . . . . . . . . . . . . 17
5.1. Non-Terminal NAPTRs - necessity . . . . . . . . . . . . . 17
5.2. Non-Terminal NAPTRs - future implementation . . . . . . . 18
5.2.1. Non-Terminal NAPTRs - general . . . . . . . . . . . . 18
5.2.2. Non-Terminal NAPTRs - loop detection and response . . 19
5.3. Interpretation of RFC 3403 and RFC 3761 . . . . . . . . . 19
5.3.1. Flags field content with Non-Terminal NAPTRs . . . . . 20
5.3.2. Services field content with Non-Terminal NAPTRs . . . 20
5.3.3. Regular Expression and Replacement field content
with non-terminal NAPTRs . . . . . . . . . . . . . . . 21
6. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 24
6.1. Services field syntax . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Conroy & Fujiwara Expires September 21, 2007 [Page 2]
Internet-Draft ENUM Experiences March 2007
1. Terminology
This document is Advisory, and does not specify a standard of any
kind. Note that recommendations here contain the words "must",
"require", "should", and "may". This particular document does not
form a standard and so these terms DO NOT hold their normative
definitions. The proposals include these terms from observation of
behaviour and for internal consistency, where Client and Server
recommendations have to match.
Conroy & Fujiwara Expires September 21, 2007 [Page 3]
Internet-Draft ENUM Experiences March 2007
2. Introduction
2.1. Document Goal
This document has been in place for a considerable period. The goal
has always been 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. It does mention
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.
It also covers topics that may be included in updates or
clarifications to the applicable standards for ENUM. The text here
is not, in any way, to be treated as a standard. However, those
topics that impinge on candidates for standards update are marked in
the text.
The ENUM protocol ([1]) and the Dynamic Delegation Discovery System
(DDDS, [2] [3] [4] [5] [6]) are defined elsewhere, and those
documents alone form the normative definition of the ENUM system.
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.
2.2. Changes since last version
Since the last version of this document, a separate draft [20] has
been produced to specify the requirement for EDNS0 support when
processing ENUM queries and responses. The advisory text covering
the remaining topics can be ascertained by a thorough analysis of all
of the existing DNS standard documents, and so is not required
separately here. Thus, the section in the previous version of this
document that covered DNS issues has been removed entirely. In this
version we have tried to bracket text impinging on potential updates
to standards inside <STD> and </STD> tags. Similarly, text merely
reiterating behaviour specified in standards is marked with <STBO>
and </STBO>. Some observations from trials have been clarified, and
where possible we have bracketed advisory observations with <ADV> and
</ADV> pairs. Finally, where a common approach may lead to easier
interoperation, we have made recommendations and bracketed those with
<ITW> and </ITW> pairs.
Conroy & Fujiwara Expires September 21, 2007 [Page 4]
Internet-Draft ENUM Experiences March 2007
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 specified in [7].
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 [21] 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. Similarly, if NAPTR content
is shown to an end user so that he or she may choose, it is important
that the content is "human readable". Thus it is unwise to use non-
printable characters 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 a domain name encoded according to the
standard DNS mechanism [8][9]. With the introduction of
Internationalized Domain Name (IDN) support, this domain name MUST be
further encoded using Punycode [10]. As this 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 US-ASCII equivalent range, so multi-byte characters cannot occur.
The Services field includes the DDDS Application identifier ("E2U")
Conroy & Fujiwara Expires September 21, 2007 [Page 5]
Internet-Draft ENUM Experiences March 2007
used for ENUM, the '+' character used to separate tokens, and a set
of ENUMservice identifiers, any of which may include the ':'
separator character. In section 2.4.2 of RFC 3761 these identifiers
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 [11]
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 [12], but with
visual-separators removed. In short, it is a telephone number (see
[13]) 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 [14] 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 [15] as extending the syntax of URIs, and specifies a mapping from
an IRI to 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
Conroy & Fujiwara Expires September 21, 2007 [Page 6]
Internet-Draft ENUM Experiences March 2007
multi-byte encodings might reasonably be found, a simple solution is
to use the mapping method specified in section 3.1 of [15] 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.
Taking into account the existing client base, it is RECOMMENDED that:
<STD item="01">
Spec All ENUMservice registrations should REQUIRE that any
static text in the repl sub-field is encoded using only
characters in the US-ASCII equivalent range that are
"printable". If any of the static text characters do fall
outside this range then they MUST be pre-processed using an
IRI/URI-specific "escape" mechanism such as that specified
in section 3.1 of [15] to re-encode them only using US-
ASCII equivalent printable characters (those in the range
U+0020 to U+007E).
</STD>
Finally, the majority of ENUM clients in use today do not support
multi-byte encodings of the Unicode Consortium's Universal Character
Set (UCS). This is a reasonable choice, particularly for "small
footprint" implementations, and they may not be able to support NAPTR
content that is non-printable as they need to present the content to
an end user for selection. Thus, it is advised that:
<ADV item="02">
Client ENUM clients have been known to discard NAPTRs in which
they detect characters not in the US-ASCII "printable"
range (0x20 to 0x7E hexadecimal).
</ADV>
ENUM zone provisioning systems should consider this. It is
RECOMMENDED that:
<ITW item="03">
Conroy & Fujiwara Expires September 21, 2007 [Page 7]
Internet-Draft ENUM Experiences March 2007
Server ENUM zone provisioning systems should not use unescaped
non-ASCII characters in the NAPTRs they generate unless it
is clear that all ENUM clients they are designed to support
will be able correctly to process such characters.
</ITW>
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. Thus this flag is redundant for E2U NAPTRs, as it does
not act on the repl sub-field contents.
To avoid the confusion that this generates, It is RECOMMENDED that:
<STD item="04">
Server When populating ENUM zones with NAPTRs, provisioning
systems should not use the 'i' RegExp field flag, as it has
no effect and some ENUM clients do not expect it.
Client ENUM clients should not assume that the delimiter is the
last character of the field.
</STD>
3.3. RegExp field delimiter
It is not possible to select a delimiter character that cannot appear
in one of the sub-fields. Some old clients are "hardwired" to expect
the character '!' as a delimiter. This is used in an example in RFC
3403.
It is RECOMMENDED that:
<ITW item="05">
Server ENUM zone provisioning systems should use '!' (U+0021) as
their RegExp delimiter character.
</ITW>
Conroy & Fujiwara Expires September 21, 2007 [Page 8]
Internet-Draft ENUM Experiences March 2007
From experience, a number of different client implementations are
still "hardwired" to expect this character as a delimiter.
Administrators of ENUM Provisioning systems are advised that:
<ADV item="06">
Client ENUM clients have been known to discard NAPTRs that do not
use '!' as a RegExp delimiter.
</ADV>
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).
<STBO item="07">
Thus, it is further RECOMMENDED that:
Server ENUM zone provisioning systems must ensure that, 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).
Finally, in keeping with RFC 3402:
Client ENUM clients should discard NAPTRs that have more or less
than 3 "unescaped" instances of the delimiter character
within the RegExp field.
</STBO>
3.4. RegExp Meta-character Issue
<STBO item="08">
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 as '+' is a meta-character in POSIX Extended
Regular Expression syntax.
The following NAPTR example is incorrect:
* IN NAPTR 100 10 "u" "E2U+sip" "!^+46555(.*)$!sip:\1@example.net!" .
This example MUST be written as:
Conroy & Fujiwara Expires September 21, 2007 [Page 9]
Internet-Draft ENUM Experiences March 2007
* IN NAPTR 100 10 "u" "E2U+sip" "!^\+46555(.*)$!sip:\1@example.net!"
.
Thus, it is RECOMMENDED that:
Server If present in the ERE sub-field of an ENUM NAPTR, '+' must
be written as "\+" (i.e. U+005C U+002B).
</STBO>
Conroy & Fujiwara Expires September 21, 2007 [Page 10]
Internet-Draft ENUM Experiences March 2007
4. ORDER/PRIORITY Processing
4.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 less
preferred ORDER values must only be dealt with once the current ones
with a "winning" ORDER value have been processed.
However, this stated behaviour is a simplification; ENUM clients may
not behave this way in practice, and so there is 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
(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.
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 "losing" ORDER field value, and yet is
chosen before a NAPTR with an "h323" ENUMservice and a "winning"
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
"winning" 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
"in one go".
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 September 21, 2007 [Page 11]
Internet-Draft ENUM Experiences March 2007
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 "winning"
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.
To avoid the risk of variable behaviour, it is RECOMMENDED that:
<STD item="09">
Server ENUM zone provisioning systems should not use different
ORDER values for NAPTRs in a Resource Record Set (RRSet).
</STD>
From experience, incorrect ORDER values in ENUM zones is a major
source of problems. Although it is by no means required, it is
further RECOMMENDED that:
<ITW item="10">
Server ENUM zone provisioning systems should use a value of 100 as
the default ORDER value to be used with all NAPTRs.
</ITW>
When populating an RRSet with NAPTRs, it is RECOMMENDED that:
<ADV item="11">
Server A Registrant should not expect the ENUM client to ignore
NAPTRs with higher ORDER field values - the "winning" ones
may have been discarded.
Server A Registrant should not expect ENUM clients to conform to
the ORDER and PREFERENCE/PRIORITY sort order he or she has
specified for NAPTRs; end users may have their own
preferences for ENUMservices.
</ADV>
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. To improve interworking whilst still accepting that end
users with ENUM clients have valid reasons for preferring particular
Conroy & Fujiwara Expires September 21, 2007 [Page 12]
Internet-Draft ENUM Experiences March 2007
URL schemes regardless of the preference specified in an RRSet, it is
RECOMMENDED that:
<ITW item="12">
Client Each ENUM client may reorder the NAPTRs it receives only to
match an explicit preference pre-specified by its end user.
Client ENUM clients that offer a list of contacts to the end user
for his or her choice may present all NAPTRs, not just the
ones with the highest currently unprocessed ORDER field
value.
Server A Registrant should not assume which NAPTR choices will be
presented to an end user "at once".
</ITW>
<STBO item="13">
The impact of this is that a Registrant should place into his or her
zone only contacts that he or she is willing to support; even those
with the "least preferred" ORDER and PREFERENCE/PRIORITY values may
be selected by an end user.
Finally, 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.
</STBO>
4.2. 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 occur.
However, in the spirit of being liberal in what is allowed, it is
RECOMMENDED that:
<ITW item="14">
Conroy & Fujiwara Expires September 21, 2007 [Page 13]
Internet-Draft ENUM Experiences March 2007
Client 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 may
do this already).
Conversely, populating the records with these identical values is
unwise, as it may lead to indeterminate client behaviour, and so it
is RECOMMENDED that:
Server When populating ENUM RRSets with NAPTRs, ENUM zone
provisioning systems should not have more than one NAPTR
with the same ORDER and the same PREFERENCE/PRIORITY field
values in any given RRSet, as ENUM clients may reject the
response, and the sequence in which these NAPTRs are
delivered to the client may vary.
</ITW>
4.2.1. Compound NAPTRs and implicit ORDER/REFERENCE Values
There is one special case in which one could derive a set of NAPTRs
with identical ORDER and identical PREFERENCE/PRIORITY fields. This
will not exist explicitly in the RRSet delivered to the client, but
may occur whilst processing a "Compound" NAPTR, and is dealt with
next.
4.3. Compound NAPTR Processing
With RFC 3761, it is possible to have more than one ENUMservice
associated with a single NAPTR. Of course, the different
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.
This compound NAPTR may be reconstructed into a set of NAPTRs each
holding a single ENUMservice. However, in this case the members of
this set all logically hold the same ORDER and PREFERENCE/PRIORITY
field values.
In this case, it is RECOMMENDED that:
<ITW item="15">
Conroy & Fujiwara Expires September 21, 2007 [Page 14]
Internet-Draft ENUM Experiences March 2007
Client 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.
Server An ENUM zone provisioning system should assume that, if it
generates compound NAPTRs, the ENUMservices will normally
be processed in left to right order within such NAPTRs.
</ITW>
As a final point on ENUM client processing of compound NAPTRs, it is
quite possible that the client is incapable of processing one of the
ENUMservices indicated.
<STBO item="16">
To clarify, it is RECOMMENDED that:
Client When an ENUM client encounters a compound NAPTR and cannot
process one of the ENUMservices within it, that ENUM client
should ignore it 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.
</STBO>
4.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.
Two main questions remain from the specifications of DDDS and RFC
3671:
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?
Conroy & Fujiwara Expires September 21, 2007 [Page 15]
Internet-Draft ENUM Experiences March 2007
Whilst one interpretation of section 1.3 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.
It is RECOMMENDED that:
<STD item="17">
Server 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).
Client 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.
</STD>
Conroy & Fujiwara Expires September 21, 2007 [Page 16]
Internet-Draft ENUM Experiences March 2007
5. Non-Terminal NAPTR Processing
5.1. Non-Terminal NAPTRs - necessity
Consider an ENUM RRSet that contains a non-terminal NAPTR record.
This non-terminal NAPTR "points to" 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
"pointed to" 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.
<ITW item="18">
To avoid interoperability problems, some kind of acceptable
requirement is needed on non-terminal NAPTRs. Given the lack of
current support and the issues raised, we propose that in general one
Conroy & Fujiwara Expires September 21, 2007 [Page 17]
Internet-Draft ENUM Experiences March 2007
should not use non-terminal NAPTRs in ENUM.
Thus, it is RECOMMENDED that:
Server ENUM zone provisioning systems should not generate non-
terminal NAPTRs (i.e. NAPTRs with an empty Flags field)
unless it is clear that all ENUM clients they are designed
to support can process these.
</ITW>
ENUM zone administrators are advised that:
<ADV item="19">
Client ENUM clients have been known to discard non-terminal NAPTRs
(i.e. they may only support ENUM NAPTRs with a Flags field
value of "u").
</ADV>
5.2. Non-Terminal NAPTRs - future implementation
The following specific issues need to be considered if non-terminal
NAPTRs are to be supported in the future. 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.
5.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 4.4
for details.
In addition, to Clarify, it is RECOMMENDED that:
<STBO item="20">
Client 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
Conroy & Fujiwara Expires September 21, 2007 [Page 18]
Internet-Draft ENUM Experiences March 2007
the non-terminal NAPTR that caused the traversal).
</STBO>
5.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
loop". To ensure consistent behaviour, it is RECOMMENDED that:
<ITW item="21">
Client ENUM clients should consider that processing a chain of
more than 5 "non-terminal" NAPTRs in a single ENUM query
indicates that a loop may have been detected, and act
accordingly.
Server 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.
</ITW>
From experience, those ENUM client implementations that support Non-
Terminal NAPTRs have differed in what they should do on encountering
a Non-Terminal loop. To avoid this confusion, it is RECOMMENDED
that:
<STD item="22">
Client 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 "non-terminal 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.
</STD>
5.3. Interpretation of RFC 3403 and RFC 3761
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.
Conroy & Fujiwara Expires September 21, 2007 [Page 19]
Internet-Draft ENUM Experiences March 2007
5.3.1. Flags field content with Non-Terminal NAPTRs
<STBO item="23">
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
(in RFC 3404 [5], 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 should have been specified in RFC 3402 or
RFC 3403.
</STBO>
5.3.2. Services field content with Non-Terminal NAPTRs
Furthermore, RFC 3761 section 3.1.1 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 there can be no valid (non-empty) Services
field content for a NAPTR to be used with the "E2U" DDDS application.
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 can be
no definition of a non-terminal ENUMservice (and so no such
Registered ENUMservice identifier), this syntax cannot be met with a
non-terminal NAPTR.
A reasonable interpretation of the specifications in their current
state is that 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. To ensure
consistent behaviour, it is RECOMMENDED that:
<STD item="24">
Conroy & Fujiwara Expires September 21, 2007 [Page 20]
Internet-Draft ENUM Experiences March 2007
Client ENUM clients should ignore any content of the Services
field when encountering a non-terminal NAPTR with an empty
Flags field.
Server ENUM zone provisioning systems should ensure that the
Services field of any non-terminal NAPTR (with an empty
Flags field) is also empty.
</STD>
5.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
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
Conroy & Fujiwara Expires September 21, 2007 [Page 21]
Internet-Draft ENUM Experiences March 2007
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) specifies 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
implementation, and this interpretation has NOT been made in current
ENUM examples "out in the wild". 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, we suggest that a non-
terminal NAPTR with an empty Flags field must be provisioned using
the (non-empty) Replacement element to hold the domain name that
forms the "next key" output from this non-terminal rule.
Thus it is RECOMMENDED that:
<STD item="25">
Client 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
should be ignored by ENUM clients
Server with an empty Flags field into an ENUM zone must ensure
that the "target" domain name is set into the Replacement
field of this NAPTR. It must not use the RegExp field in
such a non-terminal NAPTR.
</STD>
<STD item="26">
Conroy & Fujiwara Expires September 21, 2007 [Page 22]
Internet-Draft ENUM Experiences March 2007
In the future, it would be possible to update RFC 3761 (sections
3.1.1 and 2.4.1) to add a new flag to indicate a non-terminal NAPTR,
and to change the ENUMservice template to permit specification of an
ENUMservice that operates with this new flag in non-terminal NAPTRs.
In doing this, it would be possible to include a syntactically valid
non-empty Services field in such non-terminal NAPTRs. To
differentiate from the case of an empty Flags field, this new flag
could also indicate that the RegExp field was to be non-empty, and to
be processed - by implication, this would mean that the Replacement
field would be empty. However, such a change would require an update
to RFC 3761, and so will have to wait.
</STD>
Conroy & Fujiwara Expires September 21, 2007 [Page 23]
Internet-Draft ENUM Experiences March 2007
6. Backwards Compatibility
6.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. Thus it is RECOMMENDED that:
<STD item="27">
Server ENUM zone provisioning systems must not generate NAPTRs
according to the syntax defined in RFC 2916. All zones
must hold ENUM NAPTRs according to RFC 3761 (and
ENUMservice specifications according to the framework
specified there).
</STD>
However, RFC 3824 [16] 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.
It is RECOMMENDED that:
Conroy & Fujiwara Expires September 21, 2007 [Page 24]
Internet-Draft ENUM Experiences March 2007
<STD item="28">
Client 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.
</STD>
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.
There is one subtle implication of this scheme. It is RECOMMENDED
that:
<STD item="29">
Spec Registrations for an ENUMservice with the type string of
"E2U" and an empty sub-type string must not be accepted.
</STD>
Conroy & Fujiwara Expires September 21, 2007 [Page 25]
Internet-Draft ENUM Experiences March 2007
7. Security Considerations
This document does not specify any standard. It does however make
some recommendations, and so the implications of following those
suggestions have to be considered.
In addition to these issues, 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 4, and Section 6 do not appear
to have any security considerations (either positive or negative).
The suggestions in Section 5.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.
Conroy & Fujiwara Expires September 21, 2007 [Page 26]
Internet-Draft ENUM Experiences March 2007
8. IANA Considerations
This document is only advisory, and does not include any IANA
considerations other than the proposals labelled as "Spec". This is
the suggestion (at the end of Section 6.1) that no-one should specify
an ENUMservice with the identifying tag "E2U".
Conroy & Fujiwara Expires September 21, 2007 [Page 27]
Internet-Draft ENUM Experiences March 2007
9. 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 quite different.
Conroy & Fujiwara Expires September 21, 2007 [Page 28]
Internet-Draft ENUM Experiences March 2007
10. References
10.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
One: The Comprehensive DDDS", RFC 3401, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Two: The Algorithm", RFC 3402, October 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404,
October 2002.
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[8] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[9] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[10] Costello, A., "Punycode: A Bootstring encoding of Unicode for
Internationalized Domain Names in Applications (IDNA)",
RFC 3492, March 2003.
[11] 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.
[12] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[13] ITU-T, "The International Public Telecommunication Number
Plan", Recommendation E.164, February 2005.
Conroy & Fujiwara Expires September 21, 2007 [Page 29]
Internet-Draft ENUM Experiences March 2007
[14] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986,
January 2005.
[15] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[16] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164
numbers with the Session Initiation Protocol (SIP)", RFC 3824,
June 2004.
[17] Braden, R., "Requirements for Internet Hosts -- Application and
Support", RFC 1123, October 1989.
[18] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
RFC 2181, July 1997.
[19] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999.
10.2. Informative References
[20] Conroy, L. and J. Reid, "ENUM Requirement for EDNS0 Support",
draft-ietf-enum-edns0-00.txt (work in progress),
September 2006.
[21] American National Standards Institute, "Coded Character Set --
7-bit American Standard Code for Information Interchange",
ANSI X3.4, 1986.
[22] ETSI, "Minimum Requirements for Interoperability of European
ENUM Implementations", ETSI TS 102 172, October 2004.
[23] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
[24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
March 2005.
[25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[26] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
RFC 4035, March 2005.
Conroy & Fujiwara Expires September 21, 2007 [Page 30]
Internet-Draft ENUM Experiences March 2007
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 September 21, 2007 [Page 31]
Internet-Draft ENUM Experiences March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 September 21, 2007 [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-24 01:08:13 |