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

Mark Rejhon markybox at gmail.com
Mon Aug 20 15:39:44 UTC 2012


Well -- As it stands now, reprogramming RealJabber to use event=reset only
(for both new and reset), or use event=new only (for both new and reset),
yields exactly identical behavior in RealJabber.  Absolutely no UI
difference, when starting a new message with event=reset, or refreshing a
message in progress with event=new.  There is a legitimate question of
confusion: Why have both?

Does this mean event=new should be merged with event=reset?   I'd just add
a separate minor indicator (e.g. fourth attribute that is purely optional)
for those implementers that want to make a distinction between new/reset in
presentation purposes (e.g. green flash or similar, for the start of a new
message)
 On 2012-08-20 11:10 AM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:

> -----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-----
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120820/3962af0b/attachment.html>


More information about the Standards mailing list