On 2012-08-20 22:49, Mark Rejhon wrote:
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
I do not at all mind if you settle the same rule for new as for reset.
And I do not mind if you merge them ( to a 'renew' ?)
I just wanted to make clear how the contents of the retransmitted part
must be composed for the refresh to work as intended.
Some implementers might get the impression that the event='new' or
'reset' or 'renew' has some specific influence making the action
elements read out fast for the refresh action even if they include the
old <w/> elements already transmitted.
--- maybe far fetched --
Gunnar
