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

Mark Rejhon markybox at gmail.com
Mon Aug 20 09:10:50 UTC 2012

On 2012-08-20 4:20 AM, "Mark Rejhon" <markybox at gmail.com> wrote:
> On 2012-08-20 4:15 AM, "Mark Rejhon" <markybox at gmail.com> wrote:
> > > 4.6.3 Refresh
> > >
> > > A message reset is a transmission of the sender's text from the
beginning of the real-time message. 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.
> >
> > I like your idea, except I will permanently change "Message Reset" to
"Message Refresh", including the first few words of the paragraph (where
you suggest I continue using the "message reset" phrase when it should
really be "message refresh", to give it a distinction to "reset")
> >
> > >
> > > When the sender composes the part of the refresh that has been
transmitted before, <w/> elements shall not be included.When the recipient
acts on a refresh, no other waiting shall be applied than what <w/>
elements indicate.
> >
> > The exact same rule applies for 'new' so I do not like adding any
differences in behavior between 'new' and 'reset'.
> >
> > I may instead merge 'new' and 'reset' to solve the confusion
altogether.  I need to do some thinking, since I intend exact behavior and
I want to prevent vendors from doing different.
> >
> > (In realjabber, I can do message resets via event='new' too -- no
difference in visual behavior")
> When merging, add a forth attribute or some other tiny indicator for
those implementers who want to signal the start if new message
(presentatiton behavior)
> I am not going to specifically disallow any elements and order for either
new/reset. There is no enforcement, even <w/> at the beginning, because the
new/reset both should instantly playback immediately after the moment the
message buffer is cleared, up to the first <w/> element.  That is the only
info missing from the spec, and you have pointed out this excellent
omission that I shall add.

One last thing -- for time smoothed display, time smoothed playback should
be omitted for the first element of any new/reset (or merged element).
Most message refreshes will likely be one <t/> element at the beginning of
a message, and this is sufficient, for hiccup-free time smoothed playback.
I don't think I need to include specific presentation info in the spec on
this, as most implementers will never do time smoothed playback, instead
doing the Wait Intervals (key press intervals) as that is easier and
preferred with the 0301 architecture on GUI systems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120820/48cc0b4f/attachment.html>

More information about the Standards mailing list