The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
RFC 6116

RFC 6116               ENUM Protocol Specification            March 2011

   zones provisioned within such closed networks usually have a known
   capitalization for ENUM record string content, as provisioning
   systems for such networks are often carefully controlled.  In such an
   environment, clients are never exposed to records with capitalization
   that is "unexpected" and so can be (and have been) designed with case
   sensitive processing.  Only if a client is known to operate in an
   environment in which capitalization of all ENUM records it will
   encounter is known and controlled MAY that client use case sensitive
   processing.

3.7.  Collision Avoidance

   An ENUM-compliant application MUST only pass numbers to the ENUM
   client query process that it believes are E.164 numbers (e.g., it
   MUST NOT pass dialed digit strings to the ENUM query process).

   Since number plans may change over time, it can be impossible for a
   client to know if the number it intends to query is assigned and
   active within the current number plan.  Thus it is important that
   such clients can distinguish data associated with the E.164 number
   plan from that associated with other digit strings (i.e., numbers NOT
   in accordance with the E.164 number plan).

   It is the responsibility of operators that are provisioning data into
   domains to ensure that data associated with a query on an E.164
   number cannot be mistaken for data associated with other uses of
   NAPTRs.

   Three techniques are used to achieve this:

   o  the domain apex used for purposes other than data associated with
      the E.164 number plan MUST NOT be e164.arpa.

   o  for use other than with E.164 numbers, the Application Unique
      String MUST NOT begin with the '+' character, whilst for ENUM use,
      the AUS MUST begin with this character.

   o  NAPTRs that are intended for other DDDS applications MUST NOT
      include the E2U token in their service field, whilst NAPTRs
      intended for ENUM use MUST include this token.

Bradner, Conroy & Fujiwara   Standards Track                    [Page 9]
RFC 6116               ENUM Protocol Specification            March 2011

4.  ENUM Service Example

      $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
       NAPTR 100 50 "u" "E2U+sip"
           "!^(\\+441632960083)$!sip:\\1@example.com!"    .
       NAPTR 100 51 "u" "E2U+h323"
           "!^\\+441632960083$!h323:operator@example.com!"    .
       NAPTR 100 52 "u" "E2U+email:mailto"
           "!^.*$!mailto:info@example.com!"    .

   This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is
   preferably contacted by SIP, secondly via H.323 for voice, and
   thirdly by SMTP for messaging.  Note that the Enumservice tokens
   "sip", "h323", and "email" are Enumservice Types registered with
   IANA, and they have no implicit connection with the protocols or URI
   schemes with the same names.

   In all cases, the next step in the resolution process is to use the
   resolution mechanism for each of the protocols (specified by the URI
   schemes sip, h323, and mailto) to know what node to contact.

   In each of the first two records, the ERE sub-field matches only
   queries that have been made for the telephone number +441632960083.
   In the last record, the ERE matches any Application Unique String
   value.  The first record also demonstrates how the matched pattern
   can be used in the generated URI.

   Note that where NAPTR resource records are shown in DNS master file
   syntax (as in this example above), each backslash must itself be
   escaped using a second backslash.  The DNS on-the-wire packet will
   have only a single backslash in each case.

5.  Clarification of DDDS Use in ENUM

   ENUM is a DDDS Application.  This means that it relies on the DDDS
   for its operation.  DDDS is designed to be flexible, but that opens
   the possibility of differences of interpretation.  This section is
   intended to cover ENUM-specific interpretation of text within the
   DDDS specifications.  The goal is to ensure interoperability between
   ENUM clients and provisioning systems used to populate domains with
   E2U NAPTRs.

   As part of on-going development work on the ENUM specifications,
   [RFC5483] provides an (informative) analysis of the way in which ENUM
   client and provisioning system implementations behave and the
   interoperability issues that have arisen.  The following
   recommendations reflect that analysis, and further narrative
   explaining the issues can be found in that RFC.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 10]
RFC 6116               ENUM Protocol Specification            March 2011

