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

Versions: 00 01 02

ENUM -- Telephone Number Mapping                               R. Bellis
Working Group                                                 Nominet UK
Internet-Draft                                             June 23, 2008
Expires: December 25, 2008


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

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 December 25, 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) applications.











Bellis                  Expires December 25, 2008               [Page 1]


Internet-Draft             Send-N Enumservice                  June 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3

   3.  ENUM Service Registration for "Send-N" . . . . . . . . . . . .  4

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

   5.  Description  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     6.1.  United Kingdom . . . . . . . . . . . . . . . . . . . . . .  6
     6.2.  North America  . . . . . . . . . . . . . . . . . . . . . .  7

   7.  DNS Considerations . . . . . . . . . . . . . . . . . . . . . .  7
     7.1.  RRset size . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.2.  DNS Wildcards  . . . . . . . . . . . . . . . . . . . . . .  7
     7.3.  Delegations  . . . . . . . . . . . . . . . . . . . . . . .  7
     7.4.  Record positions . . . . . . . . . . . . . . . . . . . . .  8

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8

   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8

   10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . .  9

   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9

   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     12.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     12.2. Informative References . . . . . . . . . . . . . . . . . . 10

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11















Bellis                  Expires December 25, 2008               [Page 2]


Internet-Draft             Send-N Enumservice                  June 2008


1.  Introduction

   E.164 Number Mapping (ENUM) [I-D.ietf-enum-3761bis] uses the Domain
   Name System (DNS) [RFC1035] to refer from E.164 numbers [E.164] to
   Uniform Resource Identifiers (URIs) [RFC3986]

   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.

   [I-D.ietf-enum-cnam] 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



Bellis                  Expires December 25, 2008               [Page 3]


Internet-Draft             Send-N Enumservice                  June 2008


   document are to be interpreted as described in RFC 2119 [RFC2119].

   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.


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 ENUM database
      tree.

   Security Considerations: see Section 8

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






Bellis                  Expires December 25, 2008               [Page 4]


Internet-Draft             Send-N Enumservice                  June 2008


              pstndatauri    =/ ( "pstndata:" sendndatatype )
              sendndatatype  = "send-n/" [ "=" ] digitsmin
              digitsmin      = e164digitcount
              e164digitcount = %x31-39 / (%x31 %x30-35)
                               ; 1 - 15 digits, per E.164


   where 'pstndatauri' is imported from [I-D.ietf-enum-cnam]

   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 [I-D.ietf-enum-3761bis]

   Interoperability considerations: none

   Security considerations: see Section 8

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

   References: [I-D.ietf-enum-cnam]


5.  Description

   This Enumservice and URI scheme described here are primarily intended
   for use in private ENUM applications and are of particular relevance
   to Infrastructure ENUM [I-D.ietf-enum-infrastructure].

   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.



Bellis                  Expires December 25, 2008               [Page 5]


Internet-Draft             Send-N Enumservice                  June 2008


   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.


6.  Examples

6.1.  United Kingdom

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


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


   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:


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



Bellis                  Expires December 25, 2008               [Page 6]


Internet-Draft             Send-N Enumservice                  June 2008


                         )


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

6.2.  North America

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


                 $ORIGIN 1.e164.example.com.
                 @ IN NAPTR ( 100 10 "u"
                              "E2U+pstndata:send-n"
                              "!.*!pstndata:send-n/=11!" .
                            )


   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.


7.  DNS Considerations

7.1.  RRset size

   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.

7.2.  DNS Wildcards

   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.

7.3.  Delegations

   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



Bellis                  Expires December 25, 2008               [Page 7]


Internet-Draft             Send-N Enumservice                  June 2008


   may have no knowledge.

7.4.  Record positions

   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.


8.  Security Considerations

   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.


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
   [I-D.ietf-enum-enumservices-guide] and RFC3761bis
   [I-D.ietf-enum-3761bis].  The required template is contained in
   Section 3.

   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].  The required template
   is contain in Section 4.



Bellis                  Expires December 25, 2008               [Page 8]


Internet-Draft             Send-N Enumservice                  June 2008


10.  Change Log

   [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


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

   [I-D.ietf-enum-3761bis]
              Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
              Uniform Resource Identifiers (URI) Dynamic Delegation
              Discovery  System (DDDS) Application (ENUM)",
              draft-ietf-enum-3761bis-03 (work in progress), March 2008.

   [I-D.ietf-enum-cnam]
              Shockey, R., "IANA Registration for an Enumservice Calling
              Name Delivery (CNAM)  Information and IANA Registration
              for URI type 'pstndata' URI type 'pstn'",
              draft-ietf-enum-cnam-07 (work in progress), October 2007.

   [I-D.ietf-enum-enumservices-guide]



Bellis                  Expires December 25, 2008               [Page 9]


Internet-Draft             Send-N Enumservice                  June 2008


              Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
              Registration of Enumservices: Guide, Template and IANA
              Considerations", draft-ietf-enum-enumservices-guide-10
              (work in progress), May 2008.

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

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

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

12.2.  Informative References

   [E.164]    ITU-T, "The international public telecommunication
              numbering plan", Recommendation E.164 (02/05), Feb 2005.

   [I-D.ietf-enum-infrastructure]
              Livingood, J., "The E.164 to Uniform Resource Identifiers
              (URI) Dynamic Delegation Discovery  System (DDDS)
              Application for Infrastructure ENUM",
              draft-ietf-enum-infrastructure-07 (work in progress),
              December 2007.

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

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 115,
              RFC 4395, February 2006.


Author's Address

   Ray Bellis
   Nominet UK
   Edmund Halley Road
   Oxford  OX4 4DQ
   United Kingdom

   Phone: +44 1865 332211
   Email: ray.bellis@nominet.org.uk
   URI:   http://www.nominet.org.uk/





Bellis                  Expires December 25, 2008              [Page 10]


Internet-Draft             Send-N Enumservice                  June 2008


Full Copyright Statement

   Copyright (C) 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.











Bellis                  Expires December 25, 2008              [Page 11]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/