Internet DRAFT - draft-conroy-enum-modestproposal
draft-conroy-enum-modestproposal
ENUM L. Conroy
Internet-Draft Roke Manor Research
Expires: January 6, 2006 July 5, 2005
Non-Terminal NAPTR Processing: A Modest Proposal
<draft-conroy-enum-modestproposal-00.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 January 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Recent Discussions within the IETF and in other fora have highlighted
differences in interpretation of the set of standards associated with
ENUM and DDDS, on which it relies. Specifically, the operation and
semantics surrounding support for non-terminal NAPTRs has led to some
confusion. This document is an attempt to add clarification to non-
terminal NAPTR processing. In this, it clarifies RFC3403. A
subsequent document will build on this one to extend RFC3761 further,
permitting registration of non-terminal Enumservices.
Conroy Expires January 6, 2006 [Page 1]
Internet-Draft Non-terminal NAPTR clarification July 2005
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 The Problem . . . . . . . . . . . . . . . . . . . . . . . 4
3. The solution . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Clarification of RFC3403 Section 4.1 . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10
6.2 Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Conroy Expires January 6, 2006 [Page 2]
Internet-Draft Non-terminal NAPTR clarification July 2005
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 BCP 14, RFC2119 [1].
Conroy Expires January 6, 2006 [Page 3]
Internet-Draft Non-terminal NAPTR clarification July 2005
2. Introduction
RFC3403 [2] defines the NAPTR resource record. It forms part of the
set of standards ([3][4][2]) that collectively specify the Dynamic
Delegation Discovery System (DDDS). Note that the examples given in
the second half of RFC3403 (section 6 of that document) are exemplary
rather than normative. The normative definitions of those DDDS
applications are in RFC3404 [5]/[6] and RFC3761 [7]. In particular,
note that RFC3761 uses a slightly different syntax from the examples
shown in this section.
The core algorithm for DDDS is specified in RFC3402. This shows that
the DDDS process is capable of looping through records that hold
"rules", extracted from a DDDS-application specific rule database,
until one such rule provides a final result or causes an exit from
the DDDS process, or all rules are exhausted. Intermediate rules
that do not cause such an exit are called "non-terminal" and
processing such a non-terminal rule generates a new key that is used
to extract further rules from the database.
One potential database that can be used with DDDS is the Domain Name
System (DNS) [8]. A DNS Resource Record type suitable for carrying
DDDS rules is the NAPTR, specified in RFC3403.
For historical reasons (i.e. the original specification of NAPTRs
preceded the development of DDDS), the fields that are defined for
the NAPTR are a superset of the fields used in the DDDS algorithm.
In particular, the DDDS priority field is represented within a NAPTR
by the combination of the NAPTR Order and Preference elements, and
the DDDS Substitution Expression is represented by the alternative
NAPTR Regexp or Replacement elements.
The flags NAPTR element directly reflects the flags field used in the
DDDS algorithm to specify the expected output of a rule. The flags
field also indicates whether this rule is to be interpreted as
terminal or non-terminal.
2.1 The Problem
The current DDDS specifications are not completely clear on how these
NAPTR elements are used to reflect the DDDS rule fields. Individual
DDDS application specifications have clarified the interpretation of
the NAPTR Order and Preference element values when used with these
DDDS applications. However, the main issue lies with the
interpretation of the roles of the two elements that collectively
reflect the DDDS Substitution Expression field; the NAPTR Regexp and
Replacement elements.
Conroy Expires January 6, 2006 [Page 4]
Internet-Draft Non-terminal NAPTR clarification July 2005
RFC3403 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 RFC3403 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 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". A client
program processing the DDDS application may need to examine each
NAPTR to decide whether the Regexp element or instead the Replacement
element is 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
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).
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.
Conroy Expires January 6, 2006 [Page 5]
Internet-Draft Non-terminal NAPTR clarification July 2005
3. The solution
3.1 Clarification of RFC3403 Section 4.1
In those DDDS application specifications that have been released so
far, the empty flags field has been used to indicate a non-terminal
rule. As described in RFC3403, the DDDS application is also free to
specify a flag as being associated with a non-terminal rule.
A two-part convention is proposed for all DDDS applications that use
NAPTRs to store their rules.
In the first part of this convention, the empty flag field MUST be
interpreted as being associated with a non-terminal rule, and that in
this case, that non-terminal rule MUST use the (non-empty)
Replacement element to hold the domain name that forms the "next key"
output from this non-terminal rule.
In the second part of the convention, where a DDDS application
defines a flag as being associated with a non-terminal rule, the
NAPTR containing this rule MUST use the Regexp element to generate
and output the "next key".
This convention allows the client program to decide, merely by
inspection of the flags element of the NAPTR, whether it should
expect to process the Replacement or Regexp element. It also allows
more rigourous validation to be applied if required against the
output of the Regexp processing; it will be clear from the specific
flag whether this is to be interpreted as a domain name or some other
output (such as a URI, in the case of ENUM). Finally, this
convention does not change any existing DDDS application
specification - it merely clarifies what is currently not completely
specified.
Thus, it is proposed that the descriptive text for the Flags element
within section 4.1 of RFC3403 (in particular, the second paragraph)
should be interpreted as follows:
FLAGS
A <character-string> containing flags to control aspects of the
rewriting and interpretation of the fields in the record. Flags
are single characters from the set A-Z and 0-9. The case of the
alphabetic characters is not significant. The field can be empty.
Where the field is empty, the rule is interpreted as non-terminal,
and the Replacement field is used to hold the next key output by
the rule. Where the field is non-empty, it is up to the
Conroy Expires January 6, 2006 [Page 6]
Internet-Draft Non-terminal NAPTR clarification July 2005
Application specifying it is using this Database to define the
Flags in this field. It must define which ones are terminal and
which ones are not. In the case where a flag is defined as being
non-terminal, the Regexp field will be used to generate the next
key output by this rule.
Conroy Expires January 6, 2006 [Page 7]
Internet-Draft Non-terminal NAPTR clarification July 2005
4. Security Considerations
The clarification described in this document does not appear to have
any security considerations over and above those already analysed in
the DDDS specifications. The intent of this document is to specify
more clearly what fields should be used within a NAPTR resource
record for terminal and non-terminal DDDS processing and to "tighten"
the specification of NAPTR field content. Whilst this does reduce
the flexibility of DDDS applications to made their own choices on
field content and interpretation, it does simplify the processing
required of clients that handle NAPTRs.
Conroy Expires January 6, 2006 [Page 8]
Internet-Draft Non-terminal NAPTR clarification July 2005
5. IANA Considerations
Under the framework defined in RFC3402, IANA accepts registration
requests for new DDDS applications only after the specifications that
define the operation of these DDDS applications have been processed
by the IETF. Thus there are no further requirements on IANA, as it
is assumed that this document will have been considered as part of
the evaluation of any new DDDS application by the IETF.
Conroy Expires January 6, 2006 [Page 9]
Internet-Draft Non-terminal NAPTR clarification July 2005
6. References
6.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[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] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[8] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
6.2 Informative References
[9] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[10] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978,
March 2005.
[11] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3979, March 2005.
Conroy Expires January 6, 2006 [Page 10]
Internet-Draft Non-terminal NAPTR clarification July 2005
Author's Address
Lawrence Conroy
Roke Manor Research
Roke Manor
Romsey
United Kingdom
Phone: +44-1794-833666
Email: lwc@roke.co.uk
Conroy Expires January 6, 2006 [Page 11]
Internet-Draft Non-terminal NAPTR clarification July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Conroy Expires January 6, 2006 [Page 12]
