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

Mark Rejhon markybox at gmail.com
Sat Aug 18 03:15:11 UTC 2012

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 <markybox at gmail.com> 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"

> (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"

> 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!

More information about the Standards mailing list