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