[Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

Gunnar Hellström gunnar.hellstrom at omnitor.se
Tue Jul 10 06:58:39 UTC 2012

I see that you in this version have introduced a couple of "odd" 
real-time text transmission strategies in sections 6.4.1 and 6.4.2, 
based on the  'reset' event.

I get the impression that you have introduced them after getting 
feedback that it is complicated to detect and convey real-time editing 
within a real-time message.

6.4.1 proposes to send the whole real-time message for every 
transmission interval that there has been any addition or modification 
to it.
6.4.2 proposes to send the whole real-time message repeatedly while the 
user is editing within the real-time message.

They are certainly possible to use, but have, as you point out in the 
last sentence of each section, some obvious disadvantages. One is that 
the length of these messages can be very long if the user has the habit 
of seldom indicating end of message.  That behavior maybe becomes a 
common habit when you get used to real-time text.

A new reader of the specification would however maybe not detect that 
the methods are odd, but read the headings and get the impression that 
this is the normal way of transmitting real-time text. 6.4.1 has the 
heading "Basic Real-Time Text." leading to the conclusion that this is 

I suggest some reordering, modifications of headers and slight wording 
changes to amend this.

1. Insert explanation in 6.4
"This section describes alternatives for how to detect and compose what 
shall be transmitted during real-time text operation.

2. In first line of 6.4.4 insert after "method" : "to detect what 
changes to transmit"

3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method 
that is not recommended, and does not specify a solution, so it suits 
better as introductory warning words.  Use the title 6.4.3 Monitoring 
message changes.  delete title 6.4.4

4. Replace the second sentence in 6.4.3 (starting with "However..."), 
with "However, this method has disadvantages."

5. Rename 6.4.1 to "Using 'reset' events to transmit changes.

6. Include a new first sentence in 6.4.1: "As an alternative to 
detecting and transmitting only the changes in the real-time message, 
the following method can be considered."

7. Move 6.4.3 to become 6.4.1, pushing earlier 6.4.1 and 6.4.2 down to 
become 6.4.2 and 6.4.3 respectively.

Gunnar Hellström
gunnar.hellstrom at omnitor.se

More information about the Standards mailing list