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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Aug 20 21:13:02 UTC 2012


On 2012-08-20 22:49, Mark Rejhon wrote:
> 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.
>>
>> <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





More information about the Standards mailing list