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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Aug 13 02:13:51 UTC 2012

On 2012-08-09 17:09, XMPP Extensions Editor wrote:
> Version 0.7 of XEP-0301 (In-Band Real Time Text) has been released.
> Abstract: This is a specification for real-time text transmitted in-band over an XMPP session.
> Changelog: Simplifications and grammatical corrections. Some sections (1, 6.2, 6.4) shortened with simpler language. (MDR)
> Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.6/vs/0.7
> URL: http://xmpp.org/extensions/xep-0301.html

Very good to see many of the discussed issues resolved in version 0.7.
Here are my findings in reviewing version 0.7.

1.   4.2.3 id
The text should start with a description of what function this attribute 

Insert after the title:
"The id attribute is used to enable real-time correction of the last 
completed message."

Insert the title of XEP-0308
XEP-0308 Last message correction

2.  4.2.3 id
On second line. Reception must always be supported if both 0308 and 0301 
are supported.
c/MUST use this attribute if/MUST support reception of this attribute, 
and MUST transmit this attribute if/

3.   6.2.1 Activation guidelines

Can we really accept the weak indication that discovery is recommended? 
I think it shall be mandated.

c/Before sending real-time text, it ispreferable for a sender client 
to/Before sending real-time text, a sender client SHALL/

4. Section 1, intro, last bullet point, to make the description of 
REACH112 correct.:
c/A component within Total Conversation, used byReach112 
<http://www.marky.com/realjabber/xep/xep-0301.xml#nt-idp11206912>] in 
Europe, an accessible emergency service with real-time text./The 
real-time text component within Total Conversation, for example used 
byReach112 <http://www.reach112.eu/>[4 
<http://www.marky.com/realjabber/xep/xep-0301.xml#nt-idp11206912>] in 
Europe, a project for accessible communication services including 
emergency service.

5. Section 4.1 Example 1 should have a more natural distribution of 
letters in the different <rtt/> elements, appearing from the 
transmission in regular intervals as specified in section 4.1. This 
comment has been made from different sources a number of times.

6. 4.7 Third paragraph. Language correction. This is an enumeration of 
only two elements. Connect them with or instead of comma:
s/messages, incorrect/messages or incorrect/

7. Appendix G:
4 s/Reach112: European emergency service with real-time text./Reach112: 
European accessible communication and emergency service project with 
total conversation including real-time text./

8.  4.1 xml:lang
Describe explicit or implicit use of the xml:lang attribute similarly as 
it is described for <body/> in RFC 6221.
This attribute can introduce alternative language variants of the text 
in messages and other elements.
The use is described in RFC 6221.
For XEP-0301 it would be natural to offer the same opportunity to 
provide the alternative languages in the same message.

This would at least go into section 4.2 RTT attributes and <t/> 

Each language will have its own editing elements and values, so the 
xml:lang attribute should be on the <rtt/> level.

I propose insertion a new subsection in 4.2
4.2.4 Language
Multiple instances of the <rtt/> element MAY be included in a message 
stanza for the purpose of providing alternate versions of the same 
real-time text, but only if each instance possesses an 'xml:lang' 
attribute with a distinct language value (either explicitly or by 
inheritance from the 'xml:lang' value of an element farther up in the 
XML hierarchy, which from the sender's perspective can include the XML 
stream header as described in RFC 6220 [   ]). The support for language 
variants SHALL follow the principles of support for language variants in 
message bodies specified in RFC 6221[   ].

This example provides a small part of real-time text in the default 
language English and the alternative language Check.

<message from='juliet at example.com/balcony'
  id='z94nb37h' to='romeo at example.net' type='chat' xml:lang='en'>
   <rtt xmlns='urn:xmpp:rtt:0' seq='89002'><t>tho</t></rtt>
   <rtt xmlns='urn:xmpp:rtt:0' seq='32304'xml:lang='cs'> <t>ty</t></rtt>

The second line from the bottom of 4.1 should be changed from
"There MUST NOT be more than one <rtt/> element per <message/> stanza."
"There MUST NOT be more than one <rtt/> element per language variant in 
each <message/> stanza."

10. Appendix A, dependencies need updating.
Dependencies: now only contain XMPP Core and XEP-0020.
XEP-0020 seems not to be used anymore, but at least XMPP IM, XEP-0030, 
XEP-0085, XEP-0115, XEP-0308

Appendix A, dependencies,
s/XMPP Core, XEP-020/XMPP Core, XMPP IM XEP-0030, XEP--0085, XEP-0115, 