5.1.  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 to process
   such characters correctly.  If ENUM zone provisioning systems require
   non-ASCII characters, these systems MUST encode the non-ASCII data to
   emit only US-ASCII characters by applying the appropriate mechanism
   (such as those in [RFC3492], [RFC3987]).  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 be provisioned into the Regexp field of E2U NAPTRs.

   The Registrant and the ENUM zone provisioning system he or she uses
   SHOULD NOT rely on ENUM clients solely taking 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.

   All E2U 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.

      Some ENUM clients have been known to pre-discard NAPTRs within an
      RRSet simply because these records do not have the lowest ORDER
      value found in that RRSet.  Other ENUM client implementations
      appear to have confused ORDER and PREFERENCE/PRIORITY fields,
      using the latter as the major sort term rather than the former as
      specified.  Conversely, ENUM zones have been provisioned within
      which the ORDER value varies but the PREFERENCE/PRIORITY field
      value is static.  This may have been intentional, but given the
      different client behavior in the face of varying ORDER field
      values, it may not produce the desired response.

   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
   compound NAPTRs, the Enumservices will normally be processed in left-
   to-right order within such NAPTRs.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 11]
RFC 6116               ENUM Protocol Specification            March 2011

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

   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 [RFC3402]
   (i.e., "\!", U+005C U+0021).  Note that when a NAPTR resource record
   is entered in DNS master file syntax, the backslash itself must be
   escaped using a second backslash.

   If present in the ERE sub-field of an ENUM NAPTR, the literal
   character '+' MUST be escaped as "\+" (i.e.  U+005C U+002B).  Note
   that, as always, when a NAPTR resource record is entered in DNS
   master file syntax, the backslash itself must be escaped using a
   second backslash.

   Whilst this client behavior 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
   back-reference patterns in the Repl sub-field of NAPTRs they
   provision.  Some clients have limited buffer space for character
   expansion when generating URIs.  These provisioning systems SHOULD
   check the back-reference replacement patterns they use, ensuring that
   regular expression processing will not produce excessive-length URIs.

   ENUM zones MUST NOT be provisioned with NAPTRs according to the
   obsolete syntax of [RFC2916], and MUST be provisioned with NAPTRs in
   which the Services field is according to Section 3.4.3 of this
   document.

      [RFC2915] and [RFC2916] have been obsoleted by [RFC3401]-[RFC3404]
      and by this document, respectively.

   Enumservices in which the Enumservice type starts with the facet "P-"
   MUST NOT be provisioned in any system that provides answers to DNS
   queries for NAPTR resource record sets from entities outside the
   private network context in which these Enumservices are intended for
   use.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 12]
RFC 6116               ENUM Protocol Specification            March 2011

   As current support is limited, non-terminal NAPTRs SHOULD NOT be
   provisioned in ENUM zones unless it is clear that all ENUM clients
   that 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 that may be 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, as this field will be interpreted as
   holding the FQDN 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.

5.2.  Collected Implications for ENUM Clients

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

   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 MUST sort the records of a retrieved NAPTR RRSet into
   sequence using the ORDER and PREFERENCE fields of those records.  The
   ORDER is to be treated as the major sort term, with lowest numerical
   values being earlier in the sequence.  The PREFERENCE/PRIORITY field
   is to be treated as the minor sort term, with lowest numerical values
   being earlier in the sequence.

   ENUM clients SHOULD NOT discard a NAPTR record until it is considered
   or a record previous to it in the evaluation sequence has been
   accepted.

      Notably, if a record has a "worse" ORDER value than others in this
      RRSet, that record MUST NOT be discarded before consideration
      unless a record has been accepted as the result of this ENUM
      query.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 13]
RFC 6116               ENUM Protocol Specification            March 2011

   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 lowest currently unprocessed ORDER field value.  The
   client SHOULD observe 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 randomizing the order in which these are
   processed, as intervening DNS Servers might have done this already).

   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 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 MUST be ready to process NAPTRs that use a different
   character from '!' as their Regexp Delimiter without failure.

   ENUM clients SHOULD NOT assume that the delimiter is the last
   character of the Regexp field.

      Unless they are sure that in their environment this is the case,
      in general an ENUM client may still encounter NAPTRs that have
      been provisioned with a following 'i' (case-insensitive) flag,
      even though that flag has no effect at all in an ENUM scenario.

   ENUM clients SHOULD discard NAPTRs that have more or less than 3
   unescaped instances of the delimiter character within the Regexp
   field.

      In the spirit of being liberal with what it will accept, if the
      ENUM client is sure how the Regexp field should be interpreted, it
      MAY choose to process the NAPTR even in the face of an incorrect
      number of unescaped delimiter characters.  If it is not clear how
      the Regexp field should be interpreted, the client MUST discard
      the NAPTR.

   ENUM clients MUST be ready to process NAPTRs that have non-trivial
   patterns in their ERE sub-field values without failure.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 14]
