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

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 20 16:55:44 UTC 2012

Hash: SHA1

On 8/20/12 10:11 AM, Mark Rejhon 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. 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. 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). 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?

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


- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Standards mailing list