-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-hellstrom-textpreview-07.xml
775 lines (649 loc) · 37.8 KB
/
draft-hellstrom-textpreview-07.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc4103 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4103.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc4975 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4975.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.hellstrom-text-conference SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hellstrom-text-conference.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="bcp" docName="draft-hellstrom-textpreview-07" ipr="trust200902">
<front>
<title abbrev="Real-time Text Conversation">Presentation of Text Conversation in realtime and en-bloc form</title>
<author fullname="Gunnar Hellstrom" initials="G." surname="Hellstrom">
<organization>Omnitor</organization>
<address>
<postal>
<street></street>
<street>PO Box 92054</street>
<code>12006 Stockholm</code>
<city></city>
<region></region>
<country>Sweden</country>
</postal>
<phone>+46-8-58900050</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Norman Williams" initials="N." surname="Williams">
<organization>Gallaudet University</organization>
<address>
<postal>
<street>800 Florida Ave</street>
<street>SLCC-1120</street>
<code>20002</code>
<city>Washington</city>
<region>DC</region>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Arnoud A. T. van Wijk" initials="A." surname="van Wijk">
<organization>Real-Time Text Taskforce (R3TF)</organization>
<address>
<postal>
<country>NL</country>
</postal>
<uri>http://www.realtimetext.org</uri>
<email>[email protected]</email>
</address>
</author>
<author fullname="Gregg C. Vanderheiden" initials="G." surname="Vanderheiden">
<organization>Trace R&D Center, University of Wisconsin-Madison</organization>
<address>
<postal>
<street>1550 Engineering Drive</street>
<street></street>
<code>53706</code>
<city>Madison</city>
<region>WI</region>
<country>USA</country>
</postal>
<email>[email protected]</email>
<uri>http://www.engr.wisc.edu/ie/faculty/vanderheiden_gregg.html</uri>
</address>
</author>
<date day="8" month="March" year="2010" />
<abstract>
<t>This specification defines methods for presentation of a text
conversation with focus on the real-time features. 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. Both two-party
and multi-party situations are defined.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This is a specification of methods 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 methods are intended for use in a protocol environment where text
can be transmitted in real-time or in fragments of messages. Both
two-party situations and multi-party session presentations are
specified. The specification is mainly held on the presentation level,
relatively independent of the transport layer. It has though some
requirements on the lower layers, as well as some characteristics of the
lower layers cause slightly different user experience of the
presentation.</t>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Scope">
<t>This specification describes methods for presenting a text
conversation so that the gradual entry of text is made visible to the
users. One method has 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 character
by character, time-sampled, word by word, or any other method based on
small chunks. The methods cover both two-party and multi-party
situations.</t>
</section>
<section title="Real-time text presentation methods">
<t>The presentation method described here are intended to give a
convenient view of a text conversation between two or more participants
in a session. It is intended to fulfill the requirements of
ITU-T T.140 [1], 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.</t>
<figure align="center" anchor="example-realtime-preview"
title="Two-party call with real-time preview.">
<preamble>An example of a two-party view is shown in <xref target="example-realtime-preview"></xref>.</preamble>
<artwork><![CDATA[_________________________________________________
| |^|
| | |
| | |
| | |
| [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-typing> But I need to be back at the |_|
| hotel by 11 because I have t |v|
|_____________________________________________|_|
| OK, no prob |
| |
|_______________________________________________|
]]></artwork>
</figure>
<t><xref target="example-realtime-preview"></xref>: The text is here displayed in a traditional chat view, with
labelled 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.</t>
<t>Real-time text arriving from other participants is displayed in
'preview areas' within the scrolling 'history' window. They are
formatted to look different and are presented at the bottom of the
history window until they are completed. When completed they move up in
the history window and added to the history record. The text being
entered by the local participant appears in a separate entry field that
is preferably placed below the history field (to minimize eye movements
when reading and typing).</t>
<figure align="center" anchor="example-three-column-view"
title="Two-party call with column view.">
<preamble><xref target="example-three-column-view"></xref>
: Column view is an alternative presentation mode to real-time preview.</preamble>
<artwork><![CDATA[____________________________________________________________________
| Bob | Eve | Alice |
|____________________|____________________|________________________|
| | |I will arrive by TGV. |
|My flight is to Orly| |Convenient to the main |
| |Hi all, can we plan |station. |
| |for the seminar? | |
|Eve, will you do | | |
|your presentation on| | |
|Friday? |Yes, Friday at 10. | |
|Fine, wo | |We need to meet befo |
|__________________________________________________________________|
]]></artwork>
</figure>
<t>An alternative view is presented in <xref target="example-three-column-view"></xref>,
where text from each participant occupies one panel, and text
is placed in its vertical position to show its time relation.</t>
<section title="Common Aspects">
<section title="Paragraph dividing">
<t>Text entries are divided into paragraphs by hard or soft return. Hard
return finalizes a text entry. Once a text entry has been terminated by
hard return it can no longer be erased or modified. The control sequences
used for producing hard return are CRLF or paragraph separator U+2029.</t>
<t>
When soft return is used for creating a new paragraph, previous paragraph
can still be erased or modified. Soft return is produced by line separator U+2028.</t>
</section>
<section title="Completion of local entry">
<t>The end-of-entry
event may be triggered by a send button, a RETURN, or when another
condition selectable by the local user to "post what I have so far" is
met ( such as a pause in typing, a delimiting character such as a
period, or a turn-taking token).</t>
<t>When an end-of-entry event occurs, if the entry does not end with
end of paragraph as defined by the device, the sending system SHALL append one.
</t>
</section>
<section title="Moving between different states">
<t>Entries can be either "real-time (preview)" or "historical" and
they can be either "displayed" or "hidden". When real-time text is
received it SHALL BE classified as a real-time entry until an
end-of-entry indicator is received. Real-time entries SHOULD be
displayed in the real-time preview field. Once an end-of-entry
indicator is received, the entry SHALL become historical and SHOULD be
move into the history display field. Its position within the history
SHALL be determined by the time that its end-of-entry indicator was
received.</t>
<t>The local user may select to hide either the entries while they are
real-time (previews) or when they are historical. Hiding entries when
they are in real-time state may be done to avoid distraction for the
local participant. The feature to hide the entries while in real-time
state SHOULD provide some alert when an end-of-entry indicator is
received as well as when real-time text stops coming in for a period
of time. (The alert due to pause in incoming text is important because
some real-time text users are not accustomed to sending end-of-entry
indications(e.g. RETURNs) or may use a text based end-of-entry
indication (such as GA).</t>
<t>An entry (or category of entries) can be placed in a hidden state
by user command to hide it (them). (e.g. Hide all but "Mary" to make
it easier to see her thread)</t>
<t>The default SHALL be that both real-time and history are not
hidden.</t>
</section>
<section anchor="Eras" title="Erasure">
<t>Erasure SHALL only be done from the last displayed character per
participant.</t>
<t>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.</t>
<t>Characters that are composed by multiple keystrokes SHALL be erased
by one erasing action.</t>
<t>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.</t>
<t>New lines inserted by the user shall be erased in one erasing
action even if they are represented by multiple characters.</t>
<t>The erasing action MUST be performed 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 side-by-side-panel mode
described in section 6 and ITU-T T.140 <xref target="T140.refs">1</xref> and the real-time preview mode described
here.</t>
<t>The scope of erasure shall only be possible back to the latest new paragraph (hard return) sent from the erasing party.
This may be valid for message borders in certain message based
transmission systems. When using T.140, this condition should be
signalled with an "unsupported request" protocol element from the
entity that cannot perform the requested erasure.</t>
</section>
<section title="Presentation of detected errors">
<t>If a transmission error is detected and it is likely that it has
resulted in loss of text, a character SHALL be inserted in the text
for display at that point. The character should be the "Replacement
character", a question mark within a rhombus. For cases when this
character cannot be represented on the display, the replacement
character SHOULD be presented as an apostrophe (" ' ") .</t>
<t>The same applies for incoming text that cannot be presented on the
local terminal because of limitations in available fonts.</t>
</section>
<section title="Display formatting">
<t>The display SHALL be word-wrapped within the limits of the
window.</t>
<t>The following operations SHOULD be possible to do:
<list style="symbols">
<t>Select font size</t>
<t>Select text colour and background colour for each
participant.</t>
<t>Set window size</t>
</list></t>
</section>
<section title="En bloc transmission">
<t>It SHOULD be possible for the participants to hold their text and
not have it sent to the other participants until after the
end-of-message event occurs. This enables users who do not want their
message to be viewed by other participants until they have verified
it. This also facilitates editing since random editing can be done on
the text block before it is sent. This also allows a block of text to
be pasted into the text entry area and then edited before it is sent.
This could be new text or a previous text entry that the user would
like to resend with edits. The en bloc method SHALL NOT be the only
method for sending. A 'real-time / block send' switch SHOULD be
located near the local user's text entry field Real-time SHALL be the
default method for sending but a user preference setting MAY change
the default to en bloc.</t>
</section>
<section title="Multi-party sessions">
<t>A multi-party session can be presented in a similar manner as the
two-party session. The chat-view with real-time entry at the bottom of
the window is one possible view.</t>
<figure align="center" anchor="example-three-party-realtime-textpreview"
title="Three-party call with real-time preview.">
<preamble>A three-party view is shown in this example.</preamble>
<artwork><![CDATA[_________________________________________________
| |^|
| | |
| | |
| | |
|[Alice] Hi, Alice here. | |
| | |
|[Bob] Bob as well. | |
| | |
|[Eve] Hi, this is Eve, calling from Paris. | |
| I thought you should be here. | |
| | |
|[Alice] I am coming on Thursday, my | |
| performance is not until Friday morning.| |
| | |
|[Bob] And I on Wednesday evening. | |
| | |
|[Alice] 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-typing> But I need to be back to | |
| the hotel by 11 because I need | |
| |-|
| <Bob-typing> I wou |-|
|______________________________________________|v|
| of course, I underst |
|________________________________________________|
]]></artwork>
</figure>
<figure align="center" anchor="example-3party-column-view"
title="A coordinated column-view of a three-party
session with entries ordered in approximate time-order.">
<preamble><xref target="example-3party-column-view"></xref>
: This figure shows how a coordinated column view
MAY be presented on Alice´s device.</preamble>
<artwork><![CDATA[______________________________________________________________________
| Bob | Eve | Alice |
|____________________|______________________|________________________|
| | |I will arrive by TGV. |
|My flight is to Orly| |Convenient to the main |
| |Hi all, can we plan |station. |
| |for the seminar? | |
|Eve, will you do | | |
|your presentation on| | |
|Friday? |Yes, Friday at 10. | |
|Fine, wo | |We need to meet befo |
|____________________________________________________________________|
]]></artwork>
</figure>
<t>In the column view, the column showing text transmitted from the
device where the presentation is made, SHOULD be placed to the right of
all other columns, so that users recognize the operating environment
between different devices.</t>
<t>In an environment with less space in the display it MAY be necessary
to give up on displaying the relative time order in the column view in
order to display more of the conversation contents in available
space.</t>
<t>Yet other situations may call for display in separate windows for
example underneath video images from each participant.</t>
<figure align="center" anchor="example-3party-column-view-with-image"
title="Example of text conversation entries placed
underneath video images from each participant.">
<artwork><![CDATA[_______________________ _____________________ ___________________
| Bob | | Eve | | Alice |
|_____________________| |___________________| |__________________|
| ooooo | | 888 | | ... |
| / o o\ | | 8/- -\8 | | ||||| |
| ( _ | | | 0| | |0 | | || o o || |
| \_____/ | | | _ | | | || v || |
| | | \___/ | | ||\___/|| |
|_____________________| |___________________| |__________________|
|Help me to spell | |necessary | |ne.... OK you take|
|nessessarry,I always | | | |it |
|get it wrong | | | | |
|_____________________| |___________________| |__________________|
]]></artwork>
</figure>
<t>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, e.g. for live captioning of the call by a third party.</t>
<t>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 SHALL disappear from the preview window,
and text SHALL be entered en-bloc to the history display as they are
finished for that participant.</t>
</section>
</section> <!--- end section common aspects --->
<section title="Real-time Text Preview">
<section title="Entries in creation">
<t>Entries in creation SHALL be displayed in a real-time preview area,
one for each participant who has entries in creation. The real-time
preview areas MAY be placed under the list of completed entries as
shown in <xref target="example-realtime-preview"></xref> and
<xref target="example-three-party-realtime-textpreview"></xref>,
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 MAY also be displayed in
a manner more closely associated with earlier exchanged text entries
by the same participant (e.g. text from each participant goes in its
own column).</t>
<t>If real-time previews from other participants are placed under the
list of completed entries as in
<xref target="example-realtime-preview"></xref> and
<xref target="example-three-party-realtime-textpreview"></xref>, the
text being entered
by the local participant SHOULD be placed at the bottom in its own
text entry field. This is recommended for a number of reasons. First,
this is the only "editable" text on the screen. It also facilitates an
optional input behavior where the local user may sometimes be holding
their text back until it is completed while normally transmission
occurs in real-time. Having the user input area be in a separate field
MAY also be useful when scrolling the output field so that the input
field always stays in view even as the history and text previews are
scrolled out of view to read older text.</t>
<t>For ease of reading different entries, it is RECOMMENDED that all
entries be placed close together in the display area.</t>
<t>For text input technologies requiring a number of keystrokes before
the character or characters are finally decided, no characters shall
be submitted to communication until they are decided from this input
preparation process. This is for example valid for input of some Asian
languages, and for some text entry methods from number keypads, and
word prediction systems.</t>
<t>During entry, the following actions MAY be requested:
<list style="symbols">
<t>Alert. Requests alerting of the remote participant.</t>
<t anchor="Erase">Erase last character. Erases the last (
non-erased) character in the entry. (See
<xref target="Eras"></xref>)</t>
</list></t>
</section>
<section title="Completion of local entry">
<t>Text from the local participant SHALL be entered in the local user
input field, until an end-of-entry event occurs.
The completed entry SHALL be moved to the history display area. If the
protocol used defines an end-of-message indicator, it SHALL also be
issued.</t>
</section>
<section title="Completion of preview entry">
<t>Text from the remote participants SHALL be entered in the preview
area until an end-of entry event occurs. The end-of-entry is
identified by any variant of a NEW LINE coded in the character set
used, or an end of message indicator if there is a specific coding of
that event. When an end-of-entry event occurs, the completed entry
SHALL be moved to the history display area.</t>
</section>
<section title="Order of entries">
<t>The order of displayed entries in the display area SHALL be the
timing order when the entries were "posted" to the display from the
preview area. That is, when the new line or end-of-message indicator
is received.</t>
</section>
<section title="Display formatting">
<t>The labels on the entries SHOULD display the user name of the
participant. If this information is not available, labels indicating
"Received" and "Transmitted" or other suitable names for the
participants SHOULD be used.</t>
<t>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.</t>
<t>Each real-time preview area MAY have a fixed or adjustable size. It
MAY also have no specific scrolling features or its own scrolling
mechanism.</t>
</section>
<section title="Scrolling and buffering">
<t>When there are entries in the history area that have been pushed
(scrolled) out of the view by new text coming in, it SHOULD be
possible to scroll back to them within a practical limit. When the
display area is scrolled, it SHALL stay in that scrolled position
until scrolling is changed again or (at the user's option) when a new
entry is received. When scrolled to the bottom, the display area SHALL
auto-scroll as needed to show new entries. When the display
arrangement is made with the preview field placed just under the
history field as in <xref target="example-realtime-preview"></xref> and
<xref target="example-three-party-realtime-textpreview"></xref>,
the preview field and the history field SHOULD scroll together as one display area.</t>
<t>The input field of the local participant SHOULD always be visible
regardless of the scroll position of the history field.</t>
</section>
</section>
<section title="Column view">
</section>
</section>
<section title="PSTN Aspects">
<section title="Auto-real-time for Emergency calls and Textphone calls">
<t>When it is detected that the session is used for emergency
purposes, the text transmission SHALL be switched to real-time
regardless of its previous setting.</t>
<t>The user SHALL still be provided with a possibility to switch to en
bloc sending after the session is established.</t>
</section>
<section title="Reasons to finish an entry">
<t>The default end-of-entry action SHOULD be a new line request from
the user.</t>
<t>A specific send button MAY also be used.</t>
<t>Users with dominating experience from real-time text communication
in PSTN may have a habit of not ending entries with a new line. There
will be a risk that entries are left in real-time mode unintentionally
not displayed and not read if the receiving end has hidden real-time
display. Some actions are needed in order to avoid this risk.</t>
<t>If an entry is left in real-time mode without any input activity
for a long period (e.g. 10 seconds), the local participant should be
given an indication that there is an unfinished entry in the input
field, and given a hint to complete it. Optionally, e.g. when using a
voice-to-text application for generating text, the application SHOULD
create the end-of-entry.</t>
<t>A period (".") followed by a short inactivity MAY also be
configured to be used as an end-of-entry indication.</t>
</section>
<section title="Interoperability considerations with PSTN">
<t>For PSTN text gateways having user input from PSTN text telephones,
the following sequences SHOULD be included among those causing an
entry to be finished. These terminations would usually be done by the
PSTN gateway in its transmission towards the IP side:</t>
<t>
<list style="symbols">
<t>Letters "GA" or "GASK" or "SKSK" followed by short inactivity
(e.g. 3 seconds), for interaction with TTY users.</t>
<t>Character "+" or "x" followed by short inactivity (e.g. 3
seconds), for European textphone users.</t>
<t>Characters "*" or "KOM" followed by short inactivity (e.g. 3
seconds), for Northern Europe textphone users.</t>
</list>
</t>
<t>White spaces (space bar, New line, CR, and LF) after those
characters SHALL be accepted and included in the finished entry. (Some
users do type a space character after the turn-taking indicator and
some textphones will send return after the turn-taking symbol).</t>
</section>
</section>
<section title="Transport and presentation considerations ">
<section title="Time sampling and smooth display">
<t>It is RECOMMENDED that characters be buffered and transmitted in 300
ms intervals on the transport level. It is permissible to buffer
characters for transmission in up to 500 ms intervals. Display of
received chunks of text SHOULD be done one character at a time spread
over the transmission interval so that adding a chunk of text to the
real-time preview window approximately covers the transmission interval
to give a smoother flow. <vspace blankLines="0" /></t>
<t>The presentation method MAY 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.<vspace blankLines="0" /></t>
</section>
<section title="RTP based transport">
<t>The method MAY be applied on various text transmission technologies.
It 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 <xref target="T140.refs">1</xref>, and
<xref target="RFC3550">IETF RTP</xref> transport with packetization as defined
in <xref target="RFC4103">RFC 4103</xref>. The methods for applying this
in a multi-party situation is described in IETF Text media handling in
RTP based real-time and message conferences
<xref target="I-D.hellstrom-text-conference">draft-hellstrom-text-conference</xref>.</t>
</section>
<section title="MSRP and message chunk based transport">
<t>Another environment where the real-time text with preview
presentation is feasible, is with the messaging protocol
<xref target="RFC4975">IETF MSRP</xref>, where the message fragment concept
MAY be used for a real-time transmission and presentation according to
the description in this specification. This requires MSRP to be used in a real-time fashion.</t>
</section>
<section title="Identification of entries">
<t>The transport method SHALL allow identification of the source of
text, so that text from different sources can be arranged for
convenient and readable presentation at the receiving end. [e.g. to
attach labels to the incoming text).</t>
</section>
</section>
<section title="Presence indication">
<t>Appropriate SIP based presence features SHOULD be used to indicate
status in the user interface, e.g. that the user is typing when in
‘en bloc’ mode.</t>
</section>
<section title="Alerting">
<t>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. <vspace blankLines="0" /> 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. <vspace blankLines="0" /> 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 <xref target="T140.refs">T.140</xref> presentation, it
should also be issued when the alert-in-session T.140 control event is
received. <vspace blankLines="0" /> For minor events, for example when
an entry from a user is completed and displayed in the conversation
display area, an indication MAY be given e.g. by an on-screen flashing
or any other suitable alerting signal. <vspace blankLines="0" /> It may
be useful to provide external alerting also for these minor events 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.<vspace blankLines="0" /></t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="T140.refs">
<front>
<title>Recommendation T.140, Protocol for Multimedia Application
Text Conversation (including Addendum)</title>
<author fullname="" initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="February" year="2000" />
</front>
</reference>
&rfc4103;
&rfc3550;
&rfc4975;
&rfc2119;
&I-D.hellstrom-text-conference;
</references>
</back>
</rfc>