RFC 6116               ENUM Protocol Specification            March 2011

   ENUM clients MUST be ready to process NAPTRs with many copies of
   back-reference patterns within the Repl sub-field without failure.

   ENUM clients MUST be ready to process NAPTRs with a DDDS Application
   identifier other than 'E2U' without failure.

   When an ENUM client encounters a compound NAPTR (i.e., one containing
   more than one Enumservice) and cannot process or cannot recognize 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.

   ENUM clients MUST support ENUM NAPTRs according to syntax defined in
   Section 3.4.3.  ENUM clients SHOULD also support ENUM NAPTRs
   according to the obsolete syntax of [RFC2916]; there are still zones
   that hold "old" syntax NAPTRs.  The informational [RFC3824]
   recommended such support.

   Unless an ENUM client is sure that it is connected to the private
   network for which these NAPTRs are provisioned and intended, it MUST
   discard any NAPTR with an Enumservice type that starts with the "P-"
   facet.

5.2.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 implemented, 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 FQDN 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 FQDN.  By definition, it follows that the Regexp
   field will be empty in such a non-terminal NAPTR.  If present in a
   non-terminal NAPTR, a non-empty Regexp field 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), the
   ENUM query SHOULD NOT be abandoned, but instead processing SHOULD

Bradner, Conroy & Fujiwara   Standards Track                   [Page 15]
RFC 6116               ENUM Protocol Specification            March 2011

   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, 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).

   ENUM clients MUST be prepared to encounter a referential loop in
   which a sequence of non-terminal NAPTRs are retrieved within an ENUM
   query that refer back to an earlier FQDN.  ENUM clients MUST be able
   to detect and recover from such a loop, without failure.

   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.

   When 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, 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.

6.  IANA Considerations

   RFC 2916 and then RFC 3761 (which this document replaces) requested
   IANA to delegate the E164.ARPA domain following instructions that
   were provided by the IAB (as described in [RFC3245]).  The domain was
   delegated according to those instructions (which are published at
   <http://www.ripe.net/data-tools/dns/enum/iab-instructions>).

   Names within this zone are to be delegated to parties consistent with
   ITU Recommendation E.164.  The names allocated should be hierarchic
   in accordance with ITU Recommendation E.164, and the codes should be
   assigned in accordance with that Recommendation.

   The IAB is to coordinate with the ITU Telecommunications
   Standardization Bureau (TSB) if the technical contact for the domain
   e164.arpa is to change, as ITU TSB has an operational working
   relationship with this technical contact that would need to be
   reestablished.

   See [RFC6117] for Enumservice-related IANA Considerations.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 16]
RFC 6116               ENUM Protocol Specification            March 2011

7.  Security Considerations

7.1.  DNS Security

   As ENUM uses DNS, which in its current form is an insecure protocol,
   there is no mechanism for ensuring that the data one gets back is
   authentic.  As ENUM is deployed on the global Internet, it is
   expected to be a popular target for various kinds of attacks, and
   attacking the underlying DNS infrastructure is one way of attacking
   the ENUM service itself.

   There are multiple types of attacks that can happen against DNS that
   ENUM implementations should consider.  See Threat Analysis of the
   Domain Name System [RFC3833] for a review of the various threats to
   the DNS.

   Because of these threats, a deployed ENUM service SHOULD include
   mechanisms to mitigate these threats.  Most of the threats can be
   solved by verifying the authenticity of the data via mechanisms such
   as DNS Security (DNSSEC) [RFC4033].

   Others, such as Denial-Of-Service attacks, cannot be solved by data
   authentication.  It is important to remember that these threats
   include not only the NAPTR lookups themselves, but also the various
   records needed for the services to be useful (for example NS, MX,
   SRV, and A records).

   Even if DNSSEC is deployed, it cannot protect against every kind of
   attack on DNS.  ENUM is often used for number or address translation;
   retrieving an address through an ENUM lookup with DNSSEC support does
   not, however, ensure that the service is immune to attack.  It is
   unwise for a service blindly to trust that the address it has
   retrieved is valid and that the entity to which it connects using
   that address is the service peer it intended to contact.  A service
   SHOULD always authenticate the entity to which it connects during the
   service setup phase, and not rely on address or identity data
   retrieved outside that service.

   Finally, as an ENUM service will be implementing some type of
   security mechanism, software that implements ENUM MUST be prepared to
   receive DNSSEC and other standardized DNS security responses,
   including large responses and other EDNS0 signaling (see [RFC2671]),
   unknown resource records (see [RFC3597]), and so on.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 17]
