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

Mark Rejhon markybox at gmail.com
Sat Aug 18 15:36:58 UTC 2012


On Sat, Aug 18, 2012 at 2:02 AM, Gunnar Hellström
<gunnar.hellstrom at omnitor.se> wrote:
> While in 4.6.3, where the apparently confusing note is, it is said:
>
> "4.6.3 Message Reset
>
> A message reset is a retransmission of the sender's partially composed text.
> "
>
> The attribute 'reset' itself should be seen as a command to clear the
> contents of a real-time text so that it can be (re)built from the action
> elements provided.
>
> Would it be clearer to try to align 4.2.2 and 4.6.3 with each other, e.g. by
> changing 4.6.3 to:
>
> "4.6.3 Message Reset
>
> A message reset is an order to reset the real-time message in order to
> prepare for receiving the sender's partially composed text from the
> beginning of the real-time message. "

That's potentially confusing too, because:
-- Message 'reset' should logically be handled identically to 'new'
-- The partially composed text may not necessarily be at the beginning
-- the sender might start inserting a sentence in the middle, and a
message reset can still occur while a sender is typing anywhere in the
middle of the message.

I find this less confusing:
"A message reset is a retransmission of the sender's partially composed text."
(Because it does not specifically refer to the XML element itself <rtt
event='reset'/> ....I should ONLY explain only in the paragraphs that
talk specifically mention the <rtt event='reset'/> element)

So a different modification is required, as your change also makes it
confusing (to a different subset of people)
Let's go to section 4.2.2 instead:

event='reset'
For recipients, both 'new' and 'reset' are logically identical, and
differ only for implementation purposes (e.g. highlighting
newly-started messages). Recipient clients MUST initialize a new
real-time message for display, and then process action elements within
the <rtt/> element. If a real-time message already exists, from the
same sender in the same chat session, its content MUST be replaced
(i.e. cleared prior to processing action elements). Senders MAY send
subsequent <rtt/> elements that do not contain an event attribute.
Recipients MUST be able to process 'reset' without first receiving
'new'. See Message Reset, used for Keeping Real-Time Text Synchronized
and Basic Real-Time Text.


Observe that I tried to explain that multiple action elements are
allowed, via the phrase "and then process action elements within the
<rtt/> element"
Notice the plural I use; "action elements" -- the "s" at the end.

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 event='reset' attribute is
specified to be treated logically identically to event='new' (except
for any presentation-related behaviours), and thus has exactly the
same capability."


Would these two changes be acceptable to Peter?
Alternatively, would Peter prefer I merge 'new' with 'reset' since
they're the same anyway?
And maybe introduce a separate (fourth) attribute for distinguishing
message beginnings from message being reset/continued?


Thanks,
Mark Rejhon



More information about the Standards mailing list