IMPP WG D. Crocker Internet-Draft Brandenburg Expires: April 27, 2003 A. Diacakis F. Mazzoldi Net Proj C. Huitema Microsoft G. Klyne Baltimore J. Rosenberg R. Sparks dynamicsoft H. Sugano Fujitsu J. Peterson NeuStar October 27, 2002 Address Resolution for Instant Messaging and Presence draft-ietf-impp-srv-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 27, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Crocker, et al. Expires April 27, 2003 [Page 1] Internet-Draft IM&P SRV October 2002 Abstract Presence and instant messaging are defined in RFC2778 [5]. The Common Profiles for Presence [2] and Instant Messaging [1] define two URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Address Resolution . . . . . . . . . . . . . . . . . . . . . . . 3 4. Domain Name Lookup . . . . . . . . . . . . . . . . . . . . . . . 3 5. Processing SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 4 6. Processing Multiple Addresses . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 Crocker, et al. Expires April 27, 2003 [Page 2] Internet-Draft IM&P SRV October 2002 1. Introduction Presence and instant messaging are defined in RFC2778 [5]. The Common Profiles for Presence [2] and Instant Messaging [1] define two URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. The system described in this document relies on the use of DNS SRV [7] records and A records. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [3] and indicate requirement levels for compliant implementations. This memos makes use of the vocabulary defined in RFC 2778[9]. Terms such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in the same meaning as defined therein. 3. Address Resolution A client determines the address of an appropriate system running a server by resolving the destination domain name that is part of the identifier to either an intermediate relay system or a final target system. Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in an IM URI (i.e., domain names that can be resolved to SRV[11] or A RRs). 4. Domain Name Lookup Once a client lexically identifies a domain to which instant messaging or presence operations will be delivered for processing, a DNS lookup MUST be performed to resolve the domain. The names MUST be fully-qualified domain names (FQDNs) -- mechanisms for inferring FQDNs from partial names or local aliases are a local matter. The lookup first attempts to locate SRV RRs associated with the domain. If a CNAME RR is found instead, the resulting domain is processed as if it were the initial domain. If one or more SRV RRs are found for a given domain, a sender MUST NOT utilize any A RRs associated with that domain unless they are Crocker, et al. Expires April 27, 2003 [Page 3] Internet-Draft IM&P SRV October 2002 located using the SRV RRs. If no SRV RRs are found, but an A RR is found, then the A RR is treated as if it was associated with an implicit SRV RR, with a preference of 0, pointing to that domain. 5. Processing SRV RRs Taking the IM URI for a concrete example, a lookup is performed for SRVs for the target domain and a desired IM transfer protocol. For example, if the destination INSTANT INBOX is "im:fred@example.com", and the sender wishes to use an IM transfer protocol called "SIP", then a SRV lookup is performed for: _im._sip.example.com. The returned RRs, if any, specify the next-hop server. The choice of IM transfer protocol is a local configuration option for each system. Using this mechanism, seamless routing of IM traffic is possible, regardless of whether a gateway is necessary for interoperation. To achieve this transparency, a separate RR for a gateway must be present for each transfer protocol and domain pair that it serves. The same logic is used for PRES URIs. 6. Processing Multiple Addresses When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple SRV records, multihoming, or both. For reliable operations, the client MUST be able to try each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the client SHOULD try at least two addresses. Two types of information are used to rank the domain addresses: multiple SRV records, and multihomed domains. Multiple SRV records contain a preference indication that MUST be used in sorting. Lower numbers are preferable to higher ones. If there are multiple destinations with the same preference, and there is no clear reason to favor one (e.g., by recognition of an easily- reached address), then the sender MUST randomize them to spread the load across multiple servers for a specific destination. The destination domain (perhaps taken from the preferred SRV record) Crocker, et al. Expires April 27, 2003 [Page 4] Internet-Draft IM&P SRV October 2002 may be multihomed, in which case the resolver will return a list of alternative IP addresses. It is the responsibility of the resolver to have ordered this list by decreasing preference if necessary, and the sender MUST try them in the order presented. 7. Security Considerations The usage of IM and PRES URIs, and the DNS procedures in this document, introduce no security considerations beyond those described in the requirements for instant messaging and presence ([6]) and the SRV specification ([7]). 8. IANA Considerations This document introduces no new considerations for IANA. References [1] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Common Profile: Instant Messaging", draft-ietf-impp-im-00 (work in progress), October 2002. [2] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, "Common Profile: Presence", draft-ietf-impp-pres-00 (work in progress), October 2002. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987. [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [6] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for Specifying the Location of Services (SRV)", RFC 2782, February 2000. Crocker, et al. Expires April 27, 2003 [Page 5] Internet-Draft IM&P SRV October 2002 Authors' Addresses Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 US Phone: +1 408/246-8253 EMail: dcrocker@brandenburg.com Athanassios Diacakis Network Projects Inc. 4516 Henry Street Suite 113 Pittsburgh, PA 15213 US Phone: +1 412/681-6950 x202 EMail: thanos@networkprojects.com Florencio Mazzoldi Network Projects Inc. 4516 Henry Street Suite 113 Pittsburgh, PA 15213 US Phone: +1 412/681-6950 EMail: flo@networkprojects.com Christian Huitema Microsoft Corporation One Microsoft Way Redmund, WA 98052-6399 US EMail: huitema@microsoft.com Crocker, et al. Expires April 27, 2003 [Page 6] Internet-Draft IM&P SRV October 2002 Graham Klyne Baltimore Technologies 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK Phone: +44 118 903 8000 EMail: gk@acm.org Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 US EMail: jdrosen@dynamicsoft.com Robert Sparks dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 US EMail: rsparks@dynamicsoft.com Hiroyasu Sugano Fujitsu Laboratories Ltd. 200 Executive Drive 64 Nishiwaki, Ohkubo-cho Akashi 674-8555 JP EMail: suga@flab.fujitsu.co.jp Crocker, et al. Expires April 27, 2003 [Page 7] Internet-Draft IM&P SRV October 2002 Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz Crocker, et al. Expires April 27, 2003 [Page 8] Internet-Draft IM&P SRV October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Crocker, et al. Expires April 27, 2003 [Page 9]