Network Working Group G. Hellstrom
Internet-Draft Omnitor
Intended status: Best Current N. Williams
Practice Gallaudet University
Expires: February 27, 2008 A. van Wijk
Foundation AnnieS
G. Vanderheiden
University of Wisconsin-Madison
August 26, 2007
Text conversation with real-time preview
draft-hellstrom-textpreview-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 February 27, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This specification defines a method for presentation of a real-time
text conversation. The aim is to give the participants in a
conversation a good opportunity to perceive the real-time flow of the
Hellstrom, et al. Expires February 27, 2008 [Page 1]
Internet-Draft Text conversation with real-time preview August 2007
conversation and also provide a display of the history of the
conversation that makes it easy to read. This is achieved by
arranging the presentation of the conversation in separate areas for
real-time text entries in creation versus completed text entries.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Real-time preview presentation method . . . . . . . . . . . . 4
4.1. Entries in creation . . . . . . . . . . . . . . . . . . . 4
4.2. Completion of entry . . . . . . . . . . . . . . . . . . . 5
4.3. Order of entries . . . . . . . . . . . . . . . . . . . . . 5
4.4. Scrolling and buffering . . . . . . . . . . . . . . . . . 5
4.5. Moving between different states . . . . . . . . . . . . . 5
4.6. Reasons to finish an entry . . . . . . . . . . . . . . . . 5
4.7. Erasure . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.8. Moving between states . . . . . . . . . . . . . . . . . . 6
4.9. Display formatting . . . . . . . . . . . . . . . . . . . . 6
5. Transport and presentation considerations . . . . . . . . . . 7
6. Multi-party calls . . . . . . . . . . . . . . . . . . . . . . 8
7. Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Hellstrom, et al. Expires February 27, 2008 [Page 2]
Internet-Draft Text conversation with real-time preview August 2007
1. Introduction
This is a specification of a method for presentation of a real-time
text conversation. The aim is to give the participants in a
conversation a good opportunity to perceive the real-time flow of the
conversation and also provide a display of the history of the
conversation that makes it easy to follow the flow. One reason to
specify the presentation method is to be able to give participants a
synchronized view of the conversation even if they use different
presentation characteristics. The method is intended for use in a
protocol environment where text can be transmitted in real-time or in
fragments of messages. The technique has different names but some
are "real-time chat", "IM with Preview" and "IM with Real-time
Preview".
The method is possible to use for two-party calls and multi-party
calls. A two-party view is shown in Figure 1.
_______________________________________________
| <Anne>Hi, Anne here. |
| |
| <Eve>Hi, this is Eve, calling from Paris. |
| I thought you should be here. |
| |
| <Anne>I am coming on Thursday, |
| my performance is not until Friday morning. |
| |
| <Anne>Can we meet on Thursday evening? |
| |
| <Eve>Yes, definitely. How about 7pm. |
| at the entrance of the restaurant |
| Le Lion Blanc? |
| <Eve>we can have dinner and then take a walk|
|_____________________________________________|
| <Eve> But I need to be back to the hotel |
| by 11 becau |
|_____________________________________________|
| <Anne> of course, I understand, no problem, |
| see you Thursd |
|_____________________________________________|
Figure 1: Two-party call with real-time preview.
The text is displayed in a traditional chat view, with labeled
entries from each participant ordered in a list with newest entry
last. Older entries are scrolled up, out of the screen area when
there is no room for them.
Hellstrom, et al. Expires February 27, 2008 [Page 3]
Internet-Draft Text conversation with real-time preview August 2007
2. Terminology
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 RFC 2119 [5].
3. Scope
This specification describes a method for presenting a text
conversation with text flowing in real-time in a way that is similar
to common text chat, but with the possibility to follow entries while
they are created in a real-time preview area. The method may be
applied on any text conversation transport method that transmits text
on a character by character, word by word, or other small chunk
basis.
4. Real-time preview presentation method
The presentation method described here is intended to give a
convenient view of a text conversation between two or more
participants in a session. It is intended to be compatible with the
requirements of ITU-T T.140 [1], and to look familiar for text chat
users and be feasible to implement in terminals with small displays.
The basic concept however could be implemented in other text
technologies as well and displayed in different ways. ITU-T T.140
[1], Appendix I, describes a traditional chat view and a two-column
view. The display formats shall be implemented so that terminals in
a session can implement different display views meeting the
requirements of T.140 [1] and giving the users a synchronized view of
the flow of the conversation.
4.1. Entries in creation
Entries in creation are usually displayed in a separate real-time
preview area, one for each participant for whom real-time preview is
activated. The real-time preview areas may be placed under the list
of completed entries or at any other suitable place in the user
interface. If video from the participants is also displayed, then it
may be suitable to display the real-time preview areas under the
video image of the participant. The real-time text could also be
displayed in a manner more closely associated with earlier exchanged
text entries in the session.
Hellstrom, et al. Expires February 27, 2008 [Page 4]
Internet-Draft Text conversation with real-time preview August 2007
4.2. Completion of entry
Text is entered in the real-time preview window, until an end-of-
entry event occurs or another "post what I have so far" condition is
met (such as a certain number of characters, or a pause in typing, or
a delimiting character such as comma, or a turn-taking token). Then
the completed entry is moved to the display window.
During entry, the following actions may be requested:
o Alert. Requests alerting of the remote participant.
o Erase last character. Erases the last entered character.
o Request to turn Real-time Preview on/off.
4.3. Order of entries
The order of displayed entries in the display area is the timing
order when the entries were "posted" to the display from the preview
area.
4.4. Scrolling and buffering
When there are entries scrolled out of the window, it is possible to
scroll them back within a practical limit. When scrolled, the view
stays showing that position until scrolling is changed again or
(optionally) a new entry is transmitted. When scrolled so that the
last entry is within view, or (optionally) a new entry is
transmitted, the display continues showing new entries.
4.5. Moving between different states
Three states are defined for an entry. It can be in active state,
displayed state or hidden state.
It is in active state while it is being produced. It may then be
displayed in the real-time preview area.
An end of entry event takes it out of active state, normally to
displayed state.
An entry can become hidden by scrolling off screen, or by user
command.
(e.g. Hide all but "Mary" to make it easier to see her thread)
4.6. Reasons to finish an entry
The default end of entry action is a new line request from the user.
It is possible to add other end of entry actions to the logic.
A list of possible options that could be extended after experience
could be:
Hellstrom, et al. Expires February 27, 2008 [Page 5]
Internet-Draft Text conversation with real-time preview August 2007
o Long inactivity ( e.g. 30 seconds ), to ease interaction with
Instant messaging systems.
o Full stop "." followed by short inactivity (e.g. 7 seconds), for
more flow.
o Letters "GA" or "GASK" or "SKSK" followed by short inactivity
(e.g. 7 seconds), for interaction with TTY users.
o Character "+" or "x" followed by short inactivity (e.g. 7
seconds), for European textphone users.
o Character "*" followed by short inactivity (e.g. 7 seconds), for
Northern Europe textphone users.
White spaces (space bar, New line, CR, and LF) after those characters
should be accepted and included in the finished entry. (Some users
do type a space character after the turntaking indicator and some
textphones will send return after the turntaking symbol).
4.7. Erasure
Erasure is only done from the last character entered. For text
presentation methods allowing erasure over the ending border of the
entry, erasure shall be allowed to reach entries already moved to
display state. When used with transport methods not allowing erasure
over entry borders, the erasing user shall be provided feedback when
erasure is no longer possible. An entry can be moved back from
display state to active state by erasure of the last character in the
entry. When erasing, it is important to perform the erasing action
strictly according to the rules above, in order to maintain a
synchronized view of the conversation for the participants, even if
conversation participants use different display formats, such as the
two-panel mode described in ITU-T T.140 1 [1] and the real-time
preview mode described here.
4.8. Moving between states
An entry can be moved back and forth between hidden state and display
state by different actions:
o Scrolling by new entries coming.
o Scrolling by the user.
o Changing font size or window size.
o Hiding or showing entries from a participant ( most relevant in a
multi-party call )
4.9. Display formatting
The display shall be word-wrapped within the limits of the window.
The labels on the entries should display the user name of the
participant. If this information is not available, labels indicating
Hellstrom, et al. Expires February 27, 2008 [Page 6]
Internet-Draft Text conversation with real-time preview August 2007
"Received" and "Transmitted" or other suitable names for the
participants should be used.
The following operations shall be possible to do:
o Select font size
o Select text colour and background colour for each participant.
o Set window size
o Select between IM with preview mode and other modes.
The real-time preview display area may follow the same display
formatting regarding font size, colours etc as the display area or
may be different.
Each real-time preview window may have a fixed or adjustable size and
its own scrolling mechanism.
5. Transport and presentation considerations
It is recommended to buffer characters in 300 ms intervals on the
transport level. It is permissible to buffer characters for
transmission in up to 1 second intervals. Display of received chunks
of text shall be done with a slight time delay for each character so
that adding a chunk of text to the real-time preview window
approximately covers the transmission interval to give a smoother
flow.
It shall be possible to select participants in a multi-party
situation for whom text is displayed, while text entries from others
are hidden.
The presentation method can be used with transport methods for real-
time text and for all text message methods where it is possible to
use timer based transmission to transmit fragments of message
entries.
The method is designed in order to be usable for real-time text
conversation with coding and presentation according to ITU-T T.140
including its amendment 1 [1], and IETF RTP [3] transport with
packetization as defined in RFC 4103 [2]. These coding, presentation
and transport specifications SHOULD be used whenever there is no
strong reason to follow other specifications.
An example of another environment where the real-time text with
preview presentation is feasible, is with the messaging protocol IETF
MSRP [4], where the message fragment concept can be used for a
pseudo-real-time transmission and presentation according to the
description in this specification.
Hellstrom, et al. Expires February 27, 2008 [Page 7]
Internet-Draft Text conversation with real-time preview August 2007
6. Multi-party calls
When implemented in an environment that supports multi-party calls,
it may be felt less important to maintain a real-time preview view of
text from all participants. It may be very important for some
participants to have rapid real-time preview presentation of selected
participants. Thus it may be desirable to be able to turn on or off
the preview presentation per user. When turning off real-time
preview from one participant, its presentation disappears from the
preview window, and text is entered entry by entry as they are
finished for that participant.
7. Alerting
In order to be useful for hearing impaired, deaf and deaf-blind users
as well as all situations with all users, it is important to provide
audible, visual and, where possible, tactile alerting from events in
the text conversation application.
It should be possible for a user to get external alerting signals
with a method preferred by the user. It may for example be
vibration, light flashes or sound as selected by the user. It should
also be possible to get alerting on the screen at certain events.
The signals to external alerting systems should be issued when an
incoming request for session initiation is received. When the method
is used in connection with T.140 [1] presentation, it should also be
issued when the alert-in-session T.140 control event is received.
For minor events, for example when an entry from a user is completed
and displayed in the conversation display area, it is helpful to give
an indication by an on-screen flashing. Such flashing shall be
avoided when the reason for flashing is on the window that has focus.
It may be useful to provide external alerting also for these minor
events also in specific situations. If the user has not touched the
application for a number of minutes when the minor event occurs it
may be of interest to get an external alert. Details of such
arrangements are outside the scope of this document.
8. IANA Considerations
None.
9. Security Considerations
This specification does not introduce any procedures that change
security issues from what is already specified for the session and
transport environment where the presentation method is applied.
Hellstrom, et al. Expires February 27, 2008 [Page 8]
Internet-Draft Text conversation with real-time preview August 2007
10. Normative References
[1] ITU-T, "Recommendation T.140, Protocol for Multimedia
Application Text Conversation (including Addendum)",
February 2000.
[2] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-19 (work in progress),
February 2007.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Gunnar Hellstrom
Omnitor
PO Box 92054
12006 Stockholm
Sweden
Phone: +46-8-58900050
Email: gunnar.hellstrom@omnitor.se
Norman Williams
Gallaudet University
800 Florida Ave
Kendall Hall 101a
Washington, DC 20002
USA
Email: norman.williams@gallaudet.edu
Hellstrom, et al. Expires February 27, 2008 [Page 9]
Internet-Draft Text conversation with real-time preview August 2007
Arnoud A. T. van Wijk
Foundation AnnieS
Postbus 3
9700 AA Groningen
The Netherlands
Email: arnoud@annies.nl
URI: http://www.annies.nl/content/inEnglish/home.asp
Gregg C. Vanderheiden
University of Wisconsin-Madison
1550 Engineering Drive
Madison, WI 53706
USA
Email: gv@trace.wisc.edu
URI: http://www.engr.wisc.edu/ie/faculty/vanderheiden_gregg.html
Hellstrom, et al. Expires February 27, 2008 [Page 10]
Internet-Draft Text conversation with real-time preview August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hellstrom, et al. Expires February 27, 2008 [Page 11]