On 2012-08-19 05:38, Mark Rejhon wrote:
On 2012-08-18 10:08 PM, "Peter Saint-Andre" <[email protected]
<mailto:[email protected]>> 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.
/Gunnar
