I believe that the XEP-0203 mechanism could work in principle, but I am a bit concerned that inserting the time stamps does not fit the use cases described in XEP-0203. So, I don't know what XEP-0203-aware servers would do with it.
On the flip side, if it works, I like this solution better than making further changes to XEP-0301. And as an implementer, I really, really would like to see a timestamp-based synchronization mechanism, even if it is optional. Christian On Thu, Apr 18, 2013 at 5:53 PM, Gunnar Hellstrom < [email protected]> wrote: > 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: > - 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 > -- Christian Vogler, PhD Director, Technology Access Program Department of Communication Studies SLCC 1116 Gallaudet University http://tap.gallaudet.edu/ VP: 202-250-2795
