On Mon, Aug 20, 2012 at 4:26 PM, Gunnar Hellström <[email protected]> wrote: > On 2012-08-20 10:20, Mark Rejhon wrote: > > GH> > When the sender composes the part of the refresh that has been > transmitted before, <w/> elements shall not be included. > > <MR> I am not going to specifically disallow any elements and order for > either new/reset. > > <GH> > It seems to me that you did not read my comment completely. > > I think we need to set rules for how the refresh is composed.
However, some of what you are saying is reasonable, but it is not enforceable, and I don't want to confuse readers further about the distinction between new/reset. Therefore, I'm saying I don't want to set rules for how the refresh is composed. I'm leaning towards merging new/reset. Give me a few days to think of a solution on my own that would satisfy the different vendors (including satisfying your time-smoothed desire) > That would include many <w/> elements. > If such a message refresh would be sent, it would take a long time to > display, with severe flicker as a result. That's right. However, again, (1) it's not "enforceable", and (2) I don't want to confuse vendors about introducing a distinction (while legitimate), might lead to incompatible new/reset differences in some other implementations. That is my fear. So that overrides a good reason to mention <w/> for reset, even though normally <w/> will never be used as the first element of a reset. So, I'm thinking of merging new/reset, once I hear Peter's response and some other responses from this mailing list. > Another (probably better) method would be to just recreate the resulting > text and send the retransmitted part as a single <t/> element, possibly > followed by new elements. > > Therefore I think it is still valid to insert a sentence in 4.6.3 > "When the sender composes the part of the refresh that has been transmitted > before, <w/> elements shall not be included". If I do not merge new/reset, then I have a preference towards "Although there is no restriction on action element usage in new/reset, it is advisable that the first element of <rtt event='reset'/> is typically a <t/> whose purpose is to refresh the message." I'd rather say that sentence (or a improved derivative thereof). It 100% perfectly meet time-smoothed needs, and you simply skip doing a time-smooth delay for the first <t/>. But give me a few days to test alternative protocol designs that resolves the confusion altogether, or alternative methods of wording the current protocol (using "Message Refresh" terminology instead of "Message Reset" terminology) Mark Rejhon
