[Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

Mark Rejhon markybox at gmail.com
Tue Jul 10 15:32:10 UTC 2012


On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:

> Mark,
> I see that you in this version have introduced a couple of "odd" real-time
> text transmission strategies in sections 6.4.1 and 6.4.2, based on the
>  'reset' event.
> http://xmpp.org/extensions/**xep-0301.html#realtime_text_**
> transmission_methodologies<http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies>


Gunnar -- several are excellent suggestions.

An explanation at the beginning of 6.4 The transmission strategy in 6.4.1
and 6.4.2 is not recommended for messages bigger than approximately SMS
size, for mobile devices that want to write very compact & simple
implementations of real-time text that does not require much processing or
battery -- and they can take advantage of stream compression to eliminate
the redundancy disadvantage of message resets.  It was explained to me that
it may actually use less bandwidth and less CPU in certain situations.
Even though it means a disadvantage of losing key press intervals (the
intervals demonstrated at
www.realjabber.org/anim/real_time_text_demo.html) which I already
mention.

Stream compression compensates for the bandwidth penalty of doing repeated
message resets as the method of a bare-bones implementation of XEP-0301.  I
also should additionally cite this as part of this paragraph, that if it's
done, it's a good idea to use stream compression, if available.   So when
done, the strategy isn't odd anymore :-)



> 3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method
> that is not recommended, and does not specify a solution, so it suits
> better as introductory warning words.  Use the title 6.4.3 Monitoring
> message changes.  delete title 6.4.4
>

The only one I'd be cautious about is that 6.4.3 needs to be a distinct
section; because it is less confusing to vendors trying to transmit from
key press events; that way they can understand the "gotchas" of doing that
(i.e. missed autospell fixes, missed copy+paste events, etc.) ... I've
gotten feedback that gave an excellent rationale for 6.4.3 being part of 6.4

Thanks
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120710/1578fe01/attachment.html>


More information about the Standards mailing list