SIMPLE WG R. Mahy Internet-Draft C. Jennings Expires: August 9, 2004 Cisco Systems, Inc. O. Levin Microsoft Corporation A. Houri IBM M. Barnes Nortel Networks February 9, 2004 SIMPLE Session and Relay IM Protocol Requirements draft-mahy-simple-im-protocol-reqs-00.txt 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 9, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines requirements for sessions of messages in SIMPLE. These requirements apply to the Message Session Relay Protocol (MSRP). Mahy, et al. Expires August 9, 2004 [Page 1] Internet-Draft SIMPLE IM Protocol Requirements February 2004 1. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 2. Introduction and Requirements The IETF SIMPLE working group has identified a number of scenarios where using a separate protocol for bulk messaging is desirable. In particular, the SIMPLE WG will use this facility to handle a sequence of messages as a session of media setup using SIP just like any other media. The Message Session Relay Protocol (MSRP) [2] defines a protocol for delivering such messages point-to-point, but does not define any relay functionality. This document takes into consideration the "Guidelines for Instant Message Sessions" [3] and brings into the focus essential requirements on the MSRP core protocol and additional requirements for extensions to MSRP that define relay functionality. 2.1 MSRP Core Requirements o Transport level security: It MUST be possible to negotiate the desired security modes such as TLS only. For systems that support TLS, TLS is used, but for systems that only do TCP, possible to gracefully fall back to TCP from client. o Inter-domain link authentication: It MUST be possible to authenticate the link using mutual TLS. o Additional security schemes: IM protocol MUST allow for additional security schemes to be introduced later. o Features negotiation: It MUST be possible to announce or negotiate different basic and advanced IM protocol features with fine granularity. Protocol needs to support "forward compatibility" where one client can tell the other client what features it supports. o Message type negotiation: It MUST be possible to negotiate the desired message formats. o Transactional message delivery: IM protocol MUST support request-response transaction per message. o Transaction overlapping: IM protocol MUST allow for overlapping transactions. o Non-transactional message delivery: IM protocol MUST support "send and forget" mode per message. Future message delivery modes: IM protocol MUST allow for additional modes to be introduced later per message. o Order of messages: IM protocol MUST ensure the order of messages in a session. o Original sender's identification: IM protocol MUST include sender's identification per message for each of the possible Mahy, et al. Expires August 9, 2004 [Page 2] Internet-Draft SIMPLE IM Protocol Requirements February 2004 message formats. This is in order to facilitate conferencing scenarios. Even though the IM is coming from the conference system, it needs to say which person sent it to the conference system. o Session's identification: It MUST be possible to include session's identification per message (for each of the possible message formats). That is in order to facilitate multiplexing extensions. o MIME: IM protocol MUST be able convey arbitrary binary MIME data. o Peer-2-Peer: IM protocol MUST support client to client operation (no relays required). 2.2 MSRP Relay Requirements o Multiple relays: IM protocol MUST support operating through an arbitrary number of relays for policy enforcement. o Path by client: IM protocol MUST allow each client to specify which relays are traversed on its behalf. o Path by administrator: IM protocol MUST allow enterprise network administrators to insist on a policy of using relays. o Relay-to-relay features negotiation: It MUST be possible to announce or negotiate different basic and advanced IM protocol features with fine granularity. Protocol needs to support "forward compatibility" where one relay can tell the other relay what features it supports. o Relay-to-client features negotiation: It MUST be possible to announce or negotiate different basic and advanced IM protocol features with fine granularity. Protocol needs to support "forward compatibility" where a relay and a client can tell each other what features it supports. o Congestion control: The protocol MUST have adequate congestion control properties. This means traffic between relays or clients that are sending many messages must compete fairly with other TCP flows and display adequate back off during congestion. o DOS prevention: IM protocol MUST prevent SMTP style "open relays", and denial of service amplification. o Multiplexing: IM protocol MUST allow relays to use one or a small number of TCP or TLS connections to carry messages for multiple sessions, recipients, and senders. o Large messages: IM protocol MUST allow large messages to be sent over a slow connection without causing head-of-line blocking problems. o Restart: IM protocol MUST allow transmission of a large message to be interrupted and resumed in place when network connectivity is lost and later reestablished. o End-2-end notification: IM protocol MUST offer end-to-end notification of message receipt. o Storage notification: IM Protocol MUST offer notification of message storage (desirable). Mahy, et al. Expires August 9, 2004 [Page 3] Internet-Draft SIMPLE IM Protocol Requirements February 2004 o Transient state: IM Protocol MUST allow relays to delete state after a short amount of time (order 30 seconds). 3. Acknowledgments The authors thank the following members of the SIMPLE WG for spirited discussions on session mode: Ben Campbell, Jonathan Rosenberg, Robert Sparks, Paul Kyzivat, Allison Mankin, Jon Peterson, Brian Rosen, Dean Willis, Adam Roach, Aki Niemi, Hisham Khartabil, Pekka Pessi, and Chris Boulton. The authors also thank the MSN IM Group of Microsoft for sharing their experience and for providing important inputs to this document. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Informative References [2] Campbell, B., "Instant Message Sessions in SIMPLE", draft-ietf-simple-message-sessions-03 (work in progress), January 2004. [3] Mankin, A., Peterson, J., "Guidelines for Instant Message Sessions", draft-mankin-im-session-guide-00 (work in progress), November 2001. Authors' Addresses Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066 USA EMail: rohan@cisco.com Mahy, et al. Expires August 9, 2004 [Page 4] Internet-Draft SIMPLE IM Protocol Requirements February 2004 Cullen Jennings Cisco Systems, Inc. 170 West Tasman Dr. MS: SJC-21/3 San Jose, CA 95134 USA Phone: +1 408 527-9132 EMail: fluffy@cisco.com Orit Levin Microsoft Corporation One Microsoft Way MS 30/3085 Redmond, WA 98052-6399 USA Phone: +1 425 722-2225 EMail: oritl@microsoft.com Avshalom Houri IBM Science Park Building 18/D Rehovot Israel Phone: +972 8 940-9761 Ext. 123 EMail: avshalom@il.ibm.com Mary Barnes Nortel Networks 2380 Performance Drive Richardson, TX USA Phone: +1 972 684-5432 EMail: mary.barnes@nortelnetworks.com Mahy, et al. Expires August 9, 2004 [Page 5] Internet-Draft SIMPLE IM Protocol 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 Mahy, et al. Expires August 9, 2004 [Page 6] Internet-Draft SIMPLE IM Protocol 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. Mahy, et al. Expires August 9, 2004 [Page 7]