[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-conroy-enum-experiences) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5483

ENUM                                                           L. Conroy
Internet-Draft                                                      RMRL
Expires: April 24, 2005                                      K. Fujiwara
                                                                     JPRS
                                                         October 24, 2004


                ENUM Implementation Issues and Experiences
                   <draft-ietf-enum-experiences-01.txt>

Status of this Memo

    This document is an Internet-Draft and is subject to all provisions
    of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
    RFC 3668.

    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 April 24, 2005.

Copyright Notice

    Copyright (C) The Internet Society (2004).

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 informational only, 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.




Conroy & Fujiwara        Expires April 24, 2005                 [Page 1]

Internet-Draft              ENUM Experiences                October 2004


Table of Contents

    1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
    3.  Character Sets and ENUM  . . . . . . . . . . . . . . . . . . .  5
      3.1   Character Sets - Non-ASCII considered harmful  . . . . . .  5
      3.2   Case Sensitivity . . . . . . . . . . . . . . . . . . . . .  7
      3.3   Regexp Field Delimiter . . . . . . . . . . . . . . . . . .  8
      3.4   Regexp Meta-character Issue  . . . . . . . . . . . . . . .  8
    4.  ORDER/PRIORITY Processing  . . . . . . . . . . . . . . . . . . 10
      4.1   Order/Priority values - general processing . . . . . . . . 10
      4.2   NAPTRs with identical ORDER/PRIORITY values  . . . . . . . 12
      4.3   Processing Order value across Zones  . . . . . . . . . . . 13
    5.  Non-final NAPTR Processing . . . . . . . . . . . . . . . . . . 14
      5.1   Non-Final NAPTRs - necessity . . . . . . . . . . . . . . . 14
      5.2   Non-Final NAPTRs - future implementation . . . . . . . . . 15
        5.2.1   Non-Final NAPTRs - general . . . . . . . . . . . . . . 15
        5.2.2   Non-Final NAPTRs - loop detection and response . . . . 15
    6.  DNS record size and DNS software issue . . . . . . . . . . . . 16
    7.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 18
      7.1   Service field syntax . . . . . . . . . . . . . . . . . . . 18
    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
    10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
    11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
    11.1  Normative References . . . . . . . . . . . . . . . . . . . . 23
    11.2  Informative References . . . . . . . . . . . . . . . . . . . 24
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
        Intellectual Property and Copyright Statements . . . . . . . . 26






















Conroy & Fujiwara        Expires April 24, 2005                 [Page 2]

Internet-Draft              ENUM Experiences                October 2004


1.  Terminology

    This document is Informational, and does not specify a standard of
    any kind.  Note that recommendations here contain the words "MUST",
    "REQUIRE", "SHOULD", and "MAY".  In this particular document, these
    do not form a standard, and so 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 April 24, 2005                 [Page 3]

Internet-Draft              ENUM Experiences                October 2004


