Network Working Group G. Hellstrom
Internet-Draft Omnitor
Intended status: Best Current September 12, 2006
Practice
Expires: March 16, 2007
Text conversation with real-time preview
draft-hellstrom-textpreview-00
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 March 16, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
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.
Hellstrom Expires March 16, 2007 [Page 1]
Internet-Draft Text conversation with real-time preview September 2006
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 . . . . . . . . . . . . . . . . . . . . 4
4.3. Order of entries . . . . . . . . . . . . . . . . . . . . . 4
4.4. Scrolling and buffering . . . . . . . . . . . . . . . . . . 4
4.5. Moving between different states . . . . . . . . . . . . . . 5
4.6. Reasons to finish an entry . . . . . . . . . . . . . . . . 5
4.7. Erasure . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.8. Moving between states . . . . . . . . . . . . . . . . . . . 6
4.9. Display formatting . . . . . . . . . . . . . . . . . . . . 6
5. Transport and presentation considerations . . . . . . . . . . . 6
6. Multi-party calls . . . . . . . . . . . . . . . . . . . . . . . 7
7. Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
10. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Hellstrom Expires March 16, 2007 [Page 2]
Internet-Draft Text conversation with real-time preview September 2006
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 read. The 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 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. |
| |
| Can we meet on Thursday evening? |
| |
| <Eve>Yes, definitely. How about 7pm. |
| at the entrance of the restaurant |
| Le Lion Blanc? |
| we can have dinner and then take a walk. |
|_____________________________________________|
| Received from: <Eve> |
| But I need to be back to the hotel |
| by 11 because |
|_____________________________________________|
| Sent from: <Anne> |
| of course, I understand, no problem, |
| see you Thursda| |
|_____________________________________________|
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 Expires March 16, 2007 [Page 3]
Internet-Draft Text conversation with real-time preview September 2006
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 near 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
allows transmission of text in fragments shorter than complete
messages.
4. Real-time preview presentation method
4.1. Entries in creation
Entries in creation are 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.
4.2. Completion of entry
Text is entered in the real-time preview window, until an end-of-
entry event occurs. Then the completed entry is moved to the display
window.
During entry, the following actions can be requested:
o Alert. Requests alerting of the remote participant.
o Erase last character. Erases the last entered character.
4.3. Order of entries
The order of displayed entries in the display area is the timing
order when the entries were completed.
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
Hellstrom Expires March 16, 2007 [Page 4]
Internet-Draft Text conversation with real-time preview September 2006
stays showing that position until a new entry is transmitted, or
scrolling is changed again. When scrolled so that the last entry is
within view, or 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.
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.
It could be:
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 "+" 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.
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.
Hellstrom Expires March 16, 2007 [Page 5]
Internet-Draft Text conversation with real-time preview September 2006
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 is not available, labels indicating "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 follows the same display
formatting regarding font size, colours etc as the display area.
Each real-time preview window may have a fixed or adjustable size and
its own scrolling mechanism.
5. Transport and presentation considerations
It is permissible to buffer characters for transmission in up to 1
second intervals. 300 ms is recommended. Display of received chunks
of text shall be done with a slight time delay of each character so
that adding of a chunk to the real-time preview window approximately
covers the transmission interval.
In a multi-party situation it shall be possible to select
participants for whom text is displayed. Hidden from others.
The presentation method can be used with transport methods for real-
time text and for all text message methods where it is possible 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
Hellstrom Expires March 16, 2007 [Page 6]
Internet-Draft Text conversation with real-time preview September 2006
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.
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 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.
Hellstrom Expires March 16, 2007 [Page 7]
Internet-Draft Text conversation with real-time preview September 2006
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.
10. Normative References
[1] ITU-T, "Recommendation T.140, Protocol for Multimedia
Application Text Conversation and Addendum 1", 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-14 (work in progress),
February 2006.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Gunnar Hellstrom
Omnitor
Renathvagen 2
12137 Johanneshov
SE
Phone: +46-8-5560-0203
Email: gunnar.hellstrom@omnitor.se
Hellstrom Expires March 16, 2007 [Page 8]
Internet-Draft Text conversation with real-time preview September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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 Expires March 16, 2007 [Page 9]