Gunnar, see the bottom of this message for a positive surprise.... Firstly, I want to stress the importance of minimum changes. I already privately emailed to XSF team and would prefer to submit Version 0.9 with *almost NO CHANGE*. Submitting 0.9 with many changes will automatically break my promise and *will reduce the likelihood of last call approval.*
On Thu, Apr 18, 2013 at 5:53 PM, Gunnar Hellstrom < [email protected]> wrote: > 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 > I am against adding too much text about seq without removing other text about seq *in the "Protocol" section*. I think we already talk too much about trivial seq issues right now as-is. One idea is that I can delete most of the seq text and create a much bigger seq section in the "*Implementation Notes*" section. The simple sentence about the 31-bit bounds is currently sufficient (maybe a minor sentence tweak if necessary), we know that properly following "*Keeping Real-Time Text Synchronized*" indicates clients MUST not assume incrementing seq values will always happen, so it already successfully catches seq going backwards in time, which is exactly the wraparound condition too, unless both ends do the wrap properly. In addition to my preference, XSF has already complained that we are already too much like a lower-layer protocol. Expanding the talk about *seq * is against this goal, especially as the safeguards are already sufficient now, in my opinion. 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 > *DONE (indirectly)* What I did was simply make 4.6.3.3 link to section 6.5. I did the change in a different way. It's a good change. It is not an interoperability issue that belongs in the Protocol section (*I am _extremely_ adamant to keep Section 4 as compact as I can, and additionally also have been previously told by XSF to also keep Section 4 "Protocol" as simple as possible.*). > 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 ? > *WORTHY (IF REWORDED) -- BUT POSTPONE TO 2014* This is good discussion (and see below for more info about how Chris and I do it), but this can be a Year 2014 discussion if it shows to be a performance concern. But it isn't the cause of lag in current XEP-0301 implementations. More urgently is solving the problem of mishandling late <rtt> arrivals -- which is the *chief cause of the lag in both of our XEP-0301 implementations.* This is stuff that the spec needs to improve, but the talk here is an unnecessary complication / sidetrack. Computers/phones are fast enough that doing either approach would work good enough, provided there was code to handle the chief cause of lag (<rtt> backlog) > 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 ." > *WORTHY (IF REWORDED) -- BUT POSTPONE TO 2014* This turns an easy-to-read sentence into a hard sentence. More bugs will occur with your sentence than with mine, purely because your sentence is hard to read. Besides, it's not currently the cause of lag in RealJabber or Chris' software. The cause of lag is from a backlog of <rtt> elements. This is not an urgent matter of concern. Error margin of different <w> handling is extremely small, and human-perceptible differences will only be noticed slow machines (e.g. netbooks) and <rtt> catchup handling can handle this anyway. > 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," > *WORTHY -- BUT POSTPONE TO 2014* It makes a lot of sense but I'm going to postpone this change for now, because of unanticipated side effects of minor wording tweaks. Both me and Chris treat <w> intervals accumulating on a system time since the beginning of <rtt>, so slow local performance doesn't cause <w> to The cause of <rtt> lag is chiefly caused by late delivery of <rtt>. These wording changes WILL NOT solve the lag in either RealJabber or the Gallaudet RTT client. I deem this a bit of a sidetrack / red herring discussion. > 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 > *WORTHY -- BUT POSTPONE TO 2014* I like timestamps, but this is an obvious "cart before the horse" situation. I think this can be a Year 2014 discussion. It doesn't belong in XEP-0301 right now. Chris can easily experiment with this, without it requiring to be part of XEP-0301. It is a permissible stage of discussion for later into the DRAFT stage, after there's already fully functional XEP-0203 + XEP-0301 implementations. Reading XMPP's website, this is an obvious permissible change during DRAFT. There is potential side effects with timestamps. Sending intentionally inaccurate timestamps create a potential security issue / DDoS. Also, timestamps could diverge if one computer changes system clock (e.g. automatic synchronization with time server). There are MANY nasty bugs that can be introduced with timestamps. The KISS principle applies here. There are other simpler solutions (other than timestamps) to reducing XEP-0301 lag. I rather see people create XEP-0203 implementations with XEP-0301, before I mention XEP-0203 in XEP-0301 Also, the reference list in XEP-0301 already refers to too many other XEP standards, giving the impression that XEP-0301 is more complicated than it really is. Yes, I like timestamps, but this isn't a LAST CALL showstopper. It can be a Year 2014 discussion. I already announced to the XSF team and would prefer to submit Version 0.9 with *almost NO CHANGE*. Submitting 0.9 with many changes will automatically break my promise and *will reduce the likelihood of last call approval.* That said, I did hereby grant Gunnar Helstrom co-authorshop. I have sensed a strong agreement with R3TF, despite my reluctance. Congratulations, Gunnar, for becoming an official co-author -- it does seem that you have rightfully met the requirements of co-authorship under significant-contributer criteria. It does not change my reluctance, as a main author, to support unnecessary/trivial changes to XEP-0301 that is already adequately covered by the standard or elsewhere. Mark Rejhon