2.  Introduction

    The ENUM protocol (RFC3761 [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.

    From experience of creating ENUM data and of developing client
    systems to process that data it is apparent that there are some
    subtleties in the specifications that have led to different
    interpretations; in addition there are common syntactic mistakes in
    data currently "out there" on the Internet.

    This document is intended to help others avoid the potential pitfalls
    in interpreting the set of documents that specify the protocol.  It
    also reports the kind of data they will "find" and so how to process
    the intent of the publisher of that ENUM data, regardless of the
    syntax used.  As such, it is in keeping with the principle evinced in
    RFC791 that "In general, an implementation must be conservative in
    its sending behavior, and liberal in its receiving behavior".

    Note that the DDDS system is intricate and so in some places there
    are several potential interpretations of the specifications.  This
    document proposes a suggested interpretation for some of these
    points, but they are just that; suggestions.

    This draft covers 10 issues in five areas, making 37 recommendations
    and giving 2 clarifications.

    Any ENUM implementation issue has two sides:
    o  the "Server" side covering the expected behaviour of the ENUM zone
       provisioning system and expectations Registrants may make, and
    o  the "Client" side covering behaviour that has been observed and
       that can be expected of the Client, together with the expectations
       that an end user who requests an ENUM lookup may make.

    For each of the issues, we have split the recommendations into
    "Client" and "Server" proposals.  In three cases, we have indicated
    proposals that relate to ENUMservice specifications, rather than
    implementations; these are labelled as "Spec".

    There are undoubtedly other issues, and developers are asked to raise
    any others they find on the IETF ENUM Working group's mailing list
    and/or by mail to the authors (see later for contact information).
    Finally, note that the authors are not aware of any IPR issues that
    are involved in the suggestions made in this document.



Conroy & Fujiwara        Expires April 24, 2005                 [Page 4]

Internet-Draft              ENUM Experiences                October 2004


3.  Character Sets and ENUM

3.1  Character Sets - Non-ASCII considered harmful

    RFC3761 [1] and RFC3403 [2] specify that ENUM (and NAPTRs) support
    Unicode using the UTF-8 encoding specified in RFC3629 [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 non
    "UTF-8 aware" systems.

    The UTF-8 encoding has a "US-ASCII equivalent range", so that all
    characters in US-ASCII 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 they 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 Client may
    have good reason to reject NAPTRs that include these characters as
    they cannot be shown.

    There are two numeric fields in a NAPTR; the ORDER and PREFERENCE
    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-final", or it may include a
    flag character as specified in RFC3761.  These characters all fall
    into the US-ASCII equivalent range, so multi-byte characters cannot
    occur.




Conroy & Fujiwara        Expires April 24, 2005                 [Page 5]

Internet-Draft              ENUM Experiences                October 2004


    The services field includes the DDDS Application identifier ("E2U")
    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 RFC3761 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, RFC3403 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 RFC3761 to consist of digit characters,
    with an initial '+' character.  All of these 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 RFC3403.  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.

    The current URIs use the overall URI character "escaping" rules [12],
    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, a future URI scheme might be developed that
    allows characters with multi-byte UTF-8 encoding to exist.  If this
    happens, and if an ENUMservice specification is created that refers
    to this scheme, then multi-byte characters could then occur in a
    NAPTR.  The presence of these characters could complicate URI
    generation and processing routines.

    Given that this is the only place within an ENUM NAPTR where such
    multi-byte encodings might reasonably be found, a simple solution is
    for no ENUMservice definition to include a reference to a URI that
    allows UTF-8 characters outside the US-ASCII equivalent range to be
    included, or to require that such characters be "escape encoded"
    before inclusion in the repl sub-field.  The domain part of a URI
    MUST be processed using Punycode if it has a non-ASCII domain name,
    so there will be no non-ASCII characters in this part of any URI.



Conroy & Fujiwara        Expires April 24, 2005                 [Page 6]

Internet-Draft              ENUM Experiences                October 2004


    Taking into account the existing client base, it is RECOMMENDED that:
      Spec    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 a URI-specific
              "escape" mechanism to re-encode them only using US-ASCII
              equivalent printable characters (those in the range 0x20 to
              0x7E).

    At the least, it is RECOMMENDED that:
      Spec    Any ENUMservice registration that allows characters
              requiring multi-byte UTF-8 encoding to be present in the
              repl sub-field MUST have a clear indication that there may
              be characters outside of the US-ASCII equivalent range.

    Finally, the majority of ENUM Clients in use today do not support
    multi-byte encodings of 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
    RECOMMENDED that:
      Client  Clients MAY discard NAPTRs in which they detect characters
              not in the US-ASCII "printable" range (0x20 to 0x7E
              hexadecimal).

    ENUM provisioning systems should consider this.  It is RECOMMENDED
    that:
      Server  ENUM zone content population systems SHOULD NOT use
              non-ASCII characters in the NAPTRs they generate unless
              they are sure that all Clients they intend to support will
              be able correctly to process them.

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







Conroy & Fujiwara        Expires April 24, 2005                 [Page 7]

Internet-Draft              ENUM Experiences                October 2004


    To avoid the confusion that this generates, It is RECOMMENDED that:
      Server  When populating ENUM zones with NAPTRs, population systems
              SHOULD NOT use the 'i' flag, as it has no effect and some
              Clients don't expect it.

      Client  Clients SHOULD NOT assume that the field delimiter is the
              last character.

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

    It is RECOMMENDED that:
      Server  ENUM zone population systems SHOULD use '!' (U+0021) as
              their RegExp delimiter character.

      Client  Clients MAY discard NAPTRs that do not use '!' as a RegExp
              delimiter.

    This 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).
    Thus, it is further RECOMMENDED that:
      Server  ENUM zone population 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 RFC3402 (i.e.  "\!", U+005C U+0021).

      Client  Clients SHOULD discard NAPTRs that have more or less than 3
              "unescaped" instances of the delimiter character within the
              RegExp field.

3.4  Regexp Meta-character Issue

    In ENUM, the ERE sub-field may include a literal character '+', as
    the Application Unique String on which it operates includes this.
    However, if it is present, then '+' must be "escaped" using a
    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@sipcsp.se!" .




Conroy & Fujiwara        Expires April 24, 2005                 [Page 8]

Internet-Draft              ENUM Experiences                October 2004


    This example MUST be written as:

    * IN NAPTR 100 10 "u" "E2U+sip" "!^\+46555(.*)$!sip:\1@sipcsp.se!" .

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












































Conroy & Fujiwara        Expires April 24, 2005                 [Page 9]

Internet-Draft              ENUM Experiences                October 2004


4.  ORDER/PRIORITY Processing

4.1  Order/Priority values - general processing

    RFC3761 and RFC3403 state that the client MUST sort the NAPTRs using
    the ORDER field value ("lowest value is first") and SHOULD order the
    NAPTRs using the 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 expected behaviour is a simplification; 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 don't 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 their own preference for services
    to be used.  Thus, an end user may specify that they would prefer to
    use contacts with a "sip" ENUMservice, and then those with
    "msg:email" service, and are not interested in any other options.
    Thus the sorted list as proposed by the Registrant (and published via
    ENUM) may be re-ordered.  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
    inconvenient for the end user, some clients simply offer all of the
    available NAPTRs as options to the end user for their selection "in
    one go".

    In summary, some clients will take into account the service field
    value along with the ORDER and PRIORITY field values, and may
    consider the preferences of the end user.

    The Registrant and the ENUM zone population system they use MUST be
    aware of this and SHOULD NOT rely on Clients taking account of the



Conroy & Fujiwara        Expires April 24, 2005                [Page 10]

Internet-Draft              ENUM Experiences                October 2004


    value of the ORDER and the PRIORITY fields.

    Specifically, it is unsafe to assume that a Client WILL NOT consider
    another NAPTR until they have discarded one with a "winning" ORDER
    value.  The instruction (in RFC3403 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:
      Server  An ENUM zone population system SHOULD NOT use different
              ORDER values for NAPTRs within a zone.

    In our 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:
      Server  An ENUM zone population system SHOULD use a value of 100 as
              the default ORDER value to be used with all NAPTRs.

    As such, when populating a zone with NAPTRS, it is RECOMMEDED that:
      Server  A Registrant SHOULD NOT expect the client to ignore NAPTRs
              with higher ORDER field values - the "winning" ones may
              have been discarded.

      Server  Server - A Registrant SHOULD NOT expect the client to
              conform to the ORDER and PRIORITY sort order they have
              specified for their NAPTRs; the end user may have their own
              preferences for ENUMservices.

      Client  Client - Clients MAY re-order the NAPTRs only to match an
              explicit preference pre-specified by their end user.

      Client  Client - Clients that offer a list of contacts to the end
              user for their 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 "at once".

    The impact of this is that a Registrant should place into their zone
    only contacts that they are willing to support; even those with the
    "least preferred" ORDER/PRIORITY values may be selected by an end
    user.

    Finally, we have noticed a number of ENUM zones with NAPTRs that have
    identical PRIORITY field values and different ORDER values.  This may
    be the result of a zone population system "bug" or a misunderstanding
    over the uses of the two fields.



Conroy & Fujiwara        Expires April 24, 2005                [Page 11]

Internet-Draft              ENUM Experiences                October 2004


    To clarify, the ORDER field value is the major sort term, and the
    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 PRIORITY field values.

4.2  NAPTRs with identical ORDER/PRIORITY values

    From experience, there are zones that hold discrete NAPTRs with
    identical ORDER and 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:
      Client  Clients should accept all NAPTRs with identical ORDER and
              identical PRIORITY field values, and process them in the
              order 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 may
              do this already).

    Conversely, populating the records with these identical values is a
    mistake, and so it is RECOMMENDED that:
      Server  When populating ENUM zones with NAPTRs, ENUM zone
              population systems SHOULD NOT have more than one with the
              same ORDER and the same PRIORITY field values, as Clients
              MAY reject the response.

    There is a special case in which one could derive a set of NAPTRs
    with identical ORDER/PRIORITY fields.  With RFC3761, 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 ENUMservice" NAPTR could
    well be used to indicate, for example, a mobile phone that supports
    both voice:tel and msg:sms ENUMservices.

    This compound NAPTR may be deconstructed into a set of NAPTRs each
    holding a single ENUMservice.  However, in this case the members of
    this set all hold the same ORDER and PRIORITY field values.

    In this case, it is RECOMMENDED that:
      Client  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.






Conroy & Fujiwara        Expires April 24, 2005                [Page 12]

Internet-Draft              ENUM Experiences                October 2004



      Server  An ENUM zone population system SHOULD assume that, if it
              generates compound NAPTRs, the ENUMservices will be
              processed in "left to right" order within such NAPTRs.

4.3  Processing Order value across Zones

    Using a different ORDER field value in different zones is unimportant
    for most queries.  However, DDDS includes a mechanism for continuing
    a search for NAPTRs in another zone by including a reference to that
    other zone in a "non-final" NAPTR.  The treatment of non-ginal NAPTRs
    is covered in the next section, but if these are supported then it
    does have a bearing on the way that ORDER and Priority field values
    are processed.

    Two main questions remain from the specifications in DDDS and
    RFC3671:
    o  if there's a different (lower) order field value in a zone
       referred to by a non-final NAPTR, then does this mean that the
       ENUM client discards the other NAPTRs in the referring zone?

    o  Conversely, if the zone referred to by a non-final NAPTR contains
       entries that have a higher ORDER field value, then does the ENUM
       client ignore those?

    Whilst one interpretation of section 1.3 of RFC3761 is that the
    answer to both questions is "yes", this is not the way that those
    expamples of non-final NAPTRs that do exist (and those ENUM Clients
    that support them) seem to be designed.

    Thus, to reflect the interpretation that is made by those systems
    that have implemented non-final NAPTRs, it is RECOMMENDED that:
      Server  Registrants SHOULD assume that, once a non-final NAPTR has
              been selected for processing, the ORDER field value in a
              zone referred to by that non-final NAPTR will be considered
              only within the context of that referenced zone (i.e.  the
              ORDER value will be used only to sort within the referenced
              zone, and will not be used in the processing of NAPTRs in
              the referring zone).

      Client  ENUM Clients SHOULD consider the ORDER field value only
              when sorting NAPTRs within a single zone.  The ORDER field
              value SHOULD NOT be taken into account when processing
              NAPTRs across a multi-zone ENUM query created by a chain of
              non-final NAPTR references.






Conroy & Fujiwara        Expires April 24, 2005                [Page 13]

Internet-Draft              ENUM Experiences                October 2004


5.  Non-final NAPTR Processing

5.1  Non-Final NAPTRs - necessity

    Consider an ENUM domainname that contains a non-final NAPTR record.
    This non-final NAPTR "points to" another domain that has a set of
    NAPTRs.  In effect, this is similar to the non-final NAPTR being
    replaced by the NAPTRs contained in the domain to which it points.

    It is possible to have a non-final NAPTR in a domain that is, itself,
    pointed to by another non-final NAPTR.  Thus a set of domains forms a
    "chain", and the list of NAPTRs considered is the set of all NAPTRs
    contained in all of the domains in that chain.

    For an ENUM management system to support non-final 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-final NAPTRs in its domain.  If the domains
    pointed to have non-final 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 zones.  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 to support non-final NAPTRs can also be difficult.
    Processing non-final 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-final 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-final NAPTR can be replaced by the
    NAPTRs in the domain to which it points, support of non-final NAPTR
    is not needed and non-final NAPTRs may not be useful.

    Furthermore, most existing ENUM clients do not support non-final
    NAPTRs and ignore them if received.  To avoid interoperability
    problems, some kind of acceptable requirement is needed on non-final
    NAPTRs.  Given the lack of current support and the issues raised, we
    propose that one SHOULD NOT use non-final NAPTRs in ENUM.






Conroy & Fujiwara        Expires April 24, 2005                [Page 14]

Internet-Draft              ENUM Experiences                October 2004


    Thus, it is RECOMMENDED that:
      Server  ENUM zone population systems SHOULD NOT generate non-final
              NAPTRs (i.e.  NAPTRs with an empty flags field).

      Client  ENUM clients MAY discard non-final NAPTRs (i.e.  they MAY
              only support ENUM NAPTRs with a flags field of "u").

5.2  Non-Final NAPTRs - future implementation

    The following specific issues need to be considered if non-final
    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-final 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-final NAPTRs in "its" zones refer.

5.2.1  Non-Final NAPTRs - general

    To clarify, if all NAPTRs in a domain traversed as a result of a
    reference in a non-final NAPTR have been discarded, then the Client
    should continue its processing with the next NAPTR in the zone
    including the non-final NAPTR that caused the traversal.

    A non-final NAPTR in one zone refers to the NAPTRs contained in
    another zone.  The NAPTRs in the zone referred to by the non-final
    NAPTR may have a different ORDER value from that in the referring
    non-final NAPTR.  See section 4.3 for details.

5.2.2  Non-Final NAPTRs - loop detection and response

    Where a "chain" of non-final NAPTRs refers back to a domain already
    traversed in the current query, this implies a "non-final loop".  To
    ensure consistent behaviour, it is RECOMMENDED that:
      Client  Clients SHOULD consider processing more than 5 "non-final"
              NAPTRs in a single ENUM query to indicate that a loop may
              have been detected, and act accordingly.

      Server  When populating a set of domains with NAPTRs, one should
              not configure non-final NAPTRs so that more than 5 such
              NAPTRs will be processed in an ENUM query.

      Client  Where a domain is about to be entered as the result of a
              reference in a non-final NAPTR, and the client has detected
              a potential "non-final loop", then the Client should
              discard the non-final NAPTR from its processing and
              continue with the next NAPTR in its list.



Conroy & Fujiwara        Expires April 24, 2005                [Page 15]

Internet-Draft              ENUM Experiences                October 2004


6.  DNS record size and DNS software issue

    ENUM RRsets may be large.  An ENUM DNS response size may easily
    exceed the 512 octet limit for "basic" UDP-based DNS messages.

    In this case, a basic DNS response will be truncated (indicated by
    the "TC" flag being set to '1' in the response).

    The full DNS content can be carried only in TCP, or UDP packets where
    the Client has indicated a suitably large packet size with EDNS0
    [13].

    Limiting ENUM RRSet size is not easily possible in ENUM, as the
    Registrant has control of the RRSet held in "their" zone, not the
    Authoritative Name Server or the ENUM Client.

    If the Registrant chooses to hold a large set of NAPTRs in their
    zone, then all entities involved in ENUM, (ENUM clients, their ISP's
    recursive resolver/cache servers, and the authoritative servers that
    hold ENUM RRSets) MUST support TCP DNS queries and responses (or
    EDNS0 with a suitably large packet size specification) or they cannot
    resolve ENUM requests.

    The DNS protocol is defined in [8][9] and clarified in [14], whilst
    Requirements for Internet Hosts are specified in [15].

    Supporting UDP queries is mandatory, but support for TCP queries is
    recommended also, and is (in effect) required as RFC1123 requires
    that a DNS client discard a truncated response and re-try using
    another protocol.  In effect, Authoritative name servers which do not
    answer TCP queries after returning truncated responses are
    misconfigured.

    Given that ENUM queries are likely to return large RRsets that might
    cause truncated responses using the standard DNS transport, lack of
    TCP and/or EDNS0 support for the entities involved in an ENUM query
    may trigger some problems that can be difficult to determine and
    resolve.  For more details of the issues involved, see [19].

    As the normal process for a DNS Client is to make a TCP query only
    once a truncated response has been received, and there may be issues
    with the overall performance of the DNS when TCP is used for queries,
    it may be worthwhile for Clients (both the ENUM Client and any
    Recursive Resolver they use) to support EDNS0 and indicate their
    ability to receive larger response packets from DNS servers.  Note
    that this is not necessarily within the control of the ENUM Client,
    as they may well not have control over the Recursive Resolver (e.g.
    the ISP's Cache Server) they use and its capabilities.



Conroy & Fujiwara        Expires April 24, 2005                [Page 16]

Internet-Draft              ENUM Experiences                October 2004


    Thus, it is RECOMMENDED that (in keeping with the standards):
      Server  ENUM zone population systems SHOULD be careful of the DNS
              response size required to support the ENUM RRSet when
              writing NAPTRs.  It may be apropriate to warn the
              Registrant that by adding more NAPTRs they will slow down
              resolution of ENUM client queries.

      Server  Authoritative servers SHOULD support TCP queries and EDNS0.

      Client  Recursive Resolvers (e.g.  ISP's DNS Cache Servers) SHOULD
              support TCP queries and EDNS0.

      Client  ENUM clients SHOULD supprt TCP queries and EDNS0 queries.

    As a final comment, from our experiences a Name Server may support
    TCP queries, but there may well be an intervening packet filter that
    does not allow TCP traffic to pass correctly.  It is unfortunately
    common for people managing a firewall to block traffic to or from the
    DNS YCP port without considering the impact.  Thus if TCP queries do
    not seem to work, it is worthwhile considering this possibility; the
    Name Server may be operating correctly, but the TCP SYN or SYN-ACK
    packets may be blocked, effectively disabling the server from contact
    with the World outside the firewall.  This can be very hard to debug.

    Thus, although it should be obvious, we RECOMMEND that:
    MidBox    Name Servers SHOULD support TCP queries.  Thus intermediate
              systems such as firewalls SHOULD NOT be configured to
              filter traffic to or from a Name Server.  This is
              particularly important for Servers hosting ENUM data, as
              these may well need to support TCP queries to operate
              correctly




















Conroy & Fujiwara        Expires April 24, 2005                [Page 17]

Internet-Draft              ENUM Experiences                October 2004


7.  Backwards Compatibility

7.1  Service field syntax

    RFC3761 is the current standard for the syntax for NAPTRs supporting
    the ENUM DDDS application.  This obsoletes the original specification
    that was given in RFC2916.  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 RFC3403, there is now a single identifier that
    indicates the DDDS Application.  In the obsolete specification
    (RFC2915), there were zero or more "Resolution Service" identifiers
    (the equivalent of the DDDS Application).  The same identifier string
    is defined in both RFC3761 and in the old RFC2916 specifications for
    the DDDS identifier or the Resolution Service; "E2U".

    Also, RFC3761 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.  RFC3761 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.  RFC2916 specified that the protocol
    sub-field was the leftmost, followed by the '+' delimiter, in turn
    followed by the "E2U" resolution service tag.

    RFC2915 and RFC2916 have been obsoleted by RFC3401-RFC3404 and by
    RFC3761.  Thus it is RECOMMENDED that:
      Server  ENUM zone population systems MUST NOT generate NAPTRs
              according to the syntax defined in RFC2916.  All zones MUST
              hold ENUM NAPTRs according to RFC3761 (and ENUMservice
              specifications according to the framework specified there).

    However, RFC3824 [16] suggests that clients SHOULD be prepared to
    accept NAPTRs with the obsolete syntax.  Thus, a Client
    implementation may have to deal with both forms.

    It is RECOMMENDED that:
      Client  Clients MUST support ENUM NAPTRs according to RFC3761
              syntax.  Clients and SHOULD also support ENUM NAPTRs
              according to the obsolete syntax of RFC2916; there are
              still zones that hold "old" syntax NAPTRs.

    This need not be difficult.  For example, an implementation could
    process the services field into a set of tokens, and expect exactly



Conroy & Fujiwara        Expires April 24, 2005                [Page 18]

Internet-Draft              ENUM Experiences                October 2004


    one of these tokens to be "E2U".  In this way, the 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:
      Spec    Registrations for an ENUMservice with the type string of
              "E2U" and an empty sub-type string MUST NOT be accepted.











































Conroy & Fujiwara        Expires April 24, 2005                [Page 19]

Internet-Draft              ENUM Experiences                October 2004


8.  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 sections 3, 4, and 7 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
    client excess processing or memory usage.  It does, however, mean
    that a client will traverse a "tight loop" of non-final NAPTRs in two
    domains 5 times before the client detects this as a loop; this does
    introduce slightly higher processing load that would be provided
    using other methods, but avoids the risks they incur.


























Conroy & Fujiwara        Expires April 24, 2005                [Page 20]

Internet-Draft              ENUM Experiences                October 2004


9.  IANA Considerations

    This document is informational only, and does not include any IANA
    considerations other than the suggestion at the end of section 7.1
    that no-one should specify an enumservice with the identifying tag
    "E2U".













































Conroy & Fujiwara        Expires April 24, 2005                [Page 21]

Internet-Draft              ENUM Experiences                October 2004


10.  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 [20] 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 rigorous framework on which to build.
    This document reflects how complex a system it is - without the
    intricacy of RFC3401-RFC3404 and the work that went into them, it
    could have been quite different.































Conroy & Fujiwara        Expires April 24, 2005                [Page 22]

Internet-Draft              ENUM Experiences                October 2004


11.  References

11.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]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
          Resource Identifiers (URI): Generic Syntax", RFC 2396, August
          1998.

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



Conroy & Fujiwara        Expires April 24, 2005                [Page 23]

Internet-Draft              ENUM Experiences                October 2004


          August 1999.

    [14]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
          RFC 2181, July 1997.

    [15]  Braden, R., "Requirements for Internet Hosts -- Application and
          Support", RFC 1123, October 1989.

    [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]  Schulzrinne, H., "The tel URI for Telephone Numbers",
          draft-ietf-iptel-rfc2806bis-09.txt  (work in progress), July
          2004.

    [18]  ITU-T, "The International Public Telecommunication Number
          Plan", Recommendation E.164, May 1997.

11.2  Informative References

    [19]  Fujiwara, K., "DNS authoritative server misconfiguration and a
          countermeasure in resolver",
          draft-fujiwara-dnsop-bad-dns-auth-00.txt  (work in progress),
          October 2004.

    [20]  ETSI, "Minimum Requirements for Interoperability of European
          ENUM Implementations", ETSI TS 102 172, October 2004.

    [21]  Bradner, S., "The Internet Standards Process -- Revision 3",
          RFC 2026, BCP 9, October 1996.

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

    [23]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
          February 2004.

    [24]  Bradner, S., "Intellectual Property Rights in IETF Technology",
          BCP 79, RFC 3668, February 2004.











Conroy & Fujiwara        Expires April 24, 2005                [Page 24]

Internet-Draft              ENUM Experiences                October 2004


Authors' Addresses

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

    Phone: +44-1794-833666
    EMail: lwc@roke.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 April 24, 2005                [Page 25]

Internet-Draft              ENUM Experiences                October 2004


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 (2004).  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 & Fujiwara        Expires April 24, 2005                [Page 26]

------------------------------------------------------------------------
---------




</x-flowed>



ENUM                                                           L. Conroy
Internet-Draft                                                      RMRL
Expires: April 24, 2005                                      K. Fujiwara
                                                                    JPRS
                                                        October 24, 2004


               ENUM Implementation Issues and Experiences
                  <draft-ietf-enum-experiences-01.txt>

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 April 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

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 informational only, 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.




Conroy & Fujiwara        Expires April 24, 2005                 [Page 1]

Internet-Draft              ENUM Experiences                October 2004


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Character Sets and ENUM  . . . . . . . . . . . . . . . . . . .  5
     3.1   Character Sets - Non-ASCII considered harmful  . . . . . .  5
     3.2   Case Sensitivity . . . . . . . . . . . . . . . . . . . . .  7
     3.3   Regexp Field Delimiter . . . . . . . . . . . . . . . . . .  8
     3.4   Regexp Meta-character Issue  . . . . . . . . . . . . . . .  8
   4.  ORDER/PRIORITY Processing  . . . . . . . . . . . . . . . . . . 10
     4.1   Order/Priority values - general processing . . . . . . . . 10
     4.2   NAPTRs with identical ORDER/PRIORITY values  . . . . . . . 12
     4.3   Processing Order value across Zones  . . . . . . . . . . . 13
   5.  Non-final NAPTR Processing . . . . . . . . . . . . . . . . . . 14
     5.1   Non-Final NAPTRs - necessity . . . . . . . . . . . . . . . 14
     5.2   Non-Final NAPTRs - future implementation . . . . . . . . . 15
       5.2.1   Non-Final NAPTRs - general . . . . . . . . . . . . . . 15
       5.2.2   Non-Final NAPTRs - loop detection and response . . . . 15
   6.  DNS record size and DNS software issue . . . . . . . . . . . . 16
   7.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 18
     7.1   Service field syntax . . . . . . . . . . . . . . . . . . . 18
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 23
   11.1  Normative References . . . . . . . . . . . . . . . . . . . . 23
   11.2  Informative References . . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
       Intellectual Property and Copyright Statements . . . . . . . . 26






















Conroy & Fujiwara        Expires April 24, 2005                 [Page 2]

Internet-Draft              ENUM Experiences                October 2004


1.  Terminology

   This document is Informational, and does not specify a standard of
   any kind.  Note that recommendations here contain the words "MUST",
   "REQUIRE", "SHOULD", and "MAY".  In this particular document, these
   do not form a standard, and so 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 April 24, 2005                 [Page 3]

Internet-Draft              ENUM Experiences                October 2004


2.  Introduction

   The ENUM protocol (RFC3761 [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.

   From experience of creating ENUM data and of developing client
   systems to process that data it is apparent that there are some
   subtleties in the specifications that have led to different
   interpretations; in addition there are common syntactic mistakes in
   data currently "out there" on the Internet.

   This document is intended to help others avoid the potential pitfalls
   in interpreting the set of documents that specify the protocol.  It
   also reports the kind of data they will "find" and so how to process
   the intent of the publisher of that ENUM data, regardless of the
   syntax used.  As such, it is in keeping with the principle evinced in
   RFC791 that "In general, an implementation must be conservative in
   its sending behavior, and liberal in its receiving behavior".

   Note that the DDDS system is intricate and so in some places there
   are several potential interpretations of the specifications.  This
   document proposes a suggested interpretation for some of these
   points, but they are just that; suggestions.

   This draft covers 10 issues in five areas, making 37 recommendations
   and giving 2 clarifications.

   Any ENUM implementation issue has two sides:
   o  the "Server" side covering the expected behaviour of the ENUM zone
      provisioning system and expectations Registrants may make, and
   o  the "Client" side covering behaviour that has been observed and
      that can be expected of the Client, together with the expectations
      that an end user who requests an ENUM lookup may make.

   For each of the issues, we have split the recommendations into
   "Client" and "Server" proposals.  In three cases, we have indicated
   proposals that relate to ENUMservice specifications, rather than
   implementations; these are labelled as "Spec".

   There are undoubtedly other issues, and developers are asked to raise
   any others they find on the IETF ENUM Working group's mailing list
   and/or by mail to the authors (see later for contact information).
   Finally, note that the authors are not aware of any IPR issues that
   are involved in the suggestions made in this document.



Conroy & Fujiwara        Expires April 24, 2005                 [Page 4]

Internet-Draft              ENUM Experiences                October 2004


3.  Character Sets and ENUM

3.1  Character Sets - Non-ASCII considered harmful

   RFC3761 [1] and RFC3403 [2] specify that ENUM (and NAPTRs) support
   Unicode using the UTF-8 encoding specified in RFC3629 [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 non
   "UTF-8 aware" systems.

   The UTF-8 encoding has a "US-ASCII equivalent range", so that all
   characters in US-ASCII 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 they 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 Client may
   have good reason to reject NAPTRs that include these characters as
   they cannot be shown.

   There are two numeric fields in a NAPTR; the ORDER and PREFERENCE
   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-final", or it may include a
   flag character as specified in RFC3761.  These characters all fall
   into the US-ASCII equivalent range, so multi-byte characters cannot
   occur.




Conroy & Fujiwara        Expires April 24, 2005                 [Page 5]

Internet-Draft              ENUM Experiences                October 2004


   The services field includes the DDDS Application identifier ("E2U")
   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 RFC3761 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, RFC3403 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 RFC3761 to consist of digit characters,
   with an initial '+' character.  All of these 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 RFC3403.  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.

   The current URIs use the overall URI character "escaping" rules [12],
   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, a future URI scheme might be developed that
   allows characters with multi-byte UTF-8 encoding to exist.  If this
   happens, and if an ENUMservice specification is created that refers
   to this scheme, then multi-byte characters could then occur in a
   NAPTR.  The presence of these characters could complicate URI
   generation and processing routines.

   Given that this is the only place within an ENUM NAPTR where such
   multi-byte encodings might reasonably be found, a simple solution is
   for no ENUMservice definition to include a reference to a URI that
   allows UTF-8 characters outside the US-ASCII equivalent range to be
   included, or to require that such characters be "escape encoded"
   before inclusion in the repl sub-field.  The domain part of a URI
   MUST be processed using Punycode if it has a non-ASCII domain name,
   so there will be no non-ASCII characters in this part of any URI.



Conroy & Fujiwara        Expires April 24, 2005                 [Page 6]

Internet-Draft              ENUM Experiences                October 2004


   Taking into account the existing client base, it is RECOMMENDED that:
     Spec    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 a URI-specific
             "escape" mechanism to re-encode them only using US-ASCII
             equivalent printable characters (those in the range 0x20 to
             0x7E).

   At the least, it is RECOMMENDED that:
     Spec    Any ENUMservice registration that allows characters
             requiring multi-byte UTF-8 encoding to be present in the
             repl sub-field MUST have a clear indication that there may
             be characters outside of the US-ASCII equivalent range.

   Finally, the majority of ENUM Clients in use today do not support
   multi-byte encodings of 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
   RECOMMENDED that:
     Client  Clients MAY discard NAPTRs in which they detect characters
             not in the US-ASCII "printable" range (0x20 to 0x7E
             hexadecimal).

   ENUM provisioning systems should consider this.  It is RECOMMENDED
   that:
     Server  ENUM zone content population systems SHOULD NOT use
             non-ASCII characters in the NAPTRs they generate unless
             they are sure that all Clients they intend to support will
             be able correctly to process them.

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







Conroy & Fujiwara        Expires April 24, 2005                 [Page 7]

Internet-Draft              ENUM Experiences                October 2004


   To avoid the confusion that this generates, It is RECOMMENDED that:
     Server  When populating ENUM zones with NAPTRs, population systems
             SHOULD NOT use the 'i' flag, as it has no effect and some
             Clients don't expect it.

     Client  Clients SHOULD NOT assume that the field delimiter is the
             last character.

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

   It is RECOMMENDED that:
     Server  ENUM zone population systems SHOULD use '!' (U+0021) as
             their RegExp delimiter character.

     Client  Clients MAY discard NAPTRs that do not use '!' as a RegExp
             delimiter.

   This 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).
   Thus, it is further RECOMMENDED that:
     Server  ENUM zone population 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 RFC3402 (i.e.  "\!", U+005C U+0021).

     Client  Clients SHOULD discard NAPTRs that have more or less than 3
             "unescaped" instances of the delimiter character within the
             RegExp field.

3.4  Regexp Meta-character Issue

   In ENUM, the ERE sub-field may include a literal character '+', as
   the Application Unique String on which it operates includes this.
   However, if it is present, then '+' must be "escaped" using a
   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@sipcsp.se!" .




Conroy & Fujiwara        Expires April 24, 2005                 [Page 8]

Internet-Draft              ENUM Experiences                October 2004


   This example MUST be written as:

   * IN NAPTR 100 10 "u" "E2U+sip" "!^\+46555(.*)$!sip:\1@sipcsp.se!" .

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












































Conroy & Fujiwara        Expires April 24, 2005                 [Page 9]

Internet-Draft              ENUM Experiences                October 2004


4.  ORDER/PRIORITY Processing

4.1  Order/Priority values - general processing

   RFC3761 and RFC3403 state that the client MUST sort the NAPTRs using
   the ORDER field value ("lowest value is first") and SHOULD order the
   NAPTRs using the 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 expected behaviour is a simplification; 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 don't 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 their own preference for services
   to be used.  Thus, an end user may specify that they would prefer to
   use contacts with a "sip" ENUMservice, and then those with
   "msg:email" service, and are not interested in any other options.
   Thus the sorted list as proposed by the Registrant (and published via
   ENUM) may be re-ordered.  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
   inconvenient for the end user, some clients simply offer all of the
   available NAPTRs as options to the end user for their selection "in
   one go".

   In summary, some clients will take into account the service field
   value along with the ORDER and PRIORITY field values, and may
   consider the preferences of the end user.

   The Registrant and the ENUM zone population system they use MUST be
   aware of this and SHOULD NOT rely on Clients taking account of the



Conroy & Fujiwara        Expires April 24, 2005                [Page 10]

Internet-Draft              ENUM Experiences                October 2004


   value of the ORDER and the PRIORITY fields.

   Specifically, it is unsafe to assume that a Client WILL NOT consider
   another NAPTR until they have discarded one with a "winning" ORDER
   value.  The instruction (in RFC3403 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:
     Server  An ENUM zone population system SHOULD NOT use different
             ORDER values for NAPTRs within a zone.

   In our 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:
     Server  An ENUM zone population system SHOULD use a value of 100 as
             the default ORDER value to be used with all NAPTRs.

   As such, when populating a zone with NAPTRS, it is RECOMMEDED that:
     Server  A Registrant SHOULD NOT expect the client to ignore NAPTRs
             with higher ORDER field values - the "winning" ones may
             have been discarded.

     Server  Server - A Registrant SHOULD NOT expect the client to
             conform to the ORDER and PRIORITY sort order they have
             specified for their NAPTRs; the end user may have their own
             preferences for ENUMservices.

     Client  Client - Clients MAY re-order the NAPTRs only to match an
             explicit preference pre-specified by their end user.

     Client  Client - Clients that offer a list of contacts to the end
             user for their 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 "at once".

   The impact of this is that a Registrant should place into their zone
   only contacts that they are willing to support; even those with the
   "least preferred" ORDER/PRIORITY values may be selected by an end
   user.

   Finally, we have noticed a number of ENUM zones with NAPTRs that have
   identical PRIORITY field values and different ORDER values.  This may
   be the result of a zone population system "bug" or a misunderstanding
   over the uses of the two fields.



Conroy & Fujiwara        Expires April 24, 2005                [Page 11]

Internet-Draft              ENUM Experiences                October 2004


   To clarify, the ORDER field value is the major sort term, and the
   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 PRIORITY field values.

4.2  NAPTRs with identical ORDER/PRIORITY values

   From experience, there are zones that hold discrete NAPTRs with
   identical ORDER and 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:
     Client  Clients should accept all NAPTRs with identical ORDER and
             identical PRIORITY field values, and process them in the
             order 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 may
             do this already).

   Conversely, populating the records with these identical values is a
   mistake, and so it is RECOMMENDED that:
     Server  When populating ENUM zones with NAPTRs, ENUM zone
             population systems SHOULD NOT have more than one with the
             same ORDER and the same PRIORITY field values, as Clients
             MAY reject the response.

   There is a special case in which one could derive a set of NAPTRs
   with identical ORDER/PRIORITY fields.  With RFC3761, 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 ENUMservice" NAPTR could
   well be used to indicate, for example, a mobile phone that supports
   both voice:tel and msg:sms ENUMservices.

   This compound NAPTR may be deconstructed into a set of NAPTRs each
   holding a single ENUMservice.  However, in this case the members of
   this set all hold the same ORDER and PRIORITY field values.

   In this case, it is RECOMMENDED that:
     Client  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.






Conroy & Fujiwara        Expires April 24, 2005                [Page 12]

Internet-Draft              ENUM Experiences                October 2004



     Server  An ENUM zone population system SHOULD assume that, if it
             generates compound NAPTRs, the ENUMservices will be
             processed in "left to right" order within such NAPTRs.

4.3  Processing Order value across Zones

   Using a different ORDER field value in different zones is unimportant
   for most queries.  However, DDDS includes a mechanism for continuing
   a search for NAPTRs in another zone by including a reference to that
   other zone in a "non-final" NAPTR.  The treatment of non-ginal NAPTRs
   is covered in the next section, but if these are supported then it
   does have a bearing on the way that ORDER and Priority field values
   are processed.

   Two main questions remain from the specifications in DDDS and
   RFC3671:
   o  if there's a different (lower) order field value in a zone
      referred to by a non-final NAPTR, then does this mean that the
      ENUM client discards the other NAPTRs in the referring zone?

   o  Conversely, if the zone referred to by a non-final NAPTR contains
      entries that have a higher ORDER field value, then does the ENUM
      client ignore those?

   Whilst one interpretation of section 1.3 of RFC3761 is that the
   answer to both questions is "yes", this is not the way that those
   expamples of non-final NAPTRs that do exist (and those ENUM Clients
   that support them) seem to be designed.

   Thus, to reflect the interpretation that is made by those systems
   that have implemented non-final NAPTRs, it is RECOMMENDED that:
     Server  Registrants SHOULD assume that, once a non-final NAPTR has
             been selected for processing, the ORDER field value in a
             zone referred to by that non-final NAPTR will be considered
             only within the context of that referenced zone (i.e.  the
             ORDER value will be used only to sort within the referenced
             zone, and will not be used in the processing of NAPTRs in
             the referring zone).

     Client  ENUM Clients SHOULD consider the ORDER field value only
             when sorting NAPTRs within a single zone.  The ORDER field
             value SHOULD NOT be taken into account when processing
             NAPTRs across a multi-zone ENUM query created by a chain of
             non-final NAPTR references.






Conroy & Fujiwara        Expires April 24, 2005                [Page 13]

Internet-Draft              ENUM Experiences                October 2004


5.  Non-final NAPTR Processing

5.1  Non-Final NAPTRs - necessity

   Consider an ENUM domainname that contains a non-final NAPTR record.
   This non-final NAPTR "points to" another domain that has a set of
   NAPTRs.  In effect, this is similar to the non-final NAPTR being
   replaced by the NAPTRs contained in the domain to which it points.

   It is possible to have a non-final NAPTR in a domain that is, itself,
   pointed to by another non-final NAPTR.  Thus a set of domains forms a
   "chain", and the list of NAPTRs considered is the set of all NAPTRs
   contained in all of the domains in that chain.

   For an ENUM management system to support non-final 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-final NAPTRs in its domain.  If the domains
   pointed to have non-final 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 zones.  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 to support non-final NAPTRs can also be difficult.
   Processing non-final 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-final 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-final NAPTR can be replaced by the
   NAPTRs in the domain to which it points, support of non-final NAPTR
   is not needed and non-final NAPTRs may not be useful.

   Furthermore, most existing ENUM clients do not support non-final
   NAPTRs and ignore them if received.  To avoid interoperability
   problems, some kind of acceptable requirement is needed on non-final
   NAPTRs.  Given the lack of current support and the issues raised, we
   propose that one SHOULD NOT use non-final NAPTRs in ENUM.






Conroy & Fujiwara        Expires April 24, 2005                [Page 14]

Internet-Draft              ENUM Experiences                October 2004


   Thus, it is RECOMMENDED that:
     Server  ENUM zone population systems SHOULD NOT generate non-final
             NAPTRs (i.e.  NAPTRs with an empty flags field).

     Client  ENUM clients MAY discard non-final NAPTRs (i.e.  they MAY
             only support ENUM NAPTRs with a flags field of "u").

5.2  Non-Final NAPTRs - future implementation

   The following specific issues need to be considered if non-final
   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-final 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-final NAPTRs in "its" zones refer.

5.2.1  Non-Final NAPTRs - general

   To clarify, if all NAPTRs in a domain traversed as a result of a
   reference in a non-final NAPTR have been discarded, then the Client
   should continue its processing with the next NAPTR in the zone
   including the non-final NAPTR that caused the traversal.

   A non-final NAPTR in one zone refers to the NAPTRs contained in
   another zone.  The NAPTRs in the zone referred to by the non-final
   NAPTR may have a different ORDER value from that in the referring
   non-final NAPTR.  See section 4.3 for details.

5.2.2  Non-Final NAPTRs - loop detection and response

   Where a "chain" of non-final NAPTRs refers back to a domain already
   traversed in the current query, this implies a "non-final loop".  To
   ensure consistent behaviour, it is RECOMMENDED that:
     Client  Clients SHOULD consider processing more than 5 "non-final"
             NAPTRs in a single ENUM query to indicate that a loop may
             have been detected, and act accordingly.

     Server  When populating a set of domains with NAPTRs, one should
             not configure non-final NAPTRs so that more than 5 such
             NAPTRs will be processed in an ENUM query.

     Client  Where a domain is about to be entered as the result of a
             reference in a non-final NAPTR, and the client has detected
             a potential "non-final loop", then the Client should
             discard the non-final NAPTR from its processing and
             continue with the next NAPTR in its list.



Conroy & Fujiwara        Expires April 24, 2005                [Page 15]

Internet-Draft              ENUM Experiences                October 2004


6.  DNS record size and DNS software issue

   ENUM RRsets may be large.  An ENUM DNS response size may easily
   exceed the 512 octet limit for "basic" UDP-based DNS messages.

   In this case, a basic DNS response will be truncated (indicated by
   the "TC" flag being set to '1' in the response).

   The full DNS content can be carried only in TCP, or UDP packets where
   the Client has indicated a suitably large packet size with EDNS0
   [13].

   Limiting ENUM RRSet size is not easily possible in ENUM, as the
   Registrant has control of the RRSet held in "their" zone, not the
   Authoritative Name Server or the ENUM Client.

   If the Registrant chooses to hold a large set of NAPTRs in their
   zone, then all entities involved in ENUM, (ENUM clients, their ISP's
   recursive resolver/cache servers, and the authoritative servers that
   hold ENUM RRSets) MUST support TCP DNS queries and responses (or
   EDNS0 with a suitably large packet size specification) or they cannot
   resolve ENUM requests.

   The DNS protocol is defined in [8][9] and clarified in [14], whilst
   Requirements for Internet Hosts are specified in [15].

   Supporting UDP queries is mandatory, but support for TCP queries is
   recommended also, and is (in effect) required as RFC1123 requires
   that a DNS client discard a truncated response and re-try using
   another protocol.  In effect, Authoritative name servers which do not
   answer TCP queries after returning truncated responses are
   misconfigured.

   Given that ENUM queries are likely to return large RRsets that might
   cause truncated responses using the standard DNS transport, lack of
   TCP and/or EDNS0 support for the entities involved in an ENUM query
   may trigger some problems that can be difficult to determine and
   resolve.  For more details of the issues involved, see [19].

   As the normal process for a DNS Client is to make a TCP query only
   once a truncated response has been received, and there may be issues
   with the overall performance of the DNS when TCP is used for queries,
   it may be worthwhile for Clients (both the ENUM Client and any
   Recursive Resolver they use) to support EDNS0 and indicate their
   ability to receive larger response packets from DNS servers.  Note
   that this is not necessarily within the control of the ENUM Client,
   as they may well not have control over the Recursive Resolver (e.g.
   the ISP's Cache Server) they use and its capabilities.



Conroy & Fujiwara        Expires April 24, 2005                [Page 16]

Internet-Draft              ENUM Experiences                October 2004


   Thus, it is RECOMMENDED that (in keeping with the standards):
     Server  ENUM zone population systems SHOULD be careful of the DNS
             response size required to support the ENUM RRSet when
             writing NAPTRs.  It may be apropriate to warn the
             Registrant that by adding more NAPTRs they will slow down
             resolution of ENUM client queries.

     Server  Authoritative servers SHOULD support TCP queries and EDNS0.

     Client  Recursive Resolvers (e.g.  ISP's DNS Cache Servers) SHOULD
             support TCP queries and EDNS0.

     Client  ENUM clients SHOULD supprt TCP queries and EDNS0 queries.

   As a final comment, from our experiences a Name Server may support
   TCP queries, but there may well be an intervening packet filter that
   does not allow TCP traffic to pass correctly.  It is unfortunately
   common for people managing a firewall to block traffic to or from the
   DNS YCP port without considering the impact.  Thus if TCP queries do
   not seem to work, it is worthwhile considering this possibility; the
   Name Server may be operating correctly, but the TCP SYN or SYN-ACK
   packets may be blocked, effectively disabling the server from contact
   with the World outside the firewall.  This can be very hard to debug.

   Thus, although it should be obvious, we RECOMMEND that:
   MidBox    Name Servers SHOULD support TCP queries.  Thus intermediate
             systems such as firewalls SHOULD NOT be configured to
             filter traffic to or from a Name Server.  This is
             particularly important for Servers hosting ENUM data, as
             these may well need to support TCP queries to operate
             correctly




















Conroy & Fujiwara        Expires April 24, 2005                [Page 17]

Internet-Draft              ENUM Experiences                October 2004


7.  Backwards Compatibility

7.1  Service field syntax

   RFC3761 is the current standard for the syntax for NAPTRs supporting
   the ENUM DDDS application.  This obsoletes the original specification
   that was given in RFC2916.  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 RFC3403, there is now a single identifier that
   indicates the DDDS Application.  In the obsolete specification
   (RFC2915), there were zero or more "Resolution Service" identifiers
   (the equivalent of the DDDS Application).  The same identifier string
   is defined in both RFC3761 and in the old RFC2916 specifications for
   the DDDS identifier or the Resolution Service; "E2U".

   Also, RFC3761 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.  RFC3761 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.  RFC2916 specified that the protocol
   sub-field was the leftmost, followed by the '+' delimiter, in turn
   followed by the "E2U" resolution service tag.

   RFC2915 and RFC2916 have been obsoleted by RFC3401-RFC3404 and by
   RFC3761.  Thus it is RECOMMENDED that:
     Server  ENUM zone population systems MUST NOT generate NAPTRs
             according to the syntax defined in RFC2916.  All zones MUST
             hold ENUM NAPTRs according to RFC3761 (and ENUMservice
             specifications according to the framework specified there).

   However, RFC3824 [16] suggests that clients SHOULD be prepared to
   accept NAPTRs with the obsolete syntax.  Thus, a Client
   implementation may have to deal with both forms.

   It is RECOMMENDED that:
     Client  Clients MUST support ENUM NAPTRs according to RFC3761
             syntax.  Clients and SHOULD also support ENUM NAPTRs
             according to the obsolete syntax of RFC2916; there are
             still zones that hold "old" syntax NAPTRs.

   This need not be difficult.  For example, an implementation could
   process the services field into a set of tokens, and expect exactly



Conroy & Fujiwara        Expires April 24, 2005                [Page 18]

Internet-Draft              ENUM Experiences                October 2004


   one of these tokens to be "E2U".  In this way, the 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:
     Spec    Registrations for an ENUMservice with the type string of
             "E2U" and an empty sub-type string MUST NOT be accepted.











































Conroy & Fujiwara        Expires April 24, 2005                [Page 19]

Internet-Draft              ENUM Experiences                October 2004


8.  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 sections 3, 4, and 7 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
   client excess processing or memory usage.  It does, however, mean
   that a client will traverse a "tight loop" of non-final NAPTRs in two
   domains 5 times before the client detects this as a loop; this does
   introduce slightly higher processing load that would be provided
   using other methods, but avoids the risks they incur.


























Conroy & Fujiwara        Expires April 24, 2005                [Page 20]

Internet-Draft              ENUM Experiences                October 2004


9.  IANA Considerations

   This document is informational only, and does not include any IANA
   considerations other than the suggestion at the end of section 7.1
   that no-one should specify an enumservice with the identifying tag
   "E2U".













































Conroy & Fujiwara        Expires April 24, 2005                [Page 21]

Internet-Draft              ENUM Experiences                October 2004


10.  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 [20] 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 rigorous framework on which to build.
   This document reflects how complex a system it is - without the
   intricacy of RFC3401-RFC3404 and the work that went into them, it
   could have been quite different.































Conroy & Fujiwara        Expires April 24, 2005                [Page 22]

Internet-Draft              ENUM Experiences                October 2004


11.  References

11.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]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

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



Conroy & Fujiwara        Expires April 24, 2005                [Page 23]

Internet-Draft              ENUM Experiences                October 2004


         August 1999.

   [14]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
         RFC 2181, July 1997.

   [15]  Braden, R., "Requirements for Internet Hosts -- Application and
         Support", RFC 1123, October 1989.

   [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]  Schulzrinne, H., "The tel URI for Telephone Numbers",
         draft-ietf-iptel-rfc2806bis-09.txt  (work in progress), July
         2004.

   [18]  ITU-T, "The International Public Telecommunication Number
         Plan", Recommendation E.164, May 1997.

11.2  Informative References

   [19]  Fujiwara, K., "DNS authoritative server misconfiguration and a
         countermeasure in resolver",
         draft-fujiwara-dnsop-bad-dns-auth-00.txt  (work in progress),
         October 2004.

   [20]  ETSI, "Minimum Requirements for Interoperability of European
         ENUM Implementations", ETSI TS 102 172, October 2004.

   [21]  Bradner, S., "The Internet Standards Process -- Revision 3",
         RFC 2026, BCP 9, October 1996.

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

   [23]  Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
         February 2004.

   [24]  Bradner, S., "Intellectual Property Rights in IETF Technology",
         BCP 79, RFC 3668, February 2004.











Conroy & Fujiwara        Expires April 24, 2005                [Page 24]

Internet-Draft              ENUM Experiences                October 2004


Authors' Addresses

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

   Phone: +44-1794-833666
   EMail: lwc@roke.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 April 24, 2005                [Page 25]

Internet-Draft              ENUM Experiences                October 2004


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 (2004).  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 & Fujiwara        Expires April 24, 2005                [Page 26]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/