Mark, can you describe exactly how the link to Section 6.5 solves the problem of <w> interval backlog? The last version I saw made Section 6.5 look like a suggestion (clients "can" ....), rather than something that is mandatory. I might not be up to date with respect to the most recent changelog there - but based on experience I now believe that implementing it has to be mandatory, rather than optional.
Christian On Thu, Apr 18, 2013 at 6:57 PM, Mark Rejhon <[email protected]> wrote: > Addendum: > > On Thu, Apr 18, 2013 at 6:39 PM, Mark Rejhon <[email protected]> wrote: > >> *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 >> > > Incomplete sentence noticed; completing it as: > > 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 > cause a backlog. Even if it did cause a backlog, handling for backlogged > <rtt> (which is the bigger problem and chief cause of lag), that is already > written in the spec (with improved wording), can already adequately handle > this scenario in XEP-0301 clients that used a "wait since last action > element" methodology." > > In other words, the problem is already indirectly solved by the Version > 0.8 of XEP-0301 (existing section 6.5) > -- Christian Vogler, PhD Director, Technology Access Program Department of Communication Studies SLCC 1116 Gallaudet University http://tap.gallaudet.edu/ VP: 202-250-2795
