idnits 2.17.1 draft-rosenberg-impp-im-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 12 instances of lines with non-RFC2606-compliant FQDNs 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 282: '... MESSAGE request MAY (Open Issue Secti...' RFC 2119 keyword, line 293: '... MESSAGE request MUST contain a To, Fr...' RFC 2119 keyword, line 296: '... All UAs MUST be prepared to send an...' RFC 2119 keyword, line 298: '... defined in CPIM MUST be prepared to s...' RFC 2119 keyword, line 300: '...ementing MESSAGE SHOULD provide the en...' (64 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 221 has weird spacing: '... where enc. ...' == Line 238 has weird spacing: '...ncoding e ...' == Line 277 has weird spacing: '... copied with ...' -- 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 (February 28, 2001) is 8458 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: '7' is defined on line 850, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 870, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 2778 (ref. '4') == Outdated reference: A later version (-01) exists of draft-rosenberg-sip-sctp-00 -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 2406 (ref. '6') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. '7') (Obsoleted by RFC 4306) == Outdated reference: A later version (-10) exists of draft-ietf-sip-callerprefs-03 ** Obsolete normative reference: RFC 2976 (ref. '9') (Obsoleted by RFC 6086) -- Duplicate reference: RFC2543, mentioned in '10', was also mentioned in '2'. ** Obsolete normative reference: RFC 2543 (ref. '10') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) ** Obsolete normative reference: RFC 2246 (ref. '11') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '13') (Obsoleted by RFC 4566) == Outdated reference: A later version (-03) exists of draft-ietf-impp-cpim-01 -- Possible downref: Normative reference to a draft: ref. '15' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-msgfmt-00 Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Rosenberg 3 Internet-Draft D. Willis 4 Expires: August 29, 2001 R. Sparks 5 B. Campbell 6 dynamicsoft 7 H. Schulzrinne 8 J. Lennox 9 Columbia University 10 C. Huitema 11 B. Aboba 12 D. Gurle 13 Microsoft Corporation 14 D. Oran 15 Cisco Systems 16 February 28, 2001 18 SIP Extensions for Instant Messaging 19 draft-rosenberg-impp-im-01 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 29, 2001. 44 Copyright Notice 46 Copyright (C) The Internet Society (2001). All Rights Reserved. 48 Abstract 50 This document defines a SIP extension (a single new method) that 51 supports Instant Messaging (IM). 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Changes since draft-rosenberg-impp-im-00 . . . . . . . . . 4 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Overview of Operation . . . . . . . . . . . . . . . . . . 5 59 5. The MESSAGE request . . . . . . . . . . . . . . . . . . . 6 60 5.1 Method Definition . . . . . . . . . . . . . . . . . . . . 6 61 5.2 UAC processing of initial MESSAGE request . . . . . . . . 8 62 5.3 Finding the next hop . . . . . . . . . . . . . . . . . . . 9 63 5.4 Proxy processing of MESSAGE requests . . . . . . . . . . . 9 64 5.5 UAS processing of MESSAGE requests . . . . . . . . . . . . 10 65 5.6 UAS processing of initial MESSAGE response . . . . . . . . 10 66 5.7 Subsequent MESSAGE requests . . . . . . . . . . . . . . . 11 67 5.8 Supporting multiple message destinations . . . . . . . . . 11 68 5.9 Caller Preferences . . . . . . . . . . . . . . . . . . . . 12 69 5.10 Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 5.10.1 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.10.2 Message Integrity and Authenticity . . . . . . . . . . . . 13 72 5.10.3 Outbound authentication . . . . . . . . . . . . . . . . . 13 73 5.10.4 Replay Prevention . . . . . . . . . . . . . . . . . . . . 14 74 6. Congestion Control . . . . . . . . . . . . . . . . . . . . 14 75 7. Example Messages . . . . . . . . . . . . . . . . . . . . . 14 76 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1 Must a MESSAGE actually include a message? . . . . . . . . 17 78 8.2 Should support for message/cpim be mandatory in all UAs? . 18 79 8.3 message/cpim and the Accept header . . . . . . . . . . . . 18 80 8.4 Message Sessions . . . . . . . . . . . . . . . . . . . . . 18 81 8.5 What would a body in a 200 OK to a MESSAGE mean? . . . . . 18 82 8.6 The im: URL and RFC2543 proxies and registrars . . . . . . 19 83 8.7 Providing im: URL in Contact headers . . . . . . . . . . . 19 84 8.8 Congestion control . . . . . . . . . . . . . . . . . . . . 19 85 8.9 Mapping to CPIM . . . . . . . . . . . . . . . . . . . . . 19 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 87 References . . . . . . . . . . . . . . . . . . . . . . . . 20 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 21 89 A. Requirements Evaluation . . . . . . . . . . . . . . . . . 23 90 Full Copyright Statement . . . . . . . . . . . . . . . . . 27 92 1. Introduction 94 This document defines an extension to SIP (RFC2543 [2]) to support 95 Instant Messaging. 97 Instant messaging is defined as the exchange of content between a 98 set of participants in real time. Generally, the content is short 99 textual messages, although that need not be the case. Generally, the 100 messages that are exchanged are not stored, but this also need not 101 be the case. IM differs from email in common usage in that instant 102 messages are usually grouped together into brief live conversations, 103 consisting of numerous small messages sent back and forth. 105 Instant messaging as a service has been in existence within 106 intranets and IP networks for quite some time. Early implementations 107 include zephyr [1], the unix talk application, and IRC. More 108 recently, IM has been used as a service coupled with presence and 109 buddy lists; that is, when a friend comes online, a user can be made 110 aware of this and have the option of sending the friend an instant 111 message. The protocols for accomplishing this are all proprietary, 112 which has seriously hampered interoperability. Furthermore, most of 113 these protocols tightly couple presence and IM, due to the way in 114 which the service is offered. 116 Despite the popularity of presence coupled IM services, IM is a 117 separate application from presence. There are many ways to use IM 118 outside of presence (for example, as part of a voice communications 119 session). Another example are interactive games (possibly 120 established with SIP - SIP can establish any type of session, not 121 just voice or video); IM is already a common component of 122 multiplayer online games. Keeping it apart from presence means it 123 can be used in such ways. Furthermore, keeping them separate allows 124 separate providers for IM and for presence service. Of course, it 125 can always be offered by the same provider, with both protocols 126 implemented into a single client application. 128 Along a similar vein, the mechanisms needed in an IM protocol are 129 very similar to those needed to establish an interactive session - 130 rapid delivery of small content to a user at their current location, 131 which may, in general, be dynamically changing as the user moves. 132 The similarity of needed function implies that existing solutions 133 for initiation of sessions (namely, the Session Initiation Protocol 134 (SIP) [2]) is an ideal base on which to build an IM protocol. 136 2. Changes since draft-rosenberg-impp-im-00 138 This submission serves to track transition of the work on a SIP 139 implementation of IM to the newly formed SIMPLE working group. It 140 endeavors to capture the progress made in IMPP since the original 141 submission (in particular, including the im: URL and the 142 message/cpim body) and detail a set of open issues for the SIMPLE 143 working group to address. 145 To support those goals, a great deal of the background and 146 motivation material in the original text has been shortened or 147 removed. 149 3. Terminology 151 Most of the terminology used here is defined in RFC2778 [4]. 152 However, we duplicate some of the terminology from SIP in order to 153 clarify this document: 155 User Agent (UA): A UA is a piece of software which is capable of 156 initiating requests, and of responding to requests. 158 User Agent Server (UAS): A UAS is the component of a UA which 159 receives requests, and responds to them. 161 User Agent Client (UAC): A UAC is the component of a UA which sends 162 requests, and receives responses. 164 Registrar: A registrar is a SIP server which can receive and 165 process REGISTER requests. These requests are used to construct 166 address bindings. 168 4. Overview of Operation 170 When one user wishes to send an instant message to another, the 171 sender formulates and issues a SIP request using the new MESSAGE 172 method defined by this document. The request URI of this request 173 will normally be the im: URL of the party to whom the message is 174 directed (see CPIM [15]), but can also be a normal SIP URL. The body 175 of the request will contain the message to be delivered. This body 176 can be of any MIME type, including "message/cpim" [16]. 178 The request may traverse a set of SIP proxies using a variety of 179 transport mechanism (UDP, TCP, even SCTP [5]) before reaching its 180 destination. The destination for each hop is located using the 181 address resolution rules detailed in the CPIM and SIP specifications 182 (see Section 5 for more detail). During traversal, each proxy may 183 rewrite the request URI based on available routing information. 185 Provisional and final responses to the request will be returned to 186 the sender as with any other SIP request. Normally, a 200 OK 187 response will be generated by the user agent of the request's final 188 recipient. Note that this indicates that the user agent accepted the 189 message, not that the user has seen it. 191 Groups of messages in a common thread may be associated by keeping 192 them in the same session as identified by the combination of the To, 193 From and Call-ID headers. Other potential means of grouping messages 194 are discussed below. 196 It is possible that a proxy may fork a MESSAGE request based on its 197 available routing mechanism. This draft proposes a mechanism that 198 takes advangage of this, delivering messages in a session to 199 multiple endpoints until one sends a message back. After that, all 200 remaining messages in the session are delivered to the responding 201 agent. 203 5. The MESSAGE request 205 This section defines the syntax and semantics of this extension. 207 5.1 Method Definition 209 This specification defines a new SIP method, MESSAGE. The BNF for 210 this method is: 212 Message = "MESSAGE" 214 As with all other methods, the MESSAGE method name is case 215 sensitive. 217 Tables 1 and 2 extend Tables 4 and 5 of SIP by adding an additional 218 column, defining the headers that can be used in MESSAGE requests 219 and responses. 221 where enc. e-e MESSAGE 222 __________________________________________ 223 Accept R e o 224 Accept 415 e o 225 Accept-Encoding R e o 226 Accept-Encoding 415 e o 227 Accept-Language R e o 228 Accept-Language 415 e o 229 Allow 200 e o 230 Allow 405 e m 231 Authorization R e o 232 Authorization r e o 233 Call-ID gc n e m 234 Contact R e m 235 Contact 2xx e o 236 Contact 3xx e o 237 Contact 485 e o 238 Content-Encoding e e o 239 Content-Length e e m 240 Content-Type e e * 241 CSeq gc n e m 242 Date g e o 243 Encryption g n e o 244 Expires g e o 245 From gc n e m 246 Hide R n h o 247 Max-Forwards R n e o 248 Organization g c h o 250 Table 1: Summary of header fields, A--O 251 where enc. e-e MESSAGE 252 ________________________________________________________ 253 Priority R c e o 254 Proxy-Authenticate 407 n h o 255 Proxy-Authorization R n h o 256 Proxy-Require R n h o 257 Record-Route R h o 258 Record-Route 2xx,401,484 h o 259 Require R e o 260 Retry-After R c e - 261 Retry-After 404,413,480,486 c e o 262 500,503 c e o 263 600,603 c e o 264 Response-Key R c e o 265 Route R h o 266 Server r c e o 267 Subject R c e o 268 Timestamp g e o 269 To gc(1) n e m 270 Unsupported 420 e o 271 User-Agent g c e o 272 Via gc(2) n e m 273 Warning r e o 274 WWW-Authenticate R c e o 275 WWW-Authenticate 401 c e o 277 (1): copied with possible addition of tag 278 (2): UAS removes first Via header field 280 Table 2: Summary of header fields, P--Z 282 A MESSAGE request MAY (Open Issue Section 8.1) contain a body, using 283 the standard MIME headers to identify the content. 285 Unless stated otherwise in this document, the protocol for emitting 286 and responding to a MESSAGE request is identical to that for a BYE 287 request as defined in [2]. The behavior of SIP entities not 288 implementing the MESSAGE (or any other unknown) method is explicitly 289 defined in [2]. 291 5.2 UAC processing of initial MESSAGE request 293 A MESSAGE request MUST contain a To, From, Call-ID, CSeq, Via, 294 Content-Length, and Contact header, formatted as specified in [2]. 296 All UAs MUST be prepared to send and receive MESSAGE requests with a 297 body of type text/plain. All UAs wishing to provide the end to end 298 security mechanisms defined in CPIM MUST be prepared to send and 299 receive MESSAGE requests with a body type of message/cpim. All UAs 300 implementing MESSAGE SHOULD provide the end to end security 301 mechanisms defined in CPIM (Open Issue Section 8.2). 303 MESSAGE requests MAY contain an Accept header listing the allowable 304 MIME types which may be sent in the response, or in subsequent 305 requests in the reverse direction. The absence of the Accept header 306 implies that the only allowed MIME type is text/plain. This 307 simplifies operation in small devices, such as wireless appliances, 308 which will generally only have support for text, but still allows 309 any other MIME type to be used if both sides support it. (Open Issue 310 Section 8.3) 312 A UAC MAY send a MESSAGE request within an existing SIP call, 313 established with an INVITE. In this case, the MESSAGE request is 314 processed identically to the INFO method [9]. The only difference is 315 that a MESSAGE request is assumed to be for the purpose of instant 316 messaging as part of the call, whereas INFO is less specific. 318 A UAC MAY associate sequential MESSAGEs in a common thread by 319 constructing them with common To, From, and Call-ID headers and 320 increasing CSeq values. (Open Issue Section 8.4) 322 5.3 Finding the next hop 324 The mechanism used to determine the next hop destination for a SIP 325 MESSAGE request is detailed in [15] and [2]. Briefly, for the URL 326 im:user@host, 327 1. The UA makes a DNS SRV [12] query for _im._sip.host. If any RRs 328 are returned, they determine the next hop. Otherwise: 329 2. The UA makes a DNS SRV query for _sip.host. If any RRs are 330 returned, they determine the next hop. Otherwise: 331 3. The UA makes a DNS A query for host. If any records are 332 returned, they determine the address of the next hop. The 333 desination port is determined from the input URL (if the input 334 was an im: URL, the request is sent to the default SIP port of 335 5060). 336 For sip: URLs, the UA starts at step 2. 338 5.4 Proxy processing of MESSAGE requests 340 Proxies route requests with method MESSAGE the same as they would 341 any other SIP request (proxy routing in SIP does not depend on the 342 method). Note that the MESSAGE request MAY fork; this allows for 343 delivery of the message to several possible terminals where the user 344 might be. 346 If a MESSAGE request hits a proxy that uses registrations to route 347 requests, but no registration exists for the target user in the 348 request-URI, the request is rejected with a 404 (Not Found). 350 Proxies MAY have access rules which prohibit the transmission of 351 instant messages based on certain criteria. Typically, this criteria 352 will be based on the identity of the sender of the instant messages. 353 Establishment of this criteria in the proxy is outside the scope of 354 this extension. We anticipate that such access controls will often 355 be controlled through web pages accessible by users, mitigating the 356 need for standardization of a protocol for defining access rules. 358 5.5 UAS processing of MESSAGE requests 360 As specified in RFC 2543, if a UAS receives a request with a body of 361 type it does not understand, it MUST respond with a 415 (Unsupported 362 Media Type) containing an Accept header listing those types which 363 are acceptable. (This brings up Open Issue Section 8.3 again) 365 Servers MAY reject requests (using a 413 response code) that are too 366 long, where too long is a matter of local configuration. All servers 367 MUST accept requests which are up to 1184 bytes in length. 369 1184 = minimum IPv6 guaranteed length (1280 bytes) minus UDP (8 370 bytes) minus IPSEC (48 bytes) minus layer one encapsulation (40 371 bytes). 373 A UAS receiving a MESSAGE request SHOULD respond with a final 374 response immediately. A 200 OK is sent if the request is acceptable. 375 Note, however, that the UAS is not obliged to display the message to 376 the user either before or after responding with a 200 OK. A 200 377 class response to a MESSAGE request MAY contain a body, but this 378 will often not be the case, since these responses are generated 379 automatically. (Open Issue Section 8.5) 381 Like any other SIP request, an IM MAY be redirected, or otherwise 382 responded to with any SIP response code. Note that a 200 OK response 383 to a MESSAGE request does not mean the user has read the message. 385 A UAS which is, in fact, a message relay, storing the message and 386 forwarding it later on, or forwarding it into a non-SIP domain, 387 SHOULD return a 202 (Accepted) response indicating that the message 388 was accepted, but end to end delivery has not been guaranteed. 390 5.6 UAS processing of initial MESSAGE response 392 A 200 OK response to an initial IM may contain Record-Route headers. 393 If present, these MUST be used to construct a Route header for use 394 in subsequent requests for the same call-leg (defined as the 395 combination of remote address, local address, and Call-ID), using 396 the process described in Section 6.29 of SIP [2] as if the request 397 were INVITE. Note that per Section 5.8 the 200 OK response may not 398 contain a Contact header. 400 A 400 or 500 class response indicates that the message was not 401 delivered successfully. A 600 response means it was delivered 402 successfully, but refused. 404 5.7 Subsequent MESSAGE requests 406 Any subsequent MESSAGEs in a session (see Section 8.4 follow the 407 path established by the Route headers computed by the UA. The CSeq 408 header MUST be larger than a CSeq header used in a previous request 409 for the same call leg. Is is strongly RECOMMENDED that the CSeq 410 number be computed as described in Section 6.17 of SIP, using a 411 clock. This allows for the CSeq to increment without requiring the 412 UA to store the previous CSeq values. 414 5.8 Supporting multiple message destinations 416 A UAS MAY include a Contact in a 200 class response. Including a 417 Contact header enables end to end messaging, which is good for 418 efficiency. However, it rules out the possibility of effectively 419 supporting more than one terminal which can handle IM 420 simultaneously. 422 This odd but seemingly innocuous requirement enables a very 423 important feature. If a user is connected at several hosts, an 424 initial IM will fork, and arrive at each. Each UAS responds with 425 a 200 OK immediately, one of which is arbitrarily forwarded 426 upstream towards the UAC. If another IM is sent for the same 427 call-leg, we still wish for this IM to fork, since we still don't 428 know where the user is currently residing. This information is 429 known when the user sends an IM in the reverse direction. This IM 430 will contain a Contact, and when it arrives at the originator of 431 the initial MESSAGE, will update the Route so that now IMs are 432 delivered only to that one host where the user is residing. 434 A UAS constructs a set of Route headers from the Record-Route and 435 Contact headers in the MESSAGE request, as per the procedure defined 436 in [10]. 438 MESSAGE requests for an established IM session MUST contain a Tag in 439 the From field. Responses to an IM SHOULD contain a tag in the To 440 field. This represents a slightly different operation than for 441 INVITE. When a user sends an INVITE, they will receive a 200 OK with 442 a tag. Requests in the reverse direction then contain that tag, and 443 that tag only, in the From field. Here, the response to IM will 444 contain a tag in the To field, and a MESSAGE will contain a tag in 445 the From field. However, the UA may receive MESSAGE requests with 446 tags in the From field that do not match the tag in the 200 OK 447 received to the initial IM. This is because only a single 200 OK is 448 returned to a MESSAGE request, as opposed to multiple 200 OK for 449 INVITE. Thus, the UA MUST be prepared to receive MESSAGEs with many 450 different tags, each from a different PUA. 452 A UAS MUST be prepared to update the Route is has stored for an IM 453 session with a Contact received in a request, if that Contact is 454 different from one previously received, or if there was no Contact 455 previously. 457 5.9 Caller Preferences 459 User agents SHOULD add the "methods" tag defined in the caller 460 preference specification [8] to Contact headers with SIP URLs placed 461 in REGISTER requests, indicating support for the MESSAGE method. 462 Other elements of caller preferences MAY be supported. For example: 464 REGISTER sip:dynamicsoft.com SIP/2.0 465 Via: SIP/2.0/UDP mypc.dynamicsoft.com 466 To: sip:jdrosen@dynamicsoft.com 467 From: sip:jdrosen@dynamicsoft.com 468 Call-ID: asidhasd@1.2.3.4 469 CSeq: 39 REGISTER 470 Contact: sip:jdrosen@im-pc.dynamicsoft.com;methods="MESSAGE" 471 Content-Length: 0 473 Registrar/proxies which wish to offer IM service SHOULD implement 474 the proxy processing defined in the caller preferences specification 475 [8]. 477 5.10 Security 479 End-to-end security concerns for instant messaging were a primary 480 driving force behind the creation of message/cpim [16]. Applications 481 needing end-to-end security should study that work carefully. 483 SIP provides numerous security mechanisms which can be utilized in 484 addition to those made available through the use of message/cpim. 486 5.10.1 Privacy 488 In order to enhance privacy of instant messages, it is RECOMMENDED 489 that between network servers (proxies to proxies, proxies to 490 redirect servers), transport mode ESP [6] or TLS is used to encrypt 491 all traffic. Coupled with persistent connections, this makes it 492 impossible for eavesdroppers on non-UA connections to determine when 493 a particular user has even sent an IM, let alone what the content 494 is. Of course, the content of unencrypted IMs are exposed to 495 proxies. 497 Between a UAC and its local proxy, TLS [11] is RECOMMENDED. 498 Similarly, TLS SHOULD be used between a proxy and the UAS receiving 499 the IM. The proxy can determine whether TLS is supported by the 500 receiving client based on the transport parameter in the Contact 501 header of its registration. If that registration contains the token 502 "tls" as transport, it implies that the UAS supports TLS. (Open 503 issue Section 8.7) 505 Furthermore, we allow for the Contact header in the MESSAGE request 506 to contain TLS as a transport. The Contact header is used to route 507 subsequent messages between a pair of entities. It defines the 508 address and transport used to communicate with the user agent for 509 subsequent requests in the reverse direction. If no proxies insert 510 Record-Route headers, the recipient of the original IM, when it 511 wishes to send an IM back, will use the Contact header, and 512 establish a direct TLS connection for the remainder of the IM 513 communications. If a proxy does Record-Route, the situation is 514 different. When the recipient of the original IM (call this 515 participant B) sends an IM back to the originator of the original IM 516 (call this participant A), this will be sent to the proxy closest to 517 B which inserted Record- Route. This proxy, in turn, sends the 518 request to the proxy before it which Record-Routed. The first proxy 519 after A which inserted Record- Route will then use TLS to contact A. 520 Since we suspect that most proxies will not insert Record-Route into 521 instant messages, efficient, secure, direct IM will occur 522 frequently. 524 If encrypted message/cpim bodies are not available, sensitive data 525 may be protected from being observed by intermediate proxies by 526 using SIP encryption for the transmission of MESSAGE requests. SIP 527 supports PGP based encryption, which does not require the 528 establishment of a session key for encryption of messages within a 529 session (basically, a new session key is established for each 530 message as part of the PGP encryption). 532 5.10.2 Message Integrity and Authenticity 534 In addition to the integrity and authenticity protections offered 535 through message/cpim, SIP provides PGP based authentication and 536 message integrity checks (both challenge-response and normal 537 signatures), as well as http basic and digest authentication. 539 5.10.3 Outbound authentication 541 When local proxies are used for transmission of outbound messages, 542 proxy authentication is RECOMMENDED. This is useful to verify the 543 identity of the originator, and prevent spoofing and spamming at the 544 originating network. 546 5.10.4 Replay Prevention 548 To prevent the replay of old SIP requests, all signed MESSAGE 549 requests and responses SHOULD contain a Date header covered by the 550 message signature. Any message with a date older than several 551 minutes in the past, or which is more than several minutes in the 552 future, SHOULD be answered with a 400 (Incorrect Date or Time) 553 message, unless such messages arrive repeatedly from the same 554 source, in which case they MAY be discarded without sending a 555 response. Obviously, this replay attack prevention mechanism does 556 not work for devices without clocks. 558 Furthermore, all signed SIP MESSAGE requests MUST contain a Call-ID 559 and CSeq header covered by the message signature. A user agent MAY 560 store a list of Call-ID values, and for each, the higest CSeq seen 561 within that Call-ID. Any message that arrives for a Call-ID that 562 exists, whose CSeq is lower than the highest seen so far, is 563 discarded. 565 Finally, challenge-response authentication MAY be used to prevent 566 replay protection. 568 6. Congestion Control 570 (Open Issue Section 8.8) Discussion needs to take place to populate 571 this section. 573 7. Example Messages 575 An example message flow is shown in Figure 1. The message flow shows 576 an initial IM sent from User 1 to User 2, both users in the same 577 domain, "domain", through a single proxy. A second IM, sent in 578 response, flows directly from User 2 to User 1. 580 | F1 MESSAGE | | 581 |--------------------> | F2 MESSAGE | 582 | | ----------------------->| 583 | | | 584 | | F3 200 OK | 585 | | <-----------------------| 586 | F4 200 OK | | 587 |<-------------------- | | 588 | | | 589 | | | 590 | | | 591 | | F5 MESSAGE | 592 | <--------------------|------------------------ | 593 | | | 594 | F6 200 OK | | 595 | ---------------------|-----------------------> | 596 | | | 597 | | | 598 | | | 599 | | | 600 | | | 601 | | | 602 | | | 603 | | | 604 | | | 605 | | | 606 | | | 607 | | | 608 | | | 609 | | | 610 | | | 612 User 1 Proxy User 2 614 Figure 1: Example Message Flow 616 Message F1 looks like: 618 MESSAGE im:user2@domain.com SIP/2.0 619 Via: SIP/2.0/UDP user1pc.domain.com 620 From: im:user1@domain.com 621 To: im:user2@domain.com 622 Contact: sip:user1@user1pc.domain.com 623 Call-ID: asd88asd77a@1.2.3.4 624 CSeq: 1 MESSAGE 625 Content-Type: text/plain 626 Content-Length: 18 628 Watson, come here. 630 User1 forwards this message to the server for domain.com (discovered 631 through the combination of SRV and A record processing described in 632 Section 5.3 , using UDP. The proxy receives this request, and 633 recognizes that it is the server for domain.com. It looks up user2 634 in its database (built up through registrations), and finds a 635 binding from im:user2@domain.com to sip:user2@user2pc.domain.com. It 636 forwards the request to user2, and does not insert a Record-Route 637 header. The resulting message, F2, looks like: 639 MESSAGE sip:user2@domain.com SIP/2.0 640 Via: SIP/2.0/UDP proxy.domain.com 641 Via: SIP/2.0/UDP user1pc.domain.com 642 From: im:user1@domain.com 643 To: im:user2@domain.com 644 Contact: sip:user1@user1pc.domain.com 645 Call-ID: asd88asd77a@1.2.3.4 646 CSeq: 1 MESSAGE 647 Content-Type: text/plain 648 Content-Length: 18 650 Watson, come here. 652 The message is received by user2, displayed, and a response is 653 generated, message F3, and sent to the proxy: 655 SIP/2.0 200 OK 656 Via: SIP/2.0/UDP proxy.domain.com 657 Via: SIP/2.0/UDP user1pc.domain.com 658 From: im:user1@domain.com 659 To: im:user2@domain.com;tag=ab8asdasd9 660 Contact: sip:user2@user1pc.domain.com 661 Call-ID: asd88asd77a@1.2.3.4 662 CSeq: 1 MESSAGE 663 Content-Length: 0 665 Note that most of the header fields are simply reflected in the 666 response. The proxy receives this response, strips off the top Via, 667 and forwards to the address in the next Via, user1pc.domain.com, the 668 result being message F4: 670 SIP/2.0 200 OK 671 Via: SIP/2.0/UDP user1pc.domain.com 672 From: im:user1@domain.com 673 To: im:user2@domain.com;tag=ab8asdasd9 674 Call-ID: asd88asd77a@1.2.3.4 675 CSeq: 1 MESSAGE 676 Content-Length: 0 678 Now, user2 wishes to send an IM to user1, message F5. As there are 679 no Record-Routes in the original IM, it can simply send the IM 680 directly to the address in the Contact header. Note how the To and 681 From fields are now reversed from the response it sent in message 682 F4: 684 MESSAGE sip:user1@user1pc.domain.com SIP/2.0 685 Via: SIP/2.0/UDP user2pc.domain.com 686 To: im:user1@domain.com 687 From: im:user2@domain.com;tag=ab8asdasd9 688 Contact: sip:user2@user2pc.domain.com 689 Call-ID: asd88asd77a@1.2.3.4 690 CSeq: 1 MESSAGE 691 Content-Type: multipart/signed; boundary=next; 692 MDALG=SHA-1; type=application/pkcs7 693 Content-Length: 695 --next 696 Content-Type: message/cpim 698 From: 699 To: 700 Date: 2001-02-28T01:20:00-06:00 702 Content-Type: text/plain 704 My name is User2, not Watson. 706 --next 707 Content-Type: application/pkcs7 709 (signature stuff) 710 : 711 --next-- 713 This is sent directly to user1, who responds with a 200 OK in 714 message F6: 716 SIP/2.0 200 OK 717 Via: SIP/2.0/UDP user2pc.domain.com 718 To: im:user1@domain.com;tag=2c09sj3sd9 719 From: im:user2@domain.com;tag=ab8asdasd9 720 Call-ID: asd88asd77a@1.2.3.4 721 CSeq: 1 MESSAGE 722 Content-Length: 0 724 8. Open Issues 726 8.1 Must a MESSAGE actually include a message? 728 Section 5 specifies that a MESSAGE MAY contain a MIME body. Should 729 this be MUST? Does it make sense to have a MESSAGE with no body? 731 8.2 Should support for message/cpim be mandatory in all UAs? 733 Section 5 requires that UAs implementing MESSAGE support text/plain 734 bodies as the lowest common denominator. Should this be message/cpim 735 instead? Any UA wishing to support end-end signing or encryption of 736 messages passing across simple/apex/prim boundaries MUST support 737 message/cpim. If, however, end-end security is not desired, clients 738 and messaging can be made a little lighter by not including the 739 message/cpim wrapper. An unsigned message/cpim body can be created 740 from messages from those clients when crossing a boundary that 741 requires one. 743 8.3 message/cpim and the Accept header 745 Do we need text to make it clear that a UA should indicate the mime 746 types it supports _inside_ a message/cpim body as well as supporting 747 message/cpim? 749 8.4 Message Sessions 751 Several implementations of the -00 version of this draft grouped 752 messages in a common thread by placing them in a "call-leg" (common 753 To, From, and Call-ID). The first message sent or received in a 754 thread established the leg. This has provided enough information to 755 allow user interfaces to present separate threads in separate 756 dialogs. There is some concern that there is no way to formally 757 terminate this "call-leg". 759 The -00 version noded that there is state at the UA associated with 760 this notion of session, encapsulated in the Call-ID, Route headers, 761 and CSeq numbers. A UA MAY terminate this session at any time, 762 including after each MESSAGE. No messaging is required to terminate 763 it. Any associated state with the session is simply discarded. The 764 idempotency of SIP requests will ensure that if one side (side A) 765 discards session state, and the other (side B) does not, a message 766 from side B will appear as a new IM, and standard processing will 767 reconstitute the session on side A. 769 o Should we define a way to use INVITE/BYE to surround a group of 770 MESSAGE requests that are part of a logical session? 772 8.5 What would a body in a 200 OK to a MESSAGE mean? 774 Section 5.5 states "A 200 class response to a MESSAGE request MAY 775 contain a body, but this will often not be the case, since these 776 responses are generated automatically." If one were to appear, what 777 would it mean? 779 8.6 The im: URL and RFC2543 proxies and registrars 781 What are the implications of an im: URL showing up in the request 782 URI in a MESSAGE request received by an RFC2543 proxy, or the To: 783 header of a REGISTER request received by an RFC2543 registrar? 785 8.7 Providing im: URL in Contact headers 787 What are the ramifications of a UA providing an im: URL in a 788 Contact: header for a REGISTER method, or a MESSAGE method? For the 789 forseeable future, most SIP endpoints aren't going to have SRV 790 records of the form _im._sip.host or even _sip.host pointing to 791 them. Falling back to A records in that case seems to preclude the 792 use of non-UDP transports. 794 8.8 Congestion control 796 Per the amendments made to the SIMPLE charter by the IESG prior to 797 approval, congestion control needs attention. In particular the 798 requirements of BCP 41 must be met by this extension. Specifying the 799 use of transport protocols with congestion control built in, 800 particularly with the recommendation of reuse of connections, is an 801 option. The question is when can we use those that don't (UDP) and 802 what needs to be done in addition to what SIP already does in that 803 case. Among other things, this interacts with Section 8.7 805 8.9 Mapping to CPIM 807 This document needs to detail the mapping of this extension onto 808 CPIM. 810 9. Acknowledgements 812 The authors would like to thank the following people for their 813 support of the concept of SIP for IM, support for this work, and for 814 their useful comments and insights: 816 Jon Peterson Level(3) Communications 817 Sean Olson Ericsson 818 Adam Roach Ericsson 819 Billy Biggs University of Waterloo 820 Stuart Barkley UUNet 821 Mauricio Arango SUN 822 Richard Shockey Shockey Consulting LLC 823 Jorgen Bjorker Hotsip 824 Henry Sinnreich MCI Worldcom 825 Ronald Akers Motorola 827 References 829 [1] DellaFera, C. A., Eichin, M. W., French, R. S., Jedlinski, D. 830 C., Kohl, J. T. and W. E. Sommerfeld, "The Zephyr notification 831 service", in USENIX Winter Conference (Dallas, Texas), Feb. 832 1988. 834 [2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 835 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 837 [3] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 838 Presence Protocol Requirements", RFC 2779, February 2000. 840 [4] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence 841 and Instant Messaging", RFC 2778, February 2000. 843 [5] Rosenberg, J. and H. Schulzrinne, "SCTP as a transport for 844 SIP", draft-rosenberg-sip-sctp-00 (work in progress), June 845 2000. 847 [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload 848 (ESP)", RFC 2406, November 1998. 850 [7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", 851 RFC 2409, November 1998. 853 [8] Rosenberg, J. and H. Schulzrinne, "SIP caller preferences and 854 callee capabilities", draft-ietf-sip-callerprefs-03 (work in 855 progress), November 2000. 857 [9] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 859 [10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 860 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 862 [11] Dierks, T., Allen, C., Treese, W., Karlton, P. L., Freier, A. 863 O. and P. C. Kocher, "The TLS Protocol Version 1.0", RFC 2246, 864 January 1999. 866 [12] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 867 specifying the location of services (DNS SRV)", RFC 2782, 868 February 2000. 870 [13] Handley, M. and V. Jacobson, "SDP: Session Description 871 Protocol", RFC 2327, April 1998. 873 [14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 874 Extensions (MIME) Part One: Format of Internet Message 875 Bodies", RFC 2045, November 1996. 877 [15] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, 878 G., Rose, M., Rosenberg, J., Sparks, R. and H. Sugano, "A 879 Common Profile for Instant Messaging (CPIM)", 880 draft-ietf-impp-cpim-01 (work in progress), February 2001. 882 [16] Atkins, D. and G. Klyne, "Common Presence and Instant 883 Messaging Message Format", draft-ietf-impp-cpim-msgfmt-00 884 (work in progress), February 2001. 886 Authors' Addresses 888 Jonathan Rosenberg 889 dynamicsoft 890 200 Executive Drive 891 Suite 120 892 West Orange, NJ 07052 894 email: jdrosen@dynamicsoft.com 896 Dean Willis 897 dynamicsoft 898 5100 Tennyson Parkway 899 Suite 1200 900 Plano, TX 75024 902 email: dwillis@dynamicsoft.com 904 Robert J. Sparks 905 dynamicsoft 906 5100 Tennyson Parkway 907 Suite 1200 908 Plano, TX 75024 910 email: rsparks@dynamicsoft.com 912 Ben Cambpell 913 dynamicsoft 914 5100 Tennyson Parkway 915 Suite 1200 916 Plano, TX 75024 918 email: bcampbell@dynamicsoft.com 919 Henning Schulzrinne 920 Columbia University 921 M/S 0401 922 1214 Amsterdam Ave. 923 New York, NY 10027-7003 925 email: schulzrinne@cs.columbia.edu 927 Jonathan Lennox 928 Columbia University 929 M/S 0401 930 1214 Amsterdam Ave. 931 New York, NY 10027-7003 933 email: lennox@cs.columbia.edu 935 Christian Huitema 936 Microsoft Corporation 937 One Microsoft Way 938 Redmond, WA 98052-6399 940 email: huitema@microsoft.com 942 Bernard Aboba 943 Microsoft Corporation 944 One Microsoft Way 945 Redmond, WA 98052-6399 947 email: bernarda@microsoft.com 949 David Gurle 950 Microsoft Corporation 951 One Microsoft Way 952 Redmond, WA 98052-6399 954 email: dgurle@microsoft.com 956 David Oran 957 Cisco Systems 958 170 West Tasman Dr. 959 San Jose, CA 95134 961 email: oran@cisco.com 963 Appendix A. Requirements Evaluation 964 This section was moved forward verbatim from -00. 966 RFC 2779 [3] outlines requirements for IM and presence protocols. 967 The document describes both shared requirements and IM and presence 968 specific requirements. Examining each of the IM requirements in 969 turn, we also observe that they are met by this proposal: 971 "Requirement 2.1.1: The protocols MUST allow a PRESENCE SERVICE to 972 be available independent of whether an INSTANT MESSAGE SERVICE is 973 available, and vice-versa." This requirement is met by the 974 separation of presence and IM which we propose here. 976 "Requirement 2.1.2. The protocols must not assume that an INSTANT 977 INBOX is necessarily reached by the same IDENTIFIER as that of a 978 PRESENTITY. Specifically, the protocols must assume that some 979 INSTANT INBOXes may have no associated PRESENTITIES, and vice 980 versa." This requirement is also easily met by any architecture 981 which completely separates IM and presence as we propose. 983 "Requirement 2.1.3. The protocols MUST also allow an INSTANT INBOX 984 to be reached via the same IDENTIFIER as the IDENTIFIER of some 985 PRESENTITY." Same as above. 987 "Requirement 2.1.4. The administration and naming of ENTITIES 988 within a given DOMAIN MUST be able to operate independently of 989 actions in any other DOMAIN." This requirement is met by SIP. SIP 990 uses email-like identifiers which consist of a user name at a 991 domain. Administration of user names is done completely within 992 the domain, and these user names have no defined rules or 993 organization that needs to be known outside of the domain in 994 order for SIP to operate. 996 "Requirement 2.1.5. The protocol MUST allow for an arbitrary number 997 of DOMAINS within the NAMESPACE." This requirement is met by SIP. 998 SIP uses standard DNS domains, which are not restricted in 999 number. 1001 "Requirement 2.2.1. It MUST be possible for ENTITIES in one DOMAIN 1002 to interoperate with ENTITIES in another DOMAIN, without the 1003 DOMAINS having previously been aware of each other." This 1004 requirement is met by SIP, as it is essential for establishing 1005 sessions as well. DNS SRV records are used to discover servers 1006 for a particular service within a domain. They are a 1007 generalization of MX records, used for email routing. SIP defines 1008 procedures for usage of DNS records to find servers in another 1009 domains, which include SRV lookups. This allows domains to 1010 communicate without prior setup. 1012 "Requirement 2.2.2: The protocol MUST be capable of meeting its 1013 other functional and performance requirements even when there are 1014 millions of ENTITIES within a single DOMAIN." Whilst it is hard 1015 to judge whether this can be met by examining the architecture of 1016 a protocol, SIP has numerous mechanisms for achieving large 1017 scales of users within a domain. It allows hierarchies of 1018 servers, whereby the namespace can be partitioned among servers. 1019 Servers near the top of the hierarchy, used solely for routing, 1020 can be stateless, providing excellent scale. 1022 "Requirement 2.2.3: The protocol MUST be capable of meeting its 1023 other functional and performance requirements when there are 1024 millions of DOMAINS within the single NAMESPACE." The usage of 1025 DNS for dividing the namespace into domains provides the same 1026 scale as todays email systems, which support millions of DOMAINS. 1028 "Requirement 2.3.5: The PRINCIPAL controlling an INSTANT INBOX MUST 1029 be able to control which other PRINCIPALS, if any, can send 1030 INSTANT MESSAGES to that INSTANT INBOX." This is provided by 1031 access control mechanisms, outside the scope of this extension. 1033 "Requirement 2.3.6: The PRINCIPAL controlling an INSTANT INBOX MUST 1034 be able to control which other PRINCIPALS, if any, can read 1035 INSTANT MESSAGES from that INSTANT INBOX." This is accomplished 1036 through authenticated registration requests. Registrations are 1037 used to determine which user gets delivered an instant message. 1038 Policy in proxies can allow only certain users to register 1039 contact address for a particular inbox (an inbox is defined by 1040 the address-of- record in the To field in the registration). 1042 "Requirement 2.4.3: The protocol MUST allow the sending of an 1043 INSTANT MESSAGE both directly and via intermediaries, such as 1044 PROXIES." This is fundamental to the operation of SIP. 1046 "Requirement 2.4.4: The protocol proxying facilities and transport 1047 practices MUST allow ADMINISTRATORS ways to enable and disable 1048 protocol activity through existing and commonly-deployed 1049 FIREWALLS. The protocol MUST specify how it can be effectively 1050 filtered by such FIREWALLS." Although SIP itself runs on port 1051 5060 by default, any other port can be used. It is simple to 1052 specify that IM should run on a different port, if so desired. 1054 "Requirement 2.5.1. The protocol MUST provide means to ensure 1055 confidence that a received message (NOTIFICATION or INSTANT 1056 MESSAGE) has not been corrupted or tampered with." This is 1057 supported by SIPs PGP and S/MIME authentication mechanism. 1059 "Requirement 2.5.2. The protocol MUST provide means to ensure 1060 confidence that a received message (NOTIFICATION or INSTANT 1061 MESSAGE) has not been recorded and played back by an adversary." 1062 This is provided by SIP's challenge response authentication 1063 mechanisms, through timestamp-based replay prevention, or through 1064 stateful storage of previous transaction identifiers (the 1065 combination of To, From, Call-ID, CSeq). 1067 "Requirement 2.5.3. The protocol MUST provide means to ensure that 1068 a sent message (NOTIFICATION or INSTANT MESSAGE) is only readable 1069 by ENTITIES that the sender allows." This is supported through 1070 SIPs end to end and hop by hop encryption mechanisms. 1072 "Requirement 2.5.4. The protocol MUST allow any client to use the 1073 means to ensure non-corruption, non-playback, and privacy, but 1074 the protocol MUST NOT require that all clients use these means at 1075 all times." All algorithms for security in SIP are optional. 1077 "Requirement 4.1.1. All ENTITIES sending and receiving INSTANT 1078 MESSAGES MUST implement at least a common base format for INSTANT 1079 MESSAGES." We specify text/plain here. 1081 "Requirement 4.1.2. The common base format for an INSTANT MESSAGE 1082 MUST identify the sender and intended recipient." This is 1083 accomplished with the To and From fields in SIP. 1085 "Requirement 4.1.3. The common message format MUST include a return 1086 address for the receiver to reply to the sender with another 1087 INSTANT MESSAGE." This is done through the Contact headers 1088 defined in SIP. 1090 "Requirement 4.1.4. The common message format SHOULD include 1091 standard forms of addresses or contact means for media other than 1092 INSTANT MESSAGES, such as telephone numbers or email addresses." 1093 SIP supports any URL format in the Contact headers. Furthermore, 1094 the body of a MESSAGE request can be multipart, and contain 1095 things like vCards. 1097 "Requirement 4.1.5. The common message format MUST permit the 1098 encoding and identification of the message payload to allow for 1099 non-ASCII or encrypted content." MIME content labeling is used in 1100 SIP. 1102 "Requirement 4.1.6. The protocol must reflect best current 1103 practices related to internationalization." SIP uses UTF-8 and is 1104 completely internationalized. 1106 "Requirement 4.1.7. The protocol must reflect best current 1107 practices related to accessibility." Additional requirements are 1108 needed on what is required for accessibility. 1110 "Requirement 4.1.9. The working group MUST determine whether the 1111 common message format includes fields for numbering or 1112 identifying messages. If there are such fields, the working group 1113 MUST define the scope within which such identifiers are unique 1114 and the acceptable means of generating such identifiers." This is 1115 done with the combination of Call-ID and CSeq. The mechanisms for 1116 guaranteeing uniqueness are specified in SIP. 1118 "Requirement 4.1.10. The common message format SHOULD be based on 1119 IETF-standard MIME (RFC 2045)[14]." SIP uses MIME. 1121 "Requirement 4.2.1. The protocol MUST include mechanisms so that a 1122 sender can be informed of the SUCCESSFUL DELIVERY of an INSTANT 1123 MESSAGE or reasons for failure. The working group must determine 1124 what mechanisms apply when final delivery status is unknown, such 1125 as when a message is relayed to non-IMPP systems." SIP specifies 1126 notification of successful delivery through 200 OK. When delivery 1127 of requests through gateways, success can be indicated only 1128 through the SIP component (if the gateway acts as a UAS/UAC) or 1129 through the entire system (if it acts like a proxy). 1131 "Requirement 4.3.1. The transport of INSTANT MESSAGES MUST be 1132 sufficiently rapid to allow for comfortable conversational 1133 exchanges of short messages." The support for end to end 1134 messaging (i.e., without intervening proxies) allows IMs to be 1135 delivered as rapidly as possible. The UDP reliability mechanisms 1136 also support fast recovery from loss. 1138 Full Copyright Statement 1140 Copyright (C) The Internet Society (2001). All Rights Reserved. 1142 This document and translations of it may be copied and furnished to 1143 others, and derivative works that comment on or otherwise explain it 1144 or assist in its implementation may be prepared, copied, published 1145 and distributed, in whole or in part, without restriction of any 1146 kind, provided that the above copyright notice and this paragraph 1147 are included on all such copies and derivative works. However, this 1148 document itself may not be modified in any way, such as by removing 1149 the copyright notice or references to the Internet Society or other 1150 Internet organizations, except as needed for the purpose of 1151 developing Internet standards in which case the procedures for 1152 copyrights defined in the Internet Standards process must be 1153 followed, or as required to translate it into languages other than 1154 English. 1156 The limited permissions granted above are perpetual and will not be 1157 revoked by the Internet Society or its successors or assigns. 1159 This document and the information contained herein is provided on an 1160 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1161 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1162 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1163 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1164 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1166 Acknowledgement 1168 Funding for the RFC editor function is currently provided by the 1169 Internet Society.