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

Peter Saint-Andre stpeter at stpeter.im
Mon Aug 20 14:39:49 UTC 2012


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/20/12 2:15 AM, Mark Rejhon wrote:
> 
> On 2012-08-20 3:32 AM, "Gunnar Hellström"
> <gunnar.hellstrom at omnitor.se <mailto:gunnar.hellstrom at omnitor.se>>
> wrote:
>> 
>> On 2012-08-19 21:21, Gunnar Hellström wrote:
>>> 
>>> On 2012-08-19 19:11, Mark Rejhon wrote:
>>>> 
>>>> 
>>>>> My proposal has now become:
>>>>> 
>>>>> event='new' Senders MUST use this value when transmitting
>>>>> the first <rtt/> element containing Action Elements (i.e.
>>>>> when sending the first character(s) of a new message).
>>>>> 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.
>>>>> 
>>>>> event='reinitialize' For recipients, both 'new' and
>>>>> 'reinitialize' are logically identical, and can process
>>>>> exactly the same [[[Action Elements]]], in any
> number, in
>>>>> any order. They 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'. In
>>>>> addition, a common purpose of 'reinitialize' is
>>>>> retransmissions, including Message Reset, used for Keeping
>>>>> Real-Time Text Synchronized and Basic Real-Time Text.
>>> 
>>> These definitions were fine before and still look good.
>>> 
>>> I think the remaining problem is the talk about retransmission,
>>> when
> in reality it is retransmission and new transmission together.
>>> 
>>> I withdraw my proposal to see the reset as just the part of
>>> the
> message that really is a retransmission. That view does not match
> your description of use of reset for the "Basic real-time text".
>>> 
>>> So, instead we can accept your definition that results in that
>>> the
> message reset contains both the retransmitted and new text and
> other elements.
>>> 
>>> Instead we need to adjust the words around retransmission. The
>>> first
> sentence in
> 4.6.3http://xmpp.org/extensions/xep-0301.html#message_reset needs
> to be modified.
>>> 
>>> It is now: " A message reset is a retransmission of the
>>> sender's
> partially composed text. "
>>> 
>>> How about: "A message reset is a transmission of the sender's
> partially composed text from the beginning of the real-time
> message."
>>> 
>>> 
>>> 
>> Mark, you are on the right track when trying to change
>> nomenclature. The 'reset' event and the 'Message Reset' operation
>> are two quite
> different things and need to be clearly differentiated and
> described with different names.
>> 
>> I think the name 'reset' is fine for the event. It is a command
>> for
> emptying the real-time message display buffer before acting on the 
> action elements in the same and subsequent <rtt/> elements.  The
> current description in 4.2.2 look fairly ok, even if I want to
> suggest a few small changes.
>> 
>> But "4.6.3 Message Reset" is confusing by having nearly the same
>> name
> as the event 'reset'.
>> And it needs a slightly changed description. I suggest to change
>> the name to "Refresh" and introduce a bit of
> needed procedure description.
>> 
>> You want the Refresh operation to contain both a retransmission
>> of the
> real-time message and any action elements caused since latest 
> transmission. Some rules need to be applied on these two parts.
> The retransmit part need to be played out rapidly, while the
> latest additions need to be played with normal smoothing or obeying
> <w/> wait elements.
>> 
>> That can be achieved in two ways. 1. Separate the retransmission
>> part from the latest additions in
> separate message stanzas and add a rule on 'reset' event that no 
> smoothing and no wait elements shall be acted on during playout. ( 
> wording may still need to be tuned to allow the "Basic Real-time
> text" in a simple way)
>> 2. Add the requirement on composing the retransmission part that
>> it
> may not contain any wait elements and require that other types of 
> smoothing shall not be done during playout of a 'reset' event. (
> this will make time-smoothed display of combined retransmissions
> and latest additions be jerky, I do not now see how we can indicate
> the border between retransmission and latest additions sent in the
> same <rtt/> element.)
>> 
>> Mark, it is apparent that you have so far been thinking in terms
>> of
> alternative 2.
> 
> No, I am thinking of: 3. All action elements at the beginning of
> <rtt/> containing either event='new' or event'='reset' must be
> played immediately (up to the first Wait Interval, if any) after
> clearing the real-time message, at the time <rtt/> begins to be
> processed.  This is to prevent the flickering of a blank message in
> either situation.

On first reading, I conceived of event='reset' as meaning "as a
reminder, this <t/> element specifies where we stand so far". The
possible confusion I saw was figuring out what to do with <rtt/>
children other than <e/> or <w/> (or <t/> attributes) in the reset. I
thought of those as needing to be delivered in future <message/>
stanzas. However, I hadn't considered the possibility of an empty <t/>
in the reset. In any case, there's really no way to programmatically
enforce any such rules (e.g., only bare <t/> if event='reset'). That
said, I do think we need to be clear about the generation and handling
of event-'reset'.

> This also covers <rtt/> buffering/playback mechanisms including
> section "Receiving Real-Time Textt"
> 
>> Section 4.6.3 can be  amended to describe that alternative:
>> 
>> 4.6.3 Refresh
>> 
>> A message reset is a transmission of the sender's text from the
> beginning of the real-time message.

To my mind, that could mean two things:

1. The message as produced so far (i.e., the equivalent of <body/>
except that it's expected further <rtt/> elements will be sent and
received).

2. A replay of everything that the sender sent so far, including
erases and waits and insertions and all that.

> The recipient can redisplay the real-time message as a result.

Redisplay the state of the message so far, or replay how that message
was generated?

> It allows real-time text conversation to resume quickly, without
> waiting for senders to start a new message.
> 
> I like your idea, except I will permanently change "Message Reset"
> to "Message Refresh", including the first few words of the
> paragraph (where you suggest I continue using the "message reset"
> phrase when it should really be "message refresh", to give it a
> distinction to "reset")

I think that distinction is helpful.

>> When the sender composes the part of the refresh that has been
> transmitted before, <w/> elements shall not be included.When the 
> recipient acts on a refresh, no other waiting shall be applied than
> what <w/> elements indicate.
> 
> The exact same rule applies for 'new' so I do not like adding any 
> differences in behavior between 'new' and 'reset'.
> 
> I may instead merge 'new' and 'reset' to solve the confusion 
> altogether.  I need to do some thinking, since I intend exact
> behavior and I want to prevent vendors from doing different.

As I understand it so far, 'new' means we're starting a brand new
message after a message with a <body/>, whereas 'reset' means we're
doing a level-set on a message in progress. But I might be
misunderstanding things...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAyTDUACgkQNL8k5A2w/vzyDgCg2Ssw3HGuvcS55ZRbC/q6c3Ov
ZRoAn1YuJUTkyZiwn03GoKthWTeF1HZ0
=TGK7
-----END PGP SIGNATURE-----



More information about the Standards mailing list