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"  |  <etc>
        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  <absolute URI of input MAILTO URI>
        locale  =  geography  |  language  |  <etc>
        geography  =  "g="  <ISO 3166 location code>  "+"
        language  =  "l="  <language tag as defined in [RFC 3066]>  "+"
        repl  =  <absolute URI of output URI>
     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]