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

Mark Rejhon markybox at gmail.com
Sun Aug 19 16:54:44 UTC 2012


On Sun, Aug 19, 2012 at 2:32 AM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
> On 2012-08-19 05:38, Mark Rejhon wrote:
>
>
> On 2012-08-18 10:08 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
>> > To be fair, the event=new also exactly does the same thing -- it
>> > also clears the real-time message, so if I say what you say, I am
>> > also introducing a potential new confusion about the lack of
>> > distinction between event=new and event=reset.  This must be
>> > thought out carefully. Your revision does not solve confusion
>> > without creating a new, separate confusion.
>>
>> To me, reset sounds like "here is where we left off" and then you'd
>> send changes from that baseline. But as I said, it's probably OK
>> as-is, so this is a tempest in a teapot.
>>
>> Peter
>
> I'll go with a simpler clarification change:
>
> I hereby propose two changes:
>
> (1) A stronger clarification in the "event=reset" paragraph in section
> 4.2.2: http://xmpp.org/extensions/xep-0301.html#event
>
> Change: "and then process action elements within the <rtt/> element"
>
> Into: "and then process action elements within the <rtt/> element. (Any
> number of any [[[Action Elements(link)]]] can be included within <rtt/>)"
>
> and
>
> (2) Change the last sentence of 4.6.3. "Message Reset"
> http://xmpp.org/extensions/xep-0301.html#message_reset
>
> Change: "Note: There are no restrictions on using multiple [[[Action
> Elements]]] during a message reset (e.g. typing or backspacing occurring at
> the end of a retransmitted message)."
>
> Into: "Note: There are no restrictions on using multiple [[[Action
> Elements]]] during a message reset (e.g. typing or backspacing occurring at
> the end of a retransmitted message). The behavior of <rtt event='reset'/> is
> logically identical to <rtt event='new'/> (differs only to allow
> presentation-related behaviours), and has exactly the same capability for
> ongoing real-time text in multiple action elements, including [[[Preserving
> Key Press Intervals]]]."
>
> Is this overkill, or prudent?  Any remaining confusion?
>
> Yes, it is overkill, or the changes do not aim at the source of the
> confusion. The confusion is that you call something a 'reset' and finally
> say that the reset can be more than a reset. Reading with Peters' eyes,
> there is still confusion. Section 4.6.3 introduces the reset concept well as
> a retransmission, getting back to a stable state. Then the note suddenly
> takes us out of that view saying that new things never transmitted before
> can be contained in the reset.
>
> The note must instead say that there is an end of the reset within the
> <rtt/> element, and after that it is allowable to add new elements in the
> same <rtt/>.
>
> Mark, your note also indicates that what is needed for the reset operation
> should be kept in separate action elements and that it therefore would not
> be allowable to just extend the <t/>  a bit with new text typed after the
> latest transmission.
> But your examples in section 6.4.4 Basic real-time text shows just one
> gradually growing <t/> element in each reset message.
>
> That makes the note in 4.6.3 needing further adjustments:
>
> So, here is a new proposal for the note:
>
> "Note: Following what is needed for the reset operation, it is allowable to
> include further text and other Action Elements in the same <rtt/> element
> (e.g. any typing or backspacing that occurred during the interval after the
> latest transmission)."
>
> I hope that that makes it clear that the 'reset' can be just the initial
> part of the <rtt/> element.

Not necessarily.
The first element of 'reset' can be a <e/> element (which would do
nothing on a blank message, EXACTLY as if it were for 'new')
The first element of 'reset' can be a <w/> element (which would pause
on a blank message, EXACTLY as if it were for 'new')
When I say 'reset' is exactly the same as 'reset', I really mean it:
Exactly the same action element processing.

Should I rename 'reset' to 'notequitenew' or 'reinitialize'

Peter, do you suggest I rename 'reset' to 'reinitialize'?

Thanks,
Mark Rejhon



More information about the Standards mailing list