11. Appendix A. A short name should be assigned.
Some possible short names:
rtt, xmpp-rtt, real-time-text, xmpp-real-time-text


12. Chapter 1, 5th bullet point
This point refers to a brand name AOL. I am not used to see brand name 
references in standards. I would guess that that tradition applies to XEPs.

if so:
s/TheReal-Time IM 
featurefound in AOL Instant Messenger./A real-time text feature found in 
some instant messaging systems./

13. Section 4.4, second line

s/This interval meets/This interval provides an opportunity to meet/

[motivation] The F.700 requirement is for end-to-end latency ( that 
provides the human experience). We cannot guarantee network delay. 
Therefore the interval is set so that there is a good opportunity to 
meet the requirements in most network conditions.

14. Section 4.2.3 id
It has just been revealed in the XEP-0308 discussions that there may be 
cases when the id is not recognized by the receiver. It may be a just 
logged on receiver, or it may be a MUC server modifying id. Therefore 
add caution for that situation.

Add last in 4.2.3:
If 'id' is not recognized but a 'reset' with 'id' received by a 
receiver, the contents should be accepted anyway and presented as a 

15. Section 6.1.3.

s/It is acceptable for senders with bursty output to immediately 
transmit word bursts of text without buffering./It is acceptable for 
senders with bursty output to immediately transmit word bursts of text 
without buffering as long as the time between transmissions is not 
shorter than the intended transmission interval./

Extra caution needs to be added so that a bursty output sender does not 
overwhelm a receiver or the network with too frequent packets. Text 
sources such as speech-to-text and cut and paste can produce more than 
one word per 700 ms and may therefore need to transmit more than one 
word per packet.

16. Section 6.2.1 Activation.
Close to the end of this section, there is a sentence saying:
"It is inappropriate to send any further <rtt/> elements, until support 
is confirmed".

I wonder if there are any one-to-many situations with a very large 
number of recipients when it is not appropriate to expect answers from 
all recipients.

If so, this sentence should be deleted.

17. Section 6.2.1 and 6.6.2 Missing reference to XEP-0085

There are three references to XEP-0085, none of them have the customary 
reference to the reference list and a link to the document.
One is in section 6.2.1, two are in section 6.6.2

[proposal] add reference to [18]

18. Section 6.4.4  "Basic real-time text.
This is an odd way of transmitting real-time text by sending the whole 
real-time message in each transmission.
I doubt that it should be included in the specification. The title is 
The specification does not need to describe all odd ways to use the 
protocol. Implementers usually invent such ways anyway, and may use them 
as long as they are within the limits of the protocol.

If this way to transmitting real-time text has many disadvantages.
It implies a risk that each rtt message gets very long. Thus it should 
not be used with short transmission intervals. Wait elements cannot be 
used, so for usable presentation it will rely on receiving clients 
implementing time smoothing instead of keypress interval presentation, 
otherwise the presentation will be unpleasantly jerky. Time smoothing 
was mandated in early versions of this specification but is just 
mentioned in this version, with no indication that there are situations 
like this when it is essential for usability.

[proposal 1] Delete the section.

[proposal 2] if deletion is not accepted, rename section 6.4.4 to 
"Retransmission of the changing real-time message."

19. Section 6.5 Receiver guidelines
Version 0.1 of this specification had in its "Receiver guidelines" 
section the following point.

"If support for the <w> element is not possible, receiving software 
SHOULD use an alternate text-smoothing method, such as time-smoothed 
progressive output of received text."

This recommendation is not included in version 0.7. There are a couple 
of very vague indications elsewhere that smoothing is possible, but no 
clear recommendation.
Display of gradually growing text at 700 ms intervals create an 
annoyingly jerky impression. Some smoothing is needed.

Reinstate the sentence last in section 6.5 adapted to the current 
guideline language of that chapter:

"If support for the <w/> element is not possible, receiving clients are 
recommended to use an alternate text-smoothing method, such as 
time-smoothed progressive output of received text."

20. Section 4.3.1 Wrong reference
Section 4.3.1 says that <body/> is defined in XMPP CORE. It is instead 
defined in XMPP IM [10]

Change reference to XMPP CORE [9] in 4.3.1   to  XMPP IM [10]


Gunnar Hellström
gunnar.hellstrom at omnitor.se

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120813/34e68d9b/attachment.html>

More information about the Standards mailing list