[Standards] review of XEP-0301 [event='new' VS event='reset']

Mark Rejhon markybox at gmail.com
Sat Aug 18 03:05:42 UTC 2012


This is split separately, because this may become an important
discussion, due to the extreme important of Preserving Key Press
Intervals (to many of us).  We have to keep Message Resets 100%
compatible with Preserving Key Press Intervals...

On Fri, Aug 17, 2012 at 7:16 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 25. "Note: There are no restrictions on using multiple Action Elements
> during a message reset (e.g. typing or backspacing occurring at the
> end of a retransmitted message)." This seems potentially confusing.
> IMHO it would be friendlier for the recipient to process the reset as
> the state of the RTT message at a point in time and for the sender to
> then send additional <rtt/> elements for subsequent modifications.
> (Postel's Law and all that.) However, that's unenforceable so I
> suppose it's OK as-is.

[Comment]
This is important because I don't want to disturb the cadence of key
press intervals (Wait Intervals) when I'm doing the 10-second Message
Resets (in "Keeping Real-Time Text Synchronized").  In RealJabber, I
often include 700 milliseconds of recorded typing at the end of a
message reset, so that recipient software doesn't cause jerky key
interval playback.
Also, "reset" is exactly the same as "new":
Implementations can choose to treat it exactly the same:

String event = RTT.GetAttributeValue("event");
if ((event == "new") || (event == "reset"))
{
    // Clear real-time text buffer and immediately process all action
elements in RTT
}

If you re-read section 4.2.2 ("event"),
http://xmpp.org/extensions/xep-0301.html#event
I already make sure that implementers must otherwise logically treat
both identically:

event='new'
Senders MUST use this value when transmitting the first <rtt/> element
containing Action Elements (i.e. when sending the first character(s)
of a new message). Recipient clients MUST initialize a new real-time
message for display, and then process action elements within the
<rtt/> element. If a real-time message already exists, from the same
sender in the same chat session, its content MUST be replaced (i.e.
cleared prior to processing action elements). Senders MAY send
subsequent <rtt/> elements that do not contain an event attribute.

event='reset'
For recipients, both 'new' and 'reset' are logically identical, and
differ only for implementation purposes (e.g. highlighting
newly-started messages). Recipient clients MUST initialize a new
real-time message for display, and then process action elements within
the <rtt/> element. If a real-time message already exists, from the
same sender in the same chat session, its content MUST be replaced
(i.e. cleared prior to processing action elements). Senders MAY send
subsequent <rtt/> elements that do not contain an event attribute.
Recipients MUST be able to process 'reset' without first receiving
'new'. See Message Reset, used for Keeping Real-Time Text Synchronized
and Basic Real-Time Text.

SOLUTION #1:
Do you think I should add yet another sentence to event='reset',  "Any
number of any action elements can be used."
Would this sentence be sufficient clarification?

SOLUTION #2:
Another method is to eliminate event='reset' but that would eliminate
implementer ability to choose to highlight newly-started messages.
(which is an optional behavior, anyway).  Though this could be
introduced as another, separate, optional attribute (e.g. new="new" or
new="true") that's only used when creating a new message.
Example:
1. <rtt event='reset'>
2. <rtt event='reset' new='true'>
Clients can choose to ignore the "new" attribute if they are not
interested in distinguishing a new message from a resumption of
real-time text (e.g. recipient signing on after the sender has already
started typing).   As we already know, it's allowed to receive a reset
without ever receiving a new.

Mark Rejhon



More information about the Standards mailing list