The ENUM clients MAY ignore all NAPTR records except those with Flag "U". The flag field value should always be “U” and never blank.
The Order field for all NAPTRs within a single ENUM domain SHALL be set to the same value (e.g 10).
The Preference field MAY be used by the ENUM Subscriber as a recommendation to the order in which the contacts should be presented to the ENUM user. The ENUM client MAY order the list of NAPTRs using the Preference field; however it is not required to do so.
The regular expression field SHALL use the "!" character as a delimiter.
As a minimum, an ENUM Client need not be able to process NAPTRs that include Regular Expression fields that have consequent parts that are dependent on the matching part (i.e. where a string of form "\1" is included), and this part is not just a literal string holding the URI. It should be able to detect the presence of such a pattern and reject the NAPTR, and MUST not attempt to use this string.
The regular expression field is in two parts; a matching part followed by a consequent part. Unless unavoidable, the matching part SHOULD include only a fully matching pattern, with the consequent part holding a complete replacement, without re-using matched patterns. These can be considered as a full "throw away the input string and replace by the literal string held in the consequent part". In the format of the regular expression field, this would appear as "!^.*$!full-uri!" (where "full-uri" holds the target URI string).
The EDNS "extended length" option flag (footnote) should not be used in ENUM queries. This limits the space available for returned NAPTRs to ca. 500 octets.
As a result, the maximum number of NAPTRs populated in any queried subdomain should be limited to fit into this space - this equates to a limit of 5 NAPTRs per ENUM subdomain.[1]
ENUM Clients SHALL check for presence of more than one "+" and understand. They may present as if it were two or more singe NAPTRs .
It is suggested that a NAPTR with more than one "enumservice" type should be displayed as a number of values, each supporting one enumservice. In effect, the NAPTR is converted in the Client to a number of "NAPTRs", each with a single enumservice.
Note that if the NAPTR includes more than one enumservice, then if the URI-scheme differs between the enumservices, or the URI scheme is different from that shown in the Regular Expression field, then the NAPTR is incorrect and MUST be rejected by the client.
The entity publishing the Resource Record and the entity querying the Resource Record SHALL have a common understanding of the meaning stored in that Record.
To achieve this, within the ENUM trials a common (basic) set of "enumservices" is agreed that MAY be expected within the service field of an ENUM NAPTR Resource Record. The enumservices define also a common (basic) set of URI-schemes.
This does NOT mean that every ENUM client SHALL support all of the "enumservices" that are in this set, but instead that it SHALL recognise the meaning of these values and common defined behaviour (see note) SHALL be provided for "enumservices" and URI schemes which are not recognised by the ENUM clients.
2011
