idnits 2.17.1 draft-ietf-impp-im-00.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([12]), 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 (October 27, 2002) is 7845 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: '3' is defined on line 318, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 321, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 324, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 327, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 331, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 334, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 341, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 344, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 350, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 353, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 357, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-impp-srv-00 ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2822 (ref. '4') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2440 (ref. '7') (Obsoleted by RFC 4880) == Outdated reference: A later version (-03) exists of draft-klyne-message-rfc822-xml-00 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-msgfmt-05 == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-pidf-00 ** Obsolete normative reference: RFC 2632 (ref. '11') (Obsoleted by RFC 3850) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '12') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '13') Summary: 9 errors (**), 0 flaws (~~), 18 warnings (==), 3 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: April 27, 2003 A. Diacakis 5 F. Mazzoldi 6 Net Proj 7 C. Huitema 8 Microsoft 9 G. Klyne 10 Baltimore 11 J. Rosenberg 12 R. Sparks 13 dynamicsoft 14 H. Sugano 15 Fujitsu 16 J. Peterson 17 NeuStar 18 October 27, 2002 20 Common Profile: Instant Messaging 21 draft-ietf-impp-im-00 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at http:// 39 www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 27, 2003. 46 Copyright Notice 48 Copyright (C) The Internet Society (2002). All Rights Reserved. 50 Abstract 52 Instant messaging is defined in RFC2778 [12]. Today, numerous 53 instant messaging protocols are in use, and little interoperability 54 between services based on these protocols has been achieved. This 55 specification defines common semantics and data formats for instant 56 messaging to facilitate the creation of gateways between instant 57 messaging services. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Abstract Instant Messaging Service . . . . . . . . . . . . . 4 64 3.1 Overview of Instant Messaging Service . . . . . . . . . . . 4 65 3.2 Identification of INSTANT INBOXes . . . . . . . . . . . . . 5 66 3.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 5 67 3.3 Format of Instant Messages . . . . . . . . . . . . . . . . . 5 68 3.4 The Messaging Service . . . . . . . . . . . . . . . . . . . 5 69 3.4.1 The Message Operation . . . . . . . . . . . . . . . . . . . 5 70 3.4.2 Looping . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4. Security Considerations . . . . . . . . . . . . . . . . . . 7 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 73 5.1 The IM URI Scheme . . . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 75 A. IM URL IANA Registration Template . . . . . . . . . . . . . 10 76 A.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . . 10 77 A.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . . 11 78 A.3 Character encoding considerations . . . . . . . . . . . . . 11 79 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 11 80 A.5 Applications and/or protocols which use this URL scheme 81 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 A.6 Interoperability considerations . . . . . . . . . . . . . . 11 83 A.7 Security considerations . . . . . . . . . . . . . . . . . . 11 84 A.8 Relevant publications . . . . . . . . . . . . . . . . . . . 12 85 A.9 Person & email address to contact for further information . 12 86 A.10 Author/Change controller . . . . . . . . . . . . . . . . . . 12 87 A.11 Applications and/or protocols which use this URL scheme 88 name . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 B. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 12 90 B.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 12 91 B.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 12 92 References . . . . . . . . . . . . . . . . . . . . . . . . . 7 93 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 94 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 96 1. Introduction 98 Instant messaging is defined in RFC2778 [12]. Today, numerous 99 instant messaging protocols are in use, and little interoperability 100 between services based on these protocols has been achieved. This 101 specification defines semantics and data formats for common services 102 of Instant Messaging to facilitate the creation of gateways between 103 instant messaging services. 105 Service behavior is described abstractly in terms of operations 106 invoked between the consumer and provider of a service. Accordingly, 107 each IM service must specify how this behavior is mapped onto its own 108 protocol interactions. The choice of strategy is a local matter, 109 providing that there is a clear relation between the abstract 110 behaviors of the service (as specified in this memo) and how it is 111 faithfully realized by a particular instant messaging service. 113 The attributes for each operation are defined using an abstract 114 syntax. Although the syntax specifies the range of possible data 115 values, each IM service must specify how well-formed instances of the 116 abstract representation are encoded as a concrete series of bits. 118 For example, one strategy might transmit an instant message as 119 textual key/value pairs, another might use a compact binary 120 representation, and a third might use nested containers. The choice 121 of strategy is a local matter, providing that there is a clear 122 relation between the abstract syntax (as specified in this memo) and 123 how it is faithfully encoded by an particular instant messaging 124 service. 126 In order to provide a means for the preservation of end-to-end 127 features (especially security) to pass through instant messaging 128 interoperability gateways, this specification also provides 129 recommendations for instant messaging document formats that could be 130 employed by presence protocols. 132 2. Terminology 134 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 135 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 136 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 137 described in RFC2119 [1] and indicate requirement levels for 138 compliant implementations. 140 This memos makes use of the vocabulary defined in RFC 2778[9]. Terms 141 such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in 142 the same meaning as defined therein. 144 This document defines operations and attributes of an instant 145 messaging service. In order for a protocol to interface with an 146 instant messaging gateway, it must support all of the operations 147 described in this document (i.e. the instant messaging protocol must 148 have some message or capability that provides the function described 149 by this operation). Similarly, the attributes defined for these 150 operations must correspond to information available in the instant 151 messaging protocol in order for the protocol to interface with 152 gateways defined by this specification. Note that these attributes 153 provide only the minimum possible information that needs to be 154 specified for interoperability - the functions in an instant 155 messaging protocol that correspond to the operations described in 156 this document can contain additional information that will not be 157 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, and TransID. 'source' and 'destination' identity the 174 originator and destination of an instant message, respectively, and 175 consist of an INSTANT INBOX identifier (as described in Section 3.2). 176 The TransID is a unique identifier used to correlate message 177 operations to response operations. 179 The message operation also has some content, the instant message 180 itself, which may be textual, or which may consist of other data. 181 Some further information on content is provided in Section 3.3. 183 Upon receiving a message operation, the service immediately responds 184 by invoking the response operation containing the same transaction- 185 identifier, e.g., 186 +-------+ +-------+ 187 | | | | 188 | appl. | <----- response -- | IM | 189 | | | svc. | 190 +-------+ +-------+ 192 The response operation contains the following attributes: TransID and 193 status. The TransID is used to correlate the response to a 194 particular instant message. Status indicates whether the delivery of 195 the message succeeded or failed. 197 3.2 Identification of INSTANT INBOXes 199 An INSTANT INBOX is specified using an instant messaging URI with the 200 'im:' URI scheme. The full syntax of the IM URI scheme is given in 201 Appendix A. An example would be: "im:fred@example.com" 203 3.2.1 Address Resolution 205 A client determines the address of an appropriate system running a 206 server by resolving the destination domain name that is part of the 207 identifier to either an intermediate relay system or a final target 208 system. 210 Compliant implementations SHOULD follow the guidelines for 211 dereferencing URIs given in [2]. 213 3.3 Format of Instant Messages 215 This specification defines an abstract interoperability mechanism for 216 instant messaging protocols; the message content definition given 217 here pertains to semantics rather than syntax. However, some 218 important properties for interoperability can only be provided if a 219 common end-to-end format for instant messaging is employed by the 220 interoperating instant messaging protocols. Implementations 221 therefore SHOULD support the format defined in MSGFMT [9]. 223 3.4 The Messaging Service 225 Note that the transaction-identifier parameters used with the instant 226 messaging service are potentially long-lived. Accordingly, the 227 values generated for this parameter should be unique across a 228 significant duration of time. 230 3.4.1 The Message Operation 232 When an application wants to send an INSTANT MESSAGE, it invokes the 233 message operation. 235 When the service is informed of the message operation, it performs 236 these steps: 238 1. If the source or destination does not refer to a valid INSTANT 239 INBOX, a response operation having status "failure" is invoked. 241 2. If access control does not permit the application to request this 242 operation, a response operation having status "failure" is 243 invoked. 245 3. Otherwise: 247 If the service is able to successfully deliver the message, a 248 response operation having status "success" is invoked. 250 If the service is unable to successfully deliver the message, 251 a response operation having status "failure" is invoked. 253 If the service must delegate responsibility for delivery, and 254 if the delegation will not result in a future authoritative 255 indication to the service, a response operation having status 256 "indeterminant" is invoked. 258 If the service must delegate responsibility for delivery, and 259 if the delegation will result in a future authoritative 260 indication to the service, then a response operation is 261 invoked immediately after the indication is received. 263 When the service invokes the response operation, the transID 264 parameter is identical to the value found in the message operation 265 invoked by the application. 267 3.4.2 Looping 269 The dynamic routing of instant messages can result in looping of a 270 message through a relay. Detection of loops is not always obvious, 271 since aliasing and group list expansions can legitimately cause a 272 message to pass through a relay more than one time. 274 Instant messaging protocols may implement a hop counter or similar 275 mechanism that gateways can use to detect loops, but CPIM does not 276 require protocols to support any corresponding attribute. If 277 possible, CPIM gateways should translate between such loop-detection 278 mechanisms. 280 4. Security Considerations 282 Detailed security considerations for instant messaging protocols are 283 given in RFC2779 (in particular, requirements are given in section 284 5.4 and some motivating discussion in 8.1). 286 CPIM defines an interoperability function that is employed by 287 gateways between instant messaging protocols. CPIM gateways MUST be 288 compliant with the minimum security requirements of the instant 289 messaging protocols with which they interface. 291 Note that end-to-end security properties (especially confidentiality 292 and integrity) between instant messaging user agents that interface 293 through a CPIM gateway can only be provided if a common instant 294 message format (such as the format described in [9]) is supported by 295 the protocols interfacing with the CPIM gateway. 297 5. IANA Considerations 299 The IANA assigns the "im" scheme. 301 5.1 The IM URI Scheme 303 The Instant Messaging (IM) URI scheme designates an Internet 304 resource, namely an INSTANT INBOX. 306 The syntax of an IM URL is given in Appendix A. 308 References 310 [1] Bradner, S., "Key words for use in RFCs to indicate requirement 311 levels", RFC 2119, March 1997. 313 [2] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, 314 G., Rosenberg, J., Sparks, R., Sugano, H. and J. Peterson, 315 "Address resolution for Instant Messaging and Presence", draft- 316 ietf-impp-srv-00 (work in progress), October 2002. 318 [3] Crocker, D., "Standard for the format of ARPA Internet text 319 Messages", RFC 822, STD 11, August 1982. 321 [4] Resnick, P., "Internet Message Format", RFC 2822, STD 11, April 322 2001. 324 [5] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 325 1034, STD 13, November 1987. 327 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 328 Extensions (MIME) Part One: Format of Internet Message Bodies", 329 RFC 2045, November 1996. 331 [7] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 332 Message Format", RFC 2440, November 1998. 334 [8] Klyne, G., "XML Coding of RFC822 Messages", draft-klyne- 335 message-rfc822-xml-00 (work in progress), November 2001. 337 [9] Atkins, D. and G. Klyne, "Common Presence and Instant 338 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-05 339 (work in progress), December 2001. 341 [10] Sugano, H., "CPIM Presence Information Data Format", draft- 342 ietf-impp-cpim-pidf-00 (work in progress), August 2001. 344 [11] Ramsdell, B., "S/MIME Version 3 Certificate Handlng", RFC 2632, 345 June 1999. 347 [12] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 348 Instant Messaging", RFC 2778, February 2000. 350 [13] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 351 Presence Protocol Requirements", RFC 2779, February 2000. 353 [14] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 354 Specifying the Location of Services (SRV)", RFC 2782, February 355 2000. 357 [15] Allocchio, C., "GSTN Address Element Extensions in Email 358 Services", RFC 2846, June 2000. 360 Authors' Addresses 362 Dave Crocker 363 Brandenburg InternetWorking 364 675 Spruce Drive 365 Sunnyvale, CA 94086 366 US 368 Phone: +1 408/246-8253 369 EMail: dcrocker@brandenburg.com 370 Athanassios Diacakis 371 Network Projects Inc. 372 4516 Henry Street 373 Suite 113 374 Pittsburgh, PA 15213 375 US 377 Phone: +1 412/681-6950 x202 378 EMail: thanos@networkprojects.com 380 Florencio Mazzoldi 381 Network Projects Inc. 382 4516 Henry Street 383 Suite 113 384 Pittsburgh, PA 15213 385 US 387 Phone: +1 412/681-6950 388 EMail: flo@networkprojects.com 390 Christian Huitema 391 Microsoft Corporation 392 One Microsoft Way 393 Redmund, WA 98052-6399 394 US 396 EMail: huitema@microsoft.com 398 Graham Klyne 399 Baltimore Technologies 400 1310 Waterside 401 Arlington Business Park 402 Theale, Reading RG7 4SA 403 UK 405 Phone: +44 118 903 8000 406 EMail: gk@acm.org 407 Jonathan Rosenberg 408 dynamicsoft 409 200 Executive Drive 410 Suite 120 411 West Orange, NJ 07052 412 US 414 EMail: jdrosen@dynamicsoft.com 416 Robert Sparks 417 dynamicsoft 418 200 Executive Drive 419 Suite 120 420 West Orange, NJ 07052 421 US 423 EMail: rsparks@dynamicsoft.com 425 Hiroyasu Sugano 426 Fujitsu Laboratories Ltd. 427 200 Executive Drive 428 64 Nishiwaki, Ohkubo-cho 429 Akashi 674-8555 430 JP 432 EMail: suga@flab.fujitsu.co.jp 434 Jon Peterson 435 NeuStar, Inc. 436 1800 Sutter St 437 Suite 570 438 Concord, CA 94520 439 US 441 Phone: +1 925/363-8720 442 EMail: jon.peterson@neustar.biz 444 Appendix A. IM URL IANA Registration Template 446 This section provides the information to register the im: instant 447 messaging URL. 449 A.1 URL scheme name 451 im 453 A.2 URL scheme syntax 455 The syntax follows the existing mailto: URL syntax specified in 456 RFC2368. The ABNF is: 458 IM-URL = "im:" [ to ] [ headers ] 459 to = #mailbox 460 headers = "?" header *( "&" header ) 461 header = hname "=" hvalue 462 hname = *urlc 463 hvalue = *urlc 465 A.3 Character encoding considerations 467 Representation of non-ASCII character sets in local-part strings is 468 limited to the standard methods provided as extensions to RFC 2822[1] 470 A.4 Intended usage 472 Use of the im: URL follows closely usage of the mailto: URL. That 473 is, invocation of an IM URL will cause the user's instant messaging 474 application to start, with destination address and message headers 475 fill-in according to the information supplied in the URL. 477 A.5 Applications and/or protocols which use this URL scheme name 479 It is anticipated that protocols compliant with RFC2779, and meeting 480 the interoperability requirements specified here, will make use of 481 this URL scheme name. 483 A.6 Interoperability considerations 485 The underlying exchange protocol used to send an instant message may 486 vary from service to service. Therefore complete, Internet-scale 487 interoperability cannot be guaranteed. However, a service conforming 488 to this specification permits gateways to achieve interoperability 489 sufficient to the requirements of RFC2779. 491 A.7 Security considerations 493 When IM URLs are placed in instant messaging protocols, they convey 494 the identity of the sender and/or the recipient. In some cases, 495 anonymous messaging may be desired. Such a capability is beyond the 496 scope of this specification. 498 A.8 Relevant publications 500 RFC2779, RFC2778 502 A.9 Person & email address to contact for further information 504 Jon Peterson [mailto:jon.peterson@neustar.biz] 506 A.10 Author/Change controller 508 This scheme is registered under the IETF tree. As such, IETF 509 maintains change control. 511 A.11 Applications and/or protocols which use this URL scheme name 513 Instant messaging service 515 Appendix B. Issues of Interest 517 This appendix briefly discusses issues that may be of interest when 518 designing an interoperation gateway. 520 B.1 Address Mapping 522 When mapping the service described in this memo, mappings that place 523 special information into the im: address local-part MUST use the 524 meta-syntax defined in RFC 2846[12]. 526 B.2 Source-Route Mapping 528 The easiest mapping technique is a form of source- routing and 529 usually is the least friendly to humans having to type the string. 530 Source-routing also has a history of operational problems. 532 Use of source-routing for exchanges between different services is by 533 a transformation that places the entire, original address string into 534 the im: address local part and names the gateway in the domain part. 536 For example, if the destination INSTANT INBOX is "pepp://example.com/ 537 fred", then, after performing the necessary character conversions, 538 the resulting mapping is: 540 im:pepp=example.com/fred@relay-domain 542 where "relay-domain" is derived from local configuration information. 544 Experience shows that it is vastly preferable to hide this mapping 545 from end-users - if possible, the underlying software should perform 546 the mapping automatically. 548 Appendix C. Acknowledgments 549 Full Copyright Statement 551 Copyright (C) The Internet Society (2002). All Rights Reserved. 553 This document and translations of it may be copied and furnished to 554 others, and derivative works that comment on or otherwise explain it 555 or assist in its implementation may be prepared, copied, published 556 and distributed, in whole or in part, without restriction of any 557 kind, provided that the above copyright notice and this paragraph are 558 included on all such copies and derivative works. However, this 559 document itself may not be modified in any way, such as by removing 560 the copyright notice or references to the Internet Society or other 561 Internet organizations, except as needed for the purpose of 562 developing Internet standards in which case the procedures for 563 copyrights defined in the Internet Standards process must be 564 followed, or as required to translate it into languages other than 565 English. 567 The limited permissions granted above are perpetual and will not be 568 revoked by the Internet Society or its successors or assigns. 570 This document and the information contained herein is provided on an 571 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 572 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 573 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 574 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 575 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 577 Acknowledgement 579 Funding for the RFC Editor function is currently provided by the 580 Internet Society.