idnits 2.17.1 draft-ietf-impp-srv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 28, 2003) is 7726 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-ietf-impp-im-00 == Outdated reference: A later version (-04) exists of draft-ietf-impp-pres-00 ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '6') Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMPP WG D. Crocker 3 Internet-Draft Brandenburg 4 Expires: August 29, 2003 J. Peterson 5 NeuStar 6 February 28, 2003 8 Address Resolution for Instant Messaging and Presence 9 draft-ietf-impp-srv-02 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 29, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 Presence and instant messaging are defined in RFC2778 [5]. The 41 Common Profiles for Presence [2] and Instant Messaging [1] define two 42 URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. 43 This document provides guidance for locating the resources associated 44 with URIs that employ these schemes. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Address Resolution . . . . . . . . . . . . . . . . . . . . . . . 4 51 4. Domain Name Lookup . . . . . . . . . . . . . . . . . . . . . . . 4 52 5. Processing SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 4 53 6. Processing Multiple Addresses . . . . . . . . . . . . . . . . . 5 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Normative References . . . . . . . . . . . . . . . . . . . . . . 6 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 59 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 Presence and instant messaging are defined in RFC2778 [5]. The 64 Common Profiles for Presence (CPP [2]) and Instant Messaging (CPIM 65 [1]) define two URI schemes: 'im' for INSTANT INBOXes and 'pres' for 66 PRESENTITIES. This document provides rules for locating the 67 resources associated with URIs that employ these schemes via the 68 Domain Name Service [4]. These rules could no doubt be applied to 69 the resolution of other URI schemes that are unrelated to instant 70 messaging and presence. 72 CPIM and CPP both specify operations that have 'source' and 73 'destination' attributes. While only the semantics, not the syntax, 74 of these attributes are defined by CPIM and CPP, many instant 75 messaging and presence protocols today support the use of URIs to 76 reflect the source and destination of their operations. The 'im' and 77 'pres' URI schemes allow such protocols to express the identities of 78 the principals associated with a protocol exchange. When these 79 operations pass through a CPIM or CPP gateway, these URIs could be 80 relayed without modification, which has a number of desirable 81 properties for the purposes of interoperability. 83 These URI schemes are also useful in cases where no CPIM/CPP 84 gatewaying will occur. If a particular principal's endpoint supports 85 multiple instant messaging applications, for example, then a domain 86 that identifies that host might use the sort of DNS records described 87 in this document in order to provide greater compatibility with 88 clients that support only one instant messaging protocol. A client 89 would look up the record corresponding to the supported protocol, and 90 learn how to contact the endpoint for that protocol. The principal 91 in this instance would use an IM URI as their canonical address. 93 In some architectures, these URIs might also be used to locate a CPIM 94 or CPP gateway that serves a particular domain. If a particular IM 95 service provider wishes to operate CPIM/CPP gateways in its own 96 domain that map standard Internet protocols to an internal 97 proprietary protocol, that gateway could be identified by an IM URI. 98 In that case, the DNS records used to dereference the IM URI would 99 serve a purpose similar to that of MX records. 101 The system described in this document relies on the use of DNS SRV 102 [7] records and A records. 104 2. Terminology 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 108 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 109 described in RFC2119 [3] and indicate requirement levels for 110 compliant implementations. 112 This memos makes use of the vocabulary defined in RFC2778 [5]. Terms 113 such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in 114 the same meaning as defined therein. 116 3. Address Resolution 118 A client determines the address of an appropriate system running a 119 server, on behalf of the system referenced by the domain, by 120 resolving the destination domain name that is part of the identifier 121 to either an intermediate relay system or a final target system. 123 Only resolvable, fully-qualified, domain names (FQDNs) are permitted 124 when domain names are used in an IM URI (i.e., domain names that can 125 be resolved to SRV [7] or A RRs). 127 4. Domain Name Lookup 129 Once a client lexically identifies a domain to which instant 130 messaging or presence operations will be delivered for processing, a 131 DNS lookup MUST be performed to resolve the domain. The names MUST 132 be fully-qualified domain names (FQDNs) -- mechanisms for inferring 133 FQDNs from partial names or local aliases are a local matter. 135 The lookup first attempts to locate SRV RRs associated with the 136 domain. If a CNAME RR is found instead, the resulting domain is 137 processed as if it were the initial domain. 139 If one or more SRV RRs are found for a given domain, a sender MUST 140 NOT utilize any A RRs associated with that domain unless they are 141 located using the SRV RRs. If no SRV RRs are found, but an A RR is 142 found, then the A RR is treated as if it was associated with an 143 implicit SRV RR, with a preference of 0, pointing to that domain. 145 5. Processing SRV RRs 147 Taking the IM URI for a concrete example, a lookup is performed for 148 SRVs for the target domain and a desired IM transfer protocol. 150 For example, if the destination INSTANT INBOX is 151 "im:fred@example.com", and the sender wishes to use an IM transfer 152 protocol called "SIP", then a SRV lookup is performed for: 154 _im._sip.example.com. 156 The returned RRs, if any, specify the next-hop server. 158 The choice of IM transfer protocol is a local configuration option 159 for each system. 161 Receiving systems that are registed for this DNS-based SRV resolution 162 service list the transfer protocols by which they can be reached, 163 either directly or through a translating gateway. The transfer-time 164 choice of the IM transfer protocol to be used (and, therefore, to be 165 resolved) is a local configuration option for each sending system. 167 Using this mechanism, seamless routing of IM traffic is possible, 168 regardless of whether a gateway is necessary for interoperation. To 169 achieve this transparency, a separate RR for a gateway must be 170 present for each transfer protocol and domain pair that it serves. 172 The same logic is used for PRES URIs. 174 6. Processing Multiple Addresses 176 When the lookup succeeds, the mapping can result in a list of 177 alternative delivery addresses rather than a single address, because 178 of multiple SRV records, multihoming, or both. For reliable 179 operations, the client MUST be able to try each of the relevant 180 addresses in this list in order, until a delivery attempt succeeds. 181 However, there MAY also be a configurable limit on the number of 182 alternate addresses that can be tried. In any case, the client 183 SHOULD try at least two addresses. Two types of information are used 184 to rank the domain addresses: multiple SRV records, and multihomed 185 domains. 187 Multiple SRV records contain a preference indication that MUST be 188 used in sorting. Lower numbers are preferable to higher ones. If 189 there are multiple destinations with the same preference, and there 190 is no clear reason to favor one (e.g., by recognition of an easily- 191 reached address), then the sender MUST randomize them to spread the 192 load across multiple servers for a specific destination. 194 The destination domain (perhaps taken from the preferred SRV record) 195 may be multihomed, in which case the resolver will return a list of 196 alternative IP addresses. It is the responsibility of the resolver 197 to have ordered this list by decreasing preference if necessary, and 198 the sender MUST try them in the order presented. 200 7. Security Considerations 202 The usage of IM and PRES URIs, and the DNS procedures in this 203 document, introduce no security considerations beyond those described 204 in the requirements for instant messaging and presence ([6]) and the 205 SRV specification ([7]). 207 8. IANA Considerations 209 This document introduces no new considerations for IANA. 211 9. Contributors 213 The following individuals made substantial textual contributions to 214 this document: 216 Athanassios Diacakis (thanos.diacakis@openwave.com) 218 Florencio Mazzoldi (flo@networkprojects.com) 220 Christian Huitema (huitema@microsoft.com) 222 Graham Klyne (gk@ninebynine.org) 224 Jonathan Rosenberg (jdrosen@dynamicsoft.com) 226 Robert Sparks (rsparks@dynamicsoft.com) 228 Hiroyasu Sugano (suga@flab.fujitsu.co.jp) 230 Normative References 232 [1] Crocker, D. and J. Peterson, "Common Profile: Instant 233 Messaging", draft-ietf-impp-im-00 (work in progress), October 234 2002. 236 [2] Crocker, D. and J. Peterson, "Common Profile: Presence", draft- 237 ietf-impp-pres-00 (work in progress), October 2002. 239 [3] Bradner, S., "Key words for use in RFCs to indicate requirement 240 levels", RFC 2119, March 1997. 242 [4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 243 1034, STD 13, November 1987. 245 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 246 Instant Messaging", RFC 2778, February 2000. 248 [6] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 249 Presence Protocol Requirements", RFC 2779, February 2000. 251 [7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 252 Specifying the Location of Services (SRV)", RFC 2782, February 253 2000. 255 Authors' Addresses 257 Dave Crocker 258 Brandenburg InternetWorking 259 675 Spruce Drive 260 Sunnyvale, CA 94086 261 US 263 Phone: +1 408/246-8253 264 EMail: dcrocker@brandenburg.com 266 Jon Peterson 267 NeuStar, Inc. 268 1800 Sutter St 269 Suite 570 270 Concord, CA 94520 271 US 273 Phone: +1 925/363-8720 274 EMail: jon.peterson@neustar.biz 276 Full Copyright Statement 278 Copyright (C) The Internet Society (2003). All Rights Reserved. 280 This document and translations of it may be copied and furnished to 281 others, and derivative works that comment on or otherwise explain it 282 or assist in its implementation may be prepared, copied, published 283 and distributed, in whole or in part, without restriction of any 284 kind, provided that the above copyright notice and this paragraph are 285 included on all such copies and derivative works. However, this 286 document itself may not be modified in any way, such as by removing 287 the copyright notice or references to the Internet Society or other 288 Internet organizations, except as needed for the purpose of 289 developing Internet standards in which case the procedures for 290 copyrights defined in the Internet Standards process must be 291 followed, or as required to translate it into languages other than 292 English. 294 The limited permissions granted above are perpetual and will not be 295 revoked by the Internet Society or its successors or assigns. 297 This document and the information contained herein is provided on an 298 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 299 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 300 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 301 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 302 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 304 Acknowledgement 306 Funding for the RFC Editor function is currently provided by the 307 Internet Society.