2. The ENUM Application Specifications
This template defines the ENUM DDDS Application according to the
rules and requirements found in [7]. The DDDS database used by this
Application is found in [2] which is the document that defines the
NAPTR DNS Resource Record type.
ENUM is only applicable for E.164 numbers. ENUM compliant
applications MUST only query DNS for what it believes is an E.164
number. Since there are numerous dialing plans which can change over
time, it is probably impossible for a client application to have
perfect knowledge about every valid and dialable E.164 number.
Therefore a client application, doing everything within its power,
can end up with what it thinks is a syntactically correct E.164
number which in reality is not actually valid or dialable. This
implies that applications MAY send DNS queries when, for example, a
user mistypes a number in a user interface. Because of this, there
is the risk that collisions between E.164 numbers and non-E.164
numbers can occur. To mitigate this risk, the E2U portion of the
service field MUST NOT be used for non-E.164 numbers.
2.1. Application Unique String
The Application Unique String is a fully qualified E.164 number minus
any non-digit characters except for the '+' character which appears
at the beginning of the number. The "+" is kept to provide a well
understood anchor for the AUS in order to distinguish it from other
telephone numbers that are not part of the E.164 namespace.
For example, the E.164 number could start out as "+44-116-496-0348".
To ensure that no syntactic sugar is allowed into the AUS, all non-
digits except for "+" are removed, yielding "+441164960348".
2.2. First Well Known Rule
The First Well Known Rule for this Application is the identity rule.
The output of this rule is the same as the input. This is because
the E.164 namespace and this Applications databases are organized in
such a way that it is possible to go directly from the name to the
smallest granularity of the namespace directly from the name itself.
Take the previous example, the AUS is "+441164960348". Applying the
First Well Known Rule produces the exact same string,
"+441164960348".
2.3. Expected Output
The output of the last DDDS loop is a Uniform Resource Identifier in
its absolute form according to the 'absoluteURI' production in the
Collected ABNF found in RFC2396(-> 3986std66) [4].
At present only one DDDS Database is specified for this Application.
"Dynamic Delegation Discovery System (DDDS) Part Three: The DNS
Database" (RFC 3403prop) [2] specifies a DDDS Database that uses the
NAPTR DNS resource record to contain the rewrite rules. The Keys for
this database are encoded as domain-names.
The output of the First Well Known Rule for the ENUM Application is
the E.164 number minus all non-digit characters except for the +. In
order to convert this to a unique key in this Database the string is
converted into a domain-name according to this algorithm:
1. Remove all characters with the exception of the digits. For
example, the First Well Known Rule produced the Key
"+442079460148". This step would simply remove the leading "+",
producing "442079460148".
2. Put dots (".") between each digit. Example:
4.4.2.0.7.9.4.6.0.1.4.8
3. Reverse the order of the digits. Example:
8.4.1.0.6.4.9.7.0.2.4.4
4. Append the string ".e164.arpa" to the end. Example:
8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa
This domain-name is used to request NAPTR records which may contain
the end result or, if the flags field is blank, produces new keys in
the form of domain-names from the DNS.
Some nameserver implementations attempt to be intelligent about items
that are inserted into the additional information section of a given
DNS response. For example, BIND will attempt to determine if it is
authoritative for a domain whenever it encodes one into a packet. If
it is, then it will insert any A records it finds for that domain
into the additional information section of the answer until the
packet reaches the maximum length allowed. It is therefore
potentially useful for a client to check for this additional
information. It is also easy to contemplate an ENUM enhanced
nameserver that understand the actual contents of the NAPTR records
it is serving and inserts more appropriate information into the
additional information section of the response. Thus, DNS servers
MAY interpret Flag values and use that information to include
appropriate resource records in the Additional Information portion of
the DNS packet. Clients are encouraged to check for additional
information but are not required to do so. See the Additional
Information Processing section of RFC 3403prop [2], Section 4.2 for more
information on NAPTR records and the Additional Information section
of a DNS response packet.
The character set used to encode the substitution expression is UTF-
8. The allowed input characters are all those characters that are
allowed anywhere in an E.164 number. The characters allowed to be in
a Key are those that are currently defined for DNS domain-names.
2.4.1. Flags
This Database contains a field that contains flags that signal when
the DDDS algorithm has finished. At this time only one flag, "U", is
defined. This means that this Rule is the last one and that the
output of the Rule is a URI [4]. See RFC 3404prop [3].
If a client encounters a record with an unknown flag, it MUST ignore
it and move to the next Rule. This test takes precedence over any
ordering since flags can control the interpretation placed on fields.
A novel flag might change the interpretation of the regexp and/or
replacement fields such that it is impossible to determine if a
record matched a given target.
If this flag is not present then this rule is non-terminal. If a
Rule is non-terminal then clients MUST use the Key produced by this
Rewrite Rule as the new Key in the DDDS loop (i.e., causing the
client to query for new NAPTR records at the domain-name that is the
result of this Rule).
2.4.2. Services Parameters
Service Parameters for this Application take the following form and
are found in the Service field of the NAPTR record.
service-field = "E2U" 1*(servicespec)
servicespec = "+" enumservice
enumservice = type 0*(subtypespec)
subtypespec = ":" subtype
type = 1*32(ALPHA / DIGIT)
subtype = 1*32(ALPHA / DIGIT)
In other words, a non-optional "E2U" (used to denote ENUM only
Rewrite Rules in order to mitigate record collisions) followed by 1
or more or more Enumservices which indicate what class of
functionality a given end point offers. Each Enumservice is
indicated by an initial '+' character.
Enumservice specifications contain the functional specification
(i.e., what it can be used for), the valid protocols, and the URI
schemes that may be returned. Note that there is no implicit mapping
between the textual string "type" or "subtype" in the grammar for the
Enumservice and URI schemes or protocols. The mapping, if any, must
be made explicit in the specification for the Enumservice itself. A
registration of a specific Type also has to specify the Subtypes
allowed.
The only exception to the registration rule is for Types and Subtypes
used for experimental purposes, and those are to start with the facet
"X-". These elements are unregistered, experimental, and should be
used only with the active agreement of the parties exchanging them.
The registration mechanism is specified in Section 3.
2.5. What constitutes an 'Enum Resolver'?
There has been some confusion over what exactly an ENUM Resolver
returns and what relation that has to the 'Note 1' section in RFC
3402prop. On first reading it seems as though it might be possible for
an ENUM Resolver to return two Rules.
The ENUM algorithm always returns a single rule. Specific
applications may have application-specific knowledge or facilities
that allow them to present multiple results or speed selection, but
these should never change the operation of the algorithm.
