It is good to see a new version of the XMPP Real Time Text extension.
On 2013-04-08 17:47, XMPP Extensions Editor wrote:
Version 0.8 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.
Real-time text is text transmitted instantly while it is being typed or
created.
Diff: http://xmpp.org/extensions/diff/api/xep/0301/diff/0.7/vs/0.8
URL: http://xmpp.org/extensions/xep-0301.html
The general impression is that it is in a good and mature condition.
I have a couple of small comments.
1. Erasure over message border.
In 4.6.3.2, it is said about the Erase element:
"Note: Excess backspaces MUST be ignored. Thus, text is backspaced only
to the beginning of the message, in situations where n is larger than p."
This can be perceived in three ways. Support of XEP-0308 for last
message correction may change the situation a bit.
1. Seen from the transmitting user perspective, with XEP-0308 support,
backspacing over the message border may be the natural way to return to
the previous message and make a small correction. Without XEP-0308
support, the statement is true.
2. Seen from the transmitting client perspective. If XEP-0308 is
supported, then a user backspace at the beginning of the message should
not be ignored, but instead activate last message correction, providing
a <reset/> and start acting in the previous message. IF XEP-0308 is not
supported, then the statement is true.
3. Seen from the receiving client perspective, the statement is true.
"Excess" backspaces shall be caught by the transmitting client and
either ignored or caused to generate the move to the previous message
before continuing to erase, depending on XEP-0308 support.
I suggest that the XEP-0308 influence is kept largely isolated to
section 6.6.3 and therefore no discussion on its influence put in here.
Instead, if anything shall be done, I suggest to just insert words "by
the receiving client", so that the note reads:
"Note: Excess backspaces MUST be ignored by the receiving client. Thus,
text is backspaced only to the beginning of the message, in situations
where n is larger than p."
2. Risk for excessive lag.
In "6.5 Receiving Real-Time Text", I think this text is scaring:
"In processing Element <w/> -- Wait Interval
<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval>,
excess lag in incoming real-time text might occur if multiple delayed
<rtt/> elements suddenly get delivered"
I think that in most applications, the users prefer rapid presentation
over exact replication of timing of typing.
An easy way out is to be just a little bit more prescriptive:
"In processing Element <w/> -- Wait Interval
<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval>,
excess lag in incoming real-time text might occur if multiple delayed
<rtt/> elements suddenly get delivered (e.g. congestion, intermittent
wireless reception). Recipients should avoidexcess sustained lag by
monitoring the queue for excess <w/> action elements (e.g. unprocessed
<w/> elements from more than one <rtt/> element before the latest
received ) and then ignoring or shortening the intervals in <w/>
elements. This allows lagged real-time text to "catch up" quickly."
Another action would be to introduce timestamping of rtt elements rather
than acting from their time of delivery if this is a real issue.
These two comments are on a level that could be left without action. I
think that the draft is good now and can be taken through last call as
was discussed already for the previous version.
/Gunnar
