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

Mark Rejhon markybox at gmail.com
Mon Aug 20 14:21:16 UTC 2012


>> > > 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.

This would be a useless rule to most people.  You can just ignore <w/>
elements (which you are doing anyway if you are doing fixed time-smoothing).

It is true that it is a do-nothing element at the start of a RTT element,
along with <e/> being useless do-nothing element if it is the first element
of <rtt/> containing an event attribute of new or reset.

Time smoothing implementers only need to ignore doing a time-smooth pause
for the first <t/> found in any <rtt/> containing either event new or reset.

I am going to figure out a place to mention something in that direction
instead of talking about <w/> or <e/>, and the same rule will apply to
new/reset, so it may be put in the low precision/low bandwidth paragraph.

Keep tuned for 0.8 in a week or so.
(After Peter's further review of section 6 onwards)

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120820/61f610e8/attachment.html>


More information about the Standards mailing list