OK, I proofread a second time, and noticed one more errata I need to make: On Fri, Aug 17, 2012 at 11:00 PM, Mark Rejhon <[email protected]> wrote: >> 16. Why is support for the <e/> element only RECOMMENDED for senders? >> Given that most users will hit the backspace key (or equivalent) >> fairly frequently, I'd argue for REQUIRED. > > [Comment] > That's not true, because: > 1. Transcription. Many transcription engines don't support > backspacing, Sprint Captioned Telephone display corrections in > brackets right after the error. > ......AND...... > 2. Bots don't need spell checkers :-) News ticker bots. Real-time > stock quote bots. > ......AND...... > 3. Basic Real Time Text. > http://xmpp.org/extensions/xep-0301.html#basic_realtime_text > All message changes are transmitted only using message resets, which > only needs <t/> ... all message edits including backspace is supported > without <e/> > ......AND...... > 4. Combining Append-Only Real-Time Text > http://xmpp.org/extensions/xep-0301.html#monitoring_key_presses_directly
I meant 6.4.3 - "Append-Only Real-Time Text" http://xmpp.org/extensions/xep-0301.html#appendonly_realtime_text > (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"). I meant 6.4.1 - "Monitoring Text Changes Instead Of Key Presses" http://xmpp.org/extensions/xep-0301.html#monitoring_message_changes_instead_of_key_presses > That's why <e/> only RECOMMENDED for senders. > It appears I created a failure of the spec to explain clearly why <e/> > isn't REQUIRED for senders, so I'm curious: Why you thought it should > be REQUIRED? I thought the spec already made it clear about many use > cases that don't require <e/>. Suggestion welcome!
