One document matched: draft-bellis-enum-send-n-01.txt
Differences from draft-bellis-enum-send-n-00.txt
ENUM -- Telephone Number Mapping R. Bellis
Working Group Nominet UK
Internet-Draft April 22, 2008
Expires: October 24, 2008
IANA Registrations for the 'Send-N' Enumservice
draft-bellis-enum-send-n-01
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 24, 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.
Bellis Expires October 24, 2008 [Page 1]
Internet-Draft Send-N Enumservice April 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. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. United Kingdom . . . . . . . . . . . . . . . . . . . . . . 6
6.2. North America . . . . . . . . . . . . . . . . . . . . . . 6
7. DNS Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7.1. RRset size . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2. DNS Wildcards . . . . . . . . . . . . . . . . . . . . . . 7
7.3. Delegations . . . . . . . . . . . . . . . . . . . . . . . 7
7.4. Record positions . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 8
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 October 24, 2008 [Page 2]
Internet-Draft Send-N Enumservice April 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]
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 ENUM database 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] 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 [RFC2119].
Bellis Expires October 24, 2008 [Page 3]
Internet-Draft Send-N Enumservice April 2008
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]) type="abnf"
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]
Bellis Expires October 24, 2008 [Page 4]
Internet-Draft Send-N Enumservice April 2008
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
The records described here contain meta-information about an ENUM
database - specifically the depth (or range of depths) in the DNS
tree 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.
Bellis Expires October 24, 2008 [Page 5]
Internet-Draft Send-N Enumservice April 2008
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. Example
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!" .
)
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.
Bellis Expires October 24, 2008 [Page 6]
Internet-Draft Send-N Enumservice April 2008
$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
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.
An example of this is where a company switchboard might be reached by
dialling the main number and extensions are reached by dialling
Bellis Expires October 24, 2008 [Page 7]
Internet-Draft Send-N Enumservice April 2008
additional digits. In that case the country-level database would
maintain 'Send-N' records that describe the national numbering 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.
There is a potential misuse of this data in public ENUM database
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.
10. Change Log
[Note to editors: This section is to be removed before publication -
XML source available on request]
draft-bellis-enum-send-n-01
Fixed ABNF for 'e164digitcount'
Bellis Expires October 24, 2008 [Page 8]
Internet-Draft Send-N Enumservice April 2008
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.
[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.
Bellis Expires October 24, 2008 [Page 9]
Internet-Draft Send-N Enumservice April 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-enumservices-guide]
Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template and IANA
Considerations", draft-ietf-enum-enumservices-guide-08
(work in progress), March 2008.
[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 October 24, 2008 [Page 10]
Internet-Draft Send-N Enumservice April 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 October 24, 2008 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:47 |