[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

ENUM                                                           L. Conroy
Internet-Draft                                       Roke Manor Research
Expires: January 6, 2006                                    July 5, 2005

            Non-Terminal NAPTR Processing: A Modest Proposal

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   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",
   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

   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

   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:


      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.

        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
   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Conroy                   Expires January 6, 2006               [Page 12]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/