idnits 2.17.1 draft-ietf-simple-messaging-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 446. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 22, 2006) is 6517 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 341, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 352, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 356, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 359, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2421 (ref. '7') (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. '8') (Obsoleted by RFC 3501) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-14 == Outdated reference: A later version (-08) exists of draft-ietf-sipping-uri-list-message-07 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE M. Isomaki 3 Internet-Draft Nokia 4 Intended status: Informational J. Rosenberg 5 Expires: December 24, 2006 Cisco Systems 6 June 22, 2006 8 Advanced Instant Messaging Requirements for the Session Initiation 9 Protocol (SIP) 10 draft-ietf-simple-messaging-requirements-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 24, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Session Initiation Protocol (SIP) supports the basic instant 44 messaging service in both page and session mode. This document 45 defines a set of requirements for instant messaging capabilities that 46 are beyond the scope of the baseline specifications. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Instant Messaging Disposition Notifications . . . . . . . . . 3 53 4. Is-Composing . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Content Capabilities . . . . . . . . . . . . . . . . . . . . . 7 55 6. Page-Mode Groups . . . . . . . . . . . . . . . . . . . . . . . 8 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 61 10.2. Informative References . . . . . . . . . . . . . . . . . 9 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . . . . 11 65 1. Introduction 67 The Session Initiation Protocol (SIP) defines several specifications 68 that support Instant Messaging (IM). The SIP MESSAGE method [3] 69 allows for "page-mode" messaging, offering a service in some aspects 70 similar to Short Message Service (SMS) in wireless networks. A more 71 advanced capability, called session mode messaging, uses the SIP 72 INVITE method to establish a session where messages are transported 73 using Message Session Relay Protocol (MSRP) [9]. This makes it 74 possible to combine messaging with other media such as audio and 75 video. Also, many regular SIP capabilities to be directly applied to 76 instant messaging, such as conferencing [10]. 78 However, there are many additional features that exist in current, 79 proprietary IM systems. Some of these features do not require 80 protocol extensions in order to be deployed (IM message archival, for 81 example). However, others do. 83 This document provides requirements for a number of advanced IM 84 features which require additional standardization activity in 85 addition to the basic SIP MESSAGE and MSRP work. For some of the 86 requirements presented here the relevant standardization work has 87 actully been already concluded. In those cases the related 88 specifications are called out and referenced. 90 2. Terminology 92 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 93 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 94 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 95 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 96 compliant implementations. 98 3. Instant Messaging Disposition Notifications 100 In most cases, an IM is delivered immediately to the recipient. 101 Indeed, this is the principal motivation behind the "Instant" in 102 "Instant Messaging". However, in many systems, an instant message 103 can be sent even when the recipient is not available. Indeed, even 104 if they are available when the message is sent, the user may log off 105 before the message can be delivered. In addition to basic delivery 106 reporting, the sender may be interested when the recipient has 107 actually "read" the message or the message has been at least 108 displayed to the user in some way. 110 Typically, this is dealt with through a combination of two features. 112 The first is message archival and retrieval. These features allow 113 the intended recipient to retrieve their messages at a later time. 114 To support this, the receiving domain stores the content of the IM, 115 allowing the user to fetch it later. In this regard, it is very 116 similar to existing email systems. Existing protocols, such as IMAP4 117 [8], can be used for the retrieval functions of IM. 119 The second feature is message disposition notification. This feature 120 allows the sender to be notified when the message has been delivered 121 to the recipient and when the recipient has "read" the message. This 122 feature exists in SMS, email [11] and several commercia IM systems. 123 A similar function is needed for SIP-based instant messaging. 125 Certainly, much of the email specifications for message delivery 126 confirmation can be reused for IM. However, much of it is email- 127 specific, and IM introduces some new requirements. The following 128 requirements apply to IM disposition notifications: 130 REQ-DISNOT-1: It MUST be possible for the sender of an IM to 131 request a delivery notification and/or a read notification. 133 REQ-DISNOT-2: It MUST be possible for the recipient of the message 134 to immediately indicate to the sender that the recipient supports 135 delivery and/or read notifications. 137 REQ-DISNOT-3: It MUST be possible that the disposition 138 notifications can be sent and received at any point in the future 139 after the actual IM has been sent, without introducing any limits 140 on such a time window. 142 REQ-DISNOT-4: The delivery notification MUST be capable of 143 indicating that the message was delivered to the intended target. 145 REQ-DISNOT-5: The delivery notification MUST be capable of 146 indicating whether the message was delivered successfully, or 147 whether, when it was delivered, the recipient geneeated an error. 148 It MUST be possible for the sender to learn the specific error 149 condition. 151 REQ-DISNOT-6: The disposition notification MUST indicate the time 152 when the message was delivered or read. 154 REQ-DISNOT-7: The disposition notification MUST contain enough 155 information to allow the sender of the original IM to correlate 156 the notification with the correct message, provided that the 157 sender has stored the contents of the sent message. In addition 158 the notification MUST be able to carry information that might be 159 helpful to a sender who no longer has the original message 160 available, such as the original To, From, Content-Type and 161 Content-Length headers. 163 REQ-DISNOT-8: It MUST be possible for the message sender (the 164 recipient of the notification) to authenticate the sender of the 165 notification. There is no explicit requirement for confidentialy 166 of the notification. 168 REQ-DISNOT-9: As it is anticipated that this mechanism will be 169 used frequently from wireless devices, it SHOULD keep overhead to 170 a minimum, and in particular, SHOULD NOT provide extraneous 171 information not relevant to the above requirements. 173 REQ-DISNOT-10: When an IM is sent to an intermediary that will 174 relay it to a group of recipients, it MUST be possible for the 175 sender to ask that disposition notifications are generated by each 176 final recipient separately. 178 REQ-DISNOT-11: When an IM is sent to an intermediary that will 179 relay it to a group of recipients, it MUST be possible for the 180 sender to ask that the intermediary will generate summary reports 181 based on reports it receives from each final recipient. [OPEN 182 ISSUE: Is this needed?] 184 REQ-DELNOT-12: Any error condition reported by the notification 185 MAY contain a textual description of the error meant for human 186 consumption [OPEN ISSUE: How about internationalization?] 188 REQ-DELNOT-13: If an IM is being relayed through a gateway, for 189 example, to SMS, the delivery report SHOULD be able to indicate 190 such a condition [OPEN ISSUE: Is this needed?]] 192 4. Is-Composing 194 Many commercial instant messaging and presence systems provide a 195 feature generally referred to as "is-typing". This feature is used 196 during instant messaging chat sessions. Whenever one user is in the 197 process of typing a message to another user, the recipient-to-be can 198 see that a message is in progress. This avoids a common problem 199 where both participants are typing replies at the same time, so that 200 the resulting stream of converation is not well synchronized. 202 Generalizing this concept, the idea is really to allow one 203 participant to inform another participant that they are composing a 204 message of some type. By conveying a type, a broader set of features 205 can be enabled. For example, if one user indicates that they are 206 composing a message of type audio/basic, the other user will know 207 that a voice IM is coming. 209 The specification of how is-composing indicators are generated and 210 represented is available as RFC 3994 [13]. It has been designed 211 based on the requirements listed in this Section. 213 REQ-COMP-1: The is-composing feature MUST work with instant 214 messaging sessions [9]. 216 REQ-COMP-2: Either side in the session should be able to indicate 217 that they can receive the indicators. The indicators MUST NOT be 218 sent from A to B if B does not explicitly indicate that they can 219 receive them. 221 REQ-COMP-3: It MUST be possible for indicators to be sent in only 222 one direction, i.e., A sends them to B, but B does not send them 223 to A. 225 REQ-COMP-4: It MUST be possible for usage of the indicators to be 226 added or removed to any IM session after the session has begun. 228 REQ-COMP-5: The indicator MUST be able to inform the recipient 229 that the sender has begun composing a message. 231 REQ-COMP-6: The indicator MUST be able to inform the recipient 232 that the sender has stopped composing a message. 234 REQ-COMP-7: The indicator MUST be able to convey the MIME type of 235 the message that is being composed. 237 REQ-COMP-8: The indicator must be synchrnonized with the message 238 stream itself. That is, if a recipient gets an indicator that a 239 user has stopped composing a message, and they also get a message, 240 the recipient must be able to know which came first. 242 REQ-COMP-9: It must be possible to provide end-to-end message 243 integrity and authentication over the indicators. 245 REQ-COMP-10: It must be possible to associate the is-composing 246 indicator with a particular instant messaging session. 248 REQ-COMP-11: It should be possible to interwork is-composing 249 indicators between CPIM compliant systems, possibly with some loss 250 of functionality, but with integrity and authentication in tact. 252 REQ-COMP-12: It should be possible for is-composing indicators to 253 work, possibly with loss of functionality, in page mode. 255 REQ-COMP-13: The is-composing indicator should not result in an 256 increase on the load of proxies. 258 REQ-COMP-14: It must be possible to receive delivery confirmation 259 reports for is-composing indicators [OPEN ISSUE: This is related 260 to the question on whether disposition notifications will be 261 supported for session-mode messaging.] 263 REQ-COMP-15: The overhead of the indicators should be minimal. 265 5. Content Capabilities 267 Although traditionally used with text, an IM can contain any kind of 268 content. There is an increasing trend to send multimedia content, 269 including audio, video, and even applications, over IM. However, 270 recipients may not wish to receive content that they do not 271 understand, or is over a particular size limit. 273 Handling these "content capabilities" is done differently for page 274 mode and session mode. In session mode, the initial offer/answer 275 exchange [4] can be used to convey content capabilities. Indeed, the 276 messaging sessions mechanism allows for negotiation of supported 277 content types. However, some additional aspects of negotiation are 278 required: 280 REQ-CONTENT-1: A UA MUST be able to indicate the maximum message 281 size it is willing to receive. 283 This requirement has been met in MSRP via the a=max-size 284 attribute. 286 In page mode messaging, a 413 response can be sent if a MESSAGE 287 request is too large. However, there is no way to indicate what the 288 largest allowed size is: 290 REQ-CONTENT-2: A 413 response MUST be capable of indicating the 291 maximum allowed message size. [OPEN ISSUE: Is this needed?] 293 Note that, there is no requirement to support transcoding of content 294 at an intermediary in order to reduce the size of a sent message to 295 match that of a recipient. 297 6. Page-Mode Groups 299 The baseline SIP MESSAGE specification does not have explicit support 300 for sending page mode messages to groups or multiple recipients. 301 This capability is addressed by the Multi-recipient MESSAGE request 302 [12] specification to meet the following requirements. 304 REQ-GROUP-1: It MUST be possible to address a page-mode IM to a 305 group. 307 REQ-GROUP-2: Each recipient of a group page IM MUST be capable of 308 determining the set of other recipients that got the request. 310 REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 311 group, where the identities of the recipients are carried in the 312 message itself. 314 REQ-GROUP-4: It MUST be possible for the recipient of a group IM 315 to send a message to all other participants that received the same 316 group IM (i.e., Reply-To-All). 318 7. IANA Considerations 320 There are no IANA Considerations associated with this specification. 322 8. Security Considerations 324 Security requirements are discussed above where relevant. 326 9. Acknowledgments 328 This draft includes requirements contributed by Aki Niemi [14]. Eric 329 Burger, Ben Campbell, Hisham Khartabil, Paul Kyzivat, Aki Niemi, Sean 330 Olson and Robert Sparks provided valuable comments. 332 10. References 334 10.1. Normative References 336 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 337 Levels", BCP 14, RFC 2119, March 1997. 339 10.2. Informative References 341 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 342 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 343 Session Initiation Protocol", RFC 3261, June 2002. 345 [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 346 D. Gurle, "Session Initiation Protocol (SIP) Extension for 347 Instant Messaging", RFC 3428, December 2002. 349 [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 350 Session Description Protocol (SDP)", RFC 3264, June 2002. 352 [5] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant 353 Messaging / Presence Protocol Requirements", RFC 2779, 354 February 2000. 356 [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence 357 and Instant Messaging", RFC 2778, February 2000. 359 [7] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail 360 - version 2", RFC 2421, September 1998. 362 [8] Crispin, M., "Internet Message Access Protocol - Version 363 4rev1", RFC 2060, December 1996. 365 [9] Campbell, B., "The Message Session Relay Protocol", 366 draft-ietf-simple-message-sessions-14 (work in progress), 367 February 2006. 369 [10] Rosenberg, J., "A Framework for Conferencing with the Session 370 Initiation Protocol (SIP)", RFC 4353, February 2006. 372 [11] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 373 Delivery Status Notifications", RFC 3464, January 2003. 375 [12] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE 376 Requests in the Session Initiation Protocol (SIP)", 377 draft-ietf-sipping-uri-list-message-07 (work in progress), 378 February 2006. 380 [13] Schulzrinne, H., "Indication of Message Composition for Instant 381 Messaging", RFC 3994, January 2005. 383 [14] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless 384 Systems", draft-niemi-simple-im-wireless-reqs-02 (work in 385 progress), October 2003. 387 Authors' Addresses 389 Markus Isomaki 390 Nokia 391 Keilalahdentie 2-4 392 Helsinki, 02150 393 Finland 395 Phone: +358 50 5225984 396 Email: markus.isomaki@nokia.com 398 Jonathan Rosenberg 399 Cisco Systems 400 600 Lanidex Plaza 401 Parsippany, NJ 07054 402 US 404 Phone: +1 973 952-5000 405 Email: jdrosen@cisco.com 406 URI: http://www.jdrosen.net 408 Full Copyright Statement 410 Copyright (C) The Internet Society (2006). 412 This document is subject to the rights, licenses and restrictions 413 contained in BCP 78, and except as set forth therein, the authors 414 retain all their rights. 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 419 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 420 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 421 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 Intellectual Property 426 The IETF takes no position regarding the validity or scope of any 427 Intellectual Property Rights or other rights that might be claimed to 428 pertain to the implementation or use of the technology described in 429 this document or the extent to which any license under such rights 430 might or might not be available; nor does it represent that it has 431 made any independent effort to identify any such rights. Information 432 on the procedures with respect to rights in RFC documents can be 433 found in BCP 78 and BCP 79. 435 Copies of IPR disclosures made to the IETF Secretariat and any 436 assurances of licenses to be made available, or the result of an 437 attempt made to obtain a general license or permission for the use of 438 such proprietary rights by implementers or users of this 439 specification can be obtained from the IETF on-line IPR repository at 440 http://www.ietf.org/ipr. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary 444 rights that may cover technology that may be required to implement 445 this standard. Please address the information to the IETF at 446 ietf-ipr@ietf.org. 448 Acknowledgment 450 Funding for the RFC Editor function is provided by the IETF 451 Administrative Support Activity (IASA).