| TOC |
|
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 (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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.
1.
Introduction
1.1.
Background
1.2.
Problem Statement
1.3.
Proposal
1.4.
Discussion
2.
Terminology
3.
DDDS Application for E2M
3.1.
Expected Output
3.2.
Flags
3.3.
Services Parameters
4.
Registration of E2M Services
4.1.
Required Sections and Information
4.1.1.
Augmented Backus-Naur Form (<abnf>)
5.
Examples
6.
IANA Considerations
6.1.
Registry Creation
6.2.
Registration Template (XML chunk)
6.3.
Location
6.4.
Further Considerations
7.
Security Considerations
8.
Acknowledgements
9.
References
9.1.
Normative References
9.2.
Informative References
Appendix A.
Document Changelog
Appendix B.
Open Issues
§
Author's Address
| TOC |
| TOC |
E.164 Number to URI Mapping (ENUM) (Bradner, S., Conroy, L., and K. Fujiwara, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” November 2009.) [I‑D.ietf‑enum‑3761bis] provides an identifier mapping mechanism to map E.164 numbers (International Telecommunications Union, “The International Public Telecommunication Numbering Plan,” Feb 2005.) [ITU.E164.2005] to Uniform Resource Identifiers (URIs) (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) [RFC3986] using the Domain Name System (DNS) (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) [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) (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database,” October 2002.) [RFC3403] DNS Resource Record (RR).
| TOC |
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' (Shockey, R., “IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata',” September 2008.) [I‑D.ietf‑enum‑cnam] to provide information about the calling party name, and 'unused' (Stastny, R., Conroy, L., and J. Reid, “IANA Registration for Enumservice UNUSED,” March 2008.) [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.
| TOC |
This document proposes a new Dynamic Delegation Discovery System (DDDS) (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS,” October 2002.) [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.
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 (Bradner, S., Conroy, L., and K. Fujiwara, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” November 2009.) [I‑D.ietf‑enum‑3761bis] and Enumservices (Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template and IANA Considerations,” April 2010.) [I‑D.ietf‑enum‑enumservices‑guide] and is required.
| TOC |
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>.
| TOC |
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
| TOC |
If not specified differently herein, the rules described in [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),” November 2009.) for ENUM apply also for E2M. So far the following parts have been identified to be different from ENUM:
| TOC |
Section '2.3. Expected Output' of [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),” November 2009.) is replaced as follows:
The output of the last DDDS loop can be one of the following:
| TOC |
Section '2.4.3. Flags' of [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),” November 2009.) 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:
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).
| TOC |
Section '2.4.4. Services Parameters of [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),” November 2009.) 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
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] (Bradner, S., Conroy, L., and K. Fujiwara, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” November 2009.) is work in progress, certain adjustments to this section are still to be expected.
| TOC |
For the registration of E2M services, if not specified differently herein, the rules described in [I‑D.ietf‑enum‑enumservices‑guide] (Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template and IANA Considerations,” April 2010.) for Enumservices also apply for E2M services. So far the following parts have been identified to be different from the Enumservices:
| TOC |
Compared to Section '5. Required Sections and Information' in [I‑D.ietf‑enum‑enumservices‑guide] (Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template and IANA Considerations,” April 2010.) 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.
| TOC |
The ABNF (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) [RFC5234] to limit the ASCII Text string the E2M service resolves. The 'Substitution Expression Syntax' is specified in Section 3.2 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm,” October 2002.) [RFC3402]). Any parts of ABNF further specified in an E2M service specification override those parts of ABNF specified in Section 3.2 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm,” October 2002.) [RFC3402]). However, the resulting ABNF MUST be a subset of the ABNF specified in Section 3.2 (Mealling, M., “Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm,” October 2002.) [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.
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>
| TOC |
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!" .
| TOC |
| TOC |
IANA will create a Registry "E2M Service Registrations" as defined in (this) Section 6 (IANA Considerations).
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).
| TOC |
The XML chunk listed below should be used as a template to create the IANA Registration Template.
<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>
| TOC |
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 (Registration Template (XML chunk)) and specified in Section 4.1 (Required Sections and Information) 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.
| TOC |
Section 11.4 - 11.8 in [I‑D.ietf‑enum‑enumservices‑guide] (Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template and IANA Considerations,” April 2010.) for Enumservice Registrations also apply for E2M Services.
| TOC |
The security considerations outlined in [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),” November 2009.) and [I‑D.ietf‑enum‑enumservices‑guide] (Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template and IANA Considerations,” April 2010.) for ENUM apply also to E2M services. Apart from those there are no specific security issues to be considered for this document.
| TOC |
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] (Bradner, S., Conroy, L., and K. Fujiwara, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM),” November 2009.) and [I‑D.ietf‑enum‑enumservices‑guide] (Hoeneisen, B., Mayrhofer, A., and J. Livingood, “IANA Registration of Enumservices: Guide, Template and IANA Considerations,” April 2010.). Thanks to the authors of those documents. Please see also Acknowledgments section in those documents for additional acknowledgments.
| TOC |
| TOC |
| TOC |
| [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 (TXT). |
| [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 (TXT). |
| [RFC3986] | Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML). |
| [ITU.E164.2005] | International Telecommunications Union, “The International Public Telecommunication Numbering Plan,” ITU-T Recommendation E.164, Feb 2005. |
| TOC |
[RFC Editor: This section is to be removed before publication]
draft-hoeneisen-e164-to-metadata-00:
| TOC |
[RFC Editor: This section should be empty and is to be removed before publication]
| TOC |
| Bernie Hoeneisen | |
| Swisscom | |
| CH-8000 Zuerich | |
| Switzerland | |
| Email: | bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT swisscom.com) |
| URI: | http://www.swisscom.com/ |