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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Aug 20 13:59:28 UTC 2012

On 2012-08-20 11:10, Mark Rejhon wrote:
> On 2012-08-20 4:20 AM, "Mark Rejhon" <markybox at gmail.com 
> <mailto:markybox at gmail.com>> wrote:
> >
> >
> > On 2012-08-20 4:15 AM, "Mark Rejhon" <markybox at gmail.com 
> <mailto: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.
Good to see this converge.
You just need a rule in 4.6.3 saying that <w/> elements shall not be 
included in the retransmit part of the refresh.
(Theoretically, an implementor could have thought that it would have 
been good to just collect everything transmitted so far in the real-time 
message, but that would create unwanted delays. That interpretation is 
avoided by this rule.)


Using real-time text without any smoothing at transmission intervals 
over 500 ms causes user annoyance.
You could mandate smoothing by use of <w/> for transmission intervals 
over 500 ms.
You could also say that existence of <w/> elements shall activate 
smoothing. One way to do it is a time-based smoothing.
But you are right, implementing support of <w/> elements even with low 
resolution timers is likely just as easy as using time smoothing after 
the first <w/> element.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120820/2c5773fe/attachment.html>

More information about the Standards mailing list