idnits 2.17.1 draft-ietf-impp-cpim-03.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 232: '...ing, a DNS lookup MUST be performed to...' RFC 2119 keyword, line 233: '... resolve the DOMAIN[3]. The names MUST be fully-qualified domain...' RFC 2119 keyword, line 241: '...ound for a given domain, a sender MUST...' RFC 2119 keyword, line 273: '...ions, the client MUST be able to try e...' RFC 2119 keyword, line 275: '... However, there MAY also be a configu...' (8 more instances...) 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 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, 2002) is 7924 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC-1766' on line 735 -- Looks like a reference, but probably isn't: 'RFC-2396' on line 739 == Unused Reference: '2' is defined on line 845, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 851, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 855, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 881, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2822 (ref. '2') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 2440 (ref. '5') (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. '6' == 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. '9') (Obsoleted by RFC 3850) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '11') Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg 4 Expires: February 12, 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 Fujistsu 16 J. Peterson 17 NeuStar 18 August 14, 2002 20 Common Presence and Instant Messaging (CPIM) 21 draft-ietf-impp-cpim-03 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 39 http://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 February 12, 2003. 46 Copyright Notice 48 Copyright (C) The Internet Society (2002). All Rights Reserved. 50 Abstract 52 Semantics and data formats for common services of Instant Messaging 53 and online Presence, independent of underlying transfer 54 infrastructure, are described. The CPIM profile meets the 55 requirements specified in RFC 2779 using a minimalist approach 56 allowing interoperation of a wide range of IM and Presence systems. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2 Note on the Examples . . . . . . . . . . . . . . . . . . . . 4 63 2. Abstract Instant Messaging Service . . . . . . . . . . . . . 6 64 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2 Identification of INSTANT INBOXes . . . . . . . . . . . . . 6 66 2.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . . 6 67 2.2.2 Domain Name Lookup . . . . . . . . . . . . . . . . . . . . . 7 68 2.2.3 Processing SRV RRs . . . . . . . . . . . . . . . . . . . . . 7 69 2.2.4 Processing Multiple Addresses . . . . . . . . . . . . . . . 7 70 2.3 Format of Instant Messages . . . . . . . . . . . . . . . . . 8 71 2.4 The Messaging Service . . . . . . . . . . . . . . . . . . . 8 72 2.4.1 The Message Operation . . . . . . . . . . . . . . . . . . . 8 73 2.4.2 Looping . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 3. Abstract Presence Service . . . . . . . . . . . . . . . . . 10 75 3.1 Overview of the Presence Service . . . . . . . . . . . . . . 10 76 3.2 Identification of PRESENTITIES . . . . . . . . . . . . . . . 12 77 3.3 Format of Presence Information . . . . . . . . . . . . . . . 12 78 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . . 12 79 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . . 12 80 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . . 14 81 3.4.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . . 14 82 3.4.4 The Fetch Operation . . . . . . . . . . . . . . . . . . . . 14 83 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 84 4.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 4.2 Hop-by-hop security . . . . . . . . . . . . . . . . . . . . 16 86 4.3 End-to-end security . . . . . . . . . . . . . . . . . . . . 16 87 4.3.1 Instant messages . . . . . . . . . . . . . . . . . . . . . . 17 88 4.3.2 Presence service . . . . . . . . . . . . . . . . . . . . . . 17 89 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 90 5.1 The IM URI Scheme . . . . . . . . . . . . . . . . . . . . . 18 91 5.2 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . . 18 92 6. Common Service DTD . . . . . . . . . . . . . . . . . . . . . 19 93 7. Message Service DTD . . . . . . . . . . . . . . . . . . . . 20 94 8. Presence Service DTD . . . . . . . . . . . . . . . . . . . . 21 95 9. Presence DTD . . . . . . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 97 A. Message/CPIM Profile for Instant Messaging . . . . . . . . . 27 98 B. Message/CPIM Profile for Presence . . . . . . . . . . . . . 28 99 C. IM URL IANA Registration Template . . . . . . . . . . . . . 29 100 C.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . . 29 101 C.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . . 29 102 C.3 Character encoding considerations . . . . . . . . . . . . . 29 103 C.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 29 104 C.5 Applications and/or protocols which use this URL scheme name 29 105 C.6 Interoperability considerations . . . . . . . . . . . . . . 29 106 C.7 Security considerations . . . . . . . . . . . . . . . . . . 30 107 C.8 Relevant publications . . . . . . . . . . . . . . . . . . . 30 108 C.9 Person & email address to contact for further information . 30 109 C.10 Author/Change controller . . . . . . . . . . . . . . . . . . 30 110 C.11 Applications and/or protocols which use this URL scheme name 30 111 D. PRES URL IANA Registration Template . . . . . . . . . . . . 31 112 D.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . . 31 113 D.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . . 31 114 D.3 Character encoding considerations . . . . . . . . . . . . . 31 115 D.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . . 31 116 D.5 Applications and/or protocols which use this URL scheme name 31 117 D.6 Interoperability considerations . . . . . . . . . . . . . . 31 118 D.7 Security considerations . . . . . . . . . . . . . . . . . . 32 119 D.8 Relevant publications . . . . . . . . . . . . . . . . . . . 32 120 D.9 Person & email address to contact for further information . 32 121 D.10 Author/Change controller . . . . . . . . . . . . . . . . . . 32 122 D.11 Applications and/or protocols which use this URL scheme name 32 123 E. Issues of Interest . . . . . . . . . . . . . . . . . . . . . 33 124 E.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . . 33 125 E.2 Source-Route Mapping . . . . . . . . . . . . . . . . . . . . 33 126 References . . . . . . . . . . . . . . . . . . . . . . . . . 23 127 F. Acknowledgemts . . . . . . . . . . . . . . . . . . . . . . . 34 128 Full Copyright Statement . . . . . . . . . . . . . . . . . . 35 130 1. Introduction 132 To achieve interoperation of IM and Presence systems that are 133 compliant with RFC 2779[10], there must be a common agreement on both 134 Instant Messaging and Presence services. This memo defines such an 135 agreement according to the philosophy that there must be no loss of 136 information between IM systems that are minimally conformant to 137 RFC2779. 139 This memo focuses on interoperation. Accordingly only those aspects 140 of Presence and IM that require interoperation are discussed. For 141 example, the "open instant inbox" operation is not applicable as this 142 operation occurs within a single IM system and not across systems. 144 Service behavior is described abstractly in terms of operations 145 invoked between the consumer and provider of a service. Accordingly, 146 each IM service must specify how this behavior is mapped onto its own 147 protocol interactions. The choice of strategy is a local matter, 148 providing that there is a clear relation between the abstract 149 behaviors of the service (as specified in this memo) and how it is 150 faithfully realized by a particular IM service. 152 The parameters for each operation are defined using an abstract 153 syntax. Although the syntax specifies the range of possible data 154 values, each Presence and IM service must specify how well-formed 155 instances of the abstract representation are encoded as a concrete 156 series of bits. 158 For example, one strategy might transmit presence information as 159 key/value pairs, another might use a compact binary representation, 160 and a third might use nested containers. The choice of strategy is a 161 local matter, providing that there is a clear relation between the 162 abstract syntax (as specified in this memo) and how it is faithfully 163 encoded by an particular Presence or IM service. 165 1.1 Terminology 167 This memos makes use of the vocabulary defined in RFC 2778[9]. Terms 168 such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN, PRESENCE 169 SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same 170 meaning as defined therein 172 1.2 Note on the Examples 174 In the examples that follow, this memo uses time- sequence diagrams 175 annotated with XML fragments to illustrate operations and their 176 parameters. The use of XML is an artifact of this memo's 177 presentation style and does not imply any requirement for the use of 178 XML in an IM system. 180 2. Abstract Instant Messaging Service 182 2.1 Overview 184 When an application wants to send a message to an INSTANT INBOX, it 185 invokes the message operation, e.g., 187 +-------+ +-------+ 188 | | | | 189 | appl. | -- message ------> | IM | 190 | | | svc. | 191 +-------+ +-------+ 193 196 ... 197 Content-Type: text/plain; charset="us-ascii" 199 Yabba, dabba, doo! 201 The service immediately responds by invoking the response operation 202 containing the same transaction- identifier, e.g., 204 +-------+ +-------+ 205 | | | | 206 | appl. | <----- response -- | IM | 207 | | | svc. | 208 +-------+ +-------+ 210 212 2.2 Identification of INSTANT INBOXes 214 An INSTANT INBOX is specified using an instant messaging URI with the 215 'im:' URI scheme. The full syntax of the IM URI scheme is given in 216 Appendix C. 218 2.2.1 Address Resolution 220 A client determines the address of an appropriate system running a 221 server by resolving the destination domain name that is part of the 222 identifier to either an intermediate relay system or a final target 223 system. 225 Only resolvable, fully-qualified, domain names (FQDNs) are permitted 226 when domain names are used in an IM URI (i.e., domain names that can 227 be resolved to SRV[11] or A RRs). 229 2.2.2 Domain Name Lookup 231 A client lexically identifies a domain to which instant messages will 232 be delivered for processing, a DNS lookup MUST be performed to 233 resolve the DOMAIN[3]. The names MUST be fully-qualified domain 234 names (FQDNs) -- mechanisms for inferring FQDNs from partial names or 235 local aliases are a local matter. 237 The lookup first attempts to locate SRV RRs associated with the 238 domain. If a CNAME RR is found instead, the resulting domain is 239 processed as if it were the initial domain. 241 If one or more SRV RRs are found for a given domain, a sender MUST 242 NOT utilize any A RRs associated with that domain unless they are 243 located using the SRV RRs. If no SRV RRs are found, but an A RR is 244 found, then the A RR is treated as if it was associated with an 245 implicit SRV RR, with a preference of 0, pointing to that domain. 247 2.2.3 Processing SRV RRs 249 To process an IM URI, a lookup is performed for SRVs for the target 250 domain and a desired IM transfer protocol. 252 For example, if the destination INSTANT INBOX is 253 "im:fred@example.com", and the sender wishes to use an IM transfer 254 protocol called "SIP", then a SRV lookup is performed for: 256 _im._sip.example.com. 258 The returned RRs, if any, specify the next-hop server. 260 The choice of IM transfer protocol is a local configuration option 261 for each system. 263 Using this mechanism, seamless routing of IM traffic is possible, 264 regardless of whether a gateway is necessary for interoperation. To 265 achieve this transparency, a separate RR for a gateway must be 266 present for each transfer protocol and domain pair that it serves. 268 2.2.4 Processing Multiple Addresses 270 When the lookup succeeds, the mapping can result in a list of 271 alternative delivery addresses rather than a single address, because 272 of multiple SRV records, multihoming, or both. For reliable 273 operations, the client MUST be able to try each of the relevant 274 addresses in this list in order, until a delivery attempt succeeds. 275 However, there MAY also be a configurable limit on the number of 276 alternate addresses that can be tried. In any case, the client 277 SHOULD try at least two addresses. Two types of information are used 278 to rank the domain addresses: multiple SRV records, and multihomed 279 domains. 281 Multiple SRV records contain a preference indication that MUST be 282 used in sorting. Lower numbers are preferable to higher ones. If 283 there are multiple destinations with the same preference, and there 284 is no clear reason to favor one (e.g., by recognition of an easily- 285 reached address), then the sender MUST randomize them to spread the 286 load across multiple servers for a specific destination. 288 The destination domain (perhaps taken from the preferred SRV record) 289 may be multihomed, in which case the resolver will return a list of 290 alternative IP addresses. It is the responsibility of the resolver 291 to have ordered this list by decreasing preference if necessary, and 292 the sender MUST try them in the order presented. 294 2.3 Format of Instant Messages 296 An INSTANT MESSAGE comprises a "message/cpim" MIME object, as defined 297 in CPIM MSGFMT and MESSAGE/CPIM PROFILE FOR INSTANT MESSAGING. 299 2.4 The Messaging Service 301 THE COMMON SERVICE DTD and THE MESSAGING SERVICE DTD define the 302 abstract syntax of the operations invoked with the service. 304 Note that the transaction-identifier parameters used with the service 305 are potentially long-lived. Accordingly, the values of transaction- 306 identifiers should appear to be unpredictable. 308 2.4.1 The Message Operation 310 When an application wants to send an INSTANT MESSAGE, it invokes the 311 message operation. 313 The message operation has these parameters: 315 o The source parameter specifies the INSTANT INBOX on whose behalf 316 this message is sent (using an IM URI); 318 o The destination parameter specifies the INSTANT INBOX that the 319 message should be delivered to (using an IM URI); 321 o The transID parameter specifies the transaction-identifier 322 associated with this operation; and, 324 o The message to be sent. 326 When the service is informed of the message operation, it performs 327 these steps: 329 1. If the source or destination does not refer to a valid INSTANT 330 INBOX, a response operation having status "failure" is invoked. 332 2. If access control does not permit the application to request this 333 operation, a response operation having status "failure" is 334 invoked. 336 3. Otherwise: 338 If the service is able to successfully deliver the message, a 339 response operation having status "success" is invoked. 341 If the service is unable to successfully deliver the message, 342 a response operation having status "failure" is invoked. 344 If the service must delegate responsibility for delivery, and 345 if the delegation will not result in a future authoritative 346 indication to the service, a response operation having status 347 "indeterminant" is invoked. 349 If the service must delegate responsibility for delivery, and 350 if the delegation will result in a future authoritative 351 indication to the service, then a response operation is 352 invoked immediately after the indication is received. 354 When the service invokes the response operation, the transID 355 parameter is identical to the value found in the message operation 356 invoked by the application. 358 2.4.2 Looping 360 The dynamic routing of instant messages can result in looping of a 361 message through a relay. Detection of loops is not always obvious, 362 since aliasing and group list expansions can legitimately cause a 363 message to pass through a relay more than one time. 365 Instant messaging uses a hop count mechanism, for detecting looping. 367 3. Abstract Presence Service 369 3.1 Overview of the Presence Service 371 When an application wants to (periodically) receive the presence 372 information associated with a PRESENTITY, it invokes the subscribe 373 operation, e.g., 375 +-------+ +-------+ 376 | | | | 377 | appl. | -- subscribe ----> | pres. | 378 | | | svc. | 379 +-------+ +-------+ 381 385 The service immediately responds by invoking the response operation 386 containing the same transaction- identifier, e.g., 388 +-------+ +-------+ 389 | | | | 390 | appl. | <----- response -- | pres. | 391 | | | svc. | 392 +-------+ +-------+ 394 396 A WATCHER may have at most one subscription for a PRESENTITY. 398 If the response operation indicates success, the service immediate 399 invokes the notify operation to communicate the presence information 400 to the WATCHER, e.g., 401 +-------+ +-------+ 402 | | | | 403 | appl. | <------- notify -- | pres. | 404 | | | svc. | 405 +-------+ +-------+ 407 410 411 413 414 416 If the duration parameter is non-zero, then for up to the specified 417 duration, the service invokes the notify operation whenever there are 418 any changes to the PRESENTITY's presence information. Otherwise, 419 exactly one notify operation is invoked, achieving a one-time poll of 420 the presence information. Regardless, there is no application 421 response to the notify operation (i.e., the application does not 422 invoke a response operation when a notify operation occurs). 424 The application may prematurely cancel a subscription by invoking the 425 unsubscribe operation, e.g., 427 +-------+ +-------+ 428 | | | | 429 | appl. | -- unsubscribe --> | pres. | 430 | | | svc. | 431 +-------+ +-------+ 433 437 The service immediately responds by invoking the response operation 438 containing the same transaction- identifier, e.g., 440 +-------+ +-------+ 441 | | | | 442 | appl. | <----- response -- | pres. | 443 | | | svc. | 444 +-------+ +-------+ 446 448 3.2 Identification of PRESENTITIES 450 A PRESENTITY is specified using the PRES URI scheme, which is further 451 described in Appendix D. 453 To resolve identifiers associated with the Presence service, the 454 mechanism defined in Section 2.2.1 is used, except that the 455 processing of a PRES URI is performed by looking up SRV RRs for a 456 desired presence transfer protocol. 458 For example, if the destination PRESENTITY is 459 "pres:fred@example.com", and the sender wishes to use a presence 460 transfer protocol called "PEPP", then a SRV lookup is performed for: 462 _pres._pepp.example.com. 464 3.3 Format of Presence Information 466 The format of a Presence message is a MIME "Message/cpim" object, as 467 defined in MESSAGE/CPIM PROFILE FOR PRESENCE and XML/MIME[6]. 469 3.4 The Presence Service 471 THE COMMON SERVICE DTD and THE PRESENCE SERVICE DTD define the 472 abstract syntax of the operations invoked with the service. 474 An implementation of the service must maintain information about both 475 presence information and in- progress operations in persistent 476 storage. 478 Note that the transaction-identifier parameter used with the service 479 is potentially long-lived. Accordingly, the values generated for 480 this parameter should appear to be unpredictable. 482 3.4.1 The Subscribe Operation 484 When an application wants to (periodically) receive the presence 485 information associated with an PRESENTITY, it invokes the subscribe 486 operation. 488 The subscribe operation has these parameters: 490 o The watcher parameter specifies the WATCHER associated with the 491 subscription; 493 o The target parameter specifies the PRESENTITY associated with the 494 presence information; 496 o The duration parameter specifies the maximum number of seconds 497 that the SUBSCRIPTION should be active; and, 499 o The transID parameter specifies the transaction-identifier 500 associated with this operation. 502 When the service is informed of the subscribe operation, it performs 503 these steps: 505 1. If the watcher or target parameter does not refer to a valid 506 PRESENTITY, a response operation having status "failure" is 507 invoked. 509 2. If access control does not permit the application to request this 510 operation, a response operation having status "failure" is 511 invoked. 513 3. If the duration parameter is non-zero, and if the watcher and 514 target parameters refer to an in-progress subscribe operation for 515 the application, a response operation having status "failure" is 516 invoked. 518 4. Otherwise: 520 If the service is able to successfully deliver the message, a 521 response operation having status "success" is invoked. 523 A response operation having status "success" is immediately 524 invoked. (If the service chooses a different duration for the 525 subscription then it conveys this information in the response 526 operation.) 528 A notify operation, corresponding to the target's presence 529 information, is immediately invoked for the watcher. 531 For up to the amount of time indicated by the duration 532 parameter, if the target's presence information changes, and 533 if access control allows, a notify operation is invoked for 534 the watcher. 536 Note that if the duration parameter is zero-valued, then the 537 subscribe operation is making a one-time poll of the presence 538 information. Accordingly, Step 4.3 above does not occur. 540 When the service invokes a response operation as a result of this 541 processing, the transID parameter is identical to the value found in 542 the subscribe operation invoked by the application. 544 3.4.2 The Notify Operation 546 The service invokes the notify operation whenever the presence 547 information associated with a PRESENTITY changes and there are 548 subscribers to that information. 550 The notify operation has these parameters: 552 o The watcher parameter specifies the WATCHER associated with the 553 subscription; 555 o The target parameter specifies the PRESENTITY associated with the 556 presence information; 558 o The transID parameter specifies the transaction-identifier 559 associated with this operation; and, 561 o The presence information for the PRESENTITY. 563 There is no application response to the notify operation. 565 3.4.3 The Unsubscribe Operation 567 When an application wants to terminate a subscription, it issues a 568 SUBSCRIBE 0 with the ID of an existing subscription. 570 There is no explicit UNSUBSCRIBE command. 572 3.4.4 The Fetch Operation 574 When an application wants to directly request presence information to 575 be supplied immediately, it issues a SUBSCRIBE 0 with a new 576 subscription ID. 578 There is no explicit FETCH command. 580 4. Security Considerations 582 This memo makes no specific requirements on security procedures for 583 interoperation between IM systems. Accordingly, trust between 584 interconnected IM systems is determined in a bilateral matter. 586 However this memo does require that each IM system control access to 587 its Instant Messaging and Presence services. Consult both RFC 2778 588 and RFC2779 for a discussion of security considerations for IM 589 systems. 591 4.1 Threats 593 Attacks, of concern for instant messaging, include access, deletion, 594 insertion, reordering and modification of messages by unauthorized 595 principals. Replay is a combination of a subset of these attacks. 597 These attacks can take place in the communication links between 598 sending client and its server, between two servers, between the 599 receiving client and its server, or by attacking any of the hosts 600 involved. This document, not being concerned with client-server 601 interchanges, only addresses threats aimed at server-server 602 communication. 604 Countermeasures against unauthorized access are encrypted 605 communication and encrypted messages. 607 Countermeasures against insertion of false messages are 608 authentication and authorization of sending servers and strongly 609 signed messages. 611 Countermeasures against reordered messages are date- stamped or 612 serial-numbered messages, coupled with digital signatures that 613 include the date or serial number, if modification is not otherwise 614 guarded against. 616 Countermeasures against replayed messages are date stamps and unique 617 message IDs, coupled with digital signatures that include the date or 618 serial number, if modification is not otherwise guarded against. 620 Countermeasures against deletion of messages are integrity-protected 621 connections between servers where the server's identity is verified. 622 Serial-numbered messages can also be useful in detecting deleted 623 messages. 625 Attacks that target the server hosts rather than the communication 626 channels can successfully defeat all countermeasures that depend on 627 host security. Digital signatures and encrypted messages do not 628 depend on host security, for intermediate systems, but cannot by 629 themselves guard against deletion or reordering of messages. 631 For presence, the attacks include giving presence information to 632 unauthorized watchers, not reporting watcher information back to a 633 presentity, and insertion, modification, deletion and replay of 634 presence update messages. The same set of countermeasures is 635 relevant. 637 Instant messaging and presence systems can provide security at two 638 levels: hop-by-hop and/or end-to-end. 640 4.2 Hop-by-hop security 642 A useful but imperfect level of security can be provided on a hop-by- 643 hop basis, with all aspects of the communication including message 644 content and originator verification, using transfer level security 645 between servers. The main drawback of this approach is that it 646 requires that each server that handles message or presence 647 information must be trusted. But it is relatively easy to deploy, 648 because it depends only on bilateral arrangements between directly 649 communicating servers. 651 The underlying principles for using hop-by-hop security are: 653 Each server and/or domain must keep their own house in order, 654 ensuring that operations and information accesses are allowed only 655 to appropriately authorized parties, and 657 Each server and/or domain must make its own choices about the 658 levels of trust to be established to any other server and/or 659 domain with which they directly communicate. 661 When passing IM and presence information between services using 662 different protocols, a gateway system MUST be capable of using 663 security mechanisms appropriate to each of the protocols concerned, 664 and must have access to keys needed to authenticate any other system 665 with which it needs to directly communicate in a secure fashion. 667 4.3 End-to-end security 669 End-to-end security is widely regarded as being more satisfactory 670 than hop-by-hop security, as the need to trust intermediate parties 671 is reduced. However, some aspects of end-to-end security are 672 difficult to achieve because they need bilateral arrangement between 673 any pair of communicating parties about acceptable security standards 674 to use, and key exchange. Reliance on bilateral agreements does not 675 scale well. A moderating alternative is a third-party certification 676 service and this approach, so far, has not found large-scale use. 678 The two IETF standards for end-to-end MIME object security are 679 OpenPGP[7] and S/MIME[8]. They require a public key operation for 680 each message. For repeated, short transactions, this overhead can be 681 onerous. A version of these specifications, which permitted re-use 682 of the public key across multiple messages, would greatly reduce 683 instant messaging overhead. 685 4.3.1 Instant messages 687 End to end security for instant messages can be provided using any of 688 the MIME-based security mechanisms (S/MIME [8], OpenPGP [7]), as 689 instant message payload content is not interpreted or reformatted in 690 transit. 692 This specification allows any pair of communicating parties to use 693 any MIME-based security framework for instant messages (c.f. section 694 2.3), but mechanisms for establishing the required bilateral 695 arrangements and key exchange are not specified here. 697 4.3.2 Presence service 699 End-to-end security for presence notifications and subscriptions 700 could be provided by any MIME-based security mechanism. 702 5. IANA Considerations 704 The IANA assigns the "im" and "pres" URL schemes. 706 5.1 The IM URI Scheme 708 The Instant Messaging (IM) URI scheme designates an Internet 709 resource, namely an INSTANT INBOX. 711 The syntax of an IM URL is given in Appendix C. 713 5.2 The PRES URI Scheme 715 The Presence (PRES) URI scheme designates an Internet resource, 716 namely a PRESENTITY or WATCHER. 718 The syntax of a PRES URL is given in Appendix D. 720 6. Common Service DTD 722 Note that the DTDs given in the following sections are used to 723 describe abstract information services, and do not alone provide a 724 complete description of an instant messaging and presence system. 726 733 741 742 743 744 745 746 753 7. Message Service DTD 755 762 765 %IMCOMMON; 769 770 771 773 778 8. Presence Service DTD 780 786 789 %IMCOMMON; 790 793 794 795 796 797 798 801 802 803 808 809 810 815 9. Presence DTD 817 824 827 %IMCOMMON; 828 831 832 833 834 835 836 840 References 842 [1] Crocker, D., "Standard for the format of ARPA Internet text 843 Messages", RFC 822, STD 11, August 1982. 845 [2] Resnick, P., "Internet Message Format", RFC 2822, STD 11, April 846 2001. 848 [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC 849 1034, STD 13, November 1987. 851 [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 852 Extensions (MIME) Part One: Format of Internet Message Bodies", 853 RFC 2045, November 1996. 855 [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 856 Message Format", RFC 2440, November 1998. 858 [6] Klyne, G., "XML Coding of RFC822 Messages", draft-klyne- 859 message-rfc822-xml-00 (work in progress), November 2001. 861 [7] Atkins, D. and G. Klyne, "Common Presence and Instant 862 Messaging: Message Format", draft-ietf-impp-cpim-msgfmt-05 863 (work in progress), December 2001. 865 [8] Sugano, H., "CPIM Presence Information Data Format", draft- 866 ietf-impp-cpim-pidf-00 (work in progress), August 2001. 868 [9] Ramsdell, B., "S/MIME Version 3 Certificate Handlng", RFC 2632, 869 June 1999. 871 [10] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 872 Instant Messaging", RFC 2778, February 2000. 874 [11] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 875 Presence Protocol Requirements", RFC 2779, February 2000. 877 [12] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 878 Specifying the Location of Services (SRV)", RFC 2782, February 879 2000. 881 [13] Allocchio, C., "GSTN Address Element Extensions in Email 882 Services", RFC 2846, June 2000. 884 Authors' Addresses 886 Dave Crocker 887 Brandenburg InternetWorking 888 675 Spruce Drive 889 Sunnyvale, CA 94086 890 US 892 Phone: +1 408/246-8253 893 EMail: dcrocker@brandenburg.com 895 Athanassios Diacakis 896 Network Projects Inc. 897 4516 Henry Street 898 Suite 113 899 Pittsburgh, PA 15213 900 US 902 Phone: +1 412/681-6950 x202 903 EMail: thanos@networkprojects.com 905 Florencio Mazzoldi 906 Network Projects Inc. 907 4516 Henry Street 908 Suite 113 909 Pittsburgh, PA 15213 910 US 912 Phone: +1 412/681-6950 913 EMail: flo@networkprojects.com 915 Christian Huitema 916 Microsoft Corporation 917 One Microsoft Way 918 Redmund, WA 98052-6399 919 US 921 EMail: huitema@microsoft.com 922 Graham Klyne 923 Baltimore Technologies 924 1310 Waterside 925 Arlington Business Park 926 Theale, Reading RG7 4SA 927 UK 929 Phone: +44 118 903 8000 930 EMail: gk@acm.org 932 Jonathan Rosenberg 933 dynamicsoft 934 200 Executive Drive 935 Suite 120 936 West Orange, NJ 07052 937 US 939 EMail: jdrosen@dynamicsoft.com 941 Robert Sparks 942 dynamicsoft 943 200 Executive Drive 944 Suite 120 945 West Orange, NJ 07052 946 US 948 EMail: rsparks@dynamicsoft.com 950 Hiroyasu Sugano 951 Fujitsu Laboratories Ltd. 952 200 Executive Drive 953 64 Nishiwaki, Ohkubo-cho 954 Akashi 674-8555 955 JP 957 EMail: suga@flab.fujitsu.co.jp 958 Jon Peterson 959 NeuStar, Inc. 960 1800 Sutter St 961 Suite 570 962 Concord, CA 94520 963 US 965 Phone: +1 925/363-8720 966 EMail: jon.peterson@neustar.biz 968 Appendix A. Message/CPIM Profile for Instant Messaging 970 Implicit default namespace URI: 971 urn:ietf:params:cpim-headers: 973 Message/CPIM headers that MUST be recognized and understood by an 974 instant messaging client: 976 From 978 To 980 cc 982 DateTime 984 Subject 986 Require 988 (Other headers, if present, may be ignored unless they are named in a 989 "Require" header.) 991 Message/CPIM headers that MUST be present in an instant message: 993 From 995 To 997 DateTime [[[?]]] 999 Subject [[[?]]] 1001 Appendix B. Message/CPIM Profile for Presence 1003 [Ed. - This section contains detail that creates a profile of 1004 Content-Type=Message/CPIM, to cover use for Presence transactions. 1005 Text to be partly extracted from draft- ietf-impp-cpim-pidf-00.txt.] 1007 Appendix C. IM URL IANA Registration Template 1009 This section provides the information to register the im: instant 1010 messaging URL. 1012 C.1 URL scheme name 1014 im 1016 C.2 URL scheme syntax 1018 The syntax follows the existing mailto: URL syntax specified in 1019 RFC2368. The ABNF is: 1021 IM-URL = "im:" [ to ] [ headers ] 1022 to = #mailbox 1023 headers = "?" header *( "&" header ) 1024 header = hname "=" hvalue 1025 hname = *urlc 1026 hvalue = *urlc 1028 C.3 Character encoding considerations 1030 Representation of non-ASCII character sets in local-part strings is 1031 limited to the standard methods provided as extensions to RFC 2822[1] 1033 C.4 Intended usage 1035 Use of the im: URL follows closely usage of the mailto: URL. That 1036 is, invocation of an IM URL will cause the user's instant messaging 1037 application to start, with destination address and message headers 1038 fill-in according to the information supplied in the URL. 1040 C.5 Applications and/or protocols which use this URL scheme name 1042 It is anticipated that protocols compliant with RFC2779, and meeting 1043 the interoperability requirements specified here, will make use of 1044 this URL scheme name. 1046 C.6 Interoperability considerations 1048 The underlying exchange protocol used to send an instant message may 1049 vary from service to service. Therefore complete, Internet-scale 1050 interoperability cannot be guaranteed. However, a service conforming 1051 to this specification permits gateways to achieve interoperability 1052 sufficient to the requirements of RFC2779. 1054 C.7 Security considerations 1056 When IM URLs are placed in instant messaging protocols, they convey 1057 the identity of the sender and/or the recipient. In some cases, 1058 anonymous messaging may be desired. Such a capability is beyond the 1059 scope of this specification. 1061 C.8 Relevant publications 1063 RFC2779, RFC2778 1065 C.9 Person & email address to contact for further information 1067 Jon Peterson [mailto:jon.peterson@neustar.biz] 1069 C.10 Author/Change controller 1071 This scheme is registered under the IETF tree. As such, IETF 1072 maintains change control. 1074 C.11 Applications and/or protocols which use this URL scheme name 1076 Instant messaging service; presence service 1078 Appendix D. PRES URL IANA Registration Template 1080 This section provides the information to register the pres: presence 1081 URL . 1083 D.1 URL scheme name 1085 pres 1087 D.2 URL scheme syntax 1089 The syntax follows the existing mailto: URL syntax specified in 1090 RFC2368. The ABNF is: 1092 PRES-URL = "pres:" [ to ] [ headers ] 1093 to = #mailbox 1094 headers = "?" header *( "&" header ) 1095 header = hname "=" hvalue 1096 hname = *urlc 1097 hvalue = *urlc 1099 D.3 Character encoding considerations 1101 Representation of non-ASCII character sets in local-part strings is 1102 limited to the standard methods provided as extensions to RFC 2822[1] 1104 D.4 Intended usage 1106 Use of the pres: URL follows closely usage of the mailto: URL. That 1107 is, invocation of an PRES URL will cause the user's instant messaging 1108 application to start, with destination address and message headers 1109 fill-in according to the information supplied in the URL. 1111 D.5 Applications and/or protocols which use this URL scheme name 1113 It is anticipated that protocols compliant with RFC2779, and meeting 1114 the interoperability requirements specified here, will make use of 1115 this URL scheme name. 1117 D.6 Interoperability considerations 1119 The underlying exchange protocol used to send an instant message may 1120 vary from service to service. Therefore complete, Internet-scale 1121 interoperability cannot be guaranteed. However, a service conforming 1122 to this specification permits gateways to achieve interoperability 1123 sufficient to the requirements of RFC2779. 1125 D.7 Security considerations 1127 When PRES URLs are placed in presence protocols, they convey the 1128 identity of the sender and/or the recipient. In some cases, 1129 anonymous messaging may be desired. Such a capability is beyond the 1130 scope of this specification. 1132 D.8 Relevant publications 1134 RFC2779, RFC2778 1136 D.9 Person & email address to contact for further information 1138 Jon Peterson [mailto:jon.peterson@neustar.biz] 1140 D.10 Author/Change controller 1142 This scheme is registered under the IETF tree. As such, IETF 1143 maintains change control. 1145 D.11 Applications and/or protocols which use this URL scheme name 1147 Instant messaging service; presence service 1149 Appendix E. Issues of Interest 1151 This appendix briefly discusses issues that may be of interest when 1152 designing an interoperation gateway. 1154 E.1 Address Mapping 1156 When mapping the service described in this memo, mappings that place 1157 special information into the im: address local-part MUST use the 1158 meta-syntax defined in RFC 2486[12]. 1160 E.2 Source-Route Mapping 1162 The easiest mapping technique is a form of source- routing and 1163 usually is the least friendly to humans having to type the string. 1164 Source-routing also has a history of operational problems. 1166 Use of source-routing for exchanges between different services is by 1167 a transformation that places the entire, original address string into 1168 the im: address local part and names the gateway in the domain part. 1170 For example, if the destination INSTANT INBOX is 1171 "pepp://example.com/fred", then, after performing the necessary 1172 character conversions, the resulting mapping is: 1174 im:pepp=example.com/fred@relay-domain 1176 where "relay-domain" is derived from local configuration information. 1178 Experience shows that it is vastly preferable to hide this mapping 1179 from end-users - if possible, the underlying software should perform 1180 the mapping automatically. 1182 Appendix F. Acknowledgemts 1183 Full Copyright Statement 1185 Copyright (C) The Internet Society (2002). All Rights Reserved. 1187 This document and translations of it may be copied and furnished to 1188 others, and derivative works that comment on or otherwise explain it 1189 or assist in its implementation may be prepared, copied, published 1190 and distributed, in whole or in part, without restriction of any 1191 kind, provided that the above copyright notice and this paragraph are 1192 included on all such copies and derivative works. However, this 1193 document itself may not be modified in any way, such as by removing 1194 the copyright notice or references to the Internet Society or other 1195 Internet organizations, except as needed for the purpose of 1196 developing Internet standards in which case the procedures for 1197 copyrights defined in the Internet Standards process must be 1198 followed, or as required to translate it into languages other than 1199 English. 1201 The limited permissions granted above are perpetual and will not be 1202 revoked by the Internet Society or its successors or assigns. 1204 This document and the information contained herein is provided on an 1205 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1206 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1207 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1208 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1209 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1211 Acknowledgement 1213 Funding for the RFC Editor function is currently provided by the 1214 Internet Society.