RFC 6116               ENUM Protocol Specification            March 2011

7.2.  Caching Security

   The DNS architecture makes extensive use of caching of records at
   intermediary nodes to improve performance.  The propagation time (for
   changes to resource records to be reflected in query responses to end
   nodes) approaches the "time to live" value for those records.  There
   may be a number of different resource records involved in the
   resolution of a communication target.  Changes to these records may
   not be synchronized (particularly if these resource records indicate
   different times to live).  Thus a change in any one of these records
   may cause inappropriate decisions on communications targets to be
   made.  Given that DNS Update (specified in [RFC2136]) can introduce
   quite rapid changes in content in different zones, these transient
   states may become important.

   Consider a typical set of queries that follow an ENUM query that
   returns a SIP URI (for details, see [RFC3263]):

   o  Evaluation of the SIP URI triggers a query on the SIP domainpart
      for D2U/D2T NAPTRs.

   o  This in turn triggers a query on that record's target domain for
      SRV records.

   o  The SRV records will return the SIP server hostname, which will
      trigger a further query on that hostname for an A record to get
      the server's associated IP address.

   o  Finally, the local SIP User Agent Client will then attempt to
      initiate a communications session to that IP address.

   The E2U NAPTR may have changed its URI, indicating a new SIP
   identity.  The D2U NAPTR for the SIP URI domainpart may have changed
   its target.  The SRV record pointed to by that D2U NAPTR may have
   changed its target hostname.  The hostname's A record may have
   changed its IP address.  Finally, if the server exists in an
   environment where IP-addresses are dynamically assigned (for example,
   when using DHCP [RFC2131]), an unexpected end point may have been
   allocated to the IP address returned from the SIP resolution chain.

   In environments where changes to any of the chain of resource records
   or dynamic assignments to IP addresses occur, those systems
   provisioning this data SHOULD take care to minimize changes and to
   consider the respective times to live of resource records and/or DHCP
   lease times.  Users of this data SHOULD take care to detect and
   recover from unintended communications session attempts; in a
   transient environment, these may occur.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 18]
RFC 6116               ENUM Protocol Specification            March 2011

7.3.  Call Routing Security

   There are a number of countries (and other numbering environments) in
   which there are multiple providers of call routing and number/name-
   translation services.  In these areas, any system that permits users,
   or putative agents for users, to change routing or supplier
   information may provide incentives for changes that are actually
   unauthorized (and, in some cases, for denial of legitimate change
   requests).  Such environments should be designed with adequate
   mechanisms for identification and authentication of those requesting
   changes and for authorization of those changes.

7.4.  URI Resolution Security

   A large amount of security issues have to do with the resolution
   process itself, and use of the URIs produced by the DDDS mechanism.
   Those have to be specified in the registration of the Enumservice
   used, as specified in "IANA Registration of Enumservices: Guide,
   Template, and IANA Considerations" [RFC6117].

8.  Acknowledgements

   This document is an update of RFC 3761, which was edited by Patrik
   Faltstrom and Michael Mealling.  Please see the Acknowledgements
   section in that RFC for additional acknowledgements.  The authors
   would also like to thank Alfred Hoenes and Bernie Hoeneisen for their
   detailed reviews.

