Network Working Group A. Niemi Internet-Draft Nokia Expires: April 24, 2003 October 24, 2002 Requirements for Instant Messaging in 3GPP Wireless Systems draft-niemi-simple-im-wireless-reqs-00 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 April 24, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document lists the requirements specific to 3GPP wireless Instant Messaging systems. Niemi Expires April 24, 2003 [Page 1] Internet-Draft 3GPP Reqs for IM October 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Characteristics of Wireless Systems . . . . . . . . . 4 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Addressing Requirements . . . . . . . . . . . . . . . . . . . 4 3.2 Message Content Requirements . . . . . . . . . . . . . . . . . 4 3.3 Data Manipulation and Management Requirements . . . . . . . . 5 3.4 Message Delivery and Handling Requirements . . . . . . . . . . 5 3.5 User Privacy Requirements . . . . . . . . . . . . . . . . . . 6 4. Charging Requirements . . . . . . . . . . . . . . . . . . . . 6 5. Security Requirements . . . . . . . . . . . . . . . . . . . . 6 6. Proposal for Next Steps . . . . . . . . . . . . . . . . . . . 6 Normative References . . . . . . . . . . . . . . . . . . . . . 6 Informative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Niemi Expires April 24, 2003 [Page 2] Internet-Draft 3GPP Reqs for IM October 2002 1. Introduction This document lists the requirements for instant messaging based on 3GPP specifications and the special characteristics of a wireless environment. The requirements presented in this document complement the requirements in [1], and relate to already ongoing work in the SIMPLE WG. These requirements are proposed to be evaluated by the working group, and incorporated in the relevant work items. 1.1 System Overview Within the 3GPP IP Multimedia Subsystem (IMS) Messaging work, two types of messaging services [4] have been identified: Immediate Messaging A sender expects near real time message delivery. Typically, the sender is aware of the availability of the recipient a priori, possibly through the use of the presence service. Session Based Messaging A sender and a recipient have to join a messaging session before messages can be exchanged as part of the session. The participants of the session expect near real time delivery of messages. Mainly, the intended application for session based messaging are multiparty messaging sessions, i.e., chat rooms, where a group of participants exhange instant messages with each others. Both of these two messaging service types have properties which make the Session Initiation Protocol (SIP) [5] very suitable for addressing their requirements. Hence, the charter items in the SIMPLE working group for defining instant messaging and message sessions using SIP are considered as targets for the requirements presented in this memo. Note that some of the requirements herein may be more related to the data manipulation requirements of SIMPLE systems [6], and the SIP conferencing requirements [7] work in the SIPPING WG. 1.2 Conventions 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 BCP 14, RFC 2119 [2]. In this document, terms "immediate messaging" and "instant messaging" are interchangeable. Also, "message sessions" are used in place of Niemi Expires April 24, 2003 [Page 3] Internet-Draft 3GPP Reqs for IM October 2002 "session based messaging" to better align the terminology used in the 3GPP and IETF. Note that the term "session based messaging" used by the 3GPP IMS messaging often includes the notion of a multiparty message session, which includes both conferencing and message sessions as components. 2. General Characteristics of Wireless Systems The radio interface of wireless systems is often a scarce resource. As such, the message exchange over the radio interface should be efficiently compact and kept to a minimum. All the mechanisms developed should make efficient use of the radio interface. As terminals can be rather small devices, the memory and power consumption requirements, requirements for processing power, and for screen size and rendering capabilities should be kept to a minimum. Mandating support for additional protocols and mechanisms in the wireless terminal must meet these criteria. 3. Requirements This section lists the requirements for Instant Messaging in the 3GPP IMS wireless environment. Generally, these protocol requirements stem from the special characteristics of wireless systems, and the specific set of capabilities specified by the 3GPP. More information on these aspects can be found in 3GPP TS 23.228 [8]. 3.1 Addressing Requirements It MUST be possible to use a single address to identify the recipient or sender of an instant message or a member in a message session, irrespective of the messaging system. Use of E.164 numbers [3] in addressing instant messages and message session requests MUST be supported. 3.2 Message Content Requirements It MUST be possible to carry any MIME encoded data in Instant Messages and message sessions. The content size MUST NOT be limited by the Instant Messaging, or message session protocols. Additionally, it MUST be possible to send the entire message body, or parts of the body in a way that allows the recipient to choose between receiv¨ng the body and ignoring it. Niemi Expires April 24, 2003 [Page 4] Internet-Draft 3GPP Reqs for IM October 2002 Messages MUST be able to carry multiple MIME objects, and sequencing of media MUST be supported. OPEN ISSUE: The sequencing requirement is somewhat unclear. It MUST be possible for the UA to announce its callee capabilities for messaging. Similarly, it MUST also be possible to base handling of instant messages on these user capabilities and preferences. 3.3 Data Manipulation and Management Requirements It MUST be possible to create new Address-of-Records (AOR) for message session based conferences, i.e., chat rooms. These AORs are either ad-hoc style for short lived conferences, or persistent, if the identification of a conference focus is long lived. There MUST be a standardized mechanism by which such ad-hoc or persistent AORs can be created, applied, and discarded by the user. It MUST be possible for an administrator (or any user with appropriate access rights) of a chat room to control the list of allowed participants. There MUST be a standardized mechanism by which such authorization policy is inserted, manipulated and removed. There MUST be a standard mechanism for an end device to learn the address of the data manipulation interface used for performing the aforementioned control functions of a chat room. There MUST be standardized mechanisms by which an administrator (or any user with appropriate access rights) of a chat room can invite new participants to the chat room, and kick out existing participants. It MUST be possible for the administrator of a chat room to set the properties of a chat room, e.g., name, topic, and maximum number of participants. There MUST be a standardized mechanism by which such properties are set, manipulated, and removed. 3.4 Message Delivery and Handling Requirements It MUST be possible to divert or block instant messages as part of a user configurable option. Such mechanisms MUST support instant message diversion based on sender address, message size, message priority, message subject, message class and message content type. The mechanism MAY support instant message diversion based on other message properties. It MUST be possible for the sender of an instant message to receive either positive or negative acknowledgements of delivery for all sent Niemi Expires April 24, 2003 [Page 5] Internet-Draft 3GPP Reqs for IM October 2002 messages. 3.5 User Privacy Requirements It MUST be possible for a recipient of an instant message or a message session to see the identity of the originator, unless the originator is anonymous or its address is hidden. It MUST be possible to originate anonymous instant messages and message sessions. It MUST be possible to originate instant messages and message sessions using pseudonyms, or nicknames. It MUST be possible to send private messages between the participants of a multiparty message session. It MUST be possible to send private messages to participants who are using pseudonym identities or nicknames. Also, it MUST be possible to send private messages using a nickname or an anonymous identity. A private message MUST be delivered in the context of the ongoing multiparty message session, and messages intended for private consumption MUST NOT be delivered to other than the intended recipient. 4. Charging Requirements This document refers to the charging requirements of [1], and does not list any additional charging requirements at this time. 5. Security Requirements This document adopts the security requirements listed in [1], and does not introduce any additional security requirements at this time. 6. Proposal for Next Steps It is proposed that the SIMPLE Working Group evaluates the requirements presented in this document and incorporates the relevant ones in its current work items. Those requirements possibly falling out of the scope of the SIMPLE WG should find a more suitable home, possibly also in other standardization bodies. Normative References [1] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", draft-ietf-sipping-3gpp-r5-requirements-00 (work in progress), October 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Niemi Expires April 24, 2003 [Page 6] Internet-Draft 3GPP Reqs for IM October 2002 [3] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 1991. Informative References [4] 3rd Generation Partnership Project, "IMS Messaging", TR 22.940, August 2002. [5] 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. [6] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in SIMPLE Systems", draft-ietf-simple-data-req-00 (work in progress), October 2002. [7] Levin, O., "Requirements for Tightly Coupled SIP Conferencing", draft-levin-sipping-conferencing-requirements-01 (work in progress), July 2002. [8] 3rd Generation Partnership Project, "IP Multimedia Subsystem (IMS)", TS 23.228, August 2002. Author's Address Aki Niemi Nokia P.O. Box 301 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Appendix A. Acknowledgements The authors would like to thank the following people for their interest, support and efforts in the IMS messaging work: Andrew Allen (dynamicsoft), Gabor Bajko (Nokia), Balazs Bertenyi (Nokia), Keith Drage (Lucent Technologies), Alexandre Harmand (mmO2), Juha Kalliokulju (Nokia), Krisztian Kiss (Nokia), Duncan Mills (Vodafone), and Milo Orsic (Lucent Technologies). Although not an official communication of the 3GPP, this document has been discussed and commented by a number of delegates in the relevant Niemi Expires April 24, 2003 [Page 7] Internet-Draft 3GPP Reqs for IM October 2002 3GPP working groups. Niemi Expires April 24, 2003 [Page 8] Internet-Draft 3GPP Reqs for IM October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Niemi Expires April 24, 2003 [Page 9]