idnits 2.17.1 draft-hellstrom-textpreview-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Transmitted characters that take no position on the display (e.g. Bell or Alert in Session) SHALL not take any specific erasing action, but be regarded to be erased simultaneously with the succeeding character. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: New lines inserted by automatic line break and word wrap actions purely for display formatting purposes by the local system SHALL not require any specific erasing action. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 25, 2011) is 4719 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Anne' is mentioned on line 166, but not defined == Missing Reference: 'Eve' is mentioned on line 171, but not defined Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Hellstrom 3 Internet-Draft Omnitor 4 Intended status: BCP A. van Wijk 5 Expires: November 26, 2011 Real-Time Text Taskforce (R3TF) 6 G. Vanderheiden 7 Trace R&D Center, University 8 of Wisconsin-Madison 9 N. Williams 10 Gallaudet University 11 May 25, 2011 13 Presentation of Text Conversation in real-time and en-bloc form 14 draft-hellstrom-textpreview-08 16 Abstract 18 This specification defines methods for presentation of a text 19 conversation with focus on the real-time features. The aim is to 20 give the participants in a conversation a good opportunity to 21 perceive the real-time flow of the conversation and also provide a 22 display of the history of the conversation that makes it easy to 23 read. Both two-party and multi-party situations are defined. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 26, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Real-time text presentation methods . . . . . . . . . . . . . 4 63 3.1. Common Aspects . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.1. Paragraph dividing . . . . . . . . . . . . . . . . . . 6 65 3.1.2. Completion of local entry . . . . . . . . . . . . . . 6 66 3.1.3. Moving between different states . . . . . . . . . . . 7 67 3.1.4. Erasure . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.1.5. Presentation of detected errors . . . . . . . . . . . 8 69 3.1.6. Display formatting . . . . . . . . . . . . . . . . . . 8 70 3.1.7. En bloc transmission . . . . . . . . . . . . . . . . . 8 71 3.1.8. Multi-party sessions . . . . . . . . . . . . . . . . . 9 72 3.2. Real-time Text Preview . . . . . . . . . . . . . . . . . . 11 73 3.2.1. Entries in creation . . . . . . . . . . . . . . . . . 11 74 3.2.2. Completion of local entry . . . . . . . . . . . . . . 12 75 3.2.3. Completion of preview entry . . . . . . . . . . . . . 12 76 3.2.4. Order of entries . . . . . . . . . . . . . . . . . . . 12 77 3.2.5. Display formatting . . . . . . . . . . . . . . . . . . 12 78 3.2.6. Scrolling and buffering . . . . . . . . . . . . . . . 13 79 3.3. Column view . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.3.1. Entries in creation . . . . . . . . . . . . . . . . . 13 81 3.3.2. Presentation of local entry . . . . . . . . . . . . . 13 82 3.3.3. Completion of entries . . . . . . . . . . . . . . . . 13 83 3.3.4. Order of entries . . . . . . . . . . . . . . . . . . . 13 84 3.3.5. Display formatting . . . . . . . . . . . . . . . . . . 13 85 3.3.6. Scrolling and buffering . . . . . . . . . . . . . . . 14 86 4. PSTN Aspects . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.1. Auto real-time for Emergency calls and Textphone calls . . 14 88 4.2. Reasons to finish an entry . . . . . . . . . . . . . . . . 14 89 4.3. Interoperability considerations with PSTN . . . . . . . . 14 90 5. Transport and presentation considerations . . . . . . . . . . 15 91 5.1. Time sampling and smooth display . . . . . . . . . . . . . 15 92 5.2. RTP based transport . . . . . . . . . . . . . . . . . . . 15 93 5.3. Message based transport . . . . . . . . . . . . . . . . . 15 94 5.4. Identification of entries . . . . . . . . . . . . . . . . 16 95 6. Presence indication . . . . . . . . . . . . . . . . . . . . . 16 96 7. Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 99 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 102 1. Introduction 104 This is a specification of methods for presentation of a real-time 105 text conversation. The aim is to give the participants in a 106 conversation a good opportunity to perceive the real-time flow of the 107 conversation and also provide a display of the history of the 108 conversation that makes it easy to follow the flow. One reason to 109 specify the presentation method is to be able to give participants a 110 synchronized view of the conversation even if they use different 111 presentation characteristics. The methods are intended for use in a 112 protocol environment where text can be transmitted in real-time or in 113 fragments of messages. Both two-party situations and multi-party 114 session presentations are specified. The specification is mainly 115 held on the presentation level, relatively independent of the 116 transport layer. It has though some requirements on the lower 117 layers, as well as some characteristics of the lower layers cause 118 slightly different user experience of the presentation. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Scope 128 This specification describes methods for presenting a text 129 conversation so that the gradual entry of text is made visible to the 130 users. One method has text flowing in real-time in a way that is 131 similar to common text chat, but with the possibility to follow 132 entries while they are created in a real-time preview area. The 133 method may be applied on any text conversation transport method that 134 transmits text character by character, time-sampled, word by word, or 135 any other method based on small chunks. The methods cover both two- 136 party and multi-party situations. 138 3. Real-time text presentation methods 140 The presentation method described here are intended to give a 141 convenient view of a text conversation between two or more 142 participants in a session. It is intended to fulfill the 143 requirements of ITU-T T.140 [T140.refs], and be feasible to implement 144 in terminals with small displays. The basic concept however could be 145 implemented in other text technologies as well and displayed in 146 different ways. ITU-T T.140 [T140.refs], Appendix I, describes a 147 traditional chat view and a two-column view. The display formats 148 shall be implemented so that terminals in a session can implement 149 different display views meeting the requirements and giving the users 150 a synchronized view of the flow of the conversation. 152 An example of a two-party view is shown in Figure 1. 153 _________________________________________________ 154 | |^| 155 | | | 156 | | | 157 | | | 158 | [Anne] Hi, Anne here. | | 159 | | | 160 | [Eve] Hi, this is Eve, calling from Paris. | | 161 | I thought you should be here. | | 162 | | | 163 | [Anne] I am coming on Thursday, | | 164 | my performance is not until Friday | | 165 | morning. | | 166 | [Anne] Can we meet on Thursday evening? | | 167 | | | 168 | [Eve] Yes, definitely. How about 7pm. | | 169 | at the entrance of the restaurant | | 170 | Le Lion Blanc? | | 171 | [Eve] we can have dinner and then take a | | 172 | walk |_| 173 | But I need to be back at the |_| 174 | hotel by 11 because I have t |v| 175 |_____________________________________________|_| 176 | OK, no probl | 177 | | 178 |_______________________________________________| 180 Figure 1: Two-party call with real-time text preview. 182 Figure 1: The text is here displayed in a traditional chat view, with 183 labelled entries from each participant ordered in a list with newest 184 entry last. Older entries are scrolled up, out of the screen area 185 when there is no room for them. 187 Real-time text arriving from other participants is displayed in 188 'preview areas' within the scrolling 'history' window. They are 189 formatted to look different and are presented at the bottom of the 190 history window until they are completed. When completed they move up 191 in the history window and added to the history record. The text 192 being entered by the local participant appears in a separate entry 193 field that is preferably placed below the history field (to minimize 194 eye movements when reading and typing). 196 Figure 2 : Column view is an alternative presentation mode to real- 197 time preview. 198 ____________________________________________________________________ 199 | Bob | Eve | Alice | 200 |____________________|____________________|________________________| 201 | | |I will arrive by TGV. | 202 |My flight is to Orly| |Convenient to the main | 203 | |Hi all, can we plan |station. | 204 | |for the seminar? | | 205 |Eve, will you do | | | 206 |your presentation on| | | 207 |Friday? |Yes, Friday at 10. | | 208 |Fine, wo | |We need to meet befo | 209 |__________________________________________________________________| 211 Figure 2: Two-party call with column view. 213 An alternative view is presented in Figure 2, where text from each 214 participant occupies one panel, and text is placed in its vertical 215 position to show its time relation. 217 3.1. Common Aspects 219 3.1.1. Paragraph dividing 221 Text entries are divided into paragraphs by hard or soft return. 222 Hard return finalizes a text entry. Once a text entry has been 223 terminated by hard return it can no longer be erased or modified. 224 The control sequences used for producing hard return are CRLF or 225 paragraph separator U+2029. 227 When soft return is used for creating a new paragraph, previous 228 paragraph can still be erased or modified. Soft return is produced 229 by line separator U+2028. 231 3.1.2. Completion of local entry 233 The end-of-entry event may be triggered by a send button, a RETURN, 234 or when another condition selectable by the local user to "post what 235 I have so far" is met ( such as a pause in typing, a delimiting 236 character such as a period, or a turn-taking token). 238 When an end-of-entry event occurs, if the entry does not end with end 239 of paragraph as defined by the device, the sending system SHALL 240 append one. 242 3.1.3. Moving between different states 244 Entries can be either "real-time (preview)" or "historical" and they 245 can be either "displayed" or "hidden". When real-time text is 246 received it SHALL BE classified as a real-time entry until an end-of- 247 entry indicator is received. Real-time entries SHOULD be displayed 248 in the real-time preview field. Once an end-of-entry indicator is 249 received, the entry SHALL become historical and SHOULD be move into 250 the history display field. Its position within the history SHALL be 251 determined by the time that its end-of-entry indicator was received. 253 The local user may select to hide either the entries while they are 254 real-time (previews) or when they are historical. Hiding entries 255 when they are in real-time state may be done to avoid distraction for 256 the local participant. The feature to hide the entries while in 257 real-time state SHOULD provide some alert when an end-of-entry 258 indicator is received as well as when real-time text stops coming in 259 for a period of time. (The alert due to pause in incoming text is 260 important because some real-time text users are not accustomed to 261 sending end-of-entry indications(e.g. RETURNs) or may use a text 262 based end-of-entry indication (such as GA). 264 An entry (or category of entries) can be placed in a hidden state by 265 user command to hide it (them). (e.g. Hide all but "Mary" to make it 266 easier to see her thread) 268 The default SHALL be that both real-time and history are not hidden. 270 3.1.4. Erasure 272 Erasure SHALL only be done from the last displayed character per 273 participant. 275 Transmitted characters that take no position on the display (e.g. 276 Bell or Alert in Session) SHALL not take any specific erasing action, 277 but be regarded to be erased simultaneously with the succeeding 278 character. 280 Characters that are composed by multiple keystrokes SHALL be erased 281 by one erasing action. 283 New lines inserted by automatic line break and word wrap actions 284 purely for display formatting purposes by the local system SHALL not 285 require any specific erasing action. 287 New lines inserted by the user shall be erased in one erasing action 288 even if they are represented by multiple characters. 290 The erasing action MUST be performed strictly according to the rules 291 above, in order to maintain a synchronized view of the conversation 292 for the participants, even if conversation participants use different 293 display formats, such as the side-by-side-panel mode described in 294 section 6 and ITU-T T.140 1 [T140.refs] and the real-time preview 295 mode described here. 297 The scope of erasure shall only be possible back to the latest new 298 paragraph (hard return) sent from the erasing party. This may be 299 valid for message borders in certain message based transmission 300 systems. When using T.140, an erasure emitted when the cursor is 301 already at the beginning of the message should be responded with an 302 "unsupported request" protocol element from the entity that cannot 303 perform the requested erasure. 305 3.1.5. Presentation of detected errors 307 If a transmission error is detected and it is likely that it has 308 resulted in loss of text, a character SHALL be inserted in the text 309 for display at that point. The character should be the "Replacement 310 character", a question mark within a rhombus. For cases when this 311 character cannot be represented on the display, the replacement 312 character SHOULD be presented as an apostrophe (" ' ") . 314 The same applies for incoming text that cannot be presented on the 315 local terminal because of limitations in available fonts. 317 3.1.6. Display formatting 319 The display SHALL be word-wrapped within the limits of the window. 321 The following operations SHOULD be possible to do: 323 o Select font size 325 o Select text color and background color for each participant. 327 o Set window size 329 3.1.7. En bloc transmission 331 It SHOULD be possible for the participants to hold their text and not 332 have it sent to the other participants until after the end-of-message 333 event occurs. This enables users who do not want their message to be 334 viewed by other participants until they have verified it. This also 335 facilitates editing since random editing can be done on the text 336 block before it is sent. This also allows a block of text to be 337 pasted into the text entry area and then edited before it is sent. 339 This could be new text or a previous text entry that the user would 340 like to resend with edits. The en bloc method SHALL NOT be the only 341 method for sending. A 'real-time / block send' switch SHOULD be 342 located near the local user's text entry field Real-time SHALL be the 343 default method for sending but a user preference setting MAY change 344 the default to en bloc. 346 3.1.8. Multi-party sessions 348 A multi-party session can be presented in a similar manner as the 349 two-party session. The chat-view with real-time entry at the bottom 350 of the window is one possible view. 352 A three-party view is shown in this example. 353 _________________________________________________ 354 | |^| 355 | | | 356 | | | 357 | | | 358 |[Alice] Hi, Alice here. | | 359 | | | 360 |[Bob] Bob as well. | | 361 | | | 362 |[Eve] Hi, this is Eve, calling from Paris. | | 363 | I thought you should be here. | | 364 | | | 365 |[Alice] I am coming on Thursday, my | | 366 | performance is not until Friday morning.| | 367 | | | 368 |[Bob] And I on Wednesday evening. | | 369 | | | 370 |[Alice] Can we meet on Thursday evening? | | 371 | | | 372 |[Eve] Yes, definitely. How about 7pm. | | 373 | at the entrance of the restaurant | | 374 | Le Lion Blanc? | | 375 |[Eve] we can have dinner and then take a walk | | 376 | | | 377 | But I need to be back to | | 378 | the hotel by 11 because I need | | 379 | |-| 380 | I wou |-| 381 |______________________________________________|v| 382 | of course, I underst | 383 |________________________________________________| 385 Figure 3: Three-party call with real-time preview. 387 This figure shows how a coordinated column view MAY be presented on 388 Alice's device. 389 ____________________________________________________________________ 390 | Bob | Eve | Alice | 391 |____________________|_____________________|________________________| 392 | | |I will arrive by TGV. | 393 |My flight is to Orly| |Convenient to the main | 394 | |Hi all, can we plan |station. | 395 | |for the seminar? | | 396 |Eve, will you do | | | 397 |your presentation on| | | 398 |Friday? |Yes, Friday at 10. | | 399 |Fine, wo | |We need to meet befo | 400 |____________________|_____________________|________________________| 402 Figure 4: A coordinated column-view of a three-party session with 403 entries ordered in approximate time-order. 405 In the column view, the column showing text transmitted from the 406 device where the presentation is made, SHOULD be placed to the right 407 of all other columns, so that users recognize the operating 408 environment between different devices. 410 In an environment with less space in the display it MAY be necessary 411 to give up on displaying the relative time order in the column view 412 in order to display more of the conversation contents in available 413 space. 415 Yet other situations may call for display in separate windows for 416 example underneath video images from each participant. 417 _______________________ ____________________ ___________________ 418 | Bob | | Eve | | Alice | 419 |_____________________| |___________________| |__________________| 420 | ooooo | | 888 | | ... | 421 | / o o\ | | 8/- -\8 | | ||||| | 422 | ( _ | | | 0| | |0 | | || o o || | 423 | \_____/ | | | _ | | | || v || | 424 | | | \___/ | | ||\___/|| | 425 |_____________________| |___________________| |__________________| 426 |Help me to spell | |necessary | |ne.... OK you take| 427 |nessessarry,I always | | | |it | 428 |get it wrong | | | | | 429 |_____________________| |___________________| |__________________| 431 Figure 5: Example of text conversation entries placed underneath 432 video images from each participant. 434 When implemented in an environment that supports multi-party calls, 435 it may be felt less important to maintain a real-time preview view of 436 text from all participants. It may be very important for some 437 participants to have rapid real-time preview presentation of selected 438 participants, e.g. for live captioning of the call by a third party. 440 Thus it may be desirable to be able to turn on or off the preview 441 presentation per user. When turning off real-time preview from one 442 participant, its presentation SHALL disappear from the preview 443 window, and text SHALL be entered en-bloc to the history display as 444 they are finished for that participant. 446 3.2. Real-time Text Preview 448 3.2.1. Entries in creation 450 Entries in creation SHALL be displayed in a real-time preview area, 451 one for each participant who has entries in creation. The real-time 452 preview areas MAY be placed under the list of completed entries as 453 shown in Figure 1 and Figure 3, or at any other suitable place in the 454 user interface. If video from the participants is also displayed, 455 then it MAY be suitable to display the real-time preview areas under 456 the video image of the participant. The real-time text MAY also be 457 displayed in a manner more closely associated with earlier exchanged 458 text entries by the same participant (e.g. text from each participant 459 goes in its own column). 461 If real-time previews from other participants are placed under the 462 list of completed entries as in Figure 1 and Figure 3, the text being 463 entered by the local participant SHOULD be placed at the bottom in 464 its own text entry field. This is recommended for a number of 465 reasons. First, this is the only "editable" text on the screen. It 466 also facilitates an optional input behavior where the local user may 467 sometimes be holding their text back until it is completed while 468 normally transmission occurs in real-time. Having the user input 469 area be in a separate field MAY also be useful when scrolling the 470 output field so that the input field always stays in view even as the 471 history and text previews are scrolled out of view to read older 472 text. 474 For ease of reading different entries, it is RECOMMENDED that all 475 entries be placed close together in the display area. 477 For text input technologies requiring a number of keystrokes before 478 the character or characters are finally decided, no characters shall 479 be submitted to communication until they are decided from this input 480 preparation process. This is for example valid for input of some 481 Asian languages, and for some text entry methods from number keypads, 482 and word prediction systems. 484 During entry, the following actions MAY be requested: 486 o Alert. Requests alerting of the remote participant. 488 o Erase last character. Erases the last ( non-erased) character in 489 the entry. (See Section 3.1.4) 491 3.2.2. Completion of local entry 493 Text from the local participant SHALL be entered in the local user 494 input field, until an end-of-entry event occurs. The completed entry 495 SHALL be moved to the history display area. If the protocol used 496 defines an end-of-message indicator, it SHALL also be issued. 498 3.2.3. Completion of preview entry 500 Text from the remote participants SHALL be entered in the preview 501 area until an end-of entry event occurs. The end-of-entry is 502 identified by any variant of a NEW LINE coded in the character set 503 used, or an end of message indicator if there is a specific coding of 504 that event. When an end-of-entry event occurs, the completed entry 505 SHALL be moved to the history display area. 507 3.2.4. Order of entries 509 The order of displayed entries in the display area SHALL be the 510 timing order when the entries were "posted" to the display from the 511 preview area. That is, when the new line or end-of-message indicator 512 is received. 514 3.2.5. Display formatting 516 The labels on the entries SHOULD display the user name of the 517 participant. If this information is not available, labels indicating 518 "Received" and "Transmitted" or other suitable names for the 519 participants SHOULD be used. 521 The real-time preview display area MAY follow the same display 522 formatting regarding font size, colors etc as the display area or MAY 523 be different. 525 Each real-time preview area MAY have a fixed or adjustable size. It 526 MAY also have no specific scrolling features or its own scrolling 527 mechanism. 529 3.2.6. Scrolling and buffering 531 When there are entries in the history area that have been pushed 532 (scrolled) out of the view by new text coming in, it SHOULD be 533 possible to scroll back to them within a practical limit. When the 534 display area is scrolled, it SHALL stay in that scrolled position 535 until scrolling is changed again or (at the user's option) when a new 536 entry is received. When scrolled to the bottom, the display area 537 SHALL auto-scroll as needed to show new entries. When the display 538 arrangement is made with the preview field placed just under the 539 history field as in Figure 1 and Figure 3, the preview field and the 540 history field SHOULD scroll together as one display area. 542 The input field of the local participant SHOULD always be visible 543 regardless of the scroll position of the history field. 545 3.3. Column view 547 The column view is an alternative presentation mode. Figure 4 548 provides a picture of a possible column view presentation. 550 3.3.1. Entries in creation 552 Entries shall be placed in one column for each participant. Entries 553 in creation are presented in real-time. 555 3.3.2. Presentation of local entry 557 A column is used for the local entries in a similar manner as the 558 remote entries. 560 3.3.3. Completion of entries 562 Completion of an entry is shown by a new line in the column display. 564 3.3.4. Order of entries 566 It is preferable to position the entries vertically in approximately 567 the order they started, so that the conversation order can be 568 perceived by the vertical position of the entries. 570 3.3.5. Display formatting 572 Each column should have a title line indicating the source of text. 574 3.3.6. Scrolling and buffering 576 It is preferred to provide a common scrolling mechanism for all 577 columns together, so that the vertical order is maintained even 578 during scrolling. 580 4. PSTN Aspects 582 4.1. Auto real-time for Emergency calls and Textphone calls 584 When it is detected that the session is used for emergency purposes, 585 the text transmission SHALL be switched to real-time regardless of 586 its previous setting. 588 The user SHALL still be provided with a possibility to switch to en 589 bloc sending after the session is established. 591 4.2. Reasons to finish an entry 593 The default end-of-entry action SHOULD be a new line request from the 594 user. 596 A specific send button MAY also be used. 598 Users with dominating experience from real-time text communication in 599 PSTN may have a habit of not ending entries with a new line. There 600 will be a risk that entries are left in real-time mode 601 unintentionally not displayed and not read if the receiving end has 602 hidden real-time display. Some actions are needed in order to avoid 603 this risk. 605 If an entry is left in real-time mode without any input activity for 606 a long period (e.g. 10 seconds), the local participant should be 607 given an indication that there is an unfinished entry in the input 608 field, and given a hint to complete it. Optionally, e.g. when using 609 a voice-to-text application for generating text, the application 610 SHOULD create the end-of-entry. 612 A period (".") followed by a short inactivity MAY also be configured 613 to be used as an end-of-entry indication. 615 4.3. Interoperability considerations with PSTN 617 For PSTN text gateways having user input from PSTN text telephones, 618 the following sequences SHOULD be included among those causing an 619 entry to be finished. These terminations would usually be done by 620 the PSTN gateway in its transmission towards the IP side: 622 o Letters "GA" or "GASK" or "SKSK" followed by short inactivity 623 (e.g. 3 seconds), for interaction with TTY users. 625 o Character "+" or "x" followed by short inactivity (e.g. 3 626 seconds), for European textphone users. 628 o Characters "*" or "KOM" followed by short inactivity (e.g. 3 629 seconds), for Northern Europe textphone users. 631 White spaces (space bar, New line, CR, and LF) after those characters 632 SHALL be accepted and included in the finished entry. (Some users do 633 type a space character after the turn-taking indicator and some 634 textphones will send return after the turn-taking symbol). 636 5. Transport and presentation considerations 638 5.1. Time sampling and smooth display 640 It is RECOMMENDED that characters be buffered and transmitted in 300 641 ms intervals on the transport level. It is permissible to buffer 642 characters for transmission in up to 1000 ms intervals. Display of 643 received chunks of text SHOULD be done one character at a time spread 644 over the transmission interval so that adding a chunk of text to the 645 real-time preview window approximately covers the transmission 646 interval to give a smoother flow. 648 The presentation method MAY be used with transport methods for real- 649 time text and for all text message methods where it is possible to 650 use timer based transmission to transmit fragments of message 651 entries. 653 5.2. RTP based transport 655 The method MAY be applied on various text transmission technologies. 656 It is designed in order to be usable for real-time text conversation 657 with coding and presentation according to ITU-T T.140 including its 658 amendment 1 [T140.refs], and IETF RTP [RFC3550] transport with 659 packetization as defined in RFC 4103 [RFC4103]. The methods for 660 applying this in a multi-party situation is described in IETF Text 661 media handling in RTP based real-time and message conferences 662 draft-hellstrom-text-conference [I-D.hellstrom-text-conference]. 664 5.3. Message based transport 666 The real-time text with preview presentation is also feasible to use 667 with the transport protocol used by messaging protocols. For each 668 transport protocol used, there must be a definition of a negotiation 669 method to explain that the real-time variant of presentation is 670 supported on reception and is used in transmission. When an 671 implementation is made for the SIP environment RFC3261 [RFC3261], the 672 RTP based transport RFC4103 [RFC4103] MUST also be supported in order 673 to guarantee interoperability with other implementations. 675 5.4. Identification of entries 677 The transport method SHALL allow identification of the source of 678 text, so that text from different sources can be arranged for 679 convenient and readable presentation at the receiving end [e.g. to 680 attach labels to the incoming text). 682 6. Presence indication 684 Appropriate SIP based presence features SHOULD be used to indicate 685 status in the user interface, e.g. that the user is typing when in 686 'en bloc' mode. 688 7. Alerting 690 In order to be useful for users who are deaf, hard of hearing and 691 deaf-blind as well as all situations with all users, it is important 692 to provide audible, visual and, where possible, tactile alerting from 693 events in the text conversation application. 694 It should be possible for a user to get external alerting signals 695 with a method preferred by the user. It may for example be 696 vibration, light flashes or sound as selected by the user. It should 697 also be possible to get alerting on the screen at certain events. 698 The signals to external alerting systems should be issued when an 699 incoming request for session initiation is received. When the method 700 is used in connection with T.140 [T140.refs] presentation, it should 701 also be issued when the alert-in-session T.140 control event is 702 received. 703 For minor events, for example when an entry from a user is completed 704 and displayed in the conversation display area, an indication MAY be 705 given e.g. by an on-screen flashing or any other suitable alerting 706 signal. 707 It may be useful to provide external alerting also for these minor 708 events in specific situations. If the user has not touched the 709 application for a number of minutes when the minor event occurs it 710 may be of interest to get an external alert. Details of such 711 arrangements are outside the scope of this document 713 8. IANA Considerations 715 This specification includes no request to IANA. 717 9. Security Considerations 719 This specification does not introduce any procedures that change 720 security issues from what is already specified for the session and 721 transport environment where the presentation method is applied. 723 10. Normative References 725 [I-D.hellstrom-text-conference] 726 Hellstrom, G. and A. Wijk, "Text media handling in RTP 727 based real-time conferences", 728 draft-hellstrom-text-conference-04 (work in progress), 729 March 2011. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 735 A., Peterson, J., Sparks, R., Handley, M., and E. 736 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 737 June 2002. 739 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 740 Jacobson, "RTP: A Transport Protocol for Real-Time 741 Applications", STD 64, RFC 3550, July 2003. 743 [RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text 744 Conversation", RFC 4103, June 2005. 746 [T140.refs] 747 ITU-T, "Recommendation T.140, Protocol for Multimedia 748 Application Text Conversation (including Addendum)", 749 February 2000, . 751 Authors' Addresses 753 Gunnar Hellstrom 754 Omnitor 755 Box 92054 756 Stockholm SE-120 06 757 SE 759 Phone: +46 858900056 760 Fax: +46 858900051 761 Email: gunnar.hellstrom@omnitor.se 762 URI: www.omnitor.se 764 Arnoud van Wijk 765 Real-Time Text Taskforce (R3TF) 766 NL 768 Fax: +31 412614000 769 Email: arnoud@realtimetext.org 770 URI: www.realtimetext.org 772 Gregg C. Vanderheiden 773 Trace R&D Center, University of Wisconsin-Madison 774 1550 Engineering Drive 775 Madison, WI 53706 776 USA 778 Email: gv@trace.wisc.edu 779 URI: www.engr.wisc.edu/ie/faculty/vanderheiden_gregg.html 781 Norman Williams 782 Gallaudet University 783 800 Florida Ave 784 SLCC-1120 785 Washington, DC 20002 786 USA 788 Email: norman.williams@gallaudet.edu 789 URI: tap.gallaudet.edu