Network Working Group Jasdip Singh Internet-Draft Scott Williamson Expires: April 2002 October 2001 URI Localization Using NAPTR RR draft-singh-uri-localization-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 This memo specifies the structure of a Naming Authority Pointer (NAPTR) DNS Resource Record (RR) for localizing a Uniform Resource Identifier (URI) in more popular protocols like HTTP, SMTP, and FTP. URI localization means transforming by locale (geography and language) a URI into another URI that identifies a local resource. This URI transformation, where feasible, can help distribute content more efficiently and appropriately. Table of Contents 1. Introduction..................................................2 1.1. Terminology...................................................2 2. NAPTR RR Specification........................................2 2.1. Matching Algorithm............................................3 3. Examples......................................................4 3.1. Web Redirection...............................................4 3.2. Email Forwarding..............................................5 3.3. File Transfer.................................................6 4. Miscellaneous Notes...........................................6 5. Security Considerations.......................................7 Singh, Williamson [Page 1] URI Localization Using NAPTR RR October 2001 6. Ongoing Work..................................................7 7. References....................................................7 8. Authors' Addresses............................................8 1. Introduction There is a growing need for distributing content by locale: geography and language. Now-a-days, most organizations with global presence explicitly list on their home pages links to their web sites in different regions of the world and/or in different languages. Each new visitor is then asked to select from this list of sites by his (or her) locale including geographical location and/or language. Also, these organizations may need email messages received for certain roles like customer support to be distributed by locale among their data centers around the world. Similarly, FTP sites may need to be set up globally by locale. It would help greatly if there were a standard way to specify, retrieve, and match URI localization information for above applications. A ubiquitous, distributed database system is needed for storing, maintaining, and querying such data. We believe that, even in presence of directory services like LDAP, DNS provides a better way to distribute URI localization information using NAPTR resource records. 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 transforming a URI in one namespace to another URI in same or different namespace using regular expressions to specify the transformation context. ENUM [RFC 2916] is one such application of NAPTR. URI localization essentially involves transforming by locale (geography and language) a URI into another URI that identifies a local resource. A set of NAPTR resource records can be used to specify this URI transformation information for the name derived from the input URI. The specification of such a NAPTR record is as follows. The name field value is derived from the input URI. It is the domain name portion in the HTTP and FTP URIs. In a MAILTO URI, it is the email address string with the '@' character replaced by the '.' character. The order and preference field values SHOULD be the same for all NAPTR records in the set unless there are more than one URIs for a particular locale (for example, a region with more than one FTP servers) that need to have different weights. Singh, Williamson Expires April 2002 [Page 2] URI Localization Using NAPTR RR October 2001 The service field value has the following syntax in ABNF [RFC 2234]. service = protocol "+" rs protocol = "http" | "mailto" | "ftp" | rs = "I2L" The "I2L" resolution service is defined in [RFC 2483]. It indicates that the output URI is a Uniform Resource Locator (URL). 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 = flags = "i" Note the following about the regexp field value. - The protocol (scheme) names in the input and output URIs MUST match. - 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-1 two- letter country code. - Multiple geographical locations and languages can be specified in an extended regular expression. The replacement field value is the '.' character. A NAPTR record without any locale information in its extended regular expression is the default entry in the set. The default entry SHOULD be specified and will most likely have the output URI same as the input URI. 2.1. Matching Algorithm The NAPTR records for a name (derived from an input URI) 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 is constructed. This can vary from one protocol application to another. Therefore, both protocol client and proxy protocol server can potentially act as the DNS client retrieving and matching the NAPTR records. Singh, Williamson Expires April 2002 [Page 3] URI Localization Using NAPTR RR October 2001 The DNS client should construct a match string using the user locale and absolute URI of input URI. (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. Until there is a match, it SHOULD iterate over the NAPTR record set 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 there is still no match, it SHOULD use the output URI in the default entry. If there is no default entry, it MUST render the input URI itself. 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 This section illustrates various localization scenarios for above specified NAPTR record. 3.1. Web Redirection This example shows that an HTTP URI http://example.com for a global organization could be seamlessly redirected to its localized sites in various regions and languages of the world. For this purpose, the DNS for example.com will look as follows. $ORIGIN example.com. ; Pointer to proxy HTTP server @ IN A ; Default entry @ IN NAPTR 10 10 "U" "http+I2L" "!http://example.com!http://example.com!i" . ; For country China @ IN NAPTR 10 10 "U" "http+I2L" "!g=cn+http://example.com!http://example.cn!i" . ; For language Spanish @ IN NAPTR 10 10 "U" "http+I2L" "!l=es+http://example.com!http://example.com/es!i" . ; For country United Kingdom and language English @ IN NAPTR 10 10 "U" "http+I2L" "!g=uk+l=en-uk+http://example.com!http://example.co.uk!i" . All HTTP requests with domain name portion example.com will reach the listed proxy HTTP server. Upon receiving a request, the proxy server will first retrieve all NAPTR records for example.com if it does not already have them. It will then derive geographical Singh, Williamson Expires April 2002 [Page 4] URI Localization Using NAPTR RR October 2001 location information from the IP address of the HTTP client and language information from the request header. The locale information could also be derived from a previously set cookie in the HTTP client. It will then try matching retrieved NAPTR records as described earlier and redirect the client to the output URI in the regexp field of the matched record. If the output URI is the same as the input URI, it MUST render the output URI itself and NOT redirect to prevent looping. Similar A and NAPTR records should also be set for name www.example.com to redirect HTTP URI http://www.example.com. If an organization needs to explicitly list on its main site or an affiliate site links to its various localized sites, the NAPTR record set could be used to dynamically retrieve this information instead of hard-coding it. Also, an HTTP client (browser) may know about the user's locale. It could then directly retrieve and match the NAPTR records for the name in an entered URI, and specify the output URI in the HTTP request to be sent. 3.2. Email Forwarding This example shows that a MAILTO URI mailto:support@example.com could be forwarded by user locale to another MAILTO URI to enable distributing email messages among various data centers of a global organization. For this purpose, the DNS for name support.example.com (email address string with the '@' character replaced by the '.' character) will look as follows. $ORIGIN example.com. ; Pointer to proxy SMTP server @ IN MX 10 ; Default entry support IN NAPTR 10 10 "U" "mailto+I2L" "!mailto:support@example.com!mailto:support@example.com!i" . ; For country China support IN NAPTR 10 10 "U" "mailto+I2L" "!g=cn+mailto:support@example.com!mailto:support@example.cn!i" . ; For countries United States and Canada support IN NAPTR 10 10 "U" "mailto+I2L" "!g=us+g=ca+mailto:support@example.com!mailto:support@north- america.example.com!i" . ; Pointer to SMTP server for North America north-america IN MX 10 All SMTP messages for support@example.com will reach the listed proxy SMTP server. Upon receiving a message, the proxy server will first retrieve all NAPTR records for support.example.com if it does not already have them. It will then derive geographical location and Singh, Williamson Expires April 2002 [Page 5] URI Localization Using NAPTR RR October 2001 possibly language information from the source IP address of the message. The locale information could also be derived from an extended message header. It will then try matching retrieved NAPTR records as described earlier and forward the message to the output URI in the regexp field of the matched record. If the output URI is the same as the input URI, it MUST NOT forward the message to prevent looping. If an organization needs to explicitly list on its main site or an affiliate site email addresses of its various data centers around the world, the NAPTR record set could be used to dynamically retrieve this information instead of hard-coding it. Also, an SMTP client may know about the user's locale. It could then directly retrieve and match the NAPTR records for the name derived from the receiver's email address in the message to be sent, and send email to the output URI. 3.3. File Transfer This example shows that an FTP URI ftp://ftp.example.com could be transformed to a localized FTP URI to enable file transfers from the FTP server closest to a user's locale. For this purpose, the DNS for ftp.example.com will look as follows. $ORIGIN example.com. ; Default entry ftp IN NAPTR 10 10 "U" "ftp+I2L" "!ftp://ftp.example.com!ftp://ftp.example.com!i" . ; For country China ftp IN NAPTR 10 10 "U" "ftp+I2L" "!g=cn+ftp://ftp.example.com!ftp://ftp.example.cn!i" . ; For language Spanish ftp IN NAPTR 10 10 "U" "ftp+I2L" "!l=es+ftp://ftp.example.com!ftp://ftp.example.com/es!i" . ; Two FTP servers for country United States ftp IN NAPTR 10 10 "U" "ftp+I2L" "!g=us+ftp://ftp.example.com!ftp://ftp.example.com!i" . ftp IN NAPTR 10 20 "U" "ftp+I2L" "!g=us+ftp://ftp.example.com!ftp://ftp.example.va.us!i" . If an organization needs to explicitly list on its main site or an affiliate site links to its various localized FTP sites, the NAPTR record set could be used to dynamically retrieve this information instead of hard-coding it. Also, an FTP client may know the user's locale profile. It could then directly retrieve and match the NAPTR records for the name in an entered URI, and send requests to the server closest to the user. 4. Miscellaneous Notes Singh, Williamson Expires April 2002 [Page 6] URI Localization Using NAPTR RR October 2001 - HTTP URI localization can be applied to either a site (as illustrated earlier) or an element within it (for example, an image). - [EADDR] proposes an ENUM-like service called EADDR where an email address, instead of an E.164 telephone number, is used as the key to fetch URIs of other ways of contacting (for example, by telephone) a specific resource. As part of its NAPTR RR specification, it defines a new "M2U" resolution service that maps an email address to one or more URIs for various protocols including MAILTO. In contrast, the "I2L" resolution service specified here maps a MAILTO URI to another MAILTO URI only. Therefore, the "M2U" resolution service is RECOMMENDED for broader email applicability. - Unlike HTTP, FTP has no concept of redirection by a server. Therefore, only FTP clients can do URI localization. - In future, NAPTR-based URI transformation could be extended to associate two URIs by category using a standard taxonomy. For example, linking a .biz URI with a .info URI to provide business information on a specific subject. 5. Security Considerations Malicious Redirection: A malicious mapping from the input URI to an incorrect output URI could cause a client to unintentionally retrieve a bad local resource. Denial of Service: A malicious deletion of an output URI for the input URI could deny that local resource to a client. 6. Ongoing Work As per [REQRT] listing known techniques for routing requests in a content delivery network, the technique described here would be an application-layer request-routing technique using DNS to retrieve URI localization information. [SLS] proposes a restricted contextual resolution layer above existing DNS and below existing directory services like LDAP, and hence a new approach for a potential long-term solution. 7. 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 7] URI Localization Using NAPTR RR October 2001 [RFC 2483] M. Mealling and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999. [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. [REQRT] A. Barbir, B. Cain, F. Douglis, M. Green, M. Hofmann, R. Nair, D. Potter, and O. Spatscheck, "Known CDN Request- Routing Mechanisms", draft-cain-cdnp-known-request- routing-02.txt (work in progress), June 2001. [SLS] M. Mealling and L. Daigle, "Service Lookup System (SLS)", draft-mealling-sls-00.txt (work in progress), July 2001. [EADDR] J. Singh and S. Williamson, "Email Address and NAPTR RR (EADDR)", draft-singh-eaddr-00.txt (work in progress), October 2001. 8. 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 Singh, Williamson Expires April 2002 [Page 8] URI Localization Using NAPTR RR October 2001 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 9]