SIMPLE J. Rosenberg Internet-Draft dynamicsoft Expires: August 12, 2004 February 12, 2004 Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP) draft-rosenberg-simple-messaging-requirements-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 12, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This specification defines a set of requirements for new capabilities for instant messaging in SIP-based systems. Rosenberg Expires August 12, 2004 [Page 1] Internet-Draft IM Requirements February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Delivery Status Reporting . . . . . . . . . . . . . . . . . . 4 3. Is-Composing . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Content Capabilities . . . . . . . . . . . . . . . . . . . . . 9 5. Page-Mode Groups . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Invitations to Non-Real-Time Sessions . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Rosenberg Expires August 12, 2004 [Page 2] Internet-Draft IM Requirements February 2004 1. Introduction The Session Initiation Protocol (SIP) defines several specifications that support Instant Messaging (IM). The SIP MESSAGE method [2] allows for "page-mode" messaging, offering a service similar to Short Message Service (SMS) in wireless networks. A more advanced capability, called session mode messaging, uses the SIP INVITE method to establish a session whose media type is messaging [8]. This allows for many SIP capabilities to be directly applied to instant messaging, such as conferencing [9]. However, there are many additional features that exist in current, proprietary IM systems. Some of these features do not require protocol extensions in order to be deployed (IM message archival, for example). However, others do. This specification provides requirements for a number of advanced IM features which require additional standardization activity to support. It does not cover features which can be achieved with existing protocols and specifications. It is also limited to instant messaging only, and does not consider presence [5]. Rosenberg Expires August 12, 2004 [Page 3] Internet-Draft IM Requirements February 2004 2. Delivery Status Reporting In most cases, an IM is delivered immediately to the recipient. Indeed, this is the principal motivation behind the "Instant" in "Instant Messaging". However, in many systems, and instant message can be sent even when the recipient is not available. Indeed, even if they are available when the message is sent, the user may log off before the message can be delivered. Typically, this is dealt with through a combination of two features. The first is message archival and retrieval. These features allow the intended recipient to retrieve their messages at a later time. To support this, the receiving domain stores the content of the IM, allowing the user to fetch it later. In this regard, it is very similar to existing email systems. Existing protocols, such as IMAP4 [7], can be used for the retrieval functions of IM [[Note - is there any need for an "IM" profile for IMAP, similar to the "voice" profile for IMAP as specified in RFC 2421 [6]?]]. The second feature is message delivery confirmation. This feature allows the sender to know that the receiver has received the message. This feature exists in SMS and in email [10]. A similar function is needed for IP-based instant messaging. Indeed, it is provided in several commercial IM systems, including Wireless Village. Certainly, much of the email specifications for message delivery confirmation can be reused for IM. However, much of it is email-specific, and IM introduces some new requirements. The following requirements apply to IM delivery status notifications: REQ-DELNOT-1: It MUST be possible for the sender of an IM to request a delivery notification. REQ-DELNOT-2: It MUST be possible for the sender of an IM to learn immediately that a delivery notification will, or will not, be sent. REQ-DELNOT-3: It MUST be possible for the delivery notification to be sent at an arbitrary time in the future. REQ-DELNOT-4: The delivery notification MUST be capable of indicating that the message was delivered to the intended target. REQ-DELNOT-5: The delivery notification MUST be capable of indicating whether the message was delivered successfully, or whether, when it was delivered, the recipient genreated an error. It MUST be possible for the sender to learn the specific error condition. Rosenberg Expires August 12, 2004 [Page 4] Internet-Draft IM Requirements February 2004 REQ-DELNOT-6: The delivery notification MUST indicate the time of message delivery. REQ-DELNOT-7: The delivery notification MUST indicate the specific message which was delivered. REQ-DELNOT-9: In order to support interaction conversations where the sender can re-type their message if it is not received, the delivery notifications MUST be sent rapidly when the message can be immediately delivered. In this case, rapidly is loosely defined, but generally, fast enough to support an interactive conversation. REQ-DELNOT-10: It MUST be possible for the message sender (the recipient of the notification) to authenticate the sender of the notification. There is no explicit requirement for confidentialy of the notification. REQ-DELNOT-11: As it is anticipated that this mechanism will be used frequently from wireless devices, it SHOULD keep overhead to a minimum, and in particular, SHOULD NOT provide extraneous information not relevant to the above requirements. REQ-DELNOT-12: When an IM is sent to a group, there MUST be delivery notifications generated about the delivery of the IM to each group participant. REQ-DELNOT-13: REQ-DELNOT-12 MUST support recursive groups. REQ-DELNOT-14: The identity of the ultimate recipient MUST be made known to the message sender. REQ-DELNOT-16: Any error condition reported by the notification MAY contain a textual description of the error meant for human consumption [[EDITORS NOTE: Do we need this?]] REQ-DELNOT-17: If an IM is being relayed through a gateway, for example, to SMS, the delivery report SHOULD indicate such a condition [[EDITORS NOTE: Do we need this?]] REQ-DELNOT-18: The delivery notification MUST indicate the Content-Type of the message that was delivered. REQ-DELNOT-19: The delivery notification MUST indicate the Content-Length of the message that was delivered. Rosenberg Expires August 12, 2004 [Page 5] Internet-Draft IM Requirements February 2004 REQ-DELNOT-20: The delivery notification MUST indicate the To header field from the message that was delivered. REQ-DELNOT-21: The delivery notification MUST indicate the Expires header field of the message that was delivered. Rosenberg Expires August 12, 2004 [Page 6] Internet-Draft IM Requirements February 2004 3. Is-Composing Many commercial instant messaging and presence systems provide a feature generally referred to as "is-typing". This feature is used during instant messaging chat sessions. Whenever one user is in the process of typing a message to another user, the recipient-to-be can see that a message is in progress. This avoids a common problem where both participants are typing replies at the same time, so that the resulting stream of converation is not well synchronized. Generalizing this concept, the idea is really to allow one participant to inform another participant that they are composing a message of some type. By conveying a type, a broader set of features can be enabled. For example, if one user indicates that they are composing a message of type audio/basic, the other user will know that a voice IM is coming. REQ-COMP-1: The is-composing feature must work with instant messaging sessions [8]. REQ-COMP-2: Either side in the session should be able to indicate that they can receive the indicators. The indicators must not be sent from A to B if B does not explicitly indicate that they can receive them. REQ-COMP-3: It must be possible for indicators to be sent in only one direction, i.e., A sends them to B, but B does not send them to A. REQ-COMP-4: It must be possible for usage of the indicators to be added or removed to any IM session after the session has begun. REQ-COMP-5: The indicator must be able to inform the recipient that the sender has begun composing a message. REQ-COMP-6: The indicator must be able to inform the recipient that the sender has stopped composing a message. REQ-COMP-7: The indicator must be able to convey the MIME type of the message that is being composed. REQ-COMP-8: The indicator must be able to convey the content-disposition of the message that is being composed. [Do we want this requirement?] REQ-COMP-9: The indicator must be synchrnonized with the message stream itself. That is, if a recipient gets an indicator that a user has stopped composing a message, and they also get a message, Rosenberg Expires August 12, 2004 [Page 7] Internet-Draft IM Requirements February 2004 the recipient must be able to know which came first. REQ-COMP-10: It must be possible to provide end-to-end message integrity and authentication over the indicators. REQ-COMP-11: It must be possible to associate the is-composing indicator with a particular instant messaging session. REQ-COMP-12: It should be possible to interwork is-composing indicators between CPIM compliant systems, possibly with some loss of functionality, but with integrity and authentication in tact. REQ-COMP-13: It should be possible for is-composing indicators to work, possibly with loss of functionality, in page mode. [Do we want this requirement?] REQ-COMP-14: The is-composing indicator should not result in an increase on the load of proxies. REQ-COMP-15: It must be possible to receive delivery confirmation reports for is-composing indicators [Do we need this requirement?] REQ-COMP-16: The overhead of the indicators should be minimal. Rosenberg Expires August 12, 2004 [Page 8] Internet-Draft IM Requirements February 2004 4. Content Capabilities Although traditionally used with text, an IM can contain any kind of content. There is an increasing trend to send multimedia content, including audio, video, and even applications, over IM. However, recipients may not wish to receive content that they do not understand, or is over a particular size limit. Handling these "content capabilities" is done differently for page mode and session mode. In session mode, the initial offer/answer exchange [3] can be used to convey content capabilities. Indeed, the messaging sessions mechanism allows for negotiation of supported content types. However, some additional aspects of negotiation are required: REQ-CONTENT-1: A UA MUST be able to indicate the maximum message size it is willing to receive. In page mode messaging, a 413 response can be sent if a MESSAGE request is too large. However, there is no way to indicate what the largest allowed size is: REQ-CONTENT-2: A 413 response MUST be capable of indicating the maximum allowed message size. Note that, there is no requirement to support transcoding of content at an intermediary in order to reduce the size of a sent message to match that of a recipient. Rosenberg Expires August 12, 2004 [Page 9] Internet-Draft IM Requirements February 2004 5. Page-Mode Groups There is no explicit support for groups in page mode. Supporting groups in session mode is trivial, and is completely handled through the SIP conferencing specifications [9]. While there is no expectations that the same level of features will be available in page mode conferencing as session mode, some minimal features are desirable. REQ-GROUP-1: It MUST be possible to address a page-mode IM to a group. REQ-GROUP-2: Each recipient of a group page IM MUST be capable of determining the set of other recipients that got the request. REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc group, where the identities of the recipients are carried in the message itself. REQ-GROUP-4: It MUST be possible for the recipient of a group IM to send a message to all other participants that received the same group IM (i.e., Reply-To-All). [[Editors NOTE: It is not clear at all that we want to support any of this. Session mode provides a much more comprehensive conferencing story. Do we really want to add features for page mode??]] 5.1 Invitations to Non-Real-Time Sessions SIP fundamentally deals with real-time sessions. That is, it allows users to invite other users to communicate using some kind of interactive media. However, there are many other types of "sessions", in the broad sense of the word, that one can be invited to. As an example, one user could invite another user to join an email mailing list, to join a conference call occuring next week, or to view a web site. Specific desired capabilities are: REQ-NRT-1: It MUST be possible to send a user a message requesting that they perform some specific action. REQ-NRT-2: The set of possible actions MUST include the ability to request that a user add another user to their buddy list. REQ-NRT-3: The set of possible actions MUST include the ability to request the user to join a meeting scheduled at a specific time. Rosenberg Expires August 12, 2004 [Page 10] Internet-Draft IM Requirements February 2004 REQ-NRT-4: The set of possible actions MUST include the ability to request the user to view a certain URL. REQ-NRT-5: The set of possible actions MUST include the ability to request the user to join a specific group (such as a page-mode group IM list). REQ-NRT-6: The set of actions MUST be easily extensible. REQ-NRT-7: It MUST be possible for the sender to cancel the request, i.e., ask that the user not bother to perform the previous requested action. Of course, there is no expectation that the request is honored, and no way to enforce it. The only requirement is the ability to convey this desire. REQ-NRT-8: It MUST be possible for the sender to learn when the recipient has performed the desired action. REQ-NRT-9: It MUST be possible for the sender to learn that the recipient has received the request to perform the desired action. REQ-NRT-10: It MUST be possible for the recipient to indicate that they accept the invitation, reject it, or will defer it (consider it later). REQ-NRT-11: It MUST be possible for REQ-NRT-10, REQ-NRT-9 and REQ-NRT-8 to occur at an arbitrarily long period of time after the invitation was issued. REQ-NRT-12: The set of actions MUST include the ability to ask a user to initiate a Push-To-Talk session. This capability is a hybrid between a traditional SIP INVITE and a SIP MESSAGE. It is like INVITE in that it is accepted or rejected, and can be cancelled. It is not like INVITE in that the acceptances or rejections can come at any time, even days after the invitation. In that sense, it is more like a MESSAGE. Rosenberg Expires August 12, 2004 [Page 11] Internet-Draft IM Requirements February 2004 6. IANA Considerations There are no IANA Considerations associated with this specification. Rosenberg Expires August 12, 2004 [Page 12] Internet-Draft IM Requirements February 2004 7. Security Considerations Security requirements are discussed above where relevant. Rosenberg Expires August 12, 2004 [Page 13] Internet-Draft IM Requirements February 2004 8. Acknowledgments This draft includes requirements contributed by Aki Niemi [11]. Rosenberg Expires August 12, 2004 [Page 14] Internet-Draft IM Requirements February 2004 Informative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [6] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. [7] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. [8] Campbell, B., "Instant Message Sessions in SIMPLE", draft-ietf-simple-message-sessions-03 (work in progress), January 2004. [9] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-01 (work in progress), October 2003. [10] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [11] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless Systems", draft-niemi-simple-im-wireless-reqs-02 (work in progress), October 2003. Rosenberg Expires August 12, 2004 [Page 15] Internet-Draft IM Requirements February 2004 Author's Address Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg Expires August 12, 2004 [Page 16] Internet-Draft IM Requirements February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rosenberg Expires August 12, 2004 [Page 17] Internet-Draft IM Requirements February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires August 12, 2004 [Page 18]