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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Sun Aug 19 06:32:25 UTC 2012

On 2012-08-19 05:38, Mark Rejhon wrote:
> On 2012-08-18 10:08 PM, "Peter Saint-Andre" <stpeter at stpeter.im 
> <mailto: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 
<http://xmpp.org/extensions/xep-0301.html#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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120819/a101bc81/attachment.html>

More information about the Standards mailing list