Instant Messaging Requirements

Transcription

1 Instant Messaging Requirements Approved Version Aug 2012 Open Mobile Alliance OMA-RD_IM-V1_ A 2012 Open Mobile Alliance Ltd. All Rights Reserved. [OMA-Template-ReqDoc I]

2 OMA-RD_IM-V1_ A Page 2 (54) Use of this document is subject to all of the terms and conditions of the Use Agreement located at Unless this document is clearly designated as an approved specification, this document is a work in process, is not an approved Open Mobile Alliance specification, and is subject to revision or removal without notice. You may use this document or any part of the document for internal or educational purposes only, provided you do not modify, edit or take out of context the information in this document in any manner. Information contained in this document may be used, at your sole risk, for any purposes. You may not use this document in any other manner without the prior written permission of the Open Mobile Alliance. The Open Mobile Alliance authorizes you to copy this document, provided that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials and that you comply strictly with these terms. This copyright permission does not constitute an endorsement of the products or services. The Open Mobile Alliance assumes no responsibility for errors or omissions in this document. Each Open Mobile Alliance member has agreed to use reasonable endeavors to inform the Open Mobile Alliance in a timely manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification. However, the members do not have an obligation to conduct IPR searches. The declared Essential IPR is publicly available to members and non-members of the Open Mobile Alliance and may be found on the OMA IPR Declarations list at The Open Mobile Alliance has not conducted an independent IPR review of this document and the information contained herein, and makes no representations or warranties regarding third party IPR, including without limitation patents, copyrights or trade secret rights. This document may contain inventions for which you must obtain licenses from third parties before making, using or selling the inventions. Defined terms above are set forth in the schedule to the Open Mobile Alliance Application Form. NO REPRESENTATIONS OR WARRANTIES (WHETHER EXPRESS OR IMPLIED) ARE MADE BY THE OPEN MOBILE ALLIANCE OR ANY OPEN MOBILE ALLIANCE MEMBER OR ITS AFFILIATES REGARDING ANY OF THE IPR S REPRESENTED ON THE OMA IPR DECLARATIONS LIST, INCLUDING, BUT NOT LIMITED TO THE ACCURACY, COMPLETENESS, VALIDITY OR RELEVANCE OF THE INFORMATION OR WHETHER OR NOT SUCH RIGHTS ARE ESSENTIAL OR NON-ESSENTIAL. THE OPEN MOBILE ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT, INDIRECT, PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR IN CONNECTION WITH THE USE OF DOCUMENTS AND THE INFORMATION CONTAINED IN THE DOCUMENTS Open Mobile Alliance Ltd. All Rights Reserved. Used with the permission of the Open Mobile Alliance Ltd. Under the terms set forth above Open Mobile Alliance Ltd. All Rights Reserved. [OMA-Template-ReqDoc I]

3 OMA-RD_IM-V1_ A Page 3 (54) Contents 1. SCOPE (INFORMATIVE) REFERENCES NORMATIVE REFERENCES INFORMATIVE REFERENCES TERMINOLOGY AND CONVENTIONS CONVENTIONS DEFINITIONS ABBREVIATIONS INTRODUCTION (INFORMATIVE) USE CASES (INFORMATIVE) USE CASE IM CONVERSATION HISTORY Saving a conversation Restoring a conversation Deleting a conversation Send a conversation USE CASE IM NOTIFICATION Short Description Actors Pre-conditions Post-conditions Normal Flow Operational and Quality of Experience Requirements USE CASE IM USE OF PRESENCE Short Description Actors Pre-conditions Post-conditions Normal Flow Alternative Flow Operational and Quality of Experience Requirements USE CASE IM USE OF GROUP MANAGEMENT Short Description Actors Pre-conditions Post-conditions Normal Flow Alternative Flow Operational and Quality of Experience Requirements USE CASE MODIFY CONTACT ENTRY Short Description Actors Pre-conditions Post-conditions Normal Flow Alternative Flow Operational and Quality of Experience Requirements USE CASE TEMPORARY GROUP Short Description Actors Pre-conditions Post-conditions Normal Flow Open Mobile Alliance Ltd. All Rights Reserved.

4 OMA-RD_IM-V1_ A Page 4 (54) Alternative Flow Operational and Quality of Experience Requirements USE CASE MOBILE ORIGINATED CHAT Short Description Actors Pre-conditions Post-conditions Normal Flow Alternative Flow Operational and Quality of Experience Requirements INTERCONNECTION BETWEEN IM SERVICE PROVIDERS Short Description Actors Pre-conditions Post-conditions Normal Flow Alternative Flow Operational and Quality of Experience Requirements USE CASE PUBLIC CHAT Short Description Pre-conditions Post-conditions Normal Flow Alternative Flows Operational and Quality of Experience Requirements REGISTRATION IN IM BY MOBILE E.164 NUMBER Short Description Actors Pre-conditions Post-conditions Normal Flow USE CASE ADD CONTACT TO CONTACT LIST BY USER-ID OR SEARCH Short Description Actors Pre-conditions Post-conditions Normal Flow add contact by a User-ID Alternative Flow Add Contact by Search Operational and Quality of Experience Requirements ACCESSING IM SERVER VIA INTERNET CONNECTED DEVICE Short Description Actors Pre-conditions Post-conditions Normal Flow USE CASE MESSAGE FILTERING Short Description Actors Pre-conditions Post-conditions Normal Flow Operational and Quality of Experience Requirements USE CASE QUICK ANSWER Short Description Actors Pre-conditions Open Mobile Alliance Ltd. All Rights Reserved.

5 OMA-RD_IM-V1_ A Page 5 (54) Post-conditions Normal Flow Alternative Flow Operational and Quality of Experience Requirements REQUIREMENTS (NORMATIVE) HIGH-LEVEL FUNCTIONAL REQUIREMENTS General Requirements IM Data Model Registration Sending IM Receiving IM IM Message Delivery IM Notifications Conversation History Presence in IM Group Management in IM Controlling Privacy in IM Security Charging Administration and Configuration Usability Interoperability Lawful Intercept IM Usage in Enterprise/Corporate Environment User Profile IM Location Multimedia Content in IM IM one-to-one and Chat Communication Message Filtering System Messages OVERALL SYSTEM REQUIREMENTS SYSTEM ELEMENTS IM User Agent APPENDIX A. CHANGE HISTORY (INFORMATIVE) A.1 APPROVED VERSION 1.0 HISTORY Tables Table 1: High level Functional Requirements - General requirements Table 2: High level Functional Requirements - IM Data Model Table 3: High level Functional Requirements - Registration Table 4: High level Functional Requirements - Sending IM Table 5: High level Functional Requirements - Receiving IM Table 6: High level Functional Requirements - IM Message Delivery Table 7: High level Functional Requirements IM Notifications Table 8: High level Functional Requirements Conversation History Table 9: High level Functional Requirements Presence in IM Open Mobile Alliance Ltd. All Rights Reserved.

6 OMA-RD_IM-V1_ A Page 6 (54) Table 10: High level Functional Requirements Group management in IM Table 11: High level Functional Requirements Controlling Privacy in IM Table 12: High level Functional Requirements Controlling Privacy in IM Invisibility Table 13: High level Functional Requirements Security Table 14: High level Functional Requirements Charging Table 15: High level Functional Requirements Administration and Configuration Table 16: High level Functional Requirements Usability Table 17: High level Functional Requirements Interoperability Table 18: High level Functional Requirements Lawful Intercept Table 19: High level Functional Requirements IM Usage in Enterprise/ Corporate Environment Table 20: High level Functional Requirements User Profile Table 21: High level Functional Requirements IM Location Table 22: High level Functional Requirements Multimedia Content in IM Table 23: High level Functional Requirements IM One to-one and Chat Communication Table 24: High level Functional Requirements Message Filtering Table 25: High level Functional Requirements System Messages Table 26: Overall System Requirements Table 27: System Elements IM User Agent Open Mobile Alliance Ltd. All Rights Reserved.

7 OMA-RD_IM-V1_ A Page 7 (54) 1. Scope (Informative) This document describes use cases of Instant Messaging (IM) in mobile and requirements for a wireless IM solution within OMA. The overall goal of this requirements document is to investigate IM service in mobile from service provider, technological and end-users demands. This document contributes the development of an IM Solution for OMA. The overall goals of an OMA IM Solution can be stated as: Low latency (i.e. as close to real time as possible for an IM message exchange ) Optimized and efficient use of available wireless resources Interoperability & Interworking with other standardized IM solutions Security Mobility Unrestricted by content type Although the technical realization is assumed to be based on SIP/SIMPLE technology, this Requirements Document describes requirements at a high level, in a technology agnostic way Open Mobile Alliance Ltd. All Rights Reserved.

8 OMA-RD_IM-V1_ A Page 8 (54) 2. References 2.1 Normative References [GM] [PRESENCE] [PRIVACY] Group Management Requirements, Open Mobile Alliance, OMA-RD-GM-V1_ C (Note: This document is now called XML Document Management Requirements ), URL: Presence Requirements, Open Mobile Alliance, OMA-RD_Presence-V1_ C, (Note: This document is now called Presence SIMPLE Requirements ), URL: Privacy for Mobile Services Requirements, Open Mobile Alliance, November 2003, URL: [RFC2119] Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March URL: [RFC3261] SIP: Session Initiation Protocol June 2002 URL: [RFC3966] The tel URI for Telephone Numbers H. Schulzrinne. December URL: [RFC3986] Uniform Resource Identifier (URI): Generic Syntax January URL: 2.2 Informative References [FRAMEWORK] [OMA1] [RFC4353] WAP Immediate Messaging White Paper, WAP Forum, 8-January URL: Dictionary for OMA Specifications, Open Mobile Alliance, OMA-ORG-Dictionary-V2_ A, URL: "A Framework for Conferencing with the Session Initiation Protocol (SIP)", J. Rosenberg, February 2006, URL: Open Mobile Alliance Ltd. All Rights Reserved.

9 OMA-RD_IM-V1_ A Page 9 (54) 3. Terminology and Conventions 3.1 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 [RFC2119]. All sections and appendixes, except Scope and Introduction, are normative, unless they are explicitly indicated to be informative. 3.2 Definitions Cellular network Chat Alias Chat group Chat room Contact List Conversation Deferred messaging Display Name Emoticon or smiley: IM account IM Client IM communication IM Group IM Participants IM Server IM service IM service entity IM service interactions IM session A cellular network is a radio communication network that covers a territory divided in cells A unique identifier used by an IM user in a chat room. A synonym to Chat room. A synonym for session-based instant messaging conference.conference is defined in [RFC4353]. Contact information of individuals which are grouped together by an end user for his/her convenience, e.g. Friends, Family, Business, also referred to as buddy list. A Contact List can exist in different ways in different applications, with the end user having some control of it. For example, it can be used in a messaging application to group a set of presentities together, enabling the end user to easily see the presence information of those individuals. Note: a Contact List is not a (presence enhanced) phonebook or address list which is stored in a mobile device. An ordered exchange of immediate messages in the context of a session between users. If an intended recipient of an IM Pager mode or Large Message mode communication is not available, either due to the recipient s Inbox settings or the recipient being IM offline, the message is stored in the IM server for later delivery, i.e. the IM becomes deferred message. Non-unique and not routable identification of a user that could be displayed to other users as defined in [RFC3261] A character sequence used to indicate an emotional state in messaging ( , news, IM ). When displayed, emoticons are usually replaced by graphical representations of the emotion they convey. A subscription to an IM service. An IM Service endpoint. The exchange of instant messages on a one-to-one basis or between the participants of an IM group. A defined set of IM participants amongst whom an IM session may take place or who may participate in a chat session. An IM user who joined a chat room. A networked entity that provides real-time messaging functionality. A service as defined in [OMA1] using OMA IM Enabler. An entity providing one or more capabilities defined in the IM Enabler. The interactions between an IM client and an IM server (e.g. Join an IM group, leave an IM group, administer IM groups, etc). Exchange of near real-time messages where the senders and receivers join together for a period of time (session). The session is established at some moment in time, continues for a finite duration and then is 2012 Open Mobile Alliance Ltd. All Rights Reserved.

10 OMA-RD_IM-V1_ A Page 10 (54) IM subscription IM subscriber IM system IM User IM user agent Instant Messaging Service (IM Service) Invisibility in IM Mobile Directory Number (MDN) Mobile Operator Mobile Station international Integrated Services Digital Network number (MSISDN) Nickname One-to-Many-to-One Presence Phonebook Private Chat Room Private data Private Profile Public Chat Room Public Data Public Domain Public Profile Registration Session dissolved. Messages exchanged are associated together in the context of this session. A subscription as defined in [OMA1] to an IM service. A subscriber as defined in [OMA1] to an IM service. The set of entities providing an IM service. It consists of IM servers and clients. A human using the described features through a terminal device. In this document the terms User and IM user are equivalent. An endpoint of an IM communication. A system application by which a client is able to provide (near) real-time messaging capabilities. The Invisible option allows the user to do everything like a normal IM user, but with his status shown as offline. A Mobile Directory Number (MDN) is used in 3GPP2. An MDN is a dialable number associated with the mobile station through a service subscription. A Mobile Directory Number is not necessarily the same as the mobile station identification on the air interface. An MDN consists of country code, national destination code, and subscriber number. An MDN consists up to 15 digits. An operator providing a network connectivity service and possibly other services to users with mobile devices. A Mobile Station international Integrated Services Digital Network number (MSISDN) is used in 3GPP. An MSISDN is a dialable number associated with the mobile station through a service subscription. An MSISDN consists of country code, national destination code and subscriber number. An MSISDN MAY be up to 15 digits. A name assigned by an end user to an individual contact in a Contact List to support that end user s familiarity with the person. A conversation service that allows a user to send a message to multiple recipients and allows the individual recipients to communicate back to the sender ONLY. Presence, or a model for presence, may include a combination of network state information (online or offline, location), application state information (idle or active) and user specified state information (available or busy). A local database in the terminal containing phone numbers, names, etc. A Chat room conversation on a server that allows access to authorised IM users only and is usually created, managed and administered by a user. This user is the owner of the private chat room. Data in the private profile The part of the User Profile that is open only to users that the owner of the profile has accepted should be able to search in the profile. A Chat room conversation on a server that allows access to any IM user and is usually created, managed and administered by a network administrator or service provider. Data in the Public Profile Domain accessible by any internet user The part of the User Profile that is open for anyone to search in. The action or process by which an individual, who generally is a subscriber of the mobile network operator, becomes a user of the IM-Service. A stateful association of presence and other user preference, capability and identity data through which it is possible to communicate immediate messages. A session may be established between IM users or between an IM user and an IM Server Open Mobile Alliance Ltd. All Rights Reserved.

