[Standards] review of XEP-0301 [ event='reset']
markybox at gmail.com
Mon Aug 20 20:49:28 UTC 2012
On Mon, Aug 20, 2012 at 4:26 PM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> 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.
> 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
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)
More information about the Standards