idnits 2.17.1 draft-ietf-impp-cpim-01.txt: -(233): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 21 instances of lines with control characters in the document. ** 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 211: '... 822[1] (i.e., "local@domain") is used, where the local-part MUST be...' RFC 2119 keyword, line 231: '...ing, a DNS lookup MUST be performed to...' RFC 2119 keyword, line 232: '... resolve the domain[2]. The names MUST be fully-qualified domain names...' RFC 2119 keyword, line 240: '...ound for a given domain, a sender MUST...' RFC 2119 keyword, line 272: '...ions, the client MUST be able to try e...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 105 has weird spacing: '...further infor...' == Line 119 has weird spacing: '...further infor...' == Line 997 has weird spacing: '...tion of servi...' == Line 1116 has weird spacing: '... scheme name...' == Line 1128 has weird spacing: '...ient to the r...' == (6 more instances...) -- 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 (November 2000) is 8563 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) -- Looks like a reference, but probably isn't: 'RFC-1766' on line 809 -- Looks like a reference, but probably isn't: 'RFC-2396' on line 818 == Unused Reference: '3' is defined on line 977, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '1') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2440 (ref. '4') (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. '5' ** Obsolete normative reference: RFC 2632 (ref. '6') (Obsoleted by RFC 3850) ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '8') Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 5 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 Consulting 4 Expires: May 2, 2001 A. Diacakis 5 F. Mazzoldi 6 Network Projects Inc. 7 C. Huitema 8 Microsoft Corporation 9 G. Klyne 10 Content Technologies 11 M. Rose 12 Invisible Worlds 13 J. Rosenberg 14 R. Sparks 15 dynamicsoft 16 H. Sugano 17 Fujitsu Laboratories Ltd. 18 November 2000 20 A Common Profile for Instant Messaging (CPIM) 21 draft-ietf-impp-cpim-01 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 other 30 groups may also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on May 2, 2001. 45 Copyright Notice 47 Copyright (C) The Internet Society (2000). All Rights Reserved. 49 Abstract 50 Semantics and data formats for common services of Instant Messaging 51 and online Presence, independent of underlying transport 52 infrastructure, are described. The CPIM profile meets the 53 requirements specified in RFC 2779 using a minimalist approach 54 allowing interoperation of a wide range of IM and Presence systems. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2 A Note on The Examples . . . . . . . . . . . . . . . . . . 4 61 2. Abstract Messaging Service . . . . . . . . . . . . . . . . 5 62 2.1 Overview of the Messaging Service . . . . . . . . . . . . 5 63 2.2 Identification of INSTANT INBOXes . . . . . . . . . . . . 6 64 2.2.1 Address Resolution . . . . . . . . . . . . . . . . . . . . 6 65 2.2.1.1 Domain Name Lookup . . . . . . . . . . . . . . . . . . . . 6 66 2.2.1.2 Processing SRV RRs . . . . . . . . . . . . . . . . . . . . 7 67 2.2.1.3 Processing Multiple Addresses . . . . . . . . . . . . . . 7 68 2.3 Format of Instant Messages . . . . . . . . . . . . . . . . 8 69 2.4 The Messaging Service . . . . . . . . . . . . . . . . . . 9 70 2.4.1 The Message Operation . . . . . . . . . . . . . . . . . . 9 71 2.4.2 Looping . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3. Abstract Presence Service . . . . . . . . . . . . . . . . 11 73 3.1 Overview of the Presence Service . . . . . . . . . . . . . 11 74 3.2 Identification of PRESENTITIES . . . . . . . . . . . . . . 14 75 3.3 Format of Presence Information . . . . . . . . . . . . . . 15 76 3.4 The Presence Service . . . . . . . . . . . . . . . . . . . 16 77 3.4.1 The Subscribe Operation . . . . . . . . . . . . . . . . . 16 78 3.4.2 The Notify Operation . . . . . . . . . . . . . . . . . . . 18 79 3.4.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . 19 80 4. Security Considerations . . . . . . . . . . . . . . . . . 20 81 4.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 4.2 Hop-by-hop security . . . . . . . . . . . . . . . . . . . 21 83 4.3 End-to-end security . . . . . . . . . . . . . . . . . . . 22 84 4.3.1 Instant messages . . . . . . . . . . . . . . . . . . . . . 22 85 4.3.2 Presence service . . . . . . . . . . . . . . . . . . . . . 22 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 23 87 5.1 The IM URI Scheme . . . . . . . . . . . . . . . . . . . . 23 88 5.2 The PRES URI Scheme . . . . . . . . . . . . . . . . . . . 23 89 6. The Common Service DTD . . . . . . . . . . . . . . . . . . 24 90 7. The Messaging Service DTD . . . . . . . . . . . . . . . . 25 91 8. The Presence Service DTD . . . . . . . . . . . . . . . . . 26 92 9. The Presence Information DTD . . . . . . . . . . . . . . . 28 93 References . . . . . . . . . . . . . . . . . . . . . . . . 29 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 29 95 A. IM URL IANA Registration Template . . . . . . . . . . . . 32 96 A.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . 32 97 A.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . 32 98 A.3 Character encoding considerations . . . . . . . . . . . . 32 99 A.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 32 100 A.5 Applications and/or protocols which use this URL scheme 101 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 102 A.6 Interoperability considerations . . . . . . . . . . . . . 32 103 A.7 Security considerations . . . . . . . . . . . . . . . . . 33 104 A.8 Relevant publications . . . . . . . . . . . . . . . . . . 33 105 A.9 Person & email address to contact for further information 33 106 A.10 Author/Change controller . . . . . . . . . . . . . . . . . 33 107 A.11 Applications and/or protocols which use this URL scheme 108 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 109 B. PRES URL IANA Registration Template . . . . . . . . . . . 34 110 B.1 URL scheme name . . . . . . . . . . . . . . . . . . . . . 34 111 B.2 URL scheme syntax . . . . . . . . . . . . . . . . . . . . 34 112 B.3 Character encoding considerations . . . . . . . . . . . . 34 113 B.4 Intended usage . . . . . . . . . . . . . . . . . . . . . . 34 114 B.5 Applications and/or protocols which use this URL scheme 115 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 116 B.6 Interoperability considerations . . . . . . . . . . . . . 34 117 B.7 Security considerations . . . . . . . . . . . . . . . . . 35 118 B.8 Relevant publications . . . . . . . . . . . . . . . . . . 35 119 B.9 Person & email address to contact for further information 35 120 B.10 Author/Change controller . . . . . . . . . . . . . . . . . 35 121 B.11 Applications and/or protocols which use this URL scheme 122 name . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 123 C. Issues of Interest . . . . . . . . . . . . . . . . . . . . 36 124 C.1 Address Mapping . . . . . . . . . . . . . . . . . . . . . 36 125 C.1.1 Source-Route Mapping . . . . . . . . . . . . . . . . . . . 36 126 Full Copyright Statement . . . . . . . . . . . . . . . . . 37 128 1. Introduction 130 To achieve interoperation of IM systems that are compliant with RFC 131 2779[8], there must be a common agreement on both Instant Messaging 132 and Presence services. This memo defines such an agreement according 133 to the philosophy that there must be no loss of information between 134 IM systems that are minimally conformant to RFC2779. 136 This memo focuses on interoperation. Accordingly only those aspects 137 of IM that require interoperation are discussed. For example, the 138 "open instant inbox" operation is not applicable as this operation 139 occurs within a single IM system and not across systems. 141 Service behavior is described abstractly in terms of operations 142 invoked between the consumer and provider of a service. Accordingly, 143 each IM service must specify how this behavior is mapped onto its own 144 protocol interactions. The choice of strategy is a local matter, 145 providing that there is a clear relation between the abstract 146 behavior of the service (as specified in this memo) and how it is 147 faithfully realized by a particular IM service. 149 The parameters for each operation are defined using an abstract 150 syntax. Although the syntax specifies the range of possible data 151 values, each IM service must specify how well-formed instances of the 152 abstract representation are encoded as a concrete series of bits. 154 For example, one strategy might transmit presence information as 155 key/value pairs, another might use a compact binary representation, 156 and a third might use nested containers. The choice of strategy is a 157 local matter, providing that there is a clear relation between the 158 abstract syntax (as specified in this memo) and how it is faithfully 159 encoded by an particular IM service. 161 1.1 Terminology 163 This memos makes use of the vocabulary defined in RFC 2778[7]. Terms 164 such as as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN, PRESENCE 165 SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same 166 meaning as defined therein. 168 1.2 A Note on The Examples 170 In the examples which follow, this memo uses time-sequence diagrams 171 annotated with XML fragments to illustrate operations and their 172 parameters. The use of XML is an artifact of this memo's presentation 173 style and does not imply any requirement for the use of XML in an IM 174 system. 176 2. Abstract Messaging Service 178 2.1 Overview of the Messaging Service 180 When an application wants to send a message to an INSTANT INBOX, it 181 invokes the message operation, e.g., 183 +-------+ +-------+ 184 | | | | 185 | appl. | -- message ------> | IM | 186 | | | svc. | 187 +-------+ +-------+ 189 192 ... 193 Content-Type: text/plain; charset="us-ascii" 195 Yabba, dabba, doo! 197 The service immediately responds by invoking the response operation 198 containing the same transaction-identifier, e.g., 200 +-------+ +-------+ 201 | | | | 202 | appl. | <----- response -- | IM | 203 | | | svc. | 204 +-------+ +-------+ 206 208 2.2 Identification of INSTANT INBOXes 210 An INSTANT INBOX is specified using the IM URI (Section 5.1)f RFC 211 822[1] (i.e., "local@domain") is used, where the local-part MUST be 212 interpreted and assigned semantics only by the system specified in 213 the domain part of the identifier. Representation of non-ASCII 214 character sets in local-part strings is limited to the standard 215 methods provided as extensions to RFC 822[1] 217 2.2.1 Address Resolution 219 A client determines the address of an appropriate system running a 220 server by resolving the destination domain name that is part of the 221 identifier to either an intermediate relay system or a final target 222 system. 224 Only resolvable, fully-qualified, domain names (FQDNs) are permitted 225 when domain names are used in the messaging service (i.e., domain 226 names that can be resolved to SRV[9] or A RRs). 228 2.2.1.1 Domain Name Lookup 230 A client lexically identifies a domain to which instant messages will 231 be delivered for processing, a DNS lookup MUST be performed to 232 resolve the domain[2]. The names MUST be fully-qualified domain names 233 (FQDNs) �� mechanisms for inferring FQDNs from partial names or local 234 aliases are a local matter. 236 The lookup first attempts to locate SRV RRs associated with the 237 domain. If a CNAME RR is found instead, the resulting domain is 238 processed as if it were the initial domain. 240 If one or more SRV RRs are found for a given domain, a sender MUST 241 NOT utilize any A RRs associated with that domain unless they are 242 located using the SRV RRs; otherwise, if no SRV RRs are found, but an 243 A RR is found, then the A RR is treated as if it was associated with 244 an implicit SRV RR, with a preference of 0, pointing to that host. 246 2.2.1.2 Processing SRV RRs 248 To process an IM URI, a lookup is performed for SRVs for the target 249 domain and a desired IM transport protocol. 251 For example, if the destination INSTANT INBOX is 252 "im:fred@example.com", and the sender wishes to use an IM transport 253 protocol called "SIP", then a SRV lookup is performed for: 255 _im._sip.example.com. 257 The returned RRs, if any, specify the next-hop server. 259 The choice of IM transport protocol is a local configuration option 260 for each system. 262 Using this mechanism, seamless routing of IM traffic is possible, 263 regardless of whether a gateway is necessary for interoperation. To 264 achieve this transparency, a seperate RR for a gateway must be 265 present for each transport protocol and domain pair that it serves. 267 2.2.1.3 Processing Multiple Addresses 269 When the lookup succeeds, the mapping can result in a list of 270 alternative delivery addresses rather than a single address, because 271 of multiple SRV records, multihoming, or both. For reliable 272 operations, the client MUST be able to try each of the relevant 273 addresses in this list in order, until a delivery attempt succeeds. 274 However, there MAY also be a configurable limit on the number of 275 alternate addresses that can be tried. In any case, the client SHOULD 276 try at least two addresses. Two types of information are used to rank 277 the host addresses: multiple SRV records, and multihomed hosts. 279 Multiple SRV records contain a preference indication that MUST be 280 used in sorting. Lower numbers are preferrable to higher ones. If 281 there are multiple destinations with the same preference, and there 282 is no clear reason to favor one (e.g., by recognition of an easily- 283 reached address), then the sender MUST randomize them to spread the 284 load across multiple servers for a specific destination. 286 The destination host (perhaps taken from the preferred SRV record) 287 may be multihomed, in which case the resolver will return a list of 288 alternative IP addresses. It is the responsibility of the resolver to 289 have ordered this list by decreasing preference if necessary, and the 290 sender MUST try them in the order presented. 292 2.3 Format of Instant Messages 294 An INSTANT MESSAGE comprises a MIME Multipart/Related, 295 Type=message/RFC822+XML object, as defined in XML/MIME[5]. 296 Representation of non-ASCII character sets in MIME is a standard 297 feature of MIME. 299 Note that the IETF provides numerous technologies that allow end- 300 users to exchange authenticated and private messages formatted as 301 MIME objects, c.f., PGP-MIME[4] and S/MIME[6]. 303 2.4 The Messaging Service 305 Section 6 and Section 7 define the abstract syntax of the operations 306 invoked with the service. 308 Note that the transaction-identifier parameters used with the service 309 are potentially long-lived. Accordingly, the values of transaction- 310 identifiers should appear to be unpredictable. 312 2.4.1 The Message Operation 314 When an application wants to send an INSTANT MESSAGE, it invokes the 315 message operation. 317 The message operation has these parameters: 319 o the source parameter specifies the INSTANT INBOX on whose behalf 320 this message is sent (using an IM URI); 322 o the destination parameter specifies the INSTANT INBOX that the 323 message should be delivered to (using an IM URI); 325 o the transID parameter specifies the transaction-identifier 326 associated with this operation; and, 328 o the message to be sent. 330 When the service is informed of the message operation, it performs 331 these steps: 333 1. If the source or destination does not refer to a valid INSTANT 334 INBOX, a response operation having status "failure" is invoked. 336 2. If access control does not permit the application to request this 337 operation, a response operation having status "failure" is 338 invoked. 340 3. Otherwise: 342 1. If the service is able to successfully deliver the message, a 343 response operation having status "success" is invoked. 345 2. If the service is unable to successfully deliver the message, 346 a response operation having status "failure" is invoked. 348 3. If the service must delegate responsibility for delivery, and 349 if the delegation will not result in a future authoritative 350 indication to the service, a response operation having status 351 "indeterminant" is invoked. 353 4. If the service must delegate responsibility for delivery, and 354 if the delegation will result in a future authoritative 355 indication to the service, then a response operation is 356 invoked immediately after the indication is received. 358 When the service invokes the response operation, the transID 359 parameter is identical to the value found in the message operation 360 invoked by the application. 362 2.4.2 Looping 364 The dynamic routing of instant messages can result in looping of a 365 message through a relay. Detection of loops is not always obvious, 366 since aliasing and group list expansions can legitimately cause a 367 message to pass through a relay more than one time. 369 [[[ In Internet Mail, counting the number of Received headers is the 370 accepted technique for guessing that looping is occurring. Use of 371 this technique will require Instant Messaging to support Received 372 headers. /editor ]]] 374 3. Abstract Presence Service 376 3.1 Overview of the Presence Service 378 When an application wants to (periodically) receive the presence 379 information associated with a PRESENTITY, it invokes the subscribe 380 operation, e.g., 382 +-------+ +-------+ 383 | | | | 384 | appl. | -- subscribe ----> | pres. | 385 | | | svc. | 386 +-------+ +-------+ 388 392 The service immediately responds by invoking the response operation 393 containing the same transaction-identifier, e.g., 395 +-------+ +-------+ 396 | | | | 397 | appl. | <----- response -- | pres. | 398 | | | svc. | 399 +-------+ +-------+ 401 403 A WATCHER may have at most one subscription for a PRESENTITY. 405 If the response operation indicates success, the service immediate 406 invokes the notify operation to communicate the presence information 407 to the WATCHER, e.g., 409 +-------+ +-------+ 410 | | | | 411 | appl. | <------- notify -- | pres. | 412 | | | svc. | 413 +-------+ +-------+ 415 418 419 421 422 424 If the duration parameter is non-zero, then for up to the specified 425 duration, the service invokes the notify operation whenever there are 426 any changes to the PRESENTITY's presence information. Otherwise, 427 exactly one notify operation is invoked, achieving a one time poll of 428 the presence information. Regardless, there is no application 429 response to the notify operation (i.e., the application does not 430 invoke a response operation when a notify operation occurs). 432 The application may prematurely cancel a subscription by invoking the 433 unsubscribe operation, e.g., 435 +-------+ +-------+ 436 | | | | 437 | appl. | -- unsubscribe --> | pres. | 438 | | | svc. | 439 +-------+ +-------+ 441 445 The service immediately responds by invoking the response operation 446 containing the same transaction-identifier, e.g., 448 +-------+ +-------+ 449 | | | | 450 | appl. | <----- response -- | pres. | 451 | | | svc. | 452 +-------+ +-------+ 454 456 3.2 Identification of PRESENTITIES 458 A PRESENTITY is specified using the PRES URI (Section 5.2) scheme. 459 Briefly, the "addr-spec" syntax of RFC 822[1] (i.e., "local@domain") 460 is used, where the local-part MUST be interpreted and assigned 461 semantics only by the host specified in the domain part of the 462 identifier. Representation of non-ASCII character sets in local-part 463 strings is limited to the standard methods provided as extensions to 464 RFC 822[1] 466 To resolve identifiers associated with the Presence service, the 467 mechanism defined in Section 2.2.1 is used, except that the 468 processing of a PRES URI is performed by looking up SRV RRs for a 469 desired presence transport protocol. 471 For example, if the destination PRESENTITY is 472 "pres:fred@example.com", and the sender wishes to use a presence 473 transport protocol called "PEPP", then a SRV lookup is performed for: 475 _pres._pepp.example.com. 477 3.3 Format of Presence Information 479 Section 9 defines the syntax for presence information using an XML 480 DTD. 482 Each PRESENTITY's presence information contains an "entityInfo" 483 attribute, and contains one or more "tuple" elements: 485 o the "entityInfo" attribute specifies arbitrary information about 486 the PRESENTITY (using a URI); and, 488 o each "tuple" element specifies information associated with the 489 PRESENTITY. 491 Each "tuple" element has a "destination" attribute, a "status" 492 attribute, and contains arbitrary content: 494 o the "destination" attribute specifies a URI; 496 o the "status" attribute is either OPEN or CLOSED; and, 498 o the content of the "tuple" element contains arbitrary information 499 about the tuple. 501 3.4 The Presence Service 503 Section 6 and Section 8 define the abstract syntax of the operations 504 invoked with the service. 506 An implementation of the service must maintain information about both 507 presence information and in-progress operations in persistent 508 storage. 510 Note that the transaction-identifier parameter used with the service 511 is potentially long-lived. Accordingly, the values generated for this 512 parameter should appear to be unpredictable. 514 3.4.1 The Subscribe Operation 516 When an application wants to (periodically) receive the presence 517 information associated with an PRESENTITY, it invokes the subscribe 518 operation. 520 The subscribe operation has these parameters: 522 o the watcher parameter specifies the WATCHER associated with the 523 subscription; 525 o the target parameter specifies the PRESENTITY associated with the 526 presence information; 528 o the duration parameter specifies the maximum number of seconds 529 that the SUBSCRIPTION should be active; and, 531 o the transID parameter specifies the transaction-identifier 532 associated with this operation. 534 When the service is informed of the subscribe operation, it performs 535 these steps: 537 1. If the watcher or target parameter does not refer to a valid 538 PRESENTITY, a response operation having status "failure" is 539 invoked. 541 2. If access control does not permit the application to request this 542 operation, a response operation having status "failure" is 543 invoked. 545 3. If the duration parameter is non-zero, and if the watcher and 546 target parameters refer to an in-progress subscribe operation for 547 the application, a response operation having status "failure" is 548 invoked. 550 4. Otherwise: 552 1. A response operation having status "success" is immediately 553 invoked. (If the service chooses a different duration for the 554 subscription then it conveys this information in the response 555 operation.) 557 2. A notify operation, corresponding to the target's presence 558 information, is immediately invoked for the watcher. 560 3. For up to the amount of time indicated by the duration 561 parameter, if the target's presence information changes, and 562 if access control allows, a notify operation is invoked for 563 the watcher. 565 Note that if the duration parameter is zero-valued, then the 566 subscribe operation is making a one-time poll of the presence 567 information. Accordingly, Step 4.3 above does not occur. 569 When the service invokes a response operation as a result of this 570 processing, the transID parameter is identical to the value found in 571 the subscribe operation invoked by the application. 573 3.4.2 The Notify Operation 575 The service invokes the notify operation whenever the presence 576 information associated with a PRESENTITY changes and there are 577 subscribers to that information. 579 The notify operation has these parameters: 581 o the watcher parameter specifies the WATCHER associated with the 582 subscription; 584 o the target parameter specifies the PRESENTITY associated with the 585 presence information; 587 o the transID parameter specifies the transaction-identifier 588 associated with this operation; and, 590 o the presence information for the PRESENTITY. 592 There is no application response to the notify operation. 594 3.4.3 The Unsubscribe Operation 596 When an application wants to terminate a subscription, it invokes the 597 unsubscribe operation. 599 The unsubscribe operations has these parameters: 601 o the watcher parameter specifies the WATCHER associated with the 602 subscription; 604 o the target parameter specifies the PRESENTITY associated with the 605 presence information; and, 607 o the transID parameter specifies the transaction-identifier 608 associated with this operation. 610 When the service is informed of the unsubscribe operation, it 611 performs these steps: 613 1. If the watcher and target parameters do not refer to an in- 614 progress subscribe operation for the application, a response 615 operation having status "failure" is invoked. 617 2. Otherwise, the in-progress subscribe operation for the 618 application is terminated, and a response operation having status 619 "success" is invoked by the service. 621 Note that following a successful unsubscribe operation, the WATCHER 622 may receive further notifications. Although the service will no 623 longer invoke the notify operation after successfully processing a 624 unsubscribe operation, earlier notify operations may still be in 625 progress. 627 4. Security Considerations 629 This memo makes no specific requirements on security procedures for 630 interoperation between IM systems. Accordingly, trust between 631 interconnected IM systems is determined in a bilateral matter. 633 However this memo does require that each IM system control access to 634 its Instant Messaging and Presence services. Consult both RFC 2778 635 and RFC2779 for a discussion of security considerations for for IM 636 systems. 638 4.1 Threats 640 Attacks, of concern for instant messaging, include access, deletion, 641 insertion, reordering and modification of messages by unauthorized 642 principals. Replay is a combination of a subset of these attacks. 644 These attacks can take place in the communication links between 645 sending client and its server, between two servers, between the 646 receiving client and its server, or by attacking any of the hosts 647 involved. This document, not being concerned with client-server 648 interchanges, only addresses threats aimed at server-server 649 communication. 651 Countermeasures against unauthorized access are encrypted 652 communication and encrypted messages. 654 Countermeasures against insertion of false messages are 655 authentication and authorization of sending servers and strongly 656 signed messages. 658 Countermeasures against reordered messages are date-stamped or 659 serial-numbered messages, coupled with digital signatures that 660 include the date or serial number, if modification is not otherwise 661 guarded against. 663 Countermeasures against replayed messages are date stamps and unique 664 message IDs, coupled with digital signatures that include the date or 665 serial number, if modification is not otherwise guarded against. 667 Countermeasures against deletion of messages are integrity-protected 668 connections between servers where the server's identity is verified. 669 Serial-numbered messages can also be useful in detecting deleted 670 messages. 672 Attacks that target the server hosts rather than the communication 673 channels can successfully defeat all countermeasures that depend on 674 host security. Digital signatures and encrypted messages do not 675 depend on host security, for intermediate systems, but cannot by 676 themselves guard against deletion or reordering of messages. 678 For presence, the attacks include giving presence information to 679 unauthorized watchers, not reporting watcher information back to a 680 presentity, and insertion, modification, deletion and replay of 681 presence update messages. The same set of countermeasures are 682 relevant. 684 Instant messaging and presence systems can provide security at two 685 levels: hop-by-hop and/or end-to-end. 687 4.2 Hop-by-hop security 689 A useful but imperfect level of security can be provided on a hop-by- 690 hop basis, with all aspects of the communication including message 691 content and originator verification, using transport level security 692 between servers. The main drawback of this approach is that it 693 requires that each server that handles message or presence 694 information must be trusted. But it is relatively easy to deploy, 695 because it depends only on bilateral arrangements between directly 696 communicating servers. 698 The underlying principles for using hop-by-hop security are: 700 (a) each server and/or domain must keep their own house in order, 701 ensuring that operations and information accesses are allowed only to 702 appropriately authorized parties, and 704 (b) each server and/or domain must make its own choices about the 705 levels of trust to be established to any other server and/or domain 706 with which they directly communicate. [[[Some debate about the degree 707 of trust necessary between servers. /dc]]] 709 When passing IM and presence information between services using 710 different protocols, a gateway system MUST be capable of using 711 security mechanisms appropriate to each of the protocols concerned, 712 and must have access to keys needed to authenticate any other system 713 with which it needs to directly communicate in a secure fashion. 715 [[[SUGGESTION: to allow the use of common keys across different 716 protocols, we might say that hop-by-hop security should be based on 717 SASL, and specify specific profiles that should be used. This 718 doesn't buy anything at the protocol level, but it might make it 719 easier to leverage some common key-distribution infrastructure, and 720 avoid having to distribute different keys for communicating with a 721 gateway using different protocols.]]] 723 4.3 End-to-end security 725 End-to-end security is widely regarded as being more satisfactory 726 than hop-by-hop security, as the need to trust intermediate parties 727 is reduced. However, some aspects of end-to-end security are 728 difficult to achieve because they need bilateral arrangement between 729 any pair of communicating parties about acceptable security standards 730 to use, and key exchange. Reliance on bilateral agreements does not 731 scale well. A moderating alernative is a third-party certification 732 service and this approach, so far, has not found large-scale use. 734 The two IETF standards for end-to-end MIME object security are 735 OpenPGP[7] and S/MIME[8]. They require a public key operation for 736 each message. For repeated, short transactions, this overhead can be 737 onerous. A version of these specifications which permited re-use of 738 the public key across multiple messages would greatly reduce instant 739 messaging overhead. 741 4.3.1 Instant messages 743 End to end security for instant messages can be provided using any of 744 the MIME-based security mechanisms (S/MIME [8], OpenPGP [7]), as 745 instant message payload content is not interpreted or reformatted in 746 transit. 748 [[[NOTE: may need to say something about allowable MIME C-T-Es?]]] 750 This specification allows any pair of communicating parties to use 751 any MIME-based security framework for instant messages (c.f. section 752 2.3), but mechanisms for establishing the required bilateral 753 arrangements and key exchange are not specified here. 755 4.3.2 Presence service 757 The situation regarding end-to-end security for presence services is 758 unclear, as there is no common encapsulation framework specified for 759 presence, and the presence data itself is not invariant across 760 different IM services. 762 [[[NOTE: this raises a case for fixing the presence information to a 763 specific format if end-to-end security capability is to be a 764 requirement.]]] 766 5. IANA Considerations 768 The IANA assigns the "im" and "pres" URL schemes. 770 5.1 The IM URI Scheme 772 The Instant Messaging (IM) URI scheme designates an Internet 773 resource, namely an INSTANT INBOX. 775 The syntax of an IM URL has the form: 777 "im:" addr-spec 779 where "addr-spec" is defined in RFC 822. 781 5.2 The PRES URI Scheme 783 The Presence (PRES) URI scheme designates an Internet resource, 784 namely a PRESENTITY or WATCHER. 786 The syntax of a PRES URL has the form: 788 "pres:" addr-spec 790 where "addr-spec" is defined in RFC 822. 792 6. The Common Service DTD 794 803 820 821 822 823 824 827 828 835 7. The Messaging Service DTD 837 846 848 %IMCOMMON; 849 856 857 860 861 867 8. The Presence Service DTD 869 878 880 %IMCOMMON; 881 888 889 892 893 896 897 901 904 905 911 914 915 920 923 924 930 9. The Presence Information DTD 932 942 945 %IMCOMMON; 947 954 955 958 959 963 964 969 References 971 [1] Crocker, D., "Standard for the format of ARPA Internet text 972 messages", RFC 822, STD 11, Aug 1982. 974 [2] Mockapetris, P.V., "Domain names - concepts and facilities", 975 RFC 1034, STD 13, Nov 1987. 977 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 978 Extensions (MIME) Part One: Format of Internet Message Bodies", 979 RFC 2045, November 1996. 981 [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 982 Message Format", RFC 2440, November 1998. 984 [5] Klyne, G., "XML coding of RFC822 messages", I-D draft-klyne- 985 message-rfc822-xml-00.txt, November 2000. 987 [6] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC 988 2632, June 1999. 990 [7] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 991 Instant Messaging", RFC 2778, February 2000. 993 [8] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 994 Presence Protocol Requirements", RFC 2779, February 2000. 996 [9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 997 specifying the location of services (DNS SRV)", RFC 2782, 998 February 2000. 1000 [10] Allocchio, C., "GSTN Address Element Extensions in E-mail 1001 Services", RFC 2846, June 2000. 1003 Authors' Addresses 1005 Dave Crocker 1006 Brandenburg Consulting 1007 675 Spruce Drive 1008 Sunnyvale, CA 94086 1009 US 1011 Phone: +1 408 246 8253 1012 EMail: dcrocker@dcrocker.net 1013 Athanassios Diacakis 1014 Network Projects Inc. 1015 4516 Henry Street 1016 Suite 113 1017 Pittsburgh, PA 15213 1018 US 1020 Phone: +1 412 681 6950 x202 1021 EMail: thanos@networkprojects.com 1023 Florencio Mazzoldi 1024 Network Projects Inc. 1025 4516 Henry Street 1026 Suite 113 1027 Pittsburgh, PA 15213 1028 US 1030 Phone: +1 412 681 6950 1031 EMail: flo@networkprojects.com 1033 Christian Huitema 1034 Microsoft Corporation 1035 One Microsoft Way 1036 Redmond, WA 98052-6399 1037 US 1039 EMail: huitema@microsoft.com 1041 Graham Klyne 1042 Content Technologies 1043 Henley Business Centre, Newtown Road 1044 Oxfordshire RG9 1HG 1045 UK 1047 Phone: +44 118 930-1300 1048 EMail: GK@Dial.pipex.com 1049 Marshall Rose 1050 Invisible Worlds 1051 1179 North McDowell Boulevard 1052 Petaluma 94954-655 1053 US 1055 Phone: +1 916-483-8878 1056 EMail: mrose@dbc.mtview.ca.us 1058 Jonathan Rosenberg 1059 dynamicsoft 1060 200 Executive Drive 1061 Suite 120 1062 West Orange, NJ 07052 1063 US 1065 EMail: jdrosen@dynamicsoft.com 1067 Robert Sparks 1068 dynamicsoft 1069 200 Executive Drive 1070 Suite 120 1071 West Orange, NJ 07052 1072 US 1074 EMail: rsparks@dynamicsoft.com 1076 Hiroyasu Sugano 1077 Fujitsu Laboratories Ltd. 1078 64 Nishiwaki, Ohkubo-cho 1079 Akashi 674-8555 1080 JP 1082 EMail: suga@flab.fujitsu.co.jp 1084 Appendix A. IM URL IANA Registration Template 1086 This section provides the information to register the im: instant 1087 messaging URL. 1089 A.1 URL scheme name 1091 im 1093 A.2 URL scheme syntax 1095 The syntax replicates the existing mailto: URL syntax specified in 1096 RFC2368. The ABNF is: 1097 IM-URL = "im:" [ to ] [ headers ] 1098 to = #mailbox 1099 headers = "?" header *( "&" header ) 1100 header = hname "=" hvalue 1101 hname = *urlc 1102 hvalue = *urlc 1104 A.3 Character encoding considerations 1106 Representation of non-ASCII character sets in local-part strings is 1107 limited to the standard methods provided as extensions to RFC 822[1] 1109 A.4 Intended usage 1111 Use of the im: URL follows closely usage of the mailto: URL. That is, 1112 invocation of an IM URL will cause the user's instant messaging 1113 application to start, with destination address and message headers 1114 fill-in according to the information supplied in the URL. 1116 A.5 Applications and/or protocols which use this URL scheme name 1118 It is anticipated that protocols compliant with RFC2779, and meeting 1119 the interoperability requirements specified here, will make use of 1120 this URL scheme name. 1122 A.6 Interoperability considerations 1124 The underlying exchange protocol used to send an instant message may 1125 vary from service to service. Therefore complete, Internet-scale 1126 interoperability cannot be guaranteed. However, a service conforming 1127 to this specification permits gateways to achieve interoperability 1128 sufficient to the requirements of RFC2779. 1130 A.7 Security considerations 1132 When IM URLs are placed in instant messaging protocols, they convey 1133 the identity of the sender and/or the recipient. In some cases, 1134 anonymous messaging may be desired. Such a capability is beyond the 1135 scope of this specification. 1137 A.8 Relevant publications 1139 RFC2779, RFC2778 1141 A.9 Person & email address to contact for further information 1143 Dave Crocker 1145 A.10 Author/Change controller 1147 This scheme is registered under the IETF tree. As such, IETF 1148 maintains change control. 1150 A.11 Applications and/or protocols which use this URL scheme name 1152 Instant messaging service; presence service 1154 Appendix B. PRES URL IANA Registration Template 1156 This section provides the information to register the pres: presence 1157 URL . 1159 B.1 URL scheme name 1161 pres 1163 B.2 URL scheme syntax 1165 The syntax replicates the existing mailto: URL syntax specified in 1166 RFC2368. The ABNF is: 1167 PRES-URL = "pres:" [ to ] [ headers ] 1168 to = #mailbox 1169 headers = "?" header *( "&" header ) 1170 header = hname "=" hvalue 1171 hname = *urlc 1172 hvalue = *urlc 1174 B.3 Character encoding considerations 1176 Representation of non-ASCII character sets in local-part strings is 1177 limited to the standard methods provided as extensions to RFC 822[1] 1179 B.4 Intended usage 1181 Use of the pres: URL follows closely usage of the mailto: URL. That 1182 is, invocation of an PRES URL will cause the user's instant messaging 1183 application to start, with destination address and message headers 1184 fill-in according to the information supplied in the URL. 1186 B.5 Applications and/or protocols which use this URL scheme name 1188 It is anticipated that protocols compliant with RFC2779, and meeting 1189 the interoperability requirements specified here, will make use of 1190 this URL scheme name. 1192 B.6 Interoperability considerations 1194 The underlying exchange protocol used for presence may vary from 1195 service to service. Therefore complete, Internet-scale 1196 interoperability cannot be guaranteed. However, a service conforming 1197 to this specification permits gateways to achieve interoperability 1198 sufficient to the requirements of RFC2779. 1200 B.7 Security considerations 1202 When PRES URLs are placed in presence protocols, they convey the 1203 identity of the sender and/or the recipient. In some cases, anonymous 1204 messaging may be desired. Such a capability is beyond the scope of 1205 this specification. 1207 B.8 Relevant publications 1209 RFC2779, RFC2778 1211 B.9 Person & email address to contact for further information 1213 Dave Crocker 1215 B.10 Author/Change controller 1217 This scheme is registered under the IETF tree. As such, IETF 1218 maintains change control. 1220 B.11 Applications and/or protocols which use this URL scheme name 1222 Instant messaging service; presence service 1224 Appendix C. Issues of Interest 1226 This appendix briefly discusses issues that may be of interest when 1227 designing an interoperation gateway. 1229 C.1 Address Mapping 1231 When mapping the service described in this memo, mappings which place 1232 special information into the im: address local-part MUST use the 1233 meta-syntax defined in RFC 2486[10]. 1235 C.1.1 Source-Route Mapping 1237 The easiest mapping technique is a form of source-routing and usually 1238 is the least friendly to humans having to type the string. Source- 1239 routing also has a history of operational problems. 1241 Use of source-routing for exchanges between different services is by 1242 a transformation that places the entire, original address string 1243 into the im: address local part and names the gateway in the domain 1244 part. 1246 For example, if the destination INSTANT INBOX is 1247 "pepp://example.com/fred", then, after performing the necessary 1248 character conversions, the resulting mapping is: 1250 im:pepp=example.com/fred@relay-domain 1252 where "relay-domain" is derived from local configuration information. 1254 Experience shows that it is vastly preferrable to hide this mapping 1255 from end-users �� if possible, the mapping should be performed 1256 automatically by the underlying software. 1258 Full Copyright Statement 1260 Copyright (C) The Internet Society (2000). All Rights Reserved. 1262 This document and translations of it may be copied and furnished to 1263 others, and derivative works that comment on or otherwise explain it 1264 or assist in its implementation may be prepared, copied, published 1265 and distributed, in whole or in part, without restriction of any 1266 kind, provided that the above copyright notice and this paragraph are 1267 included on all such copies and derivative works. However, this 1268 document itself may not be modified in any way, such as by removing 1269 the copyright notice or references to the Internet Society or other 1270 Internet organizations, except as needed for the purpose of 1271 developing Internet standards in which case the procedures for 1272 copyrights defined in the Internet Standards process must be 1273 followed, or as required to translate it into languages other than 1274 English. 1276 The limited permissions granted above are perpetual and will not be 1277 revoked by the Internet Society or its successors or assigns. 1279 This document and the information contained herein is provided on an 1280 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1281 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1282 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1283 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1284 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1286 Acknowledgement 1288 Funding for the RFC Editor function is currently provided by the 1289 Internet Society.