SIMPLE D. Gautam Internet-Draft Huawei Technologies Intended status: Standards Track Oct 12, 2009 Expires: April 15, 2010 Quick Answer for SIMPLE draft-gautam-simple-quick-answer-00.txt 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 April 15, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 Gautam Expires April 15, 2010 [Page 1] Internet-Draft Quick Answer for SIMPLE Oct 2009 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Message Content . . . . . . . . . . . . . . . . . . . . . 4 3.2. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Registration . . . . . . . . . . . . . . . . . . . . . 4 3.2.2. Composing QA . . . . . . . . . . . . . . . . . . . . . 4 3.2.3. Receving MESSAGE message . . . . . . . . . . . . . . . 5 3.2.4. Sending QA . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Post-Registration Behavior . . . . . . . . . . . . . . . . 5 3.4. QA Holder Behavior . . . . . . . . . . . . . . . . . . . . 5 3.4.1. Receiving third-party REGISTER from registrar . . . . 5 3.4.2. Receiving MESSAGE message . . . . . . . . . . . . . . 5 4. Example Flow . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. QA Synchronization . . . . . . . . . . . . . . . . . . . . 6 4.2. QA Creation . . . . . . . . . . . . . . . . . . . . . . . 6 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Content-type registration for application/im-QA+xml . . . 7 6.2. URN Sub-Namespace Registration for 'urn:ietf:params:xml:ns:im-QA' . . . . . . . . . . . . . . 8 6.3. Schema Registration . . . . . . . . . . . . . . . . . . . 9 6.4. SIP option tag registration for qasupport . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Gautam Expires April 15, 2010 [Page 2] Internet-Draft Quick Answer for SIMPLE Oct 2009 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. As described in section 3 in more details, 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. These QA are carried using XML, as instance of the XML schema defined in section 7 and labeled as application/im-QA+xml content type. A QA is delivered to an instant messaging sender in the same manner as the messages themselves. This document doesn't not emphasize on that part considering that it can be done using existing mechanism as specified in [2] 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. The mechanism proposed here would also ease the interoperability (translation) between heterogeneous instant messaging systems. 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 Gautam Expires April 15, 2010 [Page 3] Internet-Draft Quick Answer for SIMPLE Oct 2009 "vacation" QAs are not generated automatically. 2. 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] 3. Description 3.1. Message Content This section describes the various elements which may be present in a QA message. The normative XML schema is defined in section 5. A QA message consists of a element with 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. 3.2. UAC Behavior 3.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) 3.2.2. Composing QA Any instant messaging user agent can create a QA. To do so it create a SIP MESSAGE [2] message with content-type as application/im-QA+xml and which will carry a QA as an instance of the XML schema define in section 5. This MESSAGE message will be sent to QA Holder. The message consists of a element containing the actual QA and a element providing the current date on which the QA is being created. QA Composer MUST not include element. Gautam Expires April 15, 2010 [Page 4] Internet-Draft Quick Answer for SIMPLE Oct 2009 3.2.3. Receving MESSAGE message On receiving a MESSAGE message with content type application/ im-QA+xml, a UAC SHALL store the information ( and corresponding ) received as a QA. 3.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. 3.3. Post-Registration Behavior On registration register will inform (only if qasupport option tag is present in the supported header) 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] 3.4. QA Holder Behavior 3.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. 3.4.2. Receiving MESSAGE message On receiving a MESSAGGE message [2] with content type application/ im-QA+xml, 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 SIP MESSAGE message with content type application/im-QA+xml carrying 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. 4. Example Flow Gautam Expires April 15, 2010 [Page 5] Internet-Draft Quick Answer for SIMPLE Oct 2009 4.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 4.2. QA Creation +---+ +---------+ |UAC| |QA Holder| +-.-+ +----.----+ | | | MESSAGE (QA Message | +---------------------------------------->| | 200 OK | |<----------------------------------------| | +---------------------+ | |ID Generation/Storage| | +---------------------+ | MESSAGE (QA353400g) | +<----------------------------------------| | 200 OK | |---------------------------------------->| | | | | QA Creation Flow Gautam Expires April 15, 2010 [Page 6] Internet-Draft Quick Answer for SIMPLE Oct 2009 5. XML Schema 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 Gautam Expires April 15, 2010 [Page 7] Internet-Draft Quick Answer for SIMPLE Oct 2009 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 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 Gautam Expires April 15, 2010 [Page 8] Internet-Draft Quick Answer for SIMPLE Oct 2009 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 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 Gautam Expires April 15, 2010 [Page 9] Internet-Draft Quick Answer for SIMPLE Oct 2009 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 Gautamn Huawei Technologies NingNan Av. Nanjing, Jiangsu 210012 P.R China Phone: +86 25 82276770 Email: deepanshu@huawei.com Gautam Expires April 15, 2010 [Page 10]