Here is a summary of changes from XEP-0301 version 0.8, some done in
Mark's own 0.9 draft, marked "DONE".
I do not remember what has been discussed in the list and not, so here
are all points, some still under discussion.
http://xmpp.org/extensions/xep-0301.html
1.
Section 4.2.1:
- Move "The bounds of seq is 31-bits, the range of positive values for a
signed 32-bit integer." from section 4.3 to section 4.2.1.
DONE
2.
Section 4.6.3.2 <http://4.6.3.2>:
- Change: "Excess backspaces MUST be ignored."
- To: "Excess backspaces MUST be ignored by the receiving client."
DONE
3.
Section 6.2.2:
- Fix a link error
DONE
4.
Section 6.5:
- Change: "Recipients can avoid excess lag by monitoring the queue for
excess <w/> action elements (e.g. unprocessed <w/> elements from two
<rtt/> elements ago) and then ignoring or shortening the intervals in
<w/> elements. "
- To: "Recipients can avoid excess 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."
DONE
5.
Section 6.5:
- Demote bullet 3 into a separate paragraph later into the section:
"Upon receiving a [[[Body Element]]] indicating a completed message, it
is acceptable for the full message text from <body/> to be displayed
immediately in place of the real-time message, and discard any
unprocessed action elements. This prevents any delay in displaying the
final message delivery, however, this may cause a sudden surge of text
in some situations."
DONE
6.
Section 10.3:
- Fix a link error
DONE
7.
Section 4.2.1 or 4.3 last bullet.
Insert:
"NOTE: Wrap-around may occur when incrementing <seq/> if the randomly
selected start value was close to the upper border of <seq/>. "
NOT DONE
8.
Change SHOULD to MAY in 4.6.3.3 for displaying body immediately.
DONE
9.
Section 4.6.3.3 Insert
"Recipients SHALL avoid excess lag by monitoring the queue for excess
<w/> action elements (e.g. unprocessed <w/> elements from two <rtt/>
elements ago) and then ignoring or shortening the intervals from the
<w/> elements. This allows lagged real-time text to "catch up" quickly."
( consider removing or reword the similar sentence from 6.5 so that we
do not have repetitions )
NOT DONE
10. Is there a risk for delay introduced in the description of <w/> ?
In beginning of 4.6.3.3 it is said that <w/> represent time between
key presses.
in 6.1.2 it says that <w/> represent wait between Action Elements
<http://xmpp.org/extensions/xep-0301.html#action_elements>.
Assuming that key presses are momentary, but it takes some milliseconds
to complete some action elements this will introduce on the receiving
side a sum of waits and action element performance time that is more
than the transmission interval. Thus, delays will be introduced during
times of continous typing.
Do we need to be more concise with what time <w/> represents?
Should 6.1.2 be modified to say Is it "wait from end of latest wait" or
"wait from beginning of execution of latest action element ?
In 4.6.6.3, it says:
"Wait n milliseconds before processing the next action element."
proposed to be changed to:
"Wait until n milliseconds after end of latest wait, before processing
the next action element, or if this is the first <w/> in the current
real-time message, then wait until n milliseconds after beginning
handling presentation of that real-time message ."
In 6.1.2 it says:
" This is achieved using Element <w/> – Wait Interval
<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval>
between other Action Elements
<http://xmpp.org/extensions/xep-0301.html#action_elements>. Sender
clients can transmit the length of pauses between key presses,"
proposed new wording:
"This is achieved using Element <w/> – Wait Interval
<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval> from
previous <w/> or beginning of the current <rtt/> element. Sender clients
can transmit the length of pauses between key presses,"
FOR DISCUSSION
11. Should we improve chances of smooth and low latency playout by
putting XEP-0203 timestamps on the messages as a guide to when it should
be played out.
E.g. by inserting this sentence in 6.1.2.
"For more accurate timing of beginning of playout of each <rtt/>
element, it is recommended to insert a time stamp on the <rtt/> elements
by use of XEP-0203 time stamping, and on the receiving side let this
value control when playout of the element starts rather than timing it
only from the <w/> elements throughout the whole real-time message."
Then, a reference to XEP-0203 needs to be added as well.
FOR DISCUSSION
The not done and for discussion items are all minor.
Regards
Gunnar
