SIMPLE M. Isomaki Internet-Draft Nokia Intended status: Informational J. Rosenberg Expires: December 24, 2006 Cisco Systems June 22, 2006 Advanced Instant Messaging Requirements for the Session Initiation Protocol (SIP) draft-ietf-simple-messaging-requirements-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 24, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Session Initiation Protocol (SIP) supports the basic instant messaging service in both page and session mode. This document defines a set of requirements for instant messaging capabilities that are beyond the scope of the baseline specifications. Isomaki & Rosenberg Expires December 24, 2006 [Page 1] Internet-Draft IM Requirements June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Instant Messaging Disposition Notifications . . . . . . . . . 3 4. Is-Composing . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Content Capabilities . . . . . . . . . . . . . . . . . . . . . 7 6. Page-Mode Groups . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Isomaki & Rosenberg Expires December 24, 2006 [Page 2] Internet-Draft IM Requirements June 2006 1. Introduction The Session Initiation Protocol (SIP) defines several specifications that support Instant Messaging (IM). The SIP MESSAGE method [3] allows for "page-mode" messaging, offering a service in some aspects 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 where messages are transported using Message Session Relay Protocol (MSRP) [9]. This makes it possible to combine messaging with other media such as audio and video. Also, many regular SIP capabilities to be directly applied to instant messaging, such as conferencing [10]. 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 document provides requirements for a number of advanced IM features which require additional standardization activity in addition to the basic SIP MESSAGE and MSRP work. For some of the requirements presented here the relevant standardization work has actully been already concluded. In those cases the related specifications are called out and referenced. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations. 3. Instant Messaging Disposition Notifications 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, an 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. In addition to basic delivery reporting, the sender may be interested when the recipient has actually "read" the message or the message has been at least displayed to the user in some way. Typically, this is dealt with through a combination of two features. Isomaki & Rosenberg Expires December 24, 2006 [Page 3] Internet-Draft IM Requirements June 2006 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 [8], can be used for the retrieval functions of IM. The second feature is message disposition notification. This feature allows the sender to be notified when the message has been delivered to the recipient and when the recipient has "read" the message. This feature exists in SMS, email [11] and several commercia IM systems. A similar function is needed for SIP-based instant messaging. 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 disposition notifications: REQ-DISNOT-1: It MUST be possible for the sender of an IM to request a delivery notification and/or a read notification. REQ-DISNOT-2: It MUST be possible for the recipient of the message to immediately indicate to the sender that the recipient supports delivery and/or read notifications. REQ-DISNOT-3: It MUST be possible that the disposition notifications can be sent and received at any point in the future after the actual IM has been sent, without introducing any limits on such a time window. REQ-DISNOT-4: The delivery notification MUST be capable of indicating that the message was delivered to the intended target. REQ-DISNOT-5: The delivery notification MUST be capable of indicating whether the message was delivered successfully, or whether, when it was delivered, the recipient geneeated an error. It MUST be possible for the sender to learn the specific error condition. REQ-DISNOT-6: The disposition notification MUST indicate the time when the message was delivered or read. REQ-DISNOT-7: The disposition notification MUST contain enough information to allow the sender of the original IM to correlate the notification with the correct message, provided that the sender has stored the contents of the sent message. In addition the notification MUST be able to carry information that might be helpful to a sender who no longer has the original message Isomaki & Rosenberg Expires December 24, 2006 [Page 4] Internet-Draft IM Requirements June 2006 available, such as the original To, From, Content-Type and Content-Length headers. REQ-DISNOT-8: 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-DISNOT-9: 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-DISNOT-10: When an IM is sent to an intermediary that will relay it to a group of recipients, it MUST be possible for the sender to ask that disposition notifications are generated by each final recipient separately. REQ-DISNOT-11: When an IM is sent to an intermediary that will relay it to a group of recipients, it MUST be possible for the sender to ask that the intermediary will generate summary reports based on reports it receives from each final recipient. [OPEN ISSUE: Is this needed?] REQ-DELNOT-12: Any error condition reported by the notification MAY contain a textual description of the error meant for human consumption [OPEN ISSUE: How about internationalization?] REQ-DELNOT-13: If an IM is being relayed through a gateway, for example, to SMS, the delivery report SHOULD be able to indicate such a condition [OPEN ISSUE: Is this needed?]] 4. 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 Isomaki & Rosenberg Expires December 24, 2006 [Page 5] Internet-Draft IM Requirements June 2006 composing a message of type audio/basic, the other user will know that a voice IM is coming. The specification of how is-composing indicators are generated and represented is available as RFC 3994 [13]. It has been designed based on the requirements listed in this Section. REQ-COMP-1: The is-composing feature MUST work with instant messaging sessions [9]. 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 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, the recipient must be able to know which came first. REQ-COMP-9: It must be possible to provide end-to-end message integrity and authentication over the indicators. REQ-COMP-10: It must be possible to associate the is-composing indicator with a particular instant messaging session. REQ-COMP-11: 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. Isomaki & Rosenberg Expires December 24, 2006 [Page 6] Internet-Draft IM Requirements June 2006 REQ-COMP-12: It should be possible for is-composing indicators to work, possibly with loss of functionality, in page mode. REQ-COMP-13: The is-composing indicator should not result in an increase on the load of proxies. REQ-COMP-14: It must be possible to receive delivery confirmation reports for is-composing indicators [OPEN ISSUE: This is related to the question on whether disposition notifications will be supported for session-mode messaging.] REQ-COMP-15: The overhead of the indicators should be minimal. 5. 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 [4] 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. This requirement has been met in MSRP via the a=max-size attribute. 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. [OPEN ISSUE: Is this needed?] 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. Isomaki & Rosenberg Expires December 24, 2006 [Page 7] Internet-Draft IM Requirements June 2006 6. Page-Mode Groups The baseline SIP MESSAGE specification does not have explicit support for sending page mode messages to groups or multiple recipients. This capability is addressed by the Multi-recipient MESSAGE request [12] specification to meet the following requirements. 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). 7. IANA Considerations There are no IANA Considerations associated with this specification. 8. Security Considerations Security requirements are discussed above where relevant. 9. Acknowledgments This draft includes requirements contributed by Aki Niemi [14]. Eric Burger, Ben Campbell, Hisham Khartabil, Paul Kyzivat, Aki Niemi, Sean Olson and Robert Sparks provided valuable comments. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Isomaki & Rosenberg Expires December 24, 2006 [Page 8] Internet-Draft IM Requirements June 2006 10.2. Informative References [2] 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. [3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [5] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [7] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998. [8] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. [9] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-14 (work in progress), February 2006. [10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006. [11] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [12] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)", draft-ietf-sipping-uri-list-message-07 (work in progress), February 2006. [13] Schulzrinne, H., "Indication of Message Composition for Instant Messaging", RFC 3994, January 2005. [14] Niemi, A., "Requirements for Instant Messaging in 3GPP Wireless Systems", draft-niemi-simple-im-wireless-reqs-02 (work in progress), October 2003. Isomaki & Rosenberg Expires December 24, 2006 [Page 9] Internet-Draft IM Requirements June 2006 Authors' Addresses Markus Isomaki Nokia Keilalahdentie 2-4 Helsinki, 02150 Finland Phone: +358 50 5225984 Email: markus.isomaki@nokia.com Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 Email: jdrosen@cisco.com URI: http://www.jdrosen.net Isomaki & Rosenberg Expires December 24, 2006 [Page 10] Internet-Draft IM Requirements June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Isomaki & Rosenberg Expires December 24, 2006 [Page 11]