<div class="gmail_quote">On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström <span dir="ltr"><<a href="mailto:gunnar.hellstrom@omnitor.se" target="_blank">gunnar.hellstrom@omnitor.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Mark,<br>
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.<br>
<a href="http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies" target="_blank">http://xmpp.org/extensions/<u></u>xep-0301.html#realtime_text_<u></u>transmission_methodologies</a></blockquote>

<div><br></div><div><div>Gunnar -- several are excellent suggestions.  </div><div><br></div><div>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 <a href="http://www.realjabber.org/anim/real_time_text_demo.html">www.realjabber.org/anim/real_time_text_demo.html</a> ) which I already mention.</div>

<div><br></div><div>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 :-)</div>

<div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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<br>

</blockquote><div><br></div><div>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</div>

<div><br></div><div>Thanks</div><div>Mark Rejhon</div></div>