[Standards] review of XEP-0301, sections 1-5

Mark Rejhon markybox at gmail.com
Sat Aug 18 15:44:02 UTC 2012

On Sat, Aug 18, 2012 at 2:33 AM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
> On 2012-08-18 05:15, Mark Rejhon wrote:
>> (for <t/>)
>> >and Basic Real-Time Text (whenever <e/> is otherwise needed).  A major
>> >potential implementer has indicated they prefer this method for
>> >simplicity (low CPU overhead compared to section 6.4.1 "Avoid Bursty
>> >Text Presentation").
> Mark, this is a side question, not influencing the <e/> discussion.
> What is your proposal to this potential major implementer to make real-time
> text usable when only using 'reset' and not using <w/>.
> Do you recommend to use a shorter interval than 700 ms? The earlier
> documented usability limit is 500 ms. Above that, the users start thinking
> jerkiness is unpleasant, and in reality 300 is experienced as more pleasant
> than 500.
> -But we have said that 300 ms might cause too much load on servers or
> networks to be a universally used interval.
> Or do you recommend to use time smoothing (displaying received characters
> progressively during the transmission interval ) instead of key-press
> intervals?
> -But you have said that time smoothing may be cpu consuming and is
> complicated to introduce on the receiving end in modern xml library
> environments.
> I hope they do not want to have annoyed users experiencing 700 ms jerks in
> their text conversation.

(This is talking about Transmission Intervals)

I'm interested in hearing XSF's opinion about intervals.  They are a
compromise balance.
700ms allows about 300ms of 'headroom' (network latency) to meet the 1
second (700+300 = 1000) end-to-end latency specified by ITU-T F.700
(section, IIRC)

700ms with key press intervals being preserved, often looks better
than 300ms without key press intervals.  They can also be roughly
similar (total) bandwidth, since key press intervals makes message
stanzas significantly larger.

Now, I can say my tests have shown that 100ms intervals is nearly
always as reliable, but I've seen problems with a slow-performing XMPP
network when sending ten stanzas per second.  So that's probably too
low, but I definitely don't ban that because I only use "SHOULD"
terminology with the 700ms and the 300ms-1000ms ranges I've mentioned.
 So there's room for high-performance local XMPP networks with 0ms
intervals (e.g. instant transmit of every keypess), all the way to the
other gamut of slow low-rate 9600bps Iridium satellite transmission at
2500ms interval (though that's more "NEAR real-time" not "true

All that said, I have no objection to implementers choosing to do
500ms instead of 700ms, and I wouldn't even complain if somebody
decided to be daring and used 100ms by default for their network.
But should 500ms be the default?   I need many opinions before
changing 700 to 500.

Mark Rejhon

More information about the Standards mailing list