Network Working Group Jasdip Singh Internet-Draft Scott Williamson Expires: April 2002 October 2001 Email Address and NAPTR RR (EADDR) draft-singh-eaddr-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract ENUM uses NAPTR DNS Resource Records (RRs) to map an E.164 telephone number to Uniform Resource Identifiers (URIs) of other ways of contacting (for example, by email) a specific resource. This memo proposes an ENUM-like service called EADDR where an email address, instead of a telephone number, is used as the key to fetch other contact URIs. At human level, EADDR seems more useful than ENUM because it is easier to remember an email address than a telephone number as the key. At machine level, both services are equally useful. Table of Contents 1. Introduction..................................................2 1.1. Terminology...................................................2 2. NAPTR RR Specification........................................2 2.1. M2U (Email Address to URI) Service Specification..............3 2.2. Matching Algorithm............................................4 3. Examples......................................................4 3.1. Individual Email Address......................................4 3.2. Role Email Address by Locale..................................5 Singh, Williamson [Page 1] Email Address and NAPTR RR (EADDR) October 2001 3.3. Linking ENUM..................................................5 4. Security Considerations.......................................5 5. References....................................................5 6. Authors' Addresses............................................6 1. Introduction This memo specifies the structure of a NAPTR resource record for an ENUM-like service called EADDR that maps an email address, instead of an E.164 telephone number, to URIs of other ways of contacting (for example, by telephone) a specific resource. The mapping context may include locale (geography and language) where applicable. Later, EADDR is illustrated for individual and role email addresses. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in [RFC 2119]. 2. NAPTR RR Specification NAPTR [RFC 2915] provides a mechanism for mapping a URI in one namespace to another URI in same or different namespace using regular expressions to specify the mapping context. ENUM [RFC 2916] is one such application of NAPTR. Similarly, a set of NAPTR resource records can be used to specify mapping information for the EADDR service that maps an email address to other contact URIs. The specification of such a NAPTR record is as follows. The name field value is the email address string with the '@' character replaced by the '.' character. The order and preference field values SHOULD be as defined in [RFC 2915]. The service field value has the following syntax in ABNF [RFC 2234]. service = protocol "+" rs protocol = "tel" | "fax" | "sip" | "http" | "mailto" | "ldap" | rs = "M2U" The flags field value is "U" indicating the output of the regexp field is a URI with absolute URI syntax as defined in [RFC 2396]. The regexp field value is a substitution expression with the following syntax in ABNF. subst-expr = delim-char ere delim-char repl delim-char flags delim-char = "!" ere = *locale locale = geography | language | geography = "g=" "+" language = "l=" "+" repl = Singh, Williamson Expires April 2002 [Page 2] Email Address and NAPTR RR (EADDR) October 2001 flags = "i" Note the following about the regexp field value. - An ISO 3166 location code is hierarchical in nature with each level separated by the '-' character. The first level is an ISO 3166-1 two-letter country code. The second level is an ISO 3166-2 code. Each higher level is based on the previous level. For example, the location code for Ashburn, Virginia, USA would be us-va-ashburn. The second and higher levels are optional. - A language tag is typically an ISO 639 two-letter language code, optionally appended with the '-' character and an ISO 3166 two- letter country code. - Locale (one or more geographical locations and/or languages) information can be specified in an extended regular expression. This is useful for mapping a role email address by locale. The replacement field value is the '.' character. 2.1. M2U (Email Address to URI) Service Specification Name: Email Address to URI Mnemonic: M2U Number of Operands: 1 Type of Each Operand: First operand is an email address. Format of Each Operand: First operand is a string constructed using the user locale (optionally) and absolute MAILTO URI of the email address for matching the extended regular expression in a retrieved NAPTR record. Algorithm: See the "Matching Algorithm" Section. Output: One or more URIs Error Conditions: - Invalid MAILTO URI syntax for the email address - No URIs exist for the email address - Service not available Security Considerations: - Malicious Redirection: A malicious mapping from the email address to an incorrect URI could cause a client to unintentionally retrieve a bad resource. - Denial of Service: A malicious deletion of a URI for the email address could deny that resolution protocol to a client. This operation is used to map an email address to a list of URIs. The first well-known step in the resolution process is to construct a match string using the user locale (optionally) and absolute MAILTO URI of the email address. Singh, Williamson Expires April 2002 [Page 3] Email Address and NAPTR RR (EADDR) October 2001 2.2. Matching Algorithm The NAPTR records for a name (email address string with the '@' character replaced by the '.' character) can be retrieved by either a protocol client or a proxy protocol server for matching, depending on where (protocol client or proxy protocol server) a user's locale profile, if applicable, is constructed. This can vary from one protocol application to another, including but not limited to SMTP applications. Therefore, both protocol client and proxy protocol server can potentially act as the DNS client retrieving and matching the NAPTR records. The DNS client should construct a match string using the user locale (optionally) and absolute MAILTO URI of the email address. (Note that the techniques for building a user's locale profile are beyond the scope of this memo.) It should then try matching case- insensitively the match string with the extended regular expression of each retrieved NAPTR record. If locale is specified in the match string, it SHOULD iterate over the NAPTR record set until there is a match, trying to match first by both geography and language, next by geography only, and last by language only (implying a new match string for each iteration). If the extended regular expression of a NAPTR record contains multiple geographical locations, the geographical location specified in the match string MUST match one of them. Similarly, for the language match. 3. Examples 3.1. Individual Email Address This example shows the EADDR service for the email address joe@example.com of a person named Joe. $ORIGIN example.com. joe IN NAPTR 10 10 "U" "sip+M2U" "!mailto:joe@example.com!sip:joe@example.com!i" . joe IN NAPTR 20 10 "U" "mailto+M2U" "!mailto:joe@example.com!mailto:joe@example.com!i" . joe IN NAPTR 30 10 "U" "tel+M2U" "!mailto:joe@example.com!tel:+17031234567!i" . joe IN NAPTR 40 10 "U" "fax+M2U" "!mailto:joe@example.com!fax:+17031234567!i" . joe IN NAPTR 50 10 "U" "http+M2U" "!mailto:joe@example.com!http://example.com/joe!i" . Here, Joe prefers to be contacted by SIP, email, telephone, fax, and web lastly. Singh, Williamson Expires April 2002 [Page 4] Email Address and NAPTR RR (EADDR) October 2001 3.2. Role Email Address by Locale This example shows the EADDR service for a role email address support@example.com; mapping it to other contact URIs by locale (geography and language). $ORIGIN example.com. ; Telephone number for country United States support IN NAPTR 10 10 "U" "tel+M2U" "!g=us+mailto:support@example.com!tel:+15711234567!i" . ; Telephone number for country United States and language Spanish support IN NAPTR 10 10 "U" "tel+M2U" "!g=us+l=es+mailto:support@example.com!tel:+15712345678!i" . ; Telephone number for country Sweden support IN NAPTR 10 10 "U" "tel+M2U" "!g=se+mailto:support@example.com!tel:+4689761234!i" . ; Other contact URIs for support@example.com 3.3. Linking ENUM This example shows the redirection of the ENUM name of telephone number +17031234567 to the EADDR name of email address joe@example.com for a person named Joe who maintains his contact URIs as part of his mailbox maintenance. $ORIGIN 3.2.1.3.0.7.1.e164.arpa. 7.6.5.4 IN CNAME joe.example.com. 4. Security Considerations Malicious Redirection: A malicious mapping from the email address to an incorrect URI could cause a client to unintentionally retrieve a bad resource. Denial of Service: A malicious deletion of a URI for the email address could deny that resolution protocol to a client. 5. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2234] D. Crocker and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC 2396] T. Berners-Lee, R. T. Fielding, and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Singh, Williamson Expires April 2002 [Page 5] Email Address and NAPTR RR (EADDR) October 2001 [RFC 2915] M. Mealling and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [RFC 2916] P. Faltstrom, "E.164 number and DNS", RFC 2916, September 2000. [RFC 3066] H. Alvestrand, "Tags for the Identification of Languages ", BCP 47, RFC 3066, January 2001. 6. Authors' Addresses Jasdip Singh Ashburn, Virginia USA +1 703 729 6849 jasdips@erols.com Scott Williamson Lovettsville, Virginia USA +1 540 822 5825 scottw@butterflybend.com Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Singh, Williamson Expires April 2002 [Page 6]