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. _______________________________________________ | 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. | |_____________________________________________| | Received from: | | But I need to be back to the hotel | | by 11 because | |_____________________________________________| | Sent from: | | 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]