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

Mark Rejhon markybox at gmail.com
Mon Aug 20 18:48:05 UTC 2012

On Mon, Aug 20, 2012 at 12:55 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> On 2012-08-20 11:47 AM, "Peter Saint-Andre" <stpeter at stpeter.im
>> <mailto:stpeter at stpeter.im>> wrote:
>>> On 8/20/12 9:39 AM, Mark Rejhon wrote:
>>>> Well -- As it stands now, reprogramming RealJabber to use
>>>> event=reset only (for both new and reset), or use event=new
>>>> only (for both new and reset), yields exactly identical
>>>> behavior in RealJabber.  Absolutely no UI difference, when
>>>> starting a new message with event=reset, or refreshing a
>>>> message in progress with event=new.  There is a legitimate
>>>> question of confusion: Why have both?
>>>> Does this mean event=new should be merged with event=reset?
>>>> I'd just add a separate minor indicator (e.g. fourth attribute
>>>> that is purely optional) for those implementers that want to
>>>> make a distinction between new/reset in presentation purposes
>>>> (e.g. green flash or similar, for the start of a new message)
>>> I think event='new' is probably fine for both. Clearly,
>>> somewhere along the line someone thought that the distinction was
>>> valuable (e.g., because a client might have expected a message
>>> with a <body/> at some point and never received it). That reminds
>>> me, is there value in describing the state machine a bit more
>>> completely?
>>> Peter
>>> - -- Peter Saint-Andre https://stpeter.im/
>> I am the one who decided the distinction was useful.
>> I mention that it is useful to know when a new message was just
>> begun, and do presentation behaviors (such as flash a highlight),
>> versus whether the message was started a while back.
>> If a client receives event=new, it means the message was started
>> just now.
>> If a client receives event=reset, without ever receiving event=new,
>> it typically means the message was started before the recipient
>> entered chat.
> How exactly is the sender to be aware of that? The rules governing
> when to generate event='reset' seem fuzzy at best.


The 10 second refresh in "Keeping Real-Time Text Synchronized"
repopulates the real time message. So if people join a MUC room, it
knows that it's an old message being refreshed, since it's
event='reset' without an event='new'
That's how software is able to tell.

> In a chatroom
> especially, people are constantly leaving and joining the room so the
> sender can't really know when to flag something as a reset.

Read section 4.6.3 "Message Reset:

"A message reset is a retransmission of the sender's partially
composed text. The recipient can redisplay the real-time message as a
result. It allows real-time text conversation to resume quickly,
without waiting for senders to start a new message."

"Retransmission SHOULD be done at an average interval of 10 seconds
during active typing or composing. This interval is frequent enough to
minimize user waiting time, while being infrequent enough to reduce
bandwidth overhead. This interval MAY vary to a longer interval, in
order to reduce average bandwidth (e.g. long messages, infrequent or
minor message changes)."

This applies to BOTH MUC and one-on-one chat.

> But even
> in a one-to-one chat, presence changes and online/offline resources
> might trigger event='reset' (and presence is not completely reliable,
> a new resource could come online as the sender is typing away and the
> sender's client might not become aware of that fact until just after
> sending something that from the new recipient's perspective is
> actually a reset).

Then it falls back to the 10-second refresh timer:
"Retransmission SHOULD be done at an average interval of 10 seconds
during active typing or composing."

> Etc. Or so it seems to me. Is the recipient then supposed to signal to the sender
> that it's come into the conversation mid-stream and is lacking context?

Again, as I have explained in the last two years -- no....  The 10
second refresh timer essentially guarantees that recipients is resumed
within 10 seconds (during continuous sender typing) of the recipient
joining/returning/connecting/combing back/switched systems/etc), no
matter what.

> I'm starting to doubt the value of event='reset' entirely...

It has merit, because of the guaranteed resumption that XEP-0301
provides to recipients, even when recipients join after the sender has
already started typing.

Mark Rejhon

More information about the Standards mailing list