Network Working Group A. Niemi Internet-Draft Nokia Expires: August 28, 2003 February 27, 2003 Requirements for Instant Messaging in 3GPP Wireless Systems draft-niemi-simple-im-wireless-reqs-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 28, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document lists the requirements specific to 3GPP wireless Instant Messaging systems. Niemi Expires August 28, 2003 [Page 1] Internet-Draft 3GPP Reqs for IM February 2003 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 Message Delivery and Handling Requirements . . . . . . . . . . 5 3.4 Message Session Management and Operation Requirements . . . . 5 4. User Privacy Requirements . . . . . . . . . . . . . . . . . . 7 5. Charging Requirements . . . . . . . . . . . . . . . . . . . . 7 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 7 7. Proposal for Next Steps . . . . . . . . . . . . . . . . . . . 8 Normative References . . . . . . . . . . . . . . . . . . . . . 8 Informative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 A. Changes from draft-niemi-simple-im-wireless-reqs-00 . . . . . 9 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Niemi Expires August 28, 2003 [Page 2] Internet-Draft 3GPP Reqs for IM February 2003 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 Core Network 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], the SIP conferencing requirements [7], and the conference policy data requirements [8] 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" Niemi Expires August 28, 2003 [Page 3] Internet-Draft 3GPP Reqs for IM February 2003 are interchangeable. Also, "message sessions" are used in place of "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 [9]. 3.1 Addressing Requirements ADDR-REQ1: 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. ADDR-REQ2: Use of E.164 numbers [3] in addressing instant messages and message session requests MUST be supported. 3.2 Message Content Requirements CONT-REQ1: It MUST be possible to carry any MIME encoded data in Instant Messages and message sessions. Niemi Expires August 28, 2003 [Page 4] Internet-Draft 3GPP Reqs for IM February 2003 CONT-REQ2: The content size MUST NOT be limited by the Instant Messaging, or message session protocols. CONT-REQ3: It MUST be possible for the UA to announce its device capabilities for messaging. CONT-REQ4: It MUST also be possible to base handling of instant messages on these capabilities and user preferences. 3.3 Message Delivery and Handling Requirements DELIV-REQ1: It MUST be possible for the UA to store sent instant messages, or messages pertaining to a particular message session to a network-based repository. DELIV-REQ2: It MUST be possible to redirect, block (and unblock), or store to a network-based repository incoming instant messages as part of a user configurable option. DELIV-REQ3: This incoming message treatment MUST support instant message selection based on sender address, message size, message priority, message subject, message class, message content type and availability of the recipient. The mechanism MUST support instant message selection based on other criteria. DELIV-REQ4: It MUST also be possible to subsequently retrieve, list, delete and forward the stored messages. It MUST also be possible to upload messages to a network-based repository for storage. DELIV-REQ5: It MUST be possible for the sender of an instant message to receive either positive or negative acknowledgements of delivery for all sent messages. 3.4 Message Session Management and Operation Requirements SESS-REQ1: 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. SESS-REQ2: There MUST be a standardized mechanism by which such ad-hoc or persistent AORs can be created, applied, and discarded by the user. Niemi Expires August 28, 2003 [Page 5] Internet-Draft 3GPP Reqs for IM February 2003 SESS-REQ3: It MUST be possible for an administrator (or any user with appropriate rights) of a chat room to control the list of allowed participants. SESS-REQ4: There MUST be a standardized mechanism by which such authorization policy is inserted, manipulated and removed. SESS-REQ5: 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. SESS-REQ6: There MUST be standardized mechanisms by which an administrator (or any user with appropriate rights) of a chat room can invite new participants to an ongoing chat room, and kick out existing participants. SESS-REQ7: It MUST also be possible to send semi-permanent invitations to a chat room to new participants. Semi-permanent invitations do not require the invitee to respond immediately. Also, the inviter MUST be able to cancel the invitation, and/or set a validity period for the invitation. SESS-REQ8: 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 active participants. There MUST be a standardized mechanism by which such properties are set, manipulated, and removed. SESS-REQ9: It MUST be possible for participant to request the properties of a chat room, including the list of active members. It MUST be possible to also receive automatic updates of these properties. SESS-REQ10: It MUST be possible to request and receive an indication when a particular participant or participants in a chat room are in the process of entering a message. It MUST also be possible to disable sending such an activity indication. SESS-REQ11: It MUST be possible for the sender of a message to receive either positive or negative acknowledgements of delivery for all sent messages in a message session. Niemi Expires August 28, 2003 [Page 6] Internet-Draft 3GPP Reqs for IM February 2003 SESS-REQ12: It MUST be possible to send private messages between the participants of a multiparty message session. SESS-REQ13: It MUST be possible to send private messages to participants who are using pseudonym identities or nicknames. SESS-REQ14: 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. User Privacy Requirements PRIV-REQ1: 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. PRIV-REQ2: It MUST be possible to originate anonymous instant messages and message sessions. PRIV-REQ3: It MUST be possible to originate instant messages and message sessions using pseudonyms, or nicknames. PRIV-REQ4: It MUST be possible to send private messages in a chat room using a nickname or an anonymous identity. OPEN ISSUE: To some extent, these requirements are already covered in RFC 3324 [10] and RFC 3325 [10]. However, privacy requirements for identities in message sessions and especially in multiparty sessions remain open, and are for further study. 5. Charging Requirements This document refers to the charging requirements of [1], and in addition defines an additional, messaging specific requirement: CHARG-REQ1: The instant messaging and message session protocols MUST be able to support different charging models, including ones where: * only the sender of a message pays * both the sender and the receiver of a message pay Niemi Expires August 28, 2003 [Page 7] Internet-Draft 3GPP Reqs for IM February 2003 * only the recipient of a message pays 6. Security Requirements This document adopts the security requirements listed in [1], and does not introduce any additional security requirements at this time. 7. 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. It is not expected that this document be published as an RFC by the IETF, but rather serve as a reference to various working group requirements documents. It is also expected that this document is used as a check list as requirements get included to other documents. 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. [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", TS 22.340, December 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-01 (work in progress), February 2003. Niemi Expires August 28, 2003 [Page 8] Internet-Draft 3GPP Reqs for IM February 2003 [7] Levin, O., "Requirements for Tightly Coupled SIP Conferencing", draft-levin-sipping-conferencing-requirements-02 (work in progress), November 2002. [8] Koskelainen, P., "Requirements for conference policy data", draft-koskelainen-sipping-conf-policy-req-00 (work in progress), February 2003. [9] 3rd Generation Partnership Project, "IP Multimedia Subsystem (IMS)", TS 23.228, January 2003. [10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [11] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002. Author's Address Aki Niemi Nokia P.O. Box 321 NOKIA GROUP, FIN 00045 Finland Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com Appendix A. Changes from draft-niemi-simple-im-wireless-reqs-00 o Updated the references o Clarified the format of the requirements by adding labels and reorganizing the requirements o Removed a requirement for indirect content in IMS messaging o Removed OPEN ISSUE on media sequencing o Added the requirement for semi-permanent chat room invitations o Added the requirement for chat room properties fetching/ notification o Added the requirement for "isTyping" Niemi Expires August 28, 2003 [Page 9] Internet-Draft 3GPP Reqs for IM February 2003 o Added storage requirements, and clarified the message treatment requirements o Added the requirement for delivery acknowledgements to message sessions o Reordered some requirements between chapters 4 and 3 o Added an open issue on privacy requirements o Added a general charging requirement o Minor editorial fixes Appendix B. 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), Milo Orsic (Lucent Technologies), and Milt Roselinsky (Openwave). Although not an official communication of the 3GPP, this document has been discussed and commented by a number of delegates in the relevant 3GPP working groups. Niemi Expires August 28, 2003 [Page 10] Internet-Draft 3GPP Reqs for IM February 2003 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 (2003). 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 Niemi Expires August 28, 2003 [Page 11] Internet-Draft 3GPP Reqs for IM February 2003 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 August 28, 2003 [Page 12]