IANA Registrations for the 'Send-N' Enumservice

E.164 Number Mapping (ENUM) uses the Domain Name System (DNS) to refer from E.164 numbers to Uniform Resource Identifiers (URIs) The typical operation of PSTN telephones is that dialled digits are sent to the network operator as soon as they are dialled and the call is initiated as soon as the network recognises that a complete number has been dialled (without using inter-digit timeouts). This PSTN model for dialling is known as "overlapped dialing". This is in contrast to most SIP devices and cellular devices which require the user to dial a complete telephone number and then press a 'send' or 'dial' button to initiate dialling. Currently to properly support overlapped dialling from generic PSTN telephones via an ENUM-enabled switch the switch would need to perform an ENUM lookup as each and every digit is dialled. This would impose a significant burden on the DNS servers and could also affect call setup time. By publishing additional information about the structure of the ENUM database it is possible to provide hints that allow unnecessary per-digit DNS lookups to be skipped. This additional information is encoded within NAPTR records since this avoids the need for applications to issue multiple DNS requests with varying QTYPEs depending on the type of information being looked up. To differentiate NAPTR records containing 'Send-N' data from other types of NAPTR record it is necessary to create a new Enumservice which must be registered with IANA. registers the 'cnam' Enumservice for PSTN data with type 'pstndata' and a specific 'cnam' subtype for Calling Name Delivery. It also registers the 'pstndata' Uniform Resource Identifier (URI) scheme. Both the Enumservice and the URI scheme documented therein are intended to be extensible to represent other PSTN related data. This document therefore requests the registration of a new Enumservice subtype for 'Send-N' and extends the definition of the 'pstndata' URI scheme.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Whilst the term "ENUM" is usually reserved for applications implementing RFC3761 specifically in the public e164.arpa zone, in this document it is taken to mean any system utilising an ENUM-like database structure and algorithm. A "full ENUM record" is an RRset containing NAPTR records about a complete E.164 telephone number.

The following template contains information required for the IANA registrations of the 'Send-N' Enumservice: Enumservice Name: Send-N Enum service Class: Ancillary Application Enumservice Enumservice Type: pstndata Enumservice Subtype: send-n URI Schemes: pstndata Functional Specification: This Enumservice indicates that the resource record contains information that describes the structure of the ENUM database tree. Security Considerations: see Intended Usage: COMMON Author: Ray Bellis <mailto:ray.bellis@nominet.org.uk>

URI scheme name: pstndata Status: provisional URI scheme syntax: (in ABNF )

where 'pstndatauri' is imported from URI scheme semantics: The URI contains information that describes the structure of the ENUM database. Where the URI contains an "equals" sign before the "digitsmin" field then the numeric fields shall be interpreted as an absolute number of digits. Otherwise the information is interpreted to be relative to the domain which contained the NAPTR RR which in turn contained this URI in its 'regexp' field. Encoding considerations: None, all valid characters are in US ASCII Applications: ENUM Interoperability considerations: none Security considerations: see Contact: Ray Bellis <mailto:ray.bellis@nominet.org.uk> References:

This Enumservice and URI scheme described here are primarily intended for use in private ENUM applications and are of particular relevance to Infrastructure ENUM. The NAPTR records contain meta-information about an ENUM database - specifically the minimum depth in the ENUM database at which full ENUM records may be found. In some jurisdictions this data may be static and based on information supplied by the local numbering plan administrator. It is expected however that Send-N records would be synthesised automatically by the DNS server based on the information currently stored in its ENUM database. Note that gaps in the E.164 numbering plan are not represented by this data. The 'Send-N' data only indicates the _potential_ presence of numbers, not their absence. The details of how the absence of ENUM records should be represented (e.g. for invalid or unallocated numbers) are not addressed in this document. The 'digitsmin' field of the data MUST correspond to the minimum number of digits to be dialled which might result in reaching a full ENUM record in the ENUM database. This may be either relative to the current record, or an absolute value. Absolute values are based on canonical E.164 representation, as used as the input to the ENUM algorithm. Having received 'digitsmin' digits the application SHOULD perform another DNS lookup which may return another 'Send-N' record. The information received in the new record MUST override the previously received information and the process repeated.

An example ENUM entry containing 'Send-N' data looks like:

This record indicates that at least 5 additional digits are required to reach any valid E.164 number beginning +441865. Having received the NAPTR record from the previous example, the application might subsequently receive the five additional digits "33221". Based on the previously received record the application knows that it need not perform any ENUM lookups for each of the next four digits, but on receiving the fifth it then performs another ENUM lookup, returning the record below:

This data indicates that at least one further digit needs to be dialled before a full ENUM record might be returned.

All E.164 numbers in the North American Numbering Plan (NANP) contain exactly 11 digits.

This record indicates that a minimum of 11 digits are required for any number beginning +1. The URI could alternatively have been written as "pstndata:send-n/10" to specify that at least 10 additional digits are required.

An RRset MUST NOT contain more than one 'Send-N' NAPTR record. This document accordingly makes no recommendations on suitable values for the 'order' and 'preference' fields.

The relative form of these records SHOULD NOT be used with DNS wildcards since DNS wildcards can represent an arbitrary number of labels (or digits, in the ENUM case) and the data in a relative form 'Send-N' record is specific to an exact position in the ENUM tree.

Where an ENUM database contains delegations then the 'digitsmin' data SHOULD reflect the minimum number of digits at which delegation occurs. This helps to ensure that parent domains do not inadvertently provide incorrect 'Send-N' data about delegated number space about which they may have no knowledge.

These records are mostly likely to be used in intermediate records in the ENUM database, although in countries (such as Austria) that use numbering plans where numbers may appear as leading prefixes of other numbers it might be possible to find both full NAPTR records and 'Send-N' NAPTR records in the same RRset. For example, a company switchboard might be reached by dialling the main number and extensions are reached by dialling additional digits. In this case there would be normal NAPTR records containing contact addresses for the switchboard, but there could also be a 'Send-N' record indicating the length of the internal extension numbers.

This Enumservice and URI scheme were originally designed for use on a large Infrastructure ENUM database, where no new security issues are believed to be introduced through the use of this Enumservice. There is a potential misuse of this data in public ENUM databases where delegations are made to third parties whereby a parent zone could include incorrectly high values in a 'Send-N' record. That might prevent a child zone's 'Send-N' records from being looked up which in return could result in the application over dialling. The effect of that would depend on whether the child zone includes wildcard DNS records to allow for over dialling. The effect of putting incorrectly low values of 'Send-N' is benign.

This document requests the IANA registration of the Enumservice 'Send-N' with Type 'pstndata' and Subtype 'send-n' according to the definitions in this document, RFCxxxx and RFC3761bis. The required template is contained in . This document requests an update to the IANA registration of the URI scheme 'pstndata' according to the definitions in this document and following the process described in . The required template is contain in .

[Note to editors: This section is to be removed before publication - XML source available on request] draft-bellis-enum-send-n-02 Minor editorial NITs from -01 fixed Introduction rewritten slightly draft-bellis-enum-send-n-01 Fixed ABNF for 'e164digitcount' Removed support for 'digitsmax' Introduced support for absolute digit counts Expanded DNS considerations draft-bellis-enum-send-n-00 initial draft

The author would like to thank those members of the Network Interoperability Consultative Committee () and in particular to Clive Feather, who contributed to the NICC specification for a Central Number Portability Database from which this work is derived. The author would also like to thank Alexander Mayrhofer for his assistance.