9.  Changes from RFC 3761

   A section has been added to explain the way in which DDDS is used
   with this specification.  These recommendations have been collected
   from experience of ENUM deployment.  Differences of interpretation of
   the DDDS specifications led to interoperability issues; this document
   updates RFC 3761 to add many clarifications, intended to ameliorate
   interoperability.

   Clarifications include a default value for the ORDER field and for
   the Regexp delimiter character, required use of Replacement field in
   non-terminal NAPTRs, and that string matching is case insensitive
   (Section 3.6).

   Other substantive changes include removing the discussion of
   registration mechanisms, (now specified in "IANA Registration of
   Enumservices: Guide, Template, and IANA Considerations" [RFC6117]),
   correcting an existing error by adding "-" as a valid character in
   the type and subtype fields specified in Services Parameters (Section
   3.4.3) and adding the "P-" private service type (Section 3.4.3.1).

Bradner, Conroy & Fujiwara   Standards Track                   [Page 19]
RFC 6116               ENUM Protocol Specification            March 2011

10.  References

10.1.  Normative References

   [E.164]   ITU-T, "The International Public Telecommunication Number
             Plan", Recommendation E.164, February 2005.

   [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
             STD 13, RFC 1034, November 1987.

   [RFC1035] Mockapetris, P., "Domain names - implementation and
             specification", STD 13, RFC 1035, November 1987.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
             Part Two: The Algorithm", RFC 3402, October 2002.

   [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
             Part Three: The Domain Name System (DNS) Database", RFC
             3403, October 2002.

   [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
             Part Four: The Uniform Resource Identifiers (URI)", RFC
             3404, October 2002.

   [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
             for Internationalized Domain Names in Applications (IDNA)",
             RFC 3492, March 2003.

   [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
             STD 63, RFC 3629, November 2003.

   [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
             Resource Identifiers (URI) Dynamic Delegation Discovery
             System (DDDS) Application (ENUM)", RFC 3761, April 2004.

   [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
             Resource Identifier (URI): Generic Syntax", STD 66, RFC
             3986, January 2005.

   [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
             Identifiers (IRIs)", RFC 3987, January 2005.

   [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", STD 68, RFC 5234, January 2008.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 20]
RFC 6116               ENUM Protocol Specification            March 2011

10.2.  Informative References

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             March 1997.

   [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
             "Dynamic Updates in the Domain Name System (DNS UPDATE)",
             RFC 2136, April 1997.

   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
             2671, August 1999.

   [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
             specifying the location of services (DNS SRV)", RFC 2782,
             February 2000.

   [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
             (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
             2000.

   [RFC3245] Klensin, J., Ed., and IAB, "The History and Context of
             Telephone Number Mapping (ENUM) Operational Decisions:
             Informational Documents Contributed to ITU-T Study Group 2
             (SG2)", RFC 3245, March 2002.

   [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
             Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.

   [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
             Part One: The Comprehensive DDDS", RFC 3401, October 2002.

   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
             (RR) Types", RFC 3597, September 2003.

   [RFC3824] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using
             E.164 numbers with the Session Initiation Protocol (SIP)",
             RFC 3824, June 2004.

   [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
             Name System (DNS)", RFC 3833, August 2004.

   [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
             Rose, "DNS Security Introduction and Requirements", RFC
             4033, March 2005.

Bradner, Conroy & Fujiwara   Standards Track                   [Page 21]
RFC 6116               ENUM Protocol Specification            March 2011

   [RFC5483] Conroy, L. and K. Fujiwara, "ENUM Implementation Issues and
             Experiences", RFC 5483, March 2009.

   [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
             Registration of Enumservices: Guide, Template, and IANA
             Considerations" RFC 6117, March 2011.

Authors' Addresses

   Scott Bradner
   Harvard University
   29 Oxford St.
   Cambridge MA 02138
   USA

   Phone: +1-617-495-3864
   EMail: sob@harvard.edu

   Lawrence Conroy
   Roke Manor Research
   Roke Manor
   Old Salisbury Lane
   Romsey
   United Kingdom

   Phone: +44-1794-833666
   EMail: lconroy@insensate.co.uk
   URI:   http://lawrence.tel

   Kazunori Fujiwara
   Japan Registry Services 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/

Bradner, Conroy & Fujiwara   Standards Track                   [Page 22]