SIMPLE D. Gautam Internet-Draft Huawei Technologies Intended status: Standards Track Jan 14, 2010 Expires: July 18, 2010 Quick Answer for SIMPLE draft-gautam-simple-quick-answer-01.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 to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 July 18, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Gautam Expires July 18, 2010 [Page 1] Internet-Draft Quick Answer for SIMPLE Jan 2010 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 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Usecase and Requirements . . . . . . . . . . . . . . . . . . . 4 3. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 4. Description . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Quick Answer Document . . . . . . . . . . . . . . . . . . 5 4.1.1. Content . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . 6 4.2. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Registration . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Composing QA . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Receving HTTP 200 OK . . . . . . . . . . . . . . . . . 7 4.2.4. Sending QA . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Post-Registration Behavior . . . . . . . . . . . . . . . . 7 4.4. QA Holder Behavior . . . . . . . . . . . . . . . . . . . . 7 4.4.1. Receiving third-party REGISTER from registrar . . . . 7 4.4.2. Receiving HTTP PUT request . . . . . . . . . . . . . . 7 5. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. QA Synchronization . . . . . . . . . . . . . . . . . . . . 8 5.2. QA Creation . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Content-type registration for application/im-QA+xml . . . 9 6.2. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:im-QA' . . . . . . . . . . . . . . 10 6.3. Schema Registration . . . . . . . . . . . . . . . . . . . 10 6.4. SIP option tag registration for qasupport . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Gautam Expires July 18, 2010 [Page 2] Internet-Draft Quick Answer for SIMPLE Jan 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. 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. 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 Gautam Expires July 18, 2010 [Page 3] Internet-Draft Quick Answer for SIMPLE Jan 2010 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 needs a message on her current mobile device 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). 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 initial message to several incoming instant message. To avoid overhead and to be efficient, Alice needs some messages on her current mobile device as "Hi, see some more pictures at www.matchmaker.com/ deep22gautam/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. 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 Gautam Expires July 18, 2010 [Page 4] Internet-Draft Quick Answer for SIMPLE Jan 2010 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 4.1. Quick Answer Document 4.1.1. Content Quick Answer documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying quick answer documents and document fragments. The namespace URI for elements defined by this specification is a URN, which is: urn:ietf:params:xml:ns:im-QA. A quick answer document has the element as the root element of the document. This element has a mandatory "uri" attribute, which is used to identify the owner (user) of the QA document. The content of element is a sequence of zero or more elements, each of which defines a single Quick Answer. A element consists of one mandatory element: , containing the actual QA message. In addition, there are two optional element: , used to carry the unique ID, assigned to a particular QA by QA Holder back to the UAC; , providing the date on which the QA is created. Gautam Expires July 18, 2010 [Page 5] Internet-Draft Quick Answer for SIMPLE Jan 2010 4.1.2. XML Schema XML Schema 4.2. UAC Behavior 4.2.1. Registration While registering, a QA complaint UAC SHALL include a qasupport option tag in the supported header of the REGISTER request [1] to let registrar know that it supports QA and would like registrar to initiate the synchronization process (through QA Holder) 4.2.2. Composing QA Any instant messaging user agent can create a QA. To do so it creates a HTTP PUT request (as specified in [RFC4825]) aiming to add one or more element in the QA document. The content-type of the request MUST be application/im-QA+xml. The element MUST be created with and sub-element providing actual message content and current date respectively. The sub-element MUST NOT be included in the request. Gautam Expires July 18, 2010 [Page 6] Internet-Draft Quick Answer for SIMPLE Jan 2010 4.2.3. Receving HTTP 200 OK On receiving a HTTP 200 OK with content type application/im-QA+xml, a UAC SHALL store the information ( and corresponding ) received as a QA. 4.2.4. Sending QA After synchronization is done, the UAC will have all the QA which are stored on the server. User can select one or more QA from the list and UAC will send it to the instant message receiver as a normal IM. 4.3. Post-Registration Behavior On registration registrar will inform (only if qasupport option tag is present in the supported header filed of REGISTER request) QA Holder about the registering user agent. To do this registrar will send a third-party REGISTER request to QA Holder as specified in [1] 4.4. QA Holder Behavior 4.4.1. Receiving third-party REGISTER from registrar After receiving third-party REGISTER request form registrar. QA Holder SHALL initiates a session with UAC. To do this QA Holder forms an INVITE request as specified in [1]. UAC receiving INVITE SHALL return 200 OK as the success response or the appropriate error response. The session would then be established between QA Holder and UAC. The QA synchronization process will them be performed on the session created. 4.4.2. Receiving HTTP PUT request On receiving a HTTP PUT request [RFC4825] with content type application/ im-QA+xml, QA Holder, XCAP server, SHALL deal with that request as specified in [RFC4825]. QA Holder SHALL generates a unique ID for the QA just received and store the QA with the ID generated. Further, QA Holder SHALL send the ID generated back to UAC. To do so it will generate a HTTP 200 OK response with content type application/im-QA+xml carrying (in the body) an instance of XML schema defined in section 5. The element is used to carry the ID generated. The element is used to carry the actual message. The element MAY be present. 5. Example Flow Gautam Expires July 18, 2010 [Page 7] Internet-Draft Quick Answer for SIMPLE Jan 2010 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 5.2. QA Creation +---+ +---------+ |UAC| |QA Holder| +-.-+ +----.----+ | | | HTTP (XCAP) PUT | +---------------------------------------->| | | | | | +---------------------+ | |ID Generation/Storage| | +---------------------+ | HTTP 200 OK | +<----------------------------------------| | | | | | | | | QA Creation Flow Gautam Expires July 18, 2010 [Page 8] Internet-Draft Quick Answer for SIMPLE Jan 2010 6. IANA Consideration 6.1. Content-type registration for application/im-QA+xml To: ietf-types@iana.org Subject: Registration of MIME media type application/ im-QA+xml MIME media type name: application MIME subtype name: im-QA+xml Required parameters: (none) Optional parameters: charset; Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See [4] , section 3.2. Security considerations: This content type is designed to carry user's messages for a specific person, which may involve some privacy concerns. Appropriate precautions should be adopted to limit disclosure of theses messages. Interoperability considerations: This content type provides a common format for exchange of Quick Answer. Published specification: [reference to the RFC] Applications which use this media type: Instant messaging systems. Additional information: none Person & email address to contact for further information: Deepanshu Gautam, simple@ietf.org Intended usage: LIMITED USE Author/Change controller: This specification is a work item of the IETF SIMPLE working group, with the mailing list address simple@ietf.org. Other information: None Gautam Expires July 18, 2010 [Page 9] Internet-Draft Quick Answer for SIMPLE Jan 2010 6.2. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:im-QA' URI: urn:ietf:params:xml:ns:im-QA Description: This is the XML namespace for XML elements defined by [reference to RFC] to describe Quick Answer used(send/receive) by an instant messaging client using the application/im-QA+xml content type. Registrant Contact: IETF, SIMPLE working group, simple@ietf.org, Deepanshu Gautam, deepanshu@huawei.com XML: BEGIN Quick Answer for Instant Messaging

Namespace for SIMPLE QA extension

urn:ietf:params:xml:ns:QA

See [reference to RFC].

END 6.3. Schema Registration This section registers a new XML schema per the procedures in [X]. URI: urn:ietf:params:xml:schema:im-QA Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Deepanshu Gautam (deepanshu@huawei.com). The XML for this schema can be found as the sole content of Section 7. 6.4. SIP option tag registration for qasupport This document also registers a new SIP option tag, "qasupport", adding it to the SIP Option Tags sub-registry in the SIP Parameters Gautam Expires July 18, 2010 [Page 10] Internet-Draft Quick Answer for SIMPLE Jan 2010 Registry. The required information for this registration, as specified in RFC3261 [1], is: o Name: qasupport o Description: This option tag specifies a User Agent ability to support QA. 7. Security Considerations TBD 8. Normative References [1] "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.". [2] "B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging" , RFC3428, December 2002". [3] "Tim Showalter, Ned Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.". [4] "Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.". [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.". 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 July 18, 2010 [Page 11]