Network Working Group G. Hellstrom Internet-Draft Omnitor Intended status: Best Current N. Williams Practice Gallaudet University Expires: August 26, 2007 A. van Wijk Foundation AnnieS G. Vanderheiden University of Wisconsin-Madison February 22, 2007 Text conversation with real-time preview draft-hellstrom-textpreview-01 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 August 26, 2007. 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 August 26, 2007 [Page 1] Internet-Draft Text conversation with real-time preview February 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 August 26, 2007 [Page 2] Internet-Draft Text conversation with real-time preview February 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. _______________________________________________ | Hi, Anne here. | | | | Hi, this is Eve, calling from Paris. | | I thought you should be here. | | | | I am coming on Thursday, | | my performance is not until Friday morning. | | | | Can we meet on Thursday evening? | | | | Yes, definitely. How about 7pm. | | at the entrance of the restaurant | | Le Lion Blanc? | | we can have dinner and then take a walk| |_____________________________________________| | But I need to be back to the hotel | | by 11 becau | |_____________________________________________| | 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 August 26, 2007 [Page 3] Internet-Draft Text conversation with real-time preview February 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. Te 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 August 26, 2007 [Page 4] Internet-Draft Text conversation with real-time preview February 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. It list of possible options that could be extended after experience could be: Hellstrom, et al. Expires August 26, 2007 [Page 5] Internet-Draft Text conversation with real-time preview February 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 is not available, labels indicating "Received" Hellstrom, et al. Expires August 26, 2007 [Page 6] Internet-Draft Text conversation with real-time preview February 2007 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 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 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. In a multi-party situation it shall be possible to select participants 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 August 26, 2007 [Page 7] Internet-Draft Text conversation with real-time preview February 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 August 26, 2007 [Page 8] Internet-Draft Text conversation with real-time preview February 2007 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. 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 August 26, 2007 [Page 9] Internet-Draft Text conversation with real-time preview February 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 August 26, 2007 [Page 10] Internet-Draft Text conversation with real-time preview February 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 August 26, 2007 [Page 11]