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

Mark Rejhon markybox at gmail.com
Mon Aug 20 19:03:50 UTC 2012

On Mon, Aug 20, 2012 at 2:48 PM, Mark Rejhon <markybox at gmail.com> wrote:
> 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:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>> 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.
> See:
> http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized
> 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:
> http://xmpp.org/extensions/xep-0301.html#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

One proposed addendum to bottom of Section 4.6.3 (renamed to "Message Refresh")

"When sender clients follow this Message Refresh procedure in full,
this ensures recipient clients always eventually resume seeing a
partially-composed message within a reasonable amount of time.  This
is even if the recipient connects long after the sender starts
composing a message.  This includes both one-on-one and [[[Multi-User
Chat]]], where participant(s) can join or connect after sender(s) have
started composing a message."

(This adds a slight amount of redundancy to the first sentence of
section 4.6, as this is already mentioned in the spec).

So bottom line, it's just a matter of deciding:
1. Keep both 'reset' and 'new' (while making language much clearer)
2 Do I merge event='reset'/'new' because they are logically identical
(**and** add an optional fourth attribute to flag starts of new
messages, whose only purpose is to affect optional display

I really welcome opinions from other people than Gunnar/Peter too, as
this is an important matter, as one major goals of XEP-0301 is making
it possible for sender clients (on a properly functioning XMPP
network) to essentially guarantee recipient message resumption, even
if recipient joins long after the sender starts composing a message.

(even sender user resumes composing a partial message, an hour later
(sender paused mid message due to phone call, etc), and even when the
recipient client erased the message due to 'Stale Messages' handling.)

Mark Rejhon

More information about the Standards mailing list