idnits 2.17.1 draft-ietf-impp-im-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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 14, 2003) is 7554 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) == Unused Reference: '6' is defined on line 402, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-impp-srv-02 ** Obsolete normative reference: RFC 2822 (ref. '3') (Obsoleted by RFC 5322) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '6') == Outdated reference: A later version (-09) exists of draft-ietf-smime-rfc2633bis-03 ** Obsolete normative reference: RFC 3369 (ref. '9') (Obsoleted by RFC 3852) Summary: 5 errors (**), 0 flaws (~~), 6 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: February 12, 2004 August 14, 2003 6 Common Profile for Instant Messaging (CPIM) 7 draft-ietf-impp-im-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 February 12, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 At the time this document was written, numerous instant messaging 39 protocols are in use, and little interoperability between services 40 based on these protocols has been achieved. This specification 41 defines common semantics and data formats for instant messaging to 42 facilitate the creation of gateways between instant messaging 43 services. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Abstract Instant Messaging Service . . . . . . . . . . . . . 4 50 3.1 Overview of Instant Messaging Service . . . . . . . . . . . 4 51 3.2 Identification of INSTANT INBOXes . . . . . . . . . . . . . 5 52 3.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 5 53 3.3 Format of Instant Messages . . . . . . . . . . . . . . . . . 5 54 3.4 The Messaging Service . . . . . . . . . . . . . . . . . . . 6 55 3.4.1 The Message Operation . . . . . . . . . . . . . . . . . . . 6 56 3.4.2 Looping . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. Security Considerations . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 59 5.1 The IM URI Scheme . . . . . . . . . . . . . . . . . . . . . 8 60 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 62 A. IM URI IANA Registration Template . . . . . . . . . . . . . 10 63 A.1 URI scheme name . . . . . . . . . . . . . . . . . . . . . . 10 64 A.2 URI scheme syntax . . . . . . . . . . . . . . . . . . . . . 10 65 A.3 Character encoding considerations . . . . . . . . . . . . . 10 66 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 10 67 A.5 Applications and/or protocols which use this URI scheme 68 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 A.6 Security considerations . . . . . . . . . . . . . . . . . . 11 70 A.7 Relevant publications . . . . . . . . . . . . . . . . . . . 11 71 A.8 Person & email address to contact for further information . 11 72 A.9 Author/Change controller . . . . . . . . . . . . . . . . . . 11 73 A.10 Applications and/or protocols which use this URI scheme 74 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 11 76 B.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 11 77 B.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 11 78 Normative References . . . . . . . . . . . . . . . . . . . . 9 79 Informative References . . . . . . . . . . . . . . . . . . . 9 80 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 81 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Instant messaging is defined in RFC2778 [5]. At the time this 86 document was written, numerous instant messaging protocols are in 87 use, and little interoperability between services based on these 88 protocols has been achieved. This specification defines semantics 89 and data formats for common services of instant messaging to 90 facilitate the creation of gateways between instant messaging 91 services: a common profile for instant messaging (CPIM). 93 Service behavior is described abstractly in terms of operations 94 invoked between the consumer and provider of a service. Accordingly, 95 each IM service must specify how this behavior is mapped onto its own 96 protocol interactions. The choice of strategy is a local matter, 97 providing that there is a clear relation between the abstract 98 behaviors of the service (as specified in this memo) and how it is 99 faithfully realized by a particular instant messaging service. For 100 example, one strategy might transmit an instant message as textual 101 key/value pairs, another might use a compact binary representation, 102 and a third might use nested containers. 104 The attributes for each operation are defined using an abstract 105 syntax. Although the syntax specifies the range of possible data 106 values, each IM service must specify how well-formed instances of the 107 abstract representation are encoded as a concrete series of bits. 109 In order to provide a means for the preservation of end-to-end 110 features (especially security) to pass through instant messaging 111 interoperability gateways, this specification also provides 112 recommendations for instant messaging document formats that could be 113 employed by instant messaging protocols. 115 2. Terminology 117 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 118 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 119 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 120 described in RFC2119 [1] and indicate requirement levels for 121 compliant implementations. 123 This memos makes use of the vocabulary defined in RFC2778 [5]. Terms 124 such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in 125 the same meaning as defined therein. 127 The term 'gateway' used in this draft denotes a network element 128 responsible for interworking between diverse instant messaging 129 protocols. Although the instant messaging protocols themselves are 130 diverse, under the model used in this document these protocols can 131 carry a common payload that is relayed by the gateway. Whether these 132 interworking intermediaries should be called 'gateways' or 'relays' 133 is therefore somewhat debatable; for the purposes of this document, 134 they are called 'CPIM gateways'. 136 The term 'instant messaging service' also derives from RFC2778, but 137 its meaning changes slightly due to the existence of gateways in the 138 CPIM model. When a client sends an operation to an instant messaging 139 service, that service might either be an endpoint or an intermediary 140 such as a CPIM gateway - in fact, the client should not have to be 141 aware which it is addressing, as responses from either will appear 142 the same. 144 This document defines operations and attributes of an abstract 145 instant messaging protocol. In order for a compliant protocol to 146 interface with an instant messaging gateway, it must support all of 147 the operations described in this document (i.e. the instant 148 messaging protocol must have some message or capability that provides 149 the function described by each of the given operations). Similarly, 150 the attributes defined for these operations must correspond to 151 information available in the instant messaging protocol in order for 152 the protocol to interface with gateways defined by this 153 specification. Note that these attributes provide only the minimum 154 possible information that needs to be specified for interoperability 155 - the functions in an instant messaging protocol that correspond to 156 the operations described in this document can contain additional 157 information that will not be mapped by CPIM. 159 3. Abstract Instant Messaging Service 161 3.1 Overview of Instant Messaging Service 163 When an application wants to send a message to an INSTANT INBOX, it 164 invokes the message operation, e.g., 166 +-------+ +-------+ 167 | | | | 168 | appl. | -- message ------> | IM | 169 | | | svc. | 170 +-------+ +-------+ 172 The message operation has the following attributes: source, 173 destination, MaxForwards and TransID. 'source' and 'destination' 174 identify the originator and recipient of an instant message, 175 respectively, and consist of an INSTANT INBOX identifier (as 176 described in Section 3.2). The MaxForwards is a hop counter to avoid 177 loops through gateways, with usage detailed defined in Section 3.4.2; 178 its initial value is set by the originator. The TransID is a unique 179 identifier used to correlate message operations to response 180 operations; gateways should be capable of handling TransIDs up to 40 181 bytes in length. 183 The message operation also has some content, the instant message 184 itself, which may be textual, or which may consist of other data. 185 Content details are specified in Section 3.3. 187 Note that this specification assumes that instant messaging protocols 188 provide reliable message delivery; there are no application-layer 189 message delivery assurance provisions in this specification. 191 Upon receiving a message operation, the service immediately responds 192 by invoking the response operation containing the same transaction- 193 identifier, e.g., 195 +-------+ +-------+ 196 | | | | 197 | appl. | <----- response -- | IM | 198 | | | svc. | 199 +-------+ +-------+ 201 The response operation contains the following attributes: TransID and 202 status. The TransID is used to correlate the response to a 203 particular instant message. Status indicates whether the delivery of 204 the message succeeded or failed. Valid status values are described 205 in Section 3.4.1. 207 3.2 Identification of INSTANT INBOXes 209 An INSTANT INBOX is specified using an instant messaging URI with the 210 'im:' URI scheme. The full syntax of the IM URI scheme is given in 211 Appendix A. An example would be: "im:fred@example.com" 213 3.2.1 Address Resolution 215 An IM service client determines the next hop to forward the IM to by 216 resolving the domain name portion of the service destination. 217 Compliant implementations SHOULD follow the guidelines for 218 dereferencing URIs given in [2]. 220 3.3 Format of Instant Messages 222 This specification defines an abstract interoperability mechanism for 223 instant messaging protocols; the message content definition given 224 here pertains to semantics rather than syntax. However, some 225 important properties for interoperability can only be provided if a 226 common end-to-end format for instant messaging is employed by the 227 interoperating instant messaging protocols, especially with respect 228 to security. In order to maintain end-to-end security properties, 229 applications that send message operations to a CPIM gateway MUST 230 implement the format defined in MSGFMT [4]. Applications MAY support 231 other content formats. 233 CPIM gateways MUST be capable of relaying the content of a message 234 operation between supported instant messaging protocols without 235 needing to modify or inspect the content. 237 3.4 The Messaging Service 239 3.4.1 The Message Operation 241 When an application wants to send an INSTANT MESSAGE, it invokes the 242 message operation. 244 When an instant messaging service receives the message operation, it 245 performs the following preliminary checks: 247 1. If the source or destination does not refer to a syntactically 248 valid INSTANT INBOX, a response operation having status "failure" 249 is invoked. 251 2. If the destination of the operation cannot be resolved by the 252 recipient, and the recipient is not the final recipient, a 253 response operation with the status "failure" is invoked. 255 3. If access control does not permit the application to request this 256 operation, a response operation having status "failure" is 257 invoked. 259 4. Provided these checks are successful: 261 If the instant messaging service is able to successfully 262 deliver the message, a response operation having status 263 "success" is invoked. 265 If the service is unable to successfully deliver the message, 266 a response operation having status "failure" is invoked. 268 If the service must delegate responsibility for delivery (i.e. 269 if it is acting as a gateway or proxying the operation), and 270 if the delegation will not result in a future authoritative 271 indication to the service, a response operation having status 272 "indeterminant" is invoked. 274 If the service must delegate responsibility for delivery, and 275 if the delegation will result in a future authoritative 276 indication to the service, then a response operation is 277 invoked immediately after the indication is received. 279 When the service invokes the response operation, the transID 280 parameter is identical to the value found in the message operation 281 invoked by the application. 283 3.4.2 Looping 285 The dynamic routing of instant messages can result in looping of a 286 message through a relay. Detection of loops is not always obvious, 287 since aliasing and group list expansions can legitimately cause a 288 message to pass through a relay more than one time. 290 This document assumes that instant messaging protocols that can be 291 gatewayed by CPIM support some semantic equivalent to an integer 292 value that indicates the maximum number of hops through which a 293 message can pass. When that number of hops has been reached, the 294 message is assumed to have looped. 296 When a CPIM gateway relays an instant message, it decrements the 297 value of the MaxForwards attribute. This document does not mandate 298 any particular initial setting for the MaxForwards element in instant 299 messaging protocols, but it is recommended that the value be 300 reasonably large (over one hundred). 302 If a CPIM gateway receives an instant message operation that has a 303 MaxForwards attribute of 0, it discards the message and invokes a 304 failure operation. 306 4. Security Considerations 308 Detailed security considerations for instant messaging protocols are 309 given in RFC2779 (in particular, requirements are given in section 310 5.4 and some motivating discussion with 8.1). 312 CPIM defines an interoperability function that is employed by 313 gateways between instant messaging protocols. CPIM gateways MUST be 314 compliant with the minimum security requirements of the instant 315 messaging protocols with which they interface. 317 The introduction of gateways to the security model of instant 318 messaging in RFC2779 also introduces some new risks. End-to-end 319 security properties (especially confidentiality and integrity) 320 between instant messaging user agents that interface through a CPIM 321 gateway can only be provided if a common instant message format (such 322 as the format described in MSGFMT [4]) is supported by the protocols 323 interfacing with the CPIM gateway. 325 When end-to-end security is required, the message operation MUST use 326 MSGFMT, and MUST secure the MSGFMT MIME body with S/MIME [8], with 327 encryption (CMS EnvelopeData) and/or S/MIME signatures (CMS 328 SignedData). 330 The S/MIME algorithms are set by CMS [9]. The AES [10] algorithm 331 should be preferred, as it is expected that AES best suits the 332 capabilities of many platforms. Implementations MAY use AES as an 333 encryption algorithm, but are REQUIRED to support only the baseline 334 algorithms mandated by S/MIME and CMS. 336 When IM URIs are placed in instant messaging protocols, they convey 337 the identity of the sender and/or the recipient. Certificates that 338 are used for S/MIME IM operations SHOULD, for the purposes of 339 reference integrity, contain a subjectAltName field containing the IM 340 URI of their subject. Note that such certificates may also contain 341 other identifiers, including those specific to particular instant 342 messaging protocols. In order to further facilitate interoperability 343 of secure messaging through CPIM gateways, users and service 344 providers are encouraged to employ trust anchors for certificates 345 that are widely accepted rather than trust anchors specific to any 346 particular instant messaging service or provider. 348 In some cases, anonymous messaging may be desired. Such a capability 349 is beyond the scope of this specification. 351 5. IANA Considerations 353 The IANA assigns the "im" scheme. 355 5.1 The IM URI Scheme 357 The Instant Messaging (IM) URI scheme designates an Internet 358 resource, namely an INSTANT INBOX. 360 The syntax of an IM URI is given in Appendix A. 362 6. Contributors 364 Dave Crocker edited earlier versions of this document. 366 The following individuals made substantial textual contributions to 367 this document: 369 Athanassios Diacakis (thanos.diacakis@openwave.com) 371 Florencio Mazzoldi (flo@networkprojects.com) 373 Christian Huitema (huitema@microsoft.com) 375 Graham Klyne (gk@ninebynine.org) 377 Jonathan Rosenberg (jdrosen@dynamicsoft.com) 379 Robert Sparks (rsparks@dynamicsoft.com) 381 Hiroyasu Sugano (suga@flab.fujitsu.co.jp) 383 Normative References 385 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 386 levels", RFC 2119, March 1997. 388 [2] Crocker, D. and J. Peterson, "Address resolution for Instant 389 Messaging and Presence", draft-ietf-impp-srv-02 (work in 390 progress), February 2003. 392 [3] Resnick, P., "Internet Message Format", RFC 2822, STD 11, April 393 2001. 395 [4] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging: 396 Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in 397 progress), January 2003. 399 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 400 Instant Messaging", RFC 2778, February 2000. 402 [6] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 403 Presence Protocol Requirements", RFC 2779, February 2000. 405 [7] Allocchio, C., "GSTN Address Element Extensions in Email 406 Services", RFC 2846, June 2000. 408 [8] Ramsdell, B., "S/MIME Version 3 Message Specification", draft- 409 ietf-smime-rfc2633bis-03 (work in progress), January 2003. 411 [9] Housley, R., "Cryptographic Message Syntax", RFC 3369, August 412 2002. 414 Informative References 416 [10] Schaad, J., "Use of the Advanced Encryption Standard (AES) 417 Encryption Algorithm and in Cryptographic Message Syntax 418 (CMS)", RFC 3565, July 2003. 420 Author's Address 422 Jon Peterson 423 NeuStar, Inc. 424 1800 Sutter St 425 Suite 570 426 Concord, CA 94520 427 US 429 Phone: +1 925/363-8720 430 EMail: jon.peterson@neustar.biz 432 Appendix A. IM URI IANA Registration Template 434 This section provides the information to register the im: instant 435 messaging URI. 437 A.1 URI scheme name 439 im 441 A.2 URI scheme syntax 443 The syntax follows the existing mailto: URI syntax specified in 444 RFC2368. The ABNF is: 446 IM-URI = "im:" [ to ] [ headers ] 447 to = mailbox 448 headers = "?" header *( "&" header ) 449 header = hname "=" hvalue 450 hname = *urlc 451 hvalue = *urlc 453 A.3 Character encoding considerations 455 Representation of non-ASCII character sets in local-part strings is 456 limited to the standard methods provided as extensions to RFC2822 457 [3]. 459 A.4 Intended usage 461 Use of the im: URI follows closely usage of the mailto: URI. That 462 is, invocation of an IM URI will cause the user's instant messaging 463 application to start, with destination address and message headers 464 fill-in according to the information supplied in the URI. 466 A.5 Applications and/or protocols which use this URI scheme name 468 It is anticipated that protocols compliant with RFC2779, and meeting 469 the interoperability requirements specified here, will make use of 470 this URI scheme name. 472 A.6 Security considerations 474 See Section 4. 476 A.7 Relevant publications 478 RFC2779, RFC2778 480 A.8 Person & email address to contact for further information 482 Jon Peterson [mailto:jon.peterson@neustar.biz] 484 A.9 Author/Change controller 486 This scheme is registered under the IETF tree. As such, IETF 487 maintains change control. 489 A.10 Applications and/or protocols which use this URI scheme name 491 Instant messaging service 493 Appendix B. Issues of Interest 495 This appendix briefly discusses issues that may be of interest when 496 designing an interoperation gateway. 498 B.1 Address Mapping 500 When mapping the service described in this memo, mappings that place 501 special information into the im: address local-part MUST use the 502 meta-syntax defined in RFC2846 [7]. 504 B.2 Source-Route Mapping 506 The easiest mapping technique is a form of source- routing and 507 usually is the least friendly to humans having to type the string. 508 Source-routing also has a history of operational problems. 510 Use of source-routing for exchanges between different services is by 511 a transformation that places the entire, original address string into 512 the im: address local part and names the gateway in the domain part. 514 For example, if the destination INSTANT INBOX is "pepp://example.com/ 515 fred", then, after performing the necessary character conversions, 516 the resulting mapping is: 518 im:pepp=example.com/fred@relay-domain 520 where "relay-domain" is derived from local configuration information. 522 Experience shows that it is vastly preferable to hide this mapping 523 from end-users - if possible, the underlying software should perform 524 the mapping automatically. 526 Appendix C. Acknowledgments 528 The authors would like to acknowledge John Ramsdell for his comments, 529 suggestions and enthusiasm. Thanks to Derek Atkins for editorial 530 fixes. 532 Full Copyright Statement 534 Copyright (C) The Internet Society (2003). All Rights Reserved. 536 This document and translations of it may be copied and furnished to 537 others, and derivative works that comment on or otherwise explain it 538 or assist in its implementation may be prepared, copied, published 539 and distributed, in whole or in part, without restriction of any 540 kind, provided that the above copyright notice and this paragraph are 541 included on all such copies and derivative works. However, this 542 document itself may not be modified in any way, such as by removing 543 the copyright notice or references to the Internet Society or other 544 Internet organizations, except as needed for the purpose of 545 developing Internet standards in which case the procedures for 546 copyrights defined in the Internet Standards process must be 547 followed, or as required to translate it into languages other than 548 English. 550 The limited permissions granted above are perpetual and will not be 551 revoked by the Internet Society or its successors or assigns. 553 This document and the information contained herein is provided on an 554 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 555 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 556 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 557 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 558 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 560 Acknowledgement 562 Funding for the RFC Editor function is currently provided by the 563 Internet Society.