[Standards] review of XEP-0301 [ event='reset']
gunnar.hellstrom at omnitor.se
Sat Aug 18 06:02:12 UTC 2012
On 2012-08-18 05:05, Mark Rejhon wrote:
> 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.
> 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":
I do not see where Peter finds it potentially confusing, and Peter's
final conclusion is "it's OK as-is".
So we could leave it with that conclusion.
But what is really confusing?
Let me guess:
In 4.2.2 it is said about 'reset'
" 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
While in 4.6.3, where the apparently confusing note is, it is said:
A message reset is a retransmission of the sender's partially composed
The attribute 'reset' itself should be seen as a command to clear the
contents of a real-time text so that it can be (re)built from the action
Would it be clearer to try to align 4.2.2 and 4.6.3 with each other,
e.g. by changing 4.6.3 to:
A message reset is an order to reset the real-time message in order to
prepare for receiving the sender's partially composed text from the
beginning of the real-time message."
This both makes clear that 'reset' itself just resets the real-time
message to be empty, and that the text that comes after it may be both
transmitted earlier and contain new elements.
Was that the confusion, and does the proposed change clear the confusion?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards