idnits 2.17.1 draft-rosenberg-simple-messaging-requirements-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 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 108: '...REQ-DELNOT-1: It MUST be possible for ...' RFC 2119 keyword, line 111: '...REQ-DELNOT-2: It MUST be possible for ...' RFC 2119 keyword, line 115: '...REQ-DELNOT-3: It MUST be possible for ...' RFC 2119 keyword, line 118: '...livery notification MUST be capable of...' RFC 2119 keyword, line 121: '...livery notification MUST be capable of...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2004) is 7379 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: '1' is defined on line 380, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 391, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2421 (ref. '6') (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. '7') (Obsoleted by RFC 3501) == Outdated reference: A later version (-19) exists of draft-ietf-simple-message-sessions-03 == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-01 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIMPLE J. Rosenberg 3 Internet-Draft dynamicsoft 4 Expires: August 12, 2004 February 12, 2004 6 Advanced Instant Messaging Requirements for the Session Initiation 7 Protocol (SIP) 8 draft-rosenberg-simple-messaging-requirements-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 12, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This specification defines a set of requirements for new capabilities 39 for instant messaging in SIP-based systems. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Delivery Status Reporting . . . . . . . . . . . . . . . . . . 4 45 3. Is-Composing . . . . . . . . . . . . . . . . . . . . . . . . . 7 46 4. Content Capabilities . . . . . . . . . . . . . . . . . . . . . 9 47 5. Page-Mode Groups . . . . . . . . . . . . . . . . . . . . . . . 10 48 5.1 Invitations to Non-Real-Time Sessions . . . . . . . . . . . . 10 49 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 50 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 51 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 52 Informative References . . . . . . . . . . . . . . . . . . . . 15 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 54 Intellectual Property and Copyright Statements . . . . . . . . 17 56 1. Introduction 58 The Session Initiation Protocol (SIP) defines several specifications 59 that support Instant Messaging (IM). The SIP MESSAGE method [2] 60 allows for "page-mode" messaging, offering a service similar to Short 61 Message Service (SMS) in wireless networks. A more advanced 62 capability, called session mode messaging, uses the SIP INVITE method 63 to establish a session whose media type is messaging [8]. This allows 64 for many SIP capabilities to be directly applied to instant 65 messaging, such as conferencing [9]. 67 However, there are many additional features that exist in current, 68 proprietary IM systems. Some of these features do not require 69 protocol extensions in order to be deployed (IM message archival, for 70 example). However, others do. 72 This specification provides requirements for a number of advanced IM 73 features which require additional standardization activity to 74 support. It does not cover features which can be achieved with 75 existing protocols and specifications. It is also limited to instant 76 messaging only, and does not consider presence [5]. 78 2. Delivery Status Reporting 80 In most cases, an IM is delivered immediately to the recipient. 81 Indeed, this is the principal motivation behind the "Instant" in 82 "Instant Messaging". However, in many systems, and instant message 83 can be sent even when the recipient is not available. Indeed, even if 84 they are available when the message is sent, the user may log off 85 before the message can be delivered. 87 Typically, this is dealt with through a combination of two features. 88 The first is message archival and retrieval. These features allow the 89 intended recipient to retrieve their messages at a later time. To 90 support this, the receiving domain stores the content of the IM, 91 allowing the user to fetch it later. In this regard, it is very 92 similar to existing email systems. Existing protocols, such as IMAP4 93 [7], can be used for the retrieval functions of IM [[Note - is there 94 any need for an "IM" profile for IMAP, similar to the "voice" profile 95 for IMAP as specified in RFC 2421 [6]?]]. 97 The second feature is message delivery confirmation. This feature 98 allows the sender to know that the receiver has received the message. 99 This feature exists in SMS and in email [10]. A similar function is 100 needed for IP-based instant messaging. Indeed, it is provided in 101 several commercial IM systems, including Wireless Village. 103 Certainly, much of the email specifications for message delivery 104 confirmation can be reused for IM. However, much of it is 105 email-specific, and IM introduces some new requirements. The 106 following requirements apply to IM delivery status notifications: 108 REQ-DELNOT-1: It MUST be possible for the sender of an IM to 109 request a delivery notification. 111 REQ-DELNOT-2: It MUST be possible for the sender of an IM to learn 112 immediately that a delivery notification will, or will not, be 113 sent. 115 REQ-DELNOT-3: It MUST be possible for the delivery notification to 116 be sent at an arbitrary time in the future. 118 REQ-DELNOT-4: The delivery notification MUST be capable of 119 indicating that the message was delivered to the intended target. 121 REQ-DELNOT-5: The delivery notification MUST be capable of 122 indicating whether the message was delivered successfully, or 123 whether, when it was delivered, the recipient genreated an error. 124 It MUST be possible for the sender to learn the specific error 125 condition. 127 REQ-DELNOT-6: The delivery notification MUST indicate the time of 128 message delivery. 130 REQ-DELNOT-7: The delivery notification MUST indicate the specific 131 message which was delivered. 133 REQ-DELNOT-9: In order to support interaction conversations where 134 the sender can re-type their message if it is not received, the 135 delivery notifications MUST be sent rapidly when the message can 136 be immediately delivered. In this case, rapidly is loosely 137 defined, but generally, fast enough to support an interactive 138 conversation. 140 REQ-DELNOT-10: It MUST be possible for the message sender (the 141 recipient of the notification) to authenticate the sender of the 142 notification. There is no explicit requirement for confidentialy 143 of the notification. 145 REQ-DELNOT-11: As it is anticipated that this mechanism will be 146 used frequently from wireless devices, it SHOULD keep overhead to 147 a minimum, and in particular, SHOULD NOT provide extraneous 148 information not relevant to the above requirements. 150 REQ-DELNOT-12: When an IM is sent to a group, there MUST be 151 delivery notifications generated about the delivery of the IM to 152 each group participant. 154 REQ-DELNOT-13: REQ-DELNOT-12 MUST support recursive groups. 156 REQ-DELNOT-14: The identity of the ultimate recipient MUST be made 157 known to the message sender. 159 REQ-DELNOT-16: Any error condition reported by the notification 160 MAY contain a textual description of the error meant for human 161 consumption [[EDITORS NOTE: Do we need this?]] 163 REQ-DELNOT-17: If an IM is being relayed through a gateway, for 164 example, to SMS, the delivery report SHOULD indicate such a 165 condition [[EDITORS NOTE: Do we need this?]] 167 REQ-DELNOT-18: The delivery notification MUST indicate the 168 Content-Type of the message that was delivered. 170 REQ-DELNOT-19: The delivery notification MUST indicate the 171 Content-Length of the message that was delivered. 173 REQ-DELNOT-20: The delivery notification MUST indicate the To 174 header field from the message that was delivered. 176 REQ-DELNOT-21: The delivery notification MUST indicate the Expires 177 header field of the message that was delivered. 179 3. Is-Composing 181 Many commercial instant messaging and presence systems provide a 182 feature generally referred to as "is-typing". This feature is used 183 during instant messaging chat sessions. Whenever one user is in the 184 process of typing a message to another user, the recipient-to-be can 185 see that a message is in progress. This avoids a common problem where 186 both participants are typing replies at the same time, so that the 187 resulting stream of converation is not well synchronized. 189 Generalizing this concept, the idea is really to allow one 190 participant to inform another participant that they are composing a 191 message of some type. By conveying a type, a broader set of features 192 can be enabled. For example, if one user indicates that they are 193 composing a message of type audio/basic, the other user will know 194 that a voice IM is coming. 196 REQ-COMP-1: The is-composing feature must work with instant 197 messaging sessions [8]. 199 REQ-COMP-2: Either side in the session should be able to indicate 200 that they can receive the indicators. The indicators must not be 201 sent from A to B if B does not explicitly indicate that they can 202 receive them. 204 REQ-COMP-3: It must be possible for indicators to be sent in only 205 one direction, i.e., A sends them to B, but B does not send them 206 to A. 208 REQ-COMP-4: It must be possible for usage of the indicators to be 209 added or removed to any IM session after the session has begun. 211 REQ-COMP-5: The indicator must be able to inform the recipient 212 that the sender has begun composing a message. 214 REQ-COMP-6: The indicator must be able to inform the recipient 215 that the sender has stopped composing a message. 217 REQ-COMP-7: The indicator must be able to convey the MIME type of 218 the message that is being composed. 220 REQ-COMP-8: The indicator must be able to convey the 221 content-disposition of the message that is being composed. [Do we 222 want this requirement?] 224 REQ-COMP-9: The indicator must be synchrnonized with the message 225 stream itself. That is, if a recipient gets an indicator that a 226 user has stopped composing a message, and they also get a message, 227 the recipient must be able to know which came first. 229 REQ-COMP-10: It must be possible to provide end-to-end message 230 integrity and authentication over the indicators. 232 REQ-COMP-11: It must be possible to associate the is-composing 233 indicator with a particular instant messaging session. 235 REQ-COMP-12: It should be possible to interwork is-composing 236 indicators between CPIM compliant systems, possibly with some loss 237 of functionality, but with integrity and authentication in tact. 239 REQ-COMP-13: It should be possible for is-composing indicators to 240 work, possibly with loss of functionality, in page mode. [Do we 241 want this requirement?] 243 REQ-COMP-14: The is-composing indicator should not result in an 244 increase on the load of proxies. 246 REQ-COMP-15: It must be possible to receive delivery confirmation 247 reports for is-composing indicators [Do we need this requirement?] 249 REQ-COMP-16: The overhead of the indicators should be minimal. 251 4. Content Capabilities 253 Although traditionally used with text, an IM can contain any kind of 254 content. There is an increasing trend to send multimedia content, 255 including audio, video, and even applications, over IM. However, 256 recipients may not wish to receive content that they do not 257 understand, or is over a particular size limit. 259 Handling these "content capabilities" is done differently for page 260 mode and session mode. In session mode, the initial offer/answer 261 exchange [3] can be used to convey content capabilities. Indeed, the 262 messaging sessions mechanism allows for negotiation of supported 263 content types. However, some additional aspects of negotiation are 264 required: 266 REQ-CONTENT-1: A UA MUST be able to indicate the maximum message 267 size it is willing to receive. 269 In page mode messaging, a 413 response can be sent if a MESSAGE 270 request is too large. However, there is no way to indicate what the 271 largest allowed size is: 273 REQ-CONTENT-2: A 413 response MUST be capable of indicating the 274 maximum allowed message size. 276 Note that, there is no requirement to support transcoding of content 277 at an intermediary in order to reduce the size of a sent message to 278 match that of a recipient. 280 5. Page-Mode Groups 282 There is no explicit support for groups in page mode. Supporting 283 groups in session mode is trivial, and is completely handled through 284 the SIP conferencing specifications [9]. While there is no 285 expectations that the same level of features will be available in 286 page mode conferencing as session mode, some minimal features are 287 desirable. 289 REQ-GROUP-1: It MUST be possible to address a page-mode IM to a 290 group. 292 REQ-GROUP-2: Each recipient of a group page IM MUST be capable of 293 determining the set of other recipients that got the request. 295 REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc 296 group, where the identities of the recipients are carried in the 297 message itself. 299 REQ-GROUP-4: It MUST be possible for the recipient of a group IM 300 to send a message to all other participants that received the same 301 group IM (i.e., Reply-To-All). 303 [[Editors NOTE: It is not clear at all that we want to support any of 304 this. Session mode provides a much more comprehensive conferencing 305 story. Do we really want to add features for page mode??]] 307 5.1 Invitations to Non-Real-Time Sessions 309 SIP fundamentally deals with real-time sessions. That is, it allows 310 users to invite other users to communicate using some kind of 311 interactive media. However, there are many other types of "sessions", 312 in the broad sense of the word, that one can be invited to. As an 313 example, one user could invite another user to join an email mailing 314 list, to join a conference call occuring next week, or to view a web 315 site. 317 Specific desired capabilities are: 319 REQ-NRT-1: It MUST be possible to send a user a message requesting 320 that they perform some specific action. 322 REQ-NRT-2: The set of possible actions MUST include the ability to 323 request that a user add another user to their buddy list. 325 REQ-NRT-3: The set of possible actions MUST include the ability to 326 request the user to join a meeting scheduled at a specific time. 328 REQ-NRT-4: The set of possible actions MUST include the ability to 329 request the user to view a certain URL. 331 REQ-NRT-5: The set of possible actions MUST include the ability to 332 request the user to join a specific group (such as a page-mode 333 group IM list). 335 REQ-NRT-6: The set of actions MUST be easily extensible. 337 REQ-NRT-7: It MUST be possible for the sender to cancel the 338 request, i.e., ask that the user not bother to perform the 339 previous requested action. Of course, there is no expectation that 340 the request is honored, and no way to enforce it. The only 341 requirement is the ability to convey this desire. 343 REQ-NRT-8: It MUST be possible for the sender to learn when the 344 recipient has performed the desired action. 346 REQ-NRT-9: It MUST be possible for the sender to learn that the 347 recipient has received the request to perform the desired action. 349 REQ-NRT-10: It MUST be possible for the recipient to indicate that 350 they accept the invitation, reject it, or will defer it (consider 351 it later). 353 REQ-NRT-11: It MUST be possible for REQ-NRT-10, REQ-NRT-9 and 354 REQ-NRT-8 to occur at an arbitrarily long period of time after the 355 invitation was issued. 357 REQ-NRT-12: The set of actions MUST include the ability to ask a 358 user to initiate a Push-To-Talk session. 360 This capability is a hybrid between a traditional SIP INVITE and a 361 SIP MESSAGE. It is like INVITE in that it is accepted or rejected, 362 and can be cancelled. It is not like INVITE in that the acceptances 363 or rejections can come at any time, even days after the invitation. 364 In that sense, it is more like a MESSAGE. 366 6. IANA Considerations 368 There are no IANA Considerations associated with this specification. 370 7. Security Considerations 372 Security requirements are discussed above where relevant. 374 8. Acknowledgments 376 This draft includes requirements contributed by Aki Niemi [11]. 378 Informative References 380 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 381 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 382 Session Initiation Protocol", RFC 3261, June 2002. 384 [2] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and 385 D. Gurle, "Session Initiation Protocol (SIP) Extension for 386 Instant Messaging", RFC 3428, December 2002. 388 [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 389 Session Description Protocol (SDP)", RFC 3264, June 2002. 391 [4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant 392 Messaging / Presence Protocol Requirements", RFC 2779, February 393 2000. 395 [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 396 Instant Messaging", RFC 2778, February 2000. 398 [6] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail 399 - version 2", RFC 2421, September 1998. 401 [7] Crispin, M., "Internet Message Access Protocol - Version 402 4rev1", RFC 2060, December 1996. 404 [8] Campbell, B., "Instant Message Sessions in SIMPLE", 405 draft-ietf-simple-message-sessions-03 (work in progress), 406 January 2004. 408 [9] Rosenberg, J., "A Framework for Conferencing with the Session 409 Initiation Protocol", 410 draft-ietf-sipping-conferencing-framework-01 (work in 411 progress), October 2003. 413 [10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 414 Delivery Status Notifications", RFC 3464, January 2003. 416 [11] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless 417 Systems", draft-niemi-simple-im-wireless-reqs-02 (work in 418 progress), October 2003. 420 Author's Address 422 Jonathan Rosenberg 423 dynamicsoft 424 600 Lanidex Plaza 425 Parsippany, NJ 07054 426 US 428 Phone: +1 973 952-5000 429 EMail: jdrosen@dynamicsoft.com 430 URI: http://www.jdrosen.net 432 Intellectual Property Statement 434 The IETF takes no position regarding the validity or scope of any 435 intellectual property or other rights that might be claimed to 436 pertain to the implementation or use of the technology described in 437 this document or the extent to which any license under such rights 438 might or might not be available; neither does it represent that it 439 has made any effort to identify any such rights. Information on the 440 IETF's procedures with respect to rights in standards-track and 441 standards-related documentation can be found in BCP-11. Copies of 442 claims of rights made available for publication and any assurances of 443 licenses to be made available, or the result of an attempt made to 444 obtain a general license or permission for the use of such 445 proprietary rights by implementors or users of this specification can 446 be obtained from the IETF Secretariat. 448 The IETF invites any interested party to bring to its attention any 449 copyrights, patents or patent applications, or other proprietary 450 rights which may cover technology that may be required to practice 451 this standard. Please address the information to the IETF Executive 452 Director. 454 Full Copyright Statement 456 Copyright (C) The Internet Society (2004). All Rights Reserved. 458 This document and translations of it may be copied and furnished to 459 others, and derivative works that comment on or otherwise explain it 460 or assist in its implementation may be prepared, copied, published 461 and distributed, in whole or in part, without restriction of any 462 kind, provided that the above copyright notice and this paragraph are 463 included on all such copies and derivative works. However, this 464 document itself may not be modified in any way, such as by removing 465 the copyright notice or references to the Internet Society or other 466 Internet organizations, except as needed for the purpose of 467 developing Internet standards in which case the procedures for 468 copyrights defined in the Internet Standards process must be 469 followed, or as required to translate it into languages other than 470 English. 472 The limited permissions granted above are perpetual and will not be 473 revoked by the Internet Society or its successors or assignees. 475 This document and the information contained herein is provided on an 476 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 477 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 478 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 479 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 480 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 482 Acknowledgment 484 Funding for the RFC Editor function is currently provided by the 485 Internet Society.