One document matched: draft-bellis-enum-send-n-01.xml
<?xml version='1.0' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<rfc ipr="full3978" docName="draft-bellis-enum-send-n-01">
<?rfc toc='yes' ?>
<?rfc tocompact='no' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc symrefs='yes' ?>
<front>
<title abbrev="Send-N Enumservice"> IANA Registrations for the 'Send-N' Enumservice</title>
<author initials="R.P." surname="Bellis" fullname="Ray Bellis">
<organization>Nominet UK</organization>
<address>
<postal>
<street>Edmund Halley Road</street>
<city>Oxford</city>
<code>OX4 4DQ</code>
<country>United Kingdom</country>
</postal>
<phone>+44 1865 332211</phone>
<email>ray.bellis@nominet.org.uk</email>
<uri>http://www.nominet.org.uk/</uri>
</address>
</author>
<date day="22" month="April" year="2008"/>
<area>RAI</area>
<workgroup>ENUM -- Telephone Number Mapping Working Group</workgroup>
<keyword>ENUM</keyword>
<keyword>Enumservice</keyword>
<keyword>Send-N</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t><xref target="I-D.ietf-enum-3761bis">E.164 Number Mapping (ENUM)</xref> uses the <xref
target="RFC1035">Domain Name System (DNS)</xref> to refer from <xref target="E.164">E.164
numbers</xref> to <xref target="RFC3986">Uniform Resource Identifiers (URIs)</xref></t>
<t>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".</t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
<t><xref target="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.</t>
<t> This document therefore requests the registration of a new Enumservice subtype for
'Send-N' and extends the definition of the 'pstndata:' URI scheme.</t>
</section>
<section anchor="terminology" title="Terminology">
<t> 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 <xref target="RFC2119">RFC 2119</xref>.</t>
<t> A "full ENUM record" is an RRset containing NAPTR records about a complete E.164 telephone
number.</t>
</section>
<section anchor="regenum" title="ENUM Service Registration for "Send-N"">
<t>The following template contains information required for the IANA registrations of the
'Send-N' Enumservice:</t>
<t>Enumservice Name: Send-N</t>
<t>Enum service Class: Ancillary Application Enumservice</t>
<t>Enumservice Type: pstndata</t>
<t>Enumservice Subtype: send-n</t>
<t>URI Schemes: pstndata:</t>
<t>Functional Specification: <list style="empty">
<t> This Enumservice indicates that the resource record contains information that
describes the structure of the ENUM database tree.</t>
</list>
</t>
<t>Security Considerations: see <xref target="security"/></t>
<t>Intended Usage: COMMON</t>
<t>Author: Ray Bellis <mailto:ray.bellis@nominet.org.uk> </t>
</section>
<section anchor="scheme"
title="IANA Registration Template for URI scheme "pstndata:"">
<t>URI scheme name: pstndata</t>
<t>Status: provisional</t>
<t>URI scheme syntax: (in ABNF <xref target="RFC5234"/>) type="abnf"<figure>
<artwork type="abnf" align="center">
<![CDATA[
pstndatauri =/ ( "pstndata:" sendndatatype )
sendndatatype = "send-n/" [ "=" ] digitsmin
digitsmin = e164digitcount
e164digitcount = %x31-39 / (%x31 %x30-35)
; 1 - 15 digits, per E.164
]]>
</artwork>
</figure> where 'pstndatauri' is imported from <xref target="I-D.ietf-enum-cnam"/>
</t>
<t>URI scheme semantics: The URI contains information that describes the structure of the ENUM
database.</t>
<t>Where the URI contains an "equals" sign before the "digitsmin" field then the numeric
fields shall be interpreted as an absolute number of digits.</t>
<t>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.</t>
<t>Encoding considerations: None, all valid characters are in US ASCII</t>
<t>Applications: <xref target="I-D.ietf-enum-3761bis">ENUM</xref></t>
<t>Interoperability considerations: none</t>
<t>Security considerations: see <xref target="security"/></t>
<t>Contact: Ray Bellis <mailto:ray.bellis@nominet.org.uk> </t>
<t>References: <xref target="I-D.ietf-enum-cnam"/></t>
</section>
<section anchor="description" title="Description">
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
<t> 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.</t>
<t> 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. </t>
</section>
<section anchor="examples" title="Example">
<section title="United Kingdom">
<t>An example ENUM entry containing 'Send-N' data looks like:</t>
<figure>
<artwork align="center">
<![CDATA[
$ORIGIN 5.6.8.1.4.4.e164.nicc.org.uk.
@ IN NAPTR ( 100 10 "u"
"E2U+pstndata:send-n"
"!.*!pstndata:send-n/5!" .
)
]]>
</artwork>
</figure>
<t>This record indicates that at least 5 additional digits are required to reach any valid
E.164 number beginning +441865.</t>
<!-- <t>NOTE - As described above this record does not indicate that all possible 5 or 6 digit
suffixes appended to +441865 will result in a valid ENUM lookup - numbers may be missing
from the ENUM database either because they are not in use or simply because they are not
registered for ENUM service.</t> -->
<t>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:<figure>
<artwork align="center">
<![CDATA[
$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!" .
)
]]>
</artwork>
</figure> This data indicates that at least one further digit needs to be dialled before a
full ENUM record might be returned. </t>
</section>
<section title="North America">
<t>All E.164 numbers in the North American Numbering Plan (NANP) contain exactly 11 digits.</t>
<figure>
<artwork align="center">
<![CDATA[
$ORIGIN 1.e164.example.com.
@ IN NAPTR ( 100 10 "u"
"E2U+pstndata:send-n"
"!.*!pstndata:send-n/=11!" .
)
]]>
</artwork>
</figure>
<t>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.</t>
</section>
</section>
<section anchor="dns" title="DNS Considerations">
<section title="RRset size">
<t> 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.</t>
</section>
<section title="DNS Wildcards">
<t> 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.</t>
</section>
<section title="Delegations">
<t> Where an ENUM database contains delegations then the 'digitsmin' data SHOULD reflect the
minimum number of digits at which delegation occurs.</t>
<t> 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.</t>
</section>
<section title="Record positions">
<t> 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.</t>
<t> 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 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.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t> This Enumservice and URI scheme were originally designed for use on a large private ENUM
database, where no security issues are believed to exist.</t>
<t> 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.</t>
<t> 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.</t>
<t> The effect of putting incorrectly low values of 'Send-N' is benign.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>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, <xref
target="I-D.ietf-enum-enumservices-guide">RFCxxxx</xref> and <xref
target="I-D.ietf-enum-3761bis">RFC3761bis</xref>. The required template is contained in
<xref target="regenum"/>. </t>
<t>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 <xref
target="RFC4395"/>. The required template is contain in <xref target="scheme"/>.</t>
</section>
<section anchor="changelog" title="Change Log">
<t>[Note to editors: This section is to be removed before publication - XML source available
on request]</t>
<t>draft-bellis-enum-send-n-01 <list>
<t>Fixed ABNF for 'e164digitcount'</t>
<t>Removed support for 'digitsmax'</t>
<t>Introduced support for absolute digit counts</t>
<t>Expanded DNS considerations</t>
</list>
</t>
<t>draft-bellis-enum-send-n-00 <list>
<t>initial draft</t>
</list>
</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t> The author would like to thank those members of the Network Interoperability Consultative
Committee (<eref target="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. </t>
<t>The author would also like to thank Alexander Mayrhofer for his assistance.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5234" ?>
<?rfc include="reference.RFC.3986" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.I-D.ietf-enum-cnam" ?>
<?rfc include="reference.I-D.ietf-enum-3761bis" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.4395" ?>
<?rfc include="reference.I-D.ietf-enum-enumservices-guide" ?>
<reference anchor="E.164">
<front>
<title abbrev="E.164 (02/05)">The international public telecommunication numbering plan</title>
<author initials="" surname="" fullname="">
<organization abbrev="ITU-T">ITU-T</organization>
</author>
<date month="Feb" year="2005"/>
</front>
<seriesInfo name="Recommendation" value="E.164 (02/05)"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:38:12 |