Network Working Group B. Hoeneisen
Internet-Draft Swisscom
Intended status: Standards Track Oct 12, 2009
Expires: April 15, 2010
E.164 to Metadata (E2M) Dynamic Delegation Discovery System (DDDS)
Application
draft-hoeneisen-e164-to-metadata-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 April 15, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hoeneisen Expires April 15, 2010 [Page 1]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document proposes a new Dynamic Delegation Discovery System
(DDDS) Application to map E.164 numbers to metadata.
It discusses the use of the Domain Name System (DNS) for resolving
E.164 numbers into metadata to provide information about E.164
numbers in cases where E.164 Number to URI Mapping (ENUM) can not be
used.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. DDDS Application for E2M . . . . . . . . . . . . . . . . . . . 5
3.1. Expected Output . . . . . . . . . . . . . . . . . . . . . 5
3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Services Parameters . . . . . . . . . . . . . . . . . . . 6
4. Registration of E2M Services . . . . . . . . . . . . . . . . . 7
4.1. Required Sections and Information . . . . . . . . . . . . 7
4.1.1. Augmented Backus-Naur Form (<abnf>) . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Registry Creation . . . . . . . . . . . . . . . . . . . . 8
6.2. Registration Template (XML chunk) . . . . . . . . . . . . 9
6.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Further Considerations . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
Hoeneisen Expires April 15, 2010 [Page 2]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 13
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Hoeneisen Expires April 15, 2010 [Page 3]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
1. Introduction
1.1. Background
E.164 Number to URI Mapping (ENUM) [I-D.ietf-enum-3761bis] provides
an identifier mapping mechanism to map E.164 numbers [ITU.E164.2005]
to Uniform Resource Identifiers (URIs) [RFC3986] using the Domain
Name System (DNS) [RFC1034].
Thus, ENUM can be used look up the services associated with an E.164
number. However, it is controversial whether or not the result of an
ENUM lookup should always result in a communications session using
the URI found in the corresponding Naming Authority Pointer (NAPTR)
[RFC3403] DNS Resource Record (RR).
1.2. Problem Statement
Several proposals for Enumservice registrations do not fulfill the
above mentioned interpretation, which suggests that an ENUM lookup
should always result in a communications session. These proposals
are therefore virtually locked in the process. Such proposals
include (but are not limited to) Enumservices for 'cnam'
[I-D.ietf-enum-cnam] to provide information about the calling party
name, and 'unused' [I-D.ietf-enum-unused] to provide a hint that a
number is not in use.
Another issue is that the result of a ENUM (E2U) lookup always needs
to be an URI, which makes otherwise simple mappings rather complex.
The authors of such Enumservice proposals tried to circumvent the
issues by introducing data URI scheme or inventing completely new URI
schemes, with limited success however. The main objection that an
ENUM lookup should always result in a communications session
remained.
1.3. Proposal
This document proposes a new Dynamic Delegation Discovery System
(DDDS) [RFC3401] application E2M, which can be used with DNS NAPTR RR
for resolving E.164 numbers into metadata. The resulting metadata
can be used for (for example) to provide hints about properties of
certain ENUM domains or to provide information that can be used as
attribute of an E.164 number.
This proposal intends to allow a means for services related to E.164
numbers that do not fit into the concept of ENUM (E2U), and to
provide a way forward for such existing proposals in the queue.
Hoeneisen Expires April 15, 2010 [Page 4]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
As there are lots of similarities between E2M and ENUM (E2U), this
document generally only outlines the differences to ENUM (E2U)
instead of repeating all parts shared between the two. Therefore a
firm understanding of ENUM [I-D.ietf-enum-3761bis] and Enumservices
[I-D.ietf-enum-enumservices-guide] and is required.
1.4. Discussion
This is work in progress at early stage. The members of the ENUM and
DNS related Working Groups as well as other interested parties are
invited to contribute to the discussion arising from this proposal.
Until E2M has a proper home this discussion will take place on the
ENUM WG discussion list <enum@ietf.org>.
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].
3. DDDS Application for E2M
If not specified differently herein, the rules described in
[I-D.ietf-enum-3761bis] for ENUM apply also for E2M. So far the
following parts have been identified to be different from ENUM:
3.1. Expected Output
Section '2.3. Expected Output' of [I-D.ietf-enum-3761bis] is
replaced as follows:
The output of the last DDDS loop can be one of the following:
o An ASCII Text string
The Augmented Backus-Naur Form (ABNF) [RFC5234] for the ASCII
string is to be specified in the corresponding E2M registration
(see also Section 4.1.1).
Note: Depending on the E2M service specification (see Section 4)
the Expected Output might be always empty.
o A URI in its absolute form according to the 'absoluteURI'
production in the Collected ABNF found in [RFC3986].
Hoeneisen Expires April 15, 2010 [Page 5]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
3.2. Flags
Section '2.4.3. Flags' of [I-D.ietf-enum-3761bis] is replaced as
follows:
This Database contains a field that contains flags that signal when
the DDDS algorithm has finished. At this time the following flags
are defined:
o "t": This means that this Rule is the last one and that the output
of the Rule is an ASCII Text string.
o "u": This means that this Rule is the last one and that the output
of the Rule is a URI [RFC3986].
See also [RFC3404].
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).
3.3. Services Parameters
Section '2.4.4. Services Parameters of [I-D.ietf-enum-3761bis] is
replaced as follows:
Service Parameters for this Application take the following form and
are found in the Service field of the NAPTR record that holds a
terminal rule. Where the NAPTR holds a non-terminal Rule, the
Services field SHOULD be empty, and clients SHOULD ignore its
content:
service-field = "E2M" 1*(servicespec)
servicespec = "+" e2m-service
e2mservice = type 0*(subtypespec)
subtypespec = ":" subtype
Hoeneisen Expires April 15, 2010 [Page 6]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
type = 1*32(ALPHA / DIGIT / "-")
subtype = 1*32(ALPHA / DIGIT / "-")
In other words, a non-optional "E2M" (used to denote E164 to Metadata
only Rewrite Rules in order to mitigate record collisions) followed
by one or more E2M services which indicate the class of functionality
a given end point offers. Each E2M service is indicated by an
initial '+' character.
Note: As [I-D.ietf-enum-3761bis] is work in progress, certain
adjustments to this section are still to be expected.
4. Registration of E2M Services
For the registration of E2M services, if not specified differently
herein, the rules described in [I-D.ietf-enum-enumservices-guide] for
Enumservices also apply for E2M services. So far the following parts
have been identified to be different from the Enumservices:
4.1. Required Sections and Information
Compared to Section '5. Required Sections and Information' in
[I-D.ietf-enum-enumservices-guide] the <class> element is omitted,
and a new element for <abnf> is added. Depending on the Flag either
the <urischeme> (flag "u") or the <abnf> for the ASCII Text
replacement (flag "t") MUST be specified.
4.1.1. Augmented Backus-Naur Form (<abnf>)
The ABNF [RFC5234] to limit the ASCII Text string the E2M service
resolves. The 'Substitution Expression Syntax' is specified in
Section 3.2 [RFC3402]). Any parts of ABNF further specified in an
E2M service specification override those parts of ABNF specified in
Section 3.2 [RFC3402]). However, the resulting ABNF MUST be a subset
of the ABNF specified in Section 3.2 [RFC3402]).
Typically only the 'repl' part of the ABNF needs to be further
specified. However, in rare cases (depending on the application)
also a limitation of the 'delim-char' part may be justified (see also
4th example below).
The E2M registration MAY be specified to be always empty (see also
2nd example below) or it MAY specify an encoding mechanism to allow
for localized strings.
Hoeneisen Expires April 15, 2010 [Page 7]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
e.g. <abnf>
repl = foobar / 1*8( DIGIT )
</abnf>
<abnf>
foobar = ( "foo" / "bar" / "foobar" )
</abnf>
e.g. <abnf>
repl = ""
</abnf>
e.g. <abnf>
repl = ( "active" / "passive" / "undefined" )
</abnf>
e.g. <abnf>
repl = anychar <!-- Note: 'anychar' defined in RFC 3402 -->
</abnf>
<abnf>
delim-char = "/"
</abnf>
5. Examples
The following examples illustrate the usage of the E2M service:
$ORIGIN 0.6.9.4.5.1.1.4.4.e164.arpa.
NAPTR 10 100 "t" "E2M+unused" "" .
NAPTR 10 100 "u" "E2M+unused:http" \
"!^.*$!http://www.nra.example/sabc.htm?SABC=1154!" .
NAPTR 10 100 "t" "E2M+cnam" \
"!^.*$!charset=us-ascii;Donald%20Duck!" .
6. IANA Considerations
6.1. Registry Creation
IANA will create a Registry "E2M Service Registrations" as defined in
(this) Section 6.
Hoeneisen Expires April 15, 2010 [Page 8]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
It is noted that the process described herein applies only to
ordinary E2M service registrations (i.e. the registration process of
"X-" E2M services is beyond the scope of this document).
6.2. Registration Template (XML chunk)
The XML chunk listed below should be used as a template to create the
IANA Registration Template.
Hoeneisen Expires April 15, 2010 [Page 9]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
<record>
<type> <!-- Type --> </type>
<subtype> <!-- Subtype --> </subtype>
<urischeme> <!-- URI Schema Name --> </urischeme>
<urischeme> <!-- another URI Schema Name --> </urischeme>
<abnf> <!-- ABNF description --> </abnf>
<abnf> <!-- further ABNF description --> </abnf>
<functionalspec>
<paragraph>
<!-- Text that explains the functionality of
the Enumservice to be registered -->
</paragraph>
</functionalspec>
<security>
<!-- Change accordingly -->
See <xref type="rfc" data="rfc9999"/>, Section 7.
</security>
<usage> <!-- COMMON, LIMITED USE or OBSOLETE --> </usage>
<registrationdocs>
<!-- Change accordingly -->
<xref type="rfc" data="rfc9999"/>
</registrationdocs>
<requesters>
<!-- Change accordingly -->
<xref type="person" data="John_Doe"/>
<xref type="person" data="Jane_Dale"/>
</requesters>
<additionalinfo>
<paragraph>
<!-- Text with additional information about
the Enumservice to be registered -->
</paragraph>
<artwork>
<!-- There can be artwork sections, too -->
:-)
</artwork>
</additionalinfo>
</record>
<people>
<person id="John_Doe">
<name> <!-- Firstname Lastname --> </name>
<org> <!-- Organisation Name --> </org>
<uri> <!-- mailto: or http: URI --> </uri>
<updated> <!-- date format YYYY-MM-DD --> </updated>
</person>
<!-- repeat person section for each person -->
</people>
Hoeneisen Expires April 15, 2010 [Page 10]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
6.3. Location
Approved Enumservice registrations are published in the IANA Registry
named "E2M Service Registrations", which is available at the
following URI:
< http://www.iana.org/assignments/e2m-services >.
This Registry publishes representations derived from the IANA
Registration Template as described in Section 6.2 and specified in
Section 4.1 above.
Where the E2M service Specification is NOT an RFC, IANA MUST hold an
escrow copy of that Enumservice Specification. Said escrow copy will
act as the master reference for that Enumservice Registration.
6.4. Further Considerations
Section 11.4 - 11.8 in [I-D.ietf-enum-enumservices-guide] for
Enumservice Registrations also apply for E2M Services.
7. Security Considerations
The security considerations outlined in [I-D.ietf-enum-3761bis] and
[I-D.ietf-enum-enumservices-guide] for ENUM apply also to E2M
services. Apart from those there are no specific security issues to
be considered for this document.
8. Acknowledgements
The authors would like to thank the following people who have
provided feedback or significant contributions to the development of
this document: Lawrence Conroy, Scott Hollenbeck
Some text has been copied from [I-D.ietf-enum-3761bis] and
[I-D.ietf-enum-enumservices-guide]. Thanks to the authors of those
documents. Please see also Acknowledgments section in those
documents for additional acknowledgments.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Hoeneisen Expires April 15, 2010 [Page 11]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
[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-04 (work in progress), May 2009.
[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-18
(work in progress), September 2009.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)",
RFC 3404, October 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
9.2. Informative References
[I-D.ietf-enum-unused]
Stastny, R., Conroy, L., and J. Reid, "IANA Registration
for Enumservice UNUSED", draft-ietf-enum-unused-04 (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'", draft-ietf-enum-cnam-08 (work in
progress), September 2008.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
Hoeneisen Expires April 15, 2010 [Page 12]
Internet-Draft E.164 to Metadata (E2M) Mapping Oct 2009
[ITU.E164.2005]
International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, Feb 2005.
[RFC Editor: This section is to be removed before publication]
draft-hoeneisen-e164-to-metadata-00:
o bernie: initial version
[RFC Editor: This section should be empty and is to be removed before
publication]
o Check whether [RFC3404] needs to be updated to contain the "t"
flag.
o Adjust to new revision of rfc3761bis
o Probably many others
Author's Address
Bernie Hoeneisen
Swisscom
CH-8000 Zuerich
Switzerland
Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT swisscom.com)
URI: http://www.swisscom.com/
Hoeneisen Expires April 15, 2010 [Page 13]