Internet DRAFT - draft-gautam-simple-quick-answer
draft-gautam-simple-quick-answer
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 <qa-set> 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 <qa-set> element
is a sequence of zero or more <qa> elements, each of which defines a
single Quick Answer. A <qa> element consists of one mandatory
element: <msg>, containing the actual QA message. In addition, there
are two optional element: <id>, used to carry the unique ID, assigned
to a particular QA by QA Holder back to the UAC; <creationdate>,
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 version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:im-QA"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ns="urn:ietf:params:xml:ns:im-QA">
<xs:element name="qa-set">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element name="qa" type="qaType" minOccurs="0" ma
xOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
</xs:complexType>
</xs:element>
<xs:complexType name="qaType">
<xs:sequence>
<xs:element name="id" type="xs:string" minOccurs="1"
maxOccurs="1"/>
<xs:element name="text" type="xs:string" minOccurs="1" m
axOccurs="1"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
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 <qa> element in the QA document. The content-type of the
request MUST be application/im-QA+xml. The <qa> element MUST be
created with <msg> and <creationdate> sub-element providing actual
message content and current date respectively. The <id> 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 (<id> and corresponding <msg>)
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 <id> element is used to carry the
ID generated. The <msg> element is used to carry the actual message.
The <creationdate> 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
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Quick Answer for Instant Messaging</title>
</head>
<body>
<h1>Namespace for SIMPLE QA extension</h1>
<h2>urn:ietf:params:xml:ns:QA</h2>
<p>See <a href="[URL of published RFC]">
[reference to RFC]</a>.</p>
</body>
</html>
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]
