Network Working Group B. Hoeneisen Internet-Draft Swisscom Intended status: Standards Track Dec 12, 2009 Expires: June 15, 2010 E.164 to Metadata (E2M) Dynamic Delegation Discovery System (DDDS) Application draft-hoeneisen-e164-to-metadata-01 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 June 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Hoeneisen Expires June 15, 2010 [Page 1] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 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 June 15, 2010 [Page 2] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 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 () . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6.1. Registry Creation . . . . . . . . . . . . . . . . . . . . 9 6.2. Registration Template (XML chunk) . . . . . . . . . . . . 9 6.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. Further Considerations . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 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 June 15, 2010 [Page 3] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 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 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 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 otherwise 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 E2M, 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 June 15, 2010 [Page 4] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 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] is required. 1.4. Discussion This is work in progress at an 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. The DISPATCH WG will make a decision about how to proceed with this document. Therefore, until this decision will be made and E2M have a proper home, the discussion takes place on the DISPATCH WG discussion list . 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. Hoeneisen Expires June 15, 2010 [Page 5] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 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 June 15, 2010 [Page 6] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 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] 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 element is omitted, and a new element for is added. Depending on the Flag either the (flag "u") or the for the ASCII Text replacement (flag "t") MUST be specified. 4.1.1. Augmented Backus-Naur Form () The element is expressed in the Augmented Backus-Naur Form (ABNF) [RFC5234], and used to constrain the ASCII Text string that the E2M service resolves to. The 'Substitution Expression Syntax' is specified in Section 3.2 of [RFC3402]. Any parts of ABNF further specified in an E2M 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 E2M registration MAY be specified to be always empty (see also Hoeneisen Expires June 15, 2010 [Page 7] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 2nd example below) or it MAY specify an encoding mechanism to allow for localized strings. e.g. repl = foobar / 1*8( DIGIT ) foobar = ( "foo" / "bar" / "foobar" ) e.g. repl = "" e.g. repl = ( "active" / "passive" / "undefined" ) e.g. repl = anychar delim-char = "/" 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!" . Hoeneisen Expires June 15, 2010 [Page 8] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 6. IANA Considerations 6.1. Registry Creation IANA will create a Registry "E2M Service Registrations" as defined in (this) Section 6. 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 June 15, 2010 [Page 9] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 See , Section 7. :-) Hoeneisen Expires June 15, 2010 [Page 10] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 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, 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 June 15, 2010 [Page 11] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 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-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-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. [I-D.bellis-enum-send-n] Bellis, R., "IANA Registrations for the 'Send-N' Hoeneisen Expires June 15, 2010 [Page 12] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 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-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 June 15, 2010 [Page 13] Internet-Draft E.164 to Metadata (E2M) Mapping Dec 2009 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 June 15, 2010 [Page 14]