idnits 2.17.1 draft-ietf-impp-srv-04.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 (September 2003) is 7527 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) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '6') ** Obsolete normative reference: RFC 2434 (ref. '8') (Obsoleted by RFC 5226) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IMPP WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: March 1, 2004 September 2003 6 Address Resolution for Instant Messaging and Presence 7 draft-ietf-impp-srv-04 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on March 1, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 Presence and instant messaging are defined in RFC2778 [5]. The 39 Common Profiles for Presence [2] and Instant Messaging [1] define two 40 URI schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. 41 This document provides guidance for locating the resources associated 42 with URIs that employ these schemes. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Address Resolution . . . . . . . . . . . . . . . . . . . . . . . 4 49 4. Domain Name Lookup . . . . . . . . . . . . . . . . . . . . . . . 5 50 5. Processing SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 5 51 6. Processing Multiple Addresses . . . . . . . . . . . . . . . . . 5 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 54 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 57 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 8 59 1. Introduction 61 Presence and instant messaging are defined in RFC2778 [5]. The 62 Common Profiles for Presence (CPP [2]) and Instant Messaging (CPIM 63 [1]) define two URI schemes: 'im' for INSTANT INBOXes and 'pres' for 64 PRESENTITIES. This document provides rules for locating the 65 resources associated with URIs that employ these schemes via the 66 Domain Name Service [4]. These rules could no doubt be applied to 67 the resolution of other URI schemes that are unrelated to instant 68 messaging and presence. 70 CPIM and CPP both specify operations that have 'source' and 71 'destination' attributes. While only the semantics, not the syntax, 72 of these attributes are defined by CPIM and CPP, many instant 73 messaging and presence protocols today support the use of URIs to 74 reflect the source and destination of their operations. The 'im' and 75 'pres' URI schemes allow such protocols to express the identities of 76 the principals associated with a protocol exchange. When these 77 operations pass through a CPIM or CPP gateway, these URIs could be 78 relayed without modification, which has a number of desirable 79 properties for the purposes of interoperability. 81 These URI schemes are also useful in cases where no CPIM/CPP 82 gatewaying will occur. If a particular principal's endpoint supports 83 multiple instant messaging applications, for example, then a domain 84 that identifies that host might use the sort of DNS records described 85 in this document in order to provide greater compatibility with 86 clients that support only one instant messaging protocol. A client 87 would look up the record corresponding to the supported protocol, and 88 learn how to contact the endpoint for that protocol. The principal 89 in this instance would use an IM URI as their canonical address. 91 In some architectures, these URIs might also be used to locate a CPIM 92 or CPP gateway that serves a particular domain. If a particular IM 93 service provider wishes to operate CPIM/CPP gateways in its own 94 domain that map standard Internet protocols to an internal 95 proprietary protocol, that gateway could be identified by an IM URI. 96 In that case, the DNS records used to dereference the IM URI would 97 serve a purpose similar to that of MX records. 99 The system described in this document relies on the use of DNS SRV 100 [7] records and A records. 102 2. Terminology 104 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 105 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 106 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 107 described in RFC2119 [3] and indicate requirement levels for 108 compliant implementations. 110 This memos makes use of the vocabulary defined in RFC2778 [5]. Terms 111 such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in 112 the same meaning as defined therein. 114 3. Address Resolution 116 A client determines the address of an appropriate system running a 117 server, on behalf of the system referenced by the domain, by 118 resolving the destination domain name that is part of the identifier 119 to either an intermediate relay system or a final target system. 121 Only resolvable, fully-qualified, domain names (FQDNs) are permitted 122 when domain names are used in an IM URI (i.e., domain names that can 123 be resolved to SRV [7] or A RRs). 125 The symbolic name used in the Service field of the SRV record is 126 "_im" for instant messaging and "_pres" for presence (matching their 127 respective URI schemes). However, the advertisement of these 128 services in the DNS is incomplete if it does not include the protocol 129 that will be used to instantiate the instant messaging or presence 130 operations. Thus, the Protocol field of the SRV record contains an 131 IANA-registered label corresponding to the underlying instant 132 messaging or presence protocol being advertised (see Section 8 for 133 more information on valid Protocol fields). 135 Taking the IM URI as a concrete example, a lookup is performed for 136 SRVs for the target domain, a desired service (using the "_im" 137 Service label) and a desired IM transfer protocol. If the 138 destination INSTANT INBOX is "im:fred@example.com", and the sender 139 wishes to use an IM transfer protocol called "BIP" (and supposing 140 "_bip" were registered with IANA as a valid Protocol label for the IM 141 Service), then a SRV lookup is performed for: 143 _im._bip.example.com. 145 The same procedure is used for PRES URIs, with the "_pres" Service 146 label. 148 Some clients may support multiple instant messaging or presence 149 protocols; in these cases they may make several such SRV queries, in 150 an application-specific order, until they find one supported in 151 common with the target domain. 153 4. Domain Name Lookup 155 Once a client lexically identifies a domain to which instant 156 messaging or presence operations will be delivered for processing, a 157 DNS lookup MUST be performed to resolve the domain. The names MUST 158 be fully-qualified domain names (FQDNs) -- mechanisms for inferring 159 FQDNs from partial names or local aliases are a local matter. 161 The lookup first attempts to locate SRV RRs associated with the 162 domain. If a CNAME RR is found instead, the resulting domain is 163 processed as if it were the initial domain. 165 If one or more SRV RRs are found for a given domain, a sender MUST 166 NOT utilize any A RRs associated with that domain unless they are 167 located using the SRV RRs. If no SRV RRs are found, but an A RR is 168 found, then the A RR is treated as if it was associated with an 169 implicit SRV RR, with a preference of 0, pointing to that domain. 171 5. Processing SRV RRs 173 The returned DNS RRs, if any, specify the next-hop server, which may 174 be a protocol gateway or an endpoint. 176 Receiving systems that are registered for this DNS-based SRV 177 resolution service list the transfer protocols by which they can be 178 reached, either directly or through a translating gateway (using 179 combinations of Service and Protocol labels as described above). The 180 transfer-time choice of the IM transfer protocol to be used (and, 181 therefore, to be resolved) is a local configuration option for each 182 sending system. 184 Using this mechanism, seamless routing of IM traffic is possible, 185 regardless of whether a gateway is necessary for interoperation. To 186 achieve this transparency, a separate RR for a gateway must be 187 present for each transfer protocol and domain pair that it serves. 189 6. Processing Multiple Addresses 191 When the lookup succeeds, the mapping can result in a list of 192 alternative delivery addresses rather than a single address, because 193 of multiple SRV records. For reliable operations, the client MUST be 194 able to try each of the relevant addresses in this list in order, 195 until a delivery attempt succeeds. However, there MAY also be a 196 configurable limit on the number of alternate addresses that can be 197 tried. In any case, the client SHOULD try at least two addresses. 199 Resolvers must follow the standard procedures in RFC2782 [7] for 200 handling the priority and weight fields of SRV records. 202 7. Security Considerations 204 The usage of IM and PRES URIs, and the DNS procedures in this 205 document, introduce no security considerations beyond those described 206 in the requirements for instant messaging and presence ([6]) and the 207 SRV specification ([7]). 209 Subsequent registrations of Protocol labels for use with the "_im" or 210 "_pres" Service labels MUST, however, explain any security 211 considerations that arise from the use of the protocol in question 212 with SRV. 214 8. IANA Considerations 216 This document reserves the use of "_im" and "_pres" Service labels. 217 Since these relate to a service which may pass messages over a number 218 of different message transports, they must be associated with a 219 specific instant messaging or presence service. 221 In order to ensure that the association between "_im" and "_pres" and 222 their respective underlying services is deterministic, this document 223 requests that IANA create two independent registries: the Instant 224 Messaging SRV Protocol Label registry and the Presence SRV Protocol 225 Label registry. For each registry, an entry shall consist of a label 226 name and a pointer to a specification describing how the protocol 227 named in the label uses SRV. Specifications should conform to the 228 requirements listed in RFC 2434 [8] for "specification required". 230 Protocol labels compliant with this specification MUST begin with the 231 underscore character "_" and follow all other rules for SRV Protocol 232 labels described in [7]. 234 9. Contributors 236 Dave Crocker edited earlier versions of this document. 238 The following individuals made substantial textual contributions to 239 this document: 241 Athanassios Diacakis (thanos.diacakis@openwave.com) 243 Florencio Mazzoldi (flo@networkprojects.com) 245 Christian Huitema (huitema@microsoft.com) 247 Graham Klyne (gk@ninebynine.org) 249 Jonathan Rosenberg (jdrosen@dynamicsoft.com) 250 Robert Sparks (rsparks@dynamicsoft.com) 252 Hiroyasu Sugano (suga@flab.fujitsu.co.jp) 254 Normative References 256 [1] Peterson, J., "Common Profile: Instant Messaging", draft-ietf- 257 impp-im-04 (work in progress), October 2003. 259 [2] Peterson, J., "Common Profile: Presence", draft-ietf-impp-pres- 260 04 (work in progress), October 2003. 262 [3] Bradner, S., "Key words for use in RFCs to indicate requirement 263 levels", RFC 2119, March 1997. 265 [4] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 266 1034, STD 13, November 1987. 268 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 269 Instant Messaging", RFC 2778, February 2000. 271 [6] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 272 Presence Protocol Requirements", RFC 2779, February 2000. 274 [7] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 275 Specifying the Location of Services (SRV)", RFC 2782, February 276 2000. 278 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 279 Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. 281 Author's Address 283 Jon Peterson 284 NeuStar, Inc. 285 1800 Sutter St 286 Suite 570 287 Concord, CA 94520 288 US 290 Phone: +1 925/363-8720 291 EMail: jon.peterson@neustar.biz 293 Full Copyright Statement 295 Copyright (C) The Internet Society (2003). All Rights Reserved. 297 This document and translations of it may be copied and furnished to 298 others, and derivative works that comment on or otherwise explain it 299 or assist in its implementation may be prepared, copied, published 300 and distributed, in whole or in part, without restriction of any 301 kind, provided that the above copyright notice and this paragraph are 302 included on all such copies and derivative works. However, this 303 document itself may not be modified in any way, such as by removing 304 the copyright notice or references to the Internet Society or other 305 Internet organizations, except as needed for the purpose of 306 developing Internet standards in which case the procedures for 307 copyrights defined in the Internet Standards process must be 308 followed, or as required to translate it into languages other than 309 English. 311 The limited permissions granted above are perpetual and will not be 312 revoked by the Internet Society or its successors or assigns. 314 This document and the information contained herein is provided on an 315 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 316 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 317 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 318 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 319 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 321 Acknowledgement 323 Funding for the RFC Editor function is currently provided by the 324 Internet Society.