DISPATCH D. Gautam Internet-Draft Huawei Technologies Intended status: Standards Track May 20, 2010 Expires: November 21, 2010 Quick Answer draft-gautam-dispatch-quick-answer-00.txt Abstract In instant messaging system, it is useful to have some readily available IM (text, audio or video) which can be sent in case of the receiver is too busy to type/speak/record for a reply. These short IM (here after referred as QA - Quick Answer) can be created, stored and used when needed. This document defines a new QA content type and XML namespace that conveys QA between two entities. The QAs are delivered to the instant messaging sender in the same manner as the instant messages themselves. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 21, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Gautam Expires November 21, 2010 [Page 1] Internet-Draft Quick Answer May 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Usecase and Requirements . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Conventions . . . . . . . . . . . . . . . . . . 5 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. QA Synchronization . . . . . . . . . . . . . . . . . . . . 5 5.2. QA Creation . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Gautam Expires November 21, 2010 [Page 2] Internet-Draft Quick Answer May 2010 1. Introduction In Instant Messaging conversation there may be some situation where receiver is unable to compose (type, speak) an IM in reply at that point of time. However, due to the importance of the topic discussed and the sender himself, he also doesn't want the sender to feel avoided or left waiting for long time. To solve this issue this document proposes the concept of "Quick Answer" (QA), which are some readily available IM (text, audio, video) to the user, from which user can select as a reply to the sender. QAs are created by user in his/her ideal time using any IM capable client and stored on the server (QA Holder) as well as client. When user logs-in the instant messaging system the QA stored on the client and the server are synchronized. The concept of QA may not be considered solely a client-level feature because of the fact that all the Instant Messaging system today allows users to log-in the Instant Messaging system using different client at different point of time. In this scenario QA created by one client will not be available to another client. So, this functionality requires a client-server model. To facilitate the definition of QA service, this document defines an Extensible Markup Language (XML) document (QA Document) and the application usage for managing this document using XML Configuration Access Protocol (XCAP). This document can store all the QA for a particular user. Any clients can create/modify/delete these QAs using XCAP. This document also defines a new option tag called "qasupport", which if present in the supported header field of REGISTER request, imply that the QA synchronization procedures have to be initiated by Registrar. Extensions to presence, such as PIDF [6]were also considered but have a number of disadvantages: Adds more overhead as an explicit and periodic subscription is required; Presence fits situation where IM sender (as watcher) gets information about IM recipient (as presentity), here the situation is reverse; Will not allow user to choose from different option (QA) available in real-time; I may want to send some QA to those who are not my 'watchers' (because they don't care about my presence information) but very important to me. A QA is delivered to an instant messaging recipient in the same manner as the instant messages themselves. This document doesn't not emphasize on that part considering that it can be done using existing mechanism. Gautam Expires November 21, 2010 [Page 3] Internet-Draft Quick Answer May 2010 The concept of QA can be considered related with the concept of "vacation" [3] used of emails. However unlike QA, "vacation" does not allow user to choose from the list of available options (:handle in case of vacation). In other words, no user intervention is required after vacation scripts are created. Further unlike "vacation" QAs are not generated automatically. 2. Usecase and Requirements For many instant messaging users, there are some messages to be usually used as answers. The user can preset these messages before he starts an IM session, and he can quickly send these pre-configured messages as an answer by making fewer inputs. The quick answer messages are stored in the network so that the user can set these messages once and use those from different devices. User may need several of these quick answer messages depending on the different situation and need as follows: 1. Alice is expecting an important instant message from Bob containing the venue of a party scheduled for tomorrow evening. Since, Alice will be busy in a client meeting for the next 2 hours, she created and store a QA , as "Thanks for the information, I'll be there. What is the best way to get there" (Alice is new town, and not familiar with the local travel), using her current IM clent (her laptop at her desk). Later, during the meeting Alice were log-in her IM service using her mobile device. The QA created through her Laptop were made avaliable to her mobile device automatically. She received an IM from Bob as expected. She quickly scrolled down the list of avaliable QA and selected the one she created as a reply to Bob. 2. Alice has registered on a local social networking site and receives tons of instant messages everyday initiating further conversation. Alice tends to reply same sort of messages frequently to several incoming instant messages. To avoid overhead (for composing messages everytime) and to be efficient, Alice created some messages on her current mobile device as "Hi, see some more pictures at www.matchmaker.com/alice/pic","Hey! Thanks for the message, can I see some of your pictures", "Thanks, I'll get back to you", "Sorry, we don't click", etc. The following requirements can be derived from the above use case 1. The user SHALL be able to use any Instant messaging capable device to create and store quick answer messages 2. The user SHALL be able to use all stored quick answer messages from any Instant messaging capable device, irrespective of from which device they were created and stored. Gautam Expires November 21, 2010 [Page 4] Internet-Draft Quick Answer May 2010 3. It SHALL be possible to determine whether the login device has the same quick answer messages with the QA-Holder. And if not, the QA-Holder SHALL be able to send the different quick answer messages to the device automatically. 3. Terminology and Conventions o QA-Holder: QA holder is a SIP user agent identified by a SIP URI. QA Holder stores and manages QA. o Quick Answer: Quick Answer is a readily available IM to the user. User can create Quick Answers which are made available to the user to choose from. 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 [5] 4. Description TBD 5. Example Flow 5.1. QA Synchronization +---+ +---------+ +---------+ |UAC| |Registrar| |QA Holder| +-.-+ +----+----+ +----+----+ | REGISTER(qasupport) | | +-------------------->| 3-party REGISTER | | |------------------>| | INVITE | | |<--------------------+-------------------| | 200 OK | | |---------------------+------------------>| | ACK | | |<--------------------+-------------------| | | | ooooooooooooooo Session Established ooooooooo. `Y88888888888888888888888888888888888888888888P | | | | QA Synchronization | |<--------------------+------------------>| | | | QA Synchronization Flow Gautam Expires November 21, 2010 [Page 5] Internet-Draft Quick Answer May 2010 5.2. QA Creation +---+ +---------+ |UAC| |QA Holder| +-.-+ +----.----+ | | | HTTP (XCAP) PUT | +---------------------------------------->| | | | | | +---------------------+ | |ID Generation/Storage| | +---------------------+ | HTTP 200 OK | +<----------------------------------------| | | | | | | | | QA Creation Flow 6. IANA Consideration TBD 7. Security Considerations TBD 8. Normative References [3] "Tim Showalter, Ned Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.". [5] "Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.". [6] "Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC3863, August 2004.". Gautam Expires November 21, 2010 [Page 6] Internet-Draft Quick Answer May 2010 Author's Address Deepanshu Gautam Huawei Technologies NingNan Av. Nanjing, Jiangsu 210012 P.R China Phone: +86 25 82276770 Email: deepanshu@huawei.com Gautam Expires November 21, 2010 [Page 7]