IANA Registrations for the 'Send-N' Enumservice
draft-bellis-enum-send-n-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-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 October 4, 2008.

Abstract

This document requests IANA registration of an Enumservice 'Send-N' and extends the definition of the 'pstndata:' URI scheme. This service allows more efficient support for overlapped dialling in E.164 Number Mapping (ENUM) enabled applications.

Table of Contents

1.  Introduction

2.  Terminology

3.  ENUM Service Registration for "Send-N"

4.  IANA Registration Template for URI scheme "pstndata:"

5.  Description

6.  Example

7.  DNS Considerations

8.  Security Considerations

9.  IANA Considerations

10.  Change Log

11.  Acknowledgements

12.  References
    12.1.  Normative References
    12.2.  Informative References

§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

E.164 Number Mapping (ENUM) (Bradner, S., Conroy, L., and K. Fujiwara, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” November 2009.) [I‑D.ietf‑enum‑3761bis] uses the Domain Name System (DNS) (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) [RFC1035] to refer from E.164 numbers (ITU-T, “The international public telecommunication numbering plan,” Feb 2005.) [E.164] to Uniform Resource Identifiers (URIs) (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986]

Most SIP devices and cellular devices require the user to dial a complete telephone number and then press a 'send' or 'dial' button to initiate dialling. This contrasts with the typical operation of PSTN telephones where dialled digits are sent to the network operator as soon they are dialled and the call is initiated as soon as the network recognises that a complete number has been dialled. This PSTN model for dialling is known as "overlapped dialing".

Currently to support overlapped dialling an ENUM application would need to perform an ENUM lookup as each and every digit is dialled. This would impose a significant burden on the ENUM DNS servers and could also affect call setup time.

By storing additional information within the ENUM database about the structure of the local numbering plan it is possible to provide hints to such an application that will allow it to skip unnecessary per-digit ENUM lookups.

This additional information is encoded within NAPTR records since this avoids the need for ENUM 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.

[I‑D.ietf‑enum‑cnam] (Shockey, R., “IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata',” September 2008.) 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.

2.  Terminology

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

A "full ENUM record" is an RRset containing NAPTR records about a complete E.164 telephone number.

3.  ENUM Service Registration for "Send-N"

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 local E.164 numbering plan below this point.

Security Considerations: see Section 8 (Security Considerations)

Intended Usage: COMMON

Author: Ray Bellis <mailto:ray.bellis@nominet.org.uk>

4.  IANA Registration Template for URI scheme "pstndata:"

URI scheme name: pstndata

Status: provisional

URI scheme syntax: (in ABNF [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.))

pstndatauri    =/ ( "pstndata:" sendndatatype )
sendndatatype  = "send-n/" digitsmin [ "-" digitsmax ]
digitsmin      = e164digitcount
digitsmax      = e164digitcount
e164digitcount = %x30-%x39 / (%x31 %x30-%x35)
                 ; 0 - 15 digits, per E.164

where 'pstndatauri' is imported from [I‑D.ietf‑enum‑cnam] (Shockey, R., “IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata',” September 2008.)

URI scheme semantics: The URI contains information that describes the structure of the local E.164 numbering plan. This 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 (Bradner, S., Conroy, L., and K. Fujiwara, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” November 2009.) [I‑D.ietf‑enum‑3761bis]

Interoperability considerations: none

Security considerations: see Section 8 (Security Considerations)

Contact: Ray Bellis <mailto:ray.bellis@nominet.org.uk>

References: [I‑D.ietf‑enum‑cnam] (Shockey, R., “IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata',” September 2008.)

5.  Description

The records described here contain meta-information about an ENUM database - specifically the depth (or range of depths) in the DNS tree below the current record at which full ENUM records may be found, as per the local numbering plan.

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 additional digits to be dialled, relative to the current record, which might result in reaching a full ENUM record in the ENUM database.

It is RECOMMENDED that the 'digitsmax' field also be supplied and where supplied it MUST correspond to the maximum number of additional digits that might be valid in the relevant numbering plan. If the 'digitsmax' field is omitted this represents that the information is unknown and MUST NOT be assumed to be the same as 'digitsmin'.

6.  Example

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

$ORIGIN 5.6.8.1.4.4.e164.arpa.
@ IN NAPTR ( 100 10 "u"
             "E2U+pstndata:send-n"
             "!^.*$!pstndata:send-n/5-6!" .
           )

This record indicates that between 5 and 6 additional digits are required to reach any valid E.164 number beginning +441865 according to the local numbering plan.

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:

$ORIGIN 1.2.2.3.3.5.6.8.1.4.4.e164.arpa.
@ IN NAPTR ( 100 10 "u"
             "E2U+pstndata:send-n"
             "!^.*$!pstndata:send-n/1-1!" .
           )

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

7.  DNS Considerations

These records MUST 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 'Send-N' record is specific to an exact position in the ENUM tree

These records are mostly likely to be used in intermediate records in the ENUM database, although in countries (such as Austria) that use open numbering plans it might be possible to find both full NAPTR records and 'Send-N' NAPTR records in the same RRset.

An example of this is where a company switchboard might be reached by dialling the main number and extensions are reached by dialling additional digits. In that case the country-level administrator would maintain 'Send-N' records that describe the national dialling plan, but end user ENUM registrations could supply additional 'Send-N' records that describe their internal numbering plan.

8.  Security Considerations

This Enumservice and URI scheme were originally designed for use on a large private ENUM database, where no security issues are believed to exist.

Security issues resulting from use of this data in public ENUM database where delegations are made to third parties have not been assessed in detail, however it is believed that no new security or privacy issues would arise from the use of this data.

9.  IANA Considerations

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 (Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template and IANA Considerations,” April 2010.) [I‑D.ietf‑enum‑enumservices‑guide] and RFC3761bis (Bradner, S., Conroy, L., and K. Fujiwara, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” November 2009.) [I‑D.ietf‑enum‑3761bis]. The required template is contained in Section 3 (ENUM Service Registration for "Send-N").

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 [RFC4395] (Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes,” February 2006.). The required template is contain in Section 4 (IANA Registration Template for URI scheme "pstndata:").

10.  Change Log

[Note to editors: This section is to be removed before publication - XML source available on request]

draft-bellis-enum-send-n-00

initial draft

11.  Acknowledgements

The author would like to thank those members of the Network Interoperability Consultative Committee (http://www.nicc.org.uk/) 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.

12.  References

12.1. Normative References

12.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.

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, THE IETF TRUST 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.

Intellectual Property

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.