Internet DRAFT - draft-hoeneisen-e164-to-metadata
draft-hoeneisen-e164-to-metadata
Network Working Group B. Hoeneisen
Internet-Draft Ucom.ch
Intended status: Standards Track Feb 06, 2010
Expires: August 10, 2010
E.164 to MetaData (E2MD) Dynamic Delegation Discovery System (DDDS)
Application
draft-hoeneisen-e164-to-metadata-02
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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 August 10, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Hoeneisen Expires August 10, 2010 [Page 1]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
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.
Hoeneisen Expires August 10, 2010 [Page 2]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. DDDS Application for E2MD . . . . . . . . . . . . . . . . . . 4
3.1. Expected Output . . . . . . . . . . . . . . . . . . . . . 4
3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Services Parameters . . . . . . . . . . . . . . . . . . . 5
4. Registration of E2MD Services . . . . . . . . . . . . . . . . 6
4.1. Required Sections and Information . . . . . . . . . . . . 6
4.1.1. Augmented Backus-Naur Form (<abnf>) . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Registry Creation . . . . . . . . . . . . . . . . . . . . 8
6.2. Registration Template (XML chunk) . . . . . . . . . . . . 8
6.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. Further Considerations . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Document Changelog . . . . . . . . . . . . . . . . . 12
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Hoeneisen Expires August 10, 2010 [Page 3]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
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 to 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 be intended to establish 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 be intended to 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, 'unused' [I-D.ietf-enum-unused] to provide a hint that a number
is not in use, and 'send-n' [I-D.bellis-enum-send-n] to describe the
structure of an ENUM tree.
Another issue is that the result of an ENUM (E2U) lookup always needs
to be an URI, which makes simple mappings rather complex.
The authors of such Enumservice proposals tried to circumvent the
issues by introducing the 'data' URI scheme or inventing completely
new URI schemes, with limited success however. The main objection
remained that an ENUM lookup should always result in a URI intended
to establish a communications session.
1.3. Proposal
This document proposes a new Dynamic Delegation Discovery System
(DDDS) [RFC3401] application E2MD, which can be used with DNS NAPTR
RRs for resolving E.164 numbers into metadata. The resulting
metadata can be used (for example) to provide hints about properties
of certain ENUM domains or to provide information that can be used as
attributes 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 August 10, 2010 [Page 4]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
As there are lots of similarities between E2MD (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] is required.
1.4. Discussion
A BOF has been requested and tentatively approved for the IETF-77 in
Anaheim.
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.
The discussion on this proposal takes place on the E2MD BOF
discussion list <e2md@ietf.org>. Interested parties can subscribe to
this mailing list via <https://www.ietf.org/mailman/listinfo/e2md>.
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 E2MD
If not specified differently herein, the rules described in
[I-D.ietf-enum-3761bis] for ENUM apply also for E2MD. 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 E2MD registration
(see also Section 4.1.1).
Note: Depending on the E2MD service specification (see Section 4)
the Expected Output might be always empty.
Hoeneisen Expires August 10, 2010 [Page 5]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
o A URI in its absolute form according to the 'absoluteURI'
production in the Collected ABNF found in [RFC3986].
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 no flag is present (empty flag) 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)
Hoeneisen Expires August 10, 2010 [Page 6]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
servicespec = "+" e2md-service
e2mdservice = type 0*(subtypespec)
subtypespec = ":" subtype
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 E2MD services which indicate the class of
functionality a given end point offers. Each E2MD 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 E2MD Services
For the registration of E2MD services, if not specified differently
herein, the rules described in [I-D.ietf-enum-enumservices-guide] for
Enumservices also apply for E2MD 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> element is expressed in the Augmented Backus-Naur Form
(ABNF) [RFC5234], and used to constrain the ASCII Text string that
the E2MD service resolves to. The 'Substitution Expression Syntax'
is specified in Section 3.2 of [RFC3402]. Any parts of ABNF further
specified in an E2MD service specification override those parts of
ABNF specified in Section 3.2 of [RFC3402]. However, the resulting
ABNF MUST produce a subset of the text strings produced by the ABNF
specified in Section 3.2 of [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 E2MD registration MAY be specified to be always empty (see also
Hoeneisen Expires August 10, 2010 [Page 7]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
2nd example below) or it MAY specify an encoding mechanism to allow
for localized strings.
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 E2MD 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!" .
Hoeneisen Expires August 10, 2010 [Page 8]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
6. IANA Considerations
6.1. Registry Creation
IANA will create a Registry "E2MD Service Registrations" as defined
in (this) Section 6.
It is noted that the process described herein applies only to
ordinary E2MD service registrations (i.e. the registration process of
"X-" E2MD 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 August 10, 2010 [Page 9]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
<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 August 10, 2010 [Page 10]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
6.3. Location
Approved Enumservice registrations are published in the IANA Registry
named "E2MD Service Registrations", which is available at the
following URI:
< http://www.iana.org/assignments/e2md-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 E2MD 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 E2MD 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 E2MD
services. Apart from those there are no specific security issues to
be considered for this document.
8. Acknowledgements
The author would like to thank the following people who have provided
feedback or significant contributions to the development of this
document: Lawrence Conroy, Alfred Hoenes, and 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 August 10, 2010 [Page 11]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
[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-06 (work in progress),
November 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-19
(work in progress), December 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.
[I-D.bellis-enum-send-n]
Bellis, R., "IANA Registrations for the 'Send-N'
Hoeneisen Expires August 10, 2010 [Page 12]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
Enumservice", draft-bellis-enum-send-n-02 (work in
progress), June 2008.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[ITU.E164.2005]
International Telecommunications Union, "The International
Public Telecommunication Numbering Plan", ITU-
T Recommendation E.164, Feb 2005.
Appendix A. Document Changelog
[RFC Editor: This section is to be removed before publication]
draft-hoeneisen-e164-to-metadata-02:
o bernie: Updated to new affiliation: Ucom Standards Track Solutions
Company <ucom.ch>
o bernie: Changed mailing list for discussion 'dispatch' -> 'e2md'
o bernie: Changed E2M to E2MD to avoid a naming clash with an
existing SIP WG item
o bernie: Other editorials
draft-hoeneisen-e164-to-metadata-01:
o bernie: Rephrasing and typo corrections (Feedback from Alfred
Hoenes)
o bernie: Changed mailing list for discussion 'enum' -> 'dispatch'
o bernie: I18N to Open Issues
o bernie: Added reference to (expired) send-n I-D
draft-hoeneisen-e164-to-metadata-00:
o bernie: initial version
Appendix B. Open Issues
[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 I18N considerations: Is clarification with regard to RFC 2277
needed? (Section 4.1.1)
o Probably many others
Hoeneisen Expires August 10, 2010 [Page 13]
Internet-Draft E.164 to MetaData (E2MD) Mapping Feb 2010
Author's Address
Bernie Hoeneisen
Ucom Standards Track Solutions Company
CH-8049 Zuerich
Switzerland
Phone: +41 44 500 52 44
Email: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Hoeneisen Expires August 10, 2010 [Page 14]