11 OMA-RD_IM-V1_ A Page 11 (54) System Message User-ID User Profile 3.3 Abbreviations A special type of message sent by the System for different purposes (e.g. advice of charge, service notifications, advertisements, instructions, etc). System Messages may contain a list of possible options and require a response from the user. Routable unique identification of an IM user. It takes the form of a SIP URI (as defined in [RFC3261] and [RFC3986] or the tel -URI format as defined in [RFC3966] Data related to a user which is stored by the service. It may contain data which can be managed by the user and data that can be managed by the service provider. Some data can be available only to selected users while other can be available to all users. ARCH CDR OMA Architecture Working Group Call Detail Record E.164 ITU-T Recommendation E.164 The international public telecommunication numbering plan EMS GM ID IM IMS IOP IP ISDN MDN MMS MSISDN OMA OTA PC PoC RD RFC SIP SIMPLE SMS SMTP URL WG Enhanced Messaging Service Group Management Identifier Instant Message IP Multimedia (Sub)System Interoperability Internet Protocol Integrated Services Digital Network Mobile Directory Number Multimedia Messaging Service Mobile Subscriber ISDN Number Open Mobile Alliance Over-the-Air Personal Computer Push-to-talk Over Cellular Requirement Documents Request for Comments Session Initiation Protocol SIP for Instant Messaging and Presence Leveraging Extensions Short Message Service Simple Mail Transfer Protocol Uniform Resource Locator Working Group 2012 Open Mobile Alliance Ltd. All Rights Reserved.

12 OMA-RD_IM-V1_ A Page 12 (54) 4. Introduction (Informative) Instant Messaging (IM) is a form of 2-way communications that allows users to typically send text information to the other parties (however content types are not restricted to text only). It can be peer-to-peer, one-to-many, or one-to-many-to-one configuration, meaning that the messaging can be between two individuals, within a group where everyone in the group can see what everyone else is sending, or a specific one-to-many-to-one communication for dispatch services. There is no need to maintain any type of floor control since messages are posted to the individual (or group) in the order they are received, and can be read as needed. As opposed to other kinds of messaging, Instant Messaging is characterized by its interactive nature, i.e. users exchange messages in near real time to engage conversations. This requires low latency in the delivery of messages. Instant Messaging is built upon group management and presence enablers to provide a more compelling user experience. This document first captures the use cases for IM Service, and then specific technical requirements are derived from these use cases Open Mobile Alliance Ltd. All Rights Reserved.

13 OMA-RD_IM-V1_ A Page 13 (54) 5. Use Cases (Informative) The following use cases are provided to further illustrate the functions and roles of the various system elements in the IM framework and the inter-related functions performed by the IM Server 5.1 Use Case IM Conversation History Sometimes you had such a nice conversation that you want to store it, to read again, or to show it to friends. It is possible with IM. Because it is a very big issue, This Use case is split up in a few parts: There is a Use Case for saving a conversation, restoring a conversation, deleting a conversation and sending a conversation Saving a conversation Short Description When you want to save a conversation, you could save it on the IM service provider. This Use Case describes how a user may store his conversation Actors User A: the user that uses the IM service. IM service provider provides the conversation history service to his subscribers Actor Specific Issues User must have an IM client with the conversation history feature supported. User must have an IM account. IM Service Provider has a reliable system for conversation history management. IM Service Provider must have enough space to store all conversations of all users Actor Specific Benefits The user s IM client supports the conversation history feature. IM Service provider also supports conversation history to its subscribers. IM Service provider has enough space to store the conversation Pre-conditions The user s client supports the conversation history feature. IM Service Provider also supports conversation history feature Post-conditions The conversation with User X has been saved as ConversationX Normal Flow 1. User A has the conversation screen open with the conversation User A User X. 2. User A selects the save option and requests the IM server to save the conversation. 3. The service provider prompts for a conversation-name Open Mobile Alliance Ltd. All Rights Reserved.

14 OMA-RD_IM-V1_ A Page 14 (54) 4. User A enters Conversation X and uses the save button to finish the action. 5. The conversation has been saved on the IM Server as ConversationX Alternative Flow None Operational and Quality of Experience Requirements The User may save a conversation. It must be possible for the user to enter a name for the conversation; otherwise a default name will be used. The IM user should be able to know the details about his storage quota utilization. The IM server must have a storage quota for each user. The date that the conversation has been made must be stored. The user may specify the duration to retain the items in the archival Restoring a conversation Short Description When you have saved the conversation, you want to see that conversation later again, so you ll restore your conversation. In this use case we will restore the conversation of User A with User X, ConversationX Actors User A: the User, who will restore the conversation. IM Service Provider provides the conversation history service to his subscribers Actor Specific Issues User must have an IM client with the conversation history feature supported. User must have an IM account. IM Service Provider has a reliable system for conversation history management Actor Specific Benefits The user s IM client supports the conversation history feature. IM Service Provider also supports conversation history to its subscribers Pre-conditions The user s client supports conversation history feature. IM service provider also supports conversation history feature. The user has saved a conversation under the name Conversation X Open Mobile Alliance Ltd. All Rights Reserved.

15 OMA-RD_IM-V1_ A Page 15 (54) Post-conditions ConversationX will be opened Normal Flow 1. User A opens the IM history feature and contacts the service provider. 2. User A requests the list with all stored conversation. 3. IM Service Provider shows the list with conversations. 4. User A selects ConversationX. 5. User A chooses the open option. 6. The IM service Provider opens the conversation. 7. User A could now read the conversation Alternative Flow None Operational and Quality of Experience Requirements A user must be able to open a stored conversation. The conversation must be stored in a list of conversations. A user must have the ability to scroll through the list of conversations Deleting a conversation Short Description To maintain the possibility to store a conversation, enough memory must be available. Therefore, stored conversations must be deleted in time. This use case describes how to delete the conversation ConversationX Actors User A: the user, who deletes ConversationX. IM Service Provider provides the conversation history service to its subscribers Actor Specific Issues User must have an IM Client with the conversation history feature supported. User must have an IM account. IM Service Provider has a reliable system for conversation history management Actor Specific Benefits The user s IM client supports the conversation history feature. IM Service Provider also supports conversation history to its subscribers Open Mobile Alliance Ltd. All Rights Reserved.

16 OMA-RD_IM-V1_ A Page 16 (54) Pre-conditions The user s client supports conversation history feature. IM service provider also supports conversation history feature. ConversationX is stored by the IM-Service Provider and is occupying expensive memory Post-conditions ConversationX has been removed from the IM-Server Normal Flow 1. User A opens the IM history feature and contacts the service provider. 2. User A requests the list with all stored conversation. 3. The IM Service Provider returns the list with conversations. 4. User A selects ConversationX. 5. User A selects the delete option. 6. The IM device asks for a confirmation from the IM Server. 7. User A selects yes. 8. ConversationX has been removed Alternative Flow Removing all conversations 1. User A opens the IM history feature and contacts the service provider. 2. User A requests the list with all stored conversation. 3. The IM Service Provider returns the list with conversations. 4. User A requests to delete all conversations from the IM-server. 5. The IM server warns the user that all conversations will be deleted and asks for a confirmation. 6. User A selects yes. 7. The IM server deletes all conversations and returns an empty conversation-list Operational and Quality of Experience Requirements A user must be able to remove a conversation. The terminal must ask for a confirmation, before deleting the conversation. A removed conversation will not be stored in a recycle bin. A user may remove all their conversations from the IM server Open Mobile Alliance Ltd. All Rights Reserved.

17 OMA-RD_IM-V1_ A Page 17 (54) Send a conversation Short Description Sometimes, it is useful to send a conversation to other users For instance when a company has a conference through IM, the IM session could be saved and sent to all attendees. In this Use-Case Conversation X will be sent to an address. This option becomes handy when you want to backup conversation Actors User A, the sender of the ConversationX. IM Service Provider provides the conversation history service to his subscribers Actor Specific Issues User must have an IM Client with the conversation history feature supported. User must have an IM account. IM Service Provider has a reliable system for conversation history management Actor Specific Benefits The user s IM client supports the conversation history feature. IM Service Provider also supports conversation history to its subscribers Pre-conditions The users client supports the conversation history feature. IM service provider also supports conversation history feature. ConversationX is stored on the Terminal X. and can be sent anywhere Post-conditions ConversationX is send to User B Normal Flow 1. User A opens the IM history feature and contacts the service provider. 2. User A requests the list with all stored conversation. 3. The IM Service Provider returns a list with all stored conversations. 4. User A selects in the Conversation history ConversationX. 5. User A selects the send option. 6. IM Service Provider asks for the destination address. 7. User A inputs the destination address of User B. 8. User A finally presses the send button. 9. The IM Service Provider sends the conversation to User B. 10. User B receives a message with a conversation of user A Open Mobile Alliance Ltd. All Rights Reserved.

18 OMA-RD_IM-V1_ A Page 18 (54) Alternative Flow None Operational and Quality of Experience Requirements It shall be possible to send a stored conversation. Instead of typing an address the user could choose from a list of addresses in the address book. 5.2 Use Case IM Notification This use case will demonstrate how a user of IM services will receive a notification indicating that he has received an IM. It will describe the event through the IM system and to the users IM client Short Description In this use case there will be two IM users, an IM server, and the network needed to connect the service. One of the users will send an IM to the other user and it will go through the network to the IM server, where it will be handled accordingly, and then a notification will be sent to the receiving user Actors Sam (samtheman) The user that will be receiving the notification. In this use case this user will have a device that has an IM client installed. Betty (bettybopp) Will be originating an IM and sending it to Sam. In this use case this user will have a device that has an IM client installed. IM Server Actor Specific Issues Betty is a friend of Sam s, and she wants to invite Sam to join a chat session with her to discuss plans for the evening. Sam is busy washing his car (anticipating his evening with Betty) and has his IM client connected to his belt and is not watching his IM service, but does want to be notified of incoming IM request Actor Specific Benefits Sam will be able to be notified when an IM is delivered, and Betty will be able to complete her IM session with Sam and make plans to get together later Pre-conditions Both Sam and Betty have devices with IM capability and are intelligent users of the service. Both have their IM client online and with them. Both have the other in their IM address book. The IM Server is in service and able to handle the IM request as defined in the user profiles Post-conditions Sam should be notified of the incoming IM from Betty, and he is able to join the IM chat request and plan there evening Normal Flow 1. Betty realizes that Sam has not confirmed their plans for the evening and wishes to contact Sam to finalize the details. To do this she decides to use her IM service Open Mobile Alliance Ltd. All Rights Reserved.

19 OMA-RD_IM-V1_ A Page 19 (54) 2. Betty opens her IM client s address book and selects Sam (samtheman) and inputs a message sam r u coming this evening? and sends it. 3. The IM client will interpret the address Sam as samtheman and send the message to the IM server. 4. The IM Server receives the message from Betty (bettybopp) addressed to Sam (samtheman). 5. The IM server then processes the message by checking both profiles to validate they are configured to send/receive messages between each other. This is a valid message. 6. The IM server then verifies Sam s current availability settings and privacy setting. Sam is OK to receive messages. 7. The IM server now generates the outbound message to Sam and sends it. 8. Sam s client receives the message from the IM server and sends an acknowledgement to the IM server. 9. The IM client then generates a pop-up screen, audible alarm, and vibrates the device. This is the actual notification. 10. Bob hears the alarm and looks at his device and sees a message from Betty (bettybopp) and accepts the chat request. 11. They chat and agree on the evenings plans. Sam then finishes cleaning his car Operational and Quality of Experience Requirements The receiving user shall receive notifications based on their privacy and availability settings. Users should be able to interpret the notifications easily Notification should include visual, audible, and vibrating as supported by the device. 5.3 Use Case IM Use of Presence Short Description Presence Service is a kind of catalyzer for IM Service. This use case shows how IM Service enabler uses Presence Service enabler to make user s experience better Actors Alice: The user that uses the IM service and Presence service, which uses presence feature to express her availability, device capabilities, and other presence information. Bob: The user that uses the IM service and Presence service, who wants to have an IM chat with Alice when she is available. IM Client: Application resident in a devices managing the IM service for the end users. Presence Client: Application resident in a devices managing the Presence service for the end users. IM Server: Network entity that communicates with the IM Client to achieve the IM service, which also communicates with Presence Server to publish user s availability and the device capability. Presence Server. Network entity that communicates with the Presence Client to achieve the Presence Service, which also receives user s availability and the device capability from IM Server Actor Specific Issues Alice wants to configure her presence information to express her availability, and other presence information. She also wants to chat with others using IM service when she is in her spare time. She must have an IM account, an IM Client, a Presence account, and a Presence Client Open Mobile Alliance Ltd. All Rights Reserved.

20 OMA-RD_IM-V1_ A Page 20 (54) Bob finds that Alice s availability presence turns from Busy to Available from his Presence Client, and her mobile phone supports IM service, then decides make an IM chat with Alice. He must have an IM account, an IM Client, a Presence account, and a Presence Client as well. IM Server receives the login request from Alice, then publishes Alice s availability and the capability of the IM application to the Presence Server Actor Specific Benefits Alice can modify her presence easily when she wants, and IM Server can help her updating her presence automatically. Bob can get Alice s availability before he chat with her using IM, which avoids the impolite chat request Pre-conditions Alice and Bob are both provisioned to use the IM Service and Presence Service. Alice and Bob s devices both have an IM Client and a Presence Client. Alice s availability presence is Busy, and is not logged in her IM Service Post-conditions Alice s availability presence is changed from Busy to Available. Bob finds Alice is Available and her device supports IM capability, and makes an IM chat with her Normal Flow 1. Alice is attending a meeting, so she navigates to the presence setting menu of her Presence Client and sets her availability presence to Busy. Then Alice s Presence client sends a corresponding request message to Presence server and the server records her setting. 2. Bob wants to have an IM chat with Alice. However, he checks Alice s availability presence from his Presence Client, and finds she is in Busy presence status. He feels a little disappointed, and selects an option to be alerted when Alice becomes available. 3. After two hours, Alice s meeting is over. She wants to have a rest, and navigates to the login menu of her IM Client and logs on to the IM Server. Then a login request message is sent from Alice s IM client to IM Server. 4. IM Server receives Alice request, then publishes Alice s availability and the IM capability of her mobile phone to the Presence Server. 5. Presence Server generates a notification message and sends it to Bob s Presence Client. 6. Bob s Presence Client gives an indication via an audible alarm or vibration. Then Bob checks Alice s availability presence again using his Presence Client, and happily finds she is Available and can be reached by IM. So he writes an instant message and sends to Alice, using the Send an Instant Message menu of his IM Client. Then Bob s IM Client sends a corresponding request message to IM server. 7. IM server forwards the message to Alice s IM client. Alice s IM client then generates a pop-up screen, audible alarm, or vibrates the device to indicate that an instant message comes Alternative Flow None Operational and Quality of Experience Requirements Considering the convenience for the user, it is better that user can invoke IM Client from Presence Client directly Open Mobile Alliance Ltd. All Rights Reserved.

21 OMA-RD_IM-V1_ A Page 21 (54) 5.4 Use Case IM Use of Group Management Short Description This use case shows how mobile subscribers are making use of Group Management functionalities in particular IM for contact management (e.g. add to Contact List, delete from Contact List) and IM for group conversations (e.g. initiate and manage groups for IM chat). The GM functionalities can be classified either as: Dynamic: These are the ones used over group IM conversation (chat). Static: These are the ones allowing the creation, management and deletion of IM conversation groups (chat rooms). The mobile subscriber is given the ability: To decide how to manage his/her Contact List(s). To engage group mode communications using the specified IM service Actors Julia She is the primary user to make use of Group Management functionalities. Both to manage her Contact List(s) and to create/initiate a group IM conversation. Romeo He acts as an example of a potential contact, i.e.: one to be added in Julia s Contact List(s). When added, either by invitation or by joining, Romeo s contact details constitute a given contact and member of the group. Maria She acts as an example of a given contact, i.e.: one to be managed within Julia s Contact List and able to participate in chat communication initiated and controlled by Julia. Instant Messaging (IM) service. Group Management (GM) functionalities Actor Specific Issues Julia wants: To configure her Contact List by adding a contact in this case, Romeo. To configure her Contact List by modifying the contents of the Contact List. Romeo and Maria are: Members of the Julia s Contact List management requirements. The IM service provides: The IM conversation(s) facilitated by GM functionalities between Julia and Romeo and/or Maria. The GM functionalities: To be able of supporting the above manipulations in the most efficient way possible. To work according to the commands of Julia Actor Specific Benefits Julia: 2012 Open Mobile Alliance Ltd. All Rights Reserved.

22 OMA-RD_IM-V1_ A Page 22 (54) Is able to add Romeo to her Contact List according to her preferences. Is able to manipulate her Contact List and place Romeo s details accordingly. Romeo: Becomes member of chat rooms created by Julia Is able to participate in group-mode IM conversation controlled and moderated by Julia. Maria: Is already in Julia s Contact List Can be invited or join after request Julia s chat room(s) Pre-conditions Julia, Romeo and Maria are all provisioned to use the IM Service. The IM service they are all subscribed to is enabled by GM functionalities Post-conditions Julia has added Romeo to her Contact List(s) and creates a chat room inviting him as well as Maria. Romeo and Maria engage to the chat session but with limited privileges. They are able to leave the group IM conversation at any time they choose Normal Flow 1. Julia decides to input Romeo s contact details in her Contact List in order for him to be able to join her chat rooms. She inputs the Romeo s contact details under her Contact List colleagues. 2. Julia invites Romeo to her chat room. 3. Romeo accepts the invitation. Romeo is a member of the group assigned colleague discussions. 4. Julia notifies Maria about the chat in that group. Maria s contact details are in Contact List friends. 5. Maria joins the group ( colleague discussions ) IM conversation. 6. Julia and her two friends are in group mode IM conversation. 7. After a while Maria decides to leave the group she does so. 8. Julia and Romeo continue the IM conversation (still group, but two participating users). 9. Both decide to terminate the conversation First Romeo, then Julia leave the group. 10. After termination, Julia decides to include Romeo to her friends Contact List. She does so by adding his details in that list and then deletes it from the list colleagues Alternative Flow 1. Julia decides to input Romeo s contact details in her Contact List in order for him to be able to join her chat rooms. She inputs the Romeo s contact details under her Contact List colleagues. 2. Julia invites Romeo to her chat room. 3. Romeo accepts invitation. Romeo is a member of the group assigned colleague discussions. 4. Julia invites Maria for the chat in that group. Maria s contact details are in Contact List friends Open Mobile Alliance Ltd. All Rights Reserved.

23 OMA-RD_IM-V1_ A Page 23 (54) 5. Maria joins the group ( colleague discussions ) IM conversation. 6. Julia and her two friends are in group mode IM conversation. 7. After a while Maria decides to leave the group she does so. 8. Julia and Romeo continue the IM conversation (still group, but two participating users). 9. Both decide to terminate the IM conversation First Romeo and then Julia leave the group. 10. After termination, Julia decides to include Romeo to her friends Contact List. She does so by moving his details in that list from the list colleagues Operational and Quality of Experience Requirements Julia has control over her Contact Lists(s) and she is able to modify them accordingly. Romeo is added to Julia s Contact List and is invited to participate in the chat room. Julia also invites Maria to join the group IM conversation. All three engage to group IM conversation. 5.5 Use Case Modify Contact Entry Short Description This use case demonstrates a situation where an end user has the need to modify Contact List information. An end user adds a couple of new entries in their Contact List, yet afterwards decides that a modification is necessary. In this case the change being made is to the name, or nick name associated with the contact, however other information associated with an entry could also be modified Actors User A An end user with mobile device having an IM client. Crazy-Girl aka Pretty-Girl An end user having access to an IM client. Curly-Top aka No-Hair An end user having access to an IM client Actor Specific Issues User A Has a need to update information in Contact List entries Actor Specific Benefits User A Benefits from an easy method of updating entries in a Contact List such as the name identifier, phone number, and picture Pre-conditions User A Mobile device is enabled with a provisioned and working IM client Post-conditions User A Entries in the IM Contact List reflects the information User A desires Open Mobile Alliance Ltd. All Rights Reserved.

24 OMA-RD_IM-V1_ A Page 24 (54) Normal Flow 1. User A has Crazy girl and Curly Top on his Contact List. 2. The three individuals decide to meet in person the following night at a dance club. 3. After spending the evening socializing and dancing, User A decides that the names of Crazy-Girl and Curly-Top don t describe his new friends. Instead, User A decides better nick names are Pretty-Girl and No-Hair. 4. User A requests the IM server to modify the name identifiers of Crazy-Girl to Pretty-Girl. 5. The IM server accepts this name modification request and responds with updated Contact List information. 6. User A requests the IM server to modify the name identifier of Curly-Top to No-Hair. 7. The IM server accepts this name modification request and responds with updated Contact List information Alternative Flow None Operational and Quality of Experience Requirements User A is provided with a more convenient way of modifying entries in his Contact Lists. It should not be possible to address/contact a person who is in a chat room anonymously. 5.6 Use Case Temporary Group Short Description The group persistency feature allows an end user to make the decision when creating a group whether the group is to be temporary or permanent. In the event of creating a temporary group, an end user specifies a duration period for the transitory group. The group exists during this duration period and beyond if an active session is taking place at the end of the duration period. This use case describes a scenario of an end user creating a temporary group and using this temporary group in a chat session Actors Mary End user with device provisioned with IM client. Tina End user with a device provisioned with an IM client. Ian End user with a device provisioned with an IM client. IM Client Application resident in a device managing the IM service for the end users. IM Server Network entity that communicates with the IM Client to achieve the IM service Actor Specific Issues No specific issues with any of the actors Actor Specific Benefits Mary the end user is relieved of the burden of managing a newly created group Pre-conditions Mary has a device that is enabled with IM client Open Mobile Alliance Ltd. All Rights Reserved.

25 OMA-RD_IM-V1_ A Page 25 (54) Mary has concert tickets to her favorite band, the Zombies Post-conditions The groups defined in Mary s IM client reflect what she desires, and the fact that the temporary Zombie Concert group is not present Normal Flow 1. On the evening of the Zombie concert about 3 hours before it starts, Mary decides to create a temporary IM group to chat about the concert. 2. The IM client in Mary s device requests the IM server to create a temporary group providing a group name of Zombie Concert, the fact it is a temporary group, and the duration period of the group being 3 hours. 3. The IM Server responds to the group creation request from Mary s IM Client with an updated Contact List which includes the new Zombie Concert group identified as temporary. Mary s IM Client processes this Contact List update showing the Zombie Concert group. 4. In route to the concert, Mary invites Tina to join the Zombie Concert group. Tina accepts the invitation to the Zombie Concert group and says Hello to the group. 5. Mary invites Ian to join the Zombie Concert group. Ian accepts the invitation to the Zombie Concert group and says Hello Everyone to the group. 6. Three hours after Mary created the temporary Zombie Concert group Mary, Tina, and Ian are still in an active chat session and therefore the IM Server maintains the group. 7. Sometime later Ian, Tina, and Mary exit the Zombie Concert group chat session. 8. The IM server recognizes that the active chat session has ended in the Zombie Concert group and that it is a temporary group past its expiration time. Therefore the IM server deletes the group and provides Mary s IM Client with an updated Contact List, which doesn t include the Zombie Concert group Alternative Flow None Operational and Quality of Experience Requirements Minimizes maintenance of groups by the end user. Minimizes memory in an IM client to store groups. 5.7 Use Case Mobile Originated Chat Short Description Bob sends an Instant Message to this friend Sue. Sue replies, and a conversation starts Actors Sue Bob IM Service Provider 2012 Open Mobile Alliance Ltd. All Rights Reserved.