[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT

Mark Rejhon markybox at gmail.com
Thu Jul 19 19:18:58 UTC 2012

On Thu, Jul 19, 2012 at 1:48 PM, Kevin Smith <kevin at kismith.co.uk> wrote:

> I had not meant that every RTT element would have an id in it, but
> that every RTT element that is part of a correction would include the
> id it's part of the correction for. So
> no id) I'm RTTing a new message
> id) I'm RTT correcting the message referred to by id.

Got it.  +1 in always requiring an id attribute for any retroactive edit.

If I was to implement 301 and 308, but not RTT correction (the
> intersection), another client would send me RTT corrections - a
> significant number of stanzas that I'll then ignore. I won't fail in
> any interesting way (although the UX will be quite odd), but we
> generally try to design protocols that don't send unsolicited stanzas
> that the recipient will be unable to process (or will misinterpret).

That's not true...
It's 100% backwards compatible!

*Backwards compatible behavior (End User Viewpoint)*
The retroactive real-time edit will temporarily appear as if it was a brand
new message.   Basically, the real-time message will be a *copy* of the old
message, while the retroactive edit is taking place.   When the edit is
finished, the real-time message disappears and the edit shows up above in
the last message.

*Backwards compatible behavior (Developer viewpoint) *
Technical reasoning in 0301+0308 clients that don't do 0301 retroactive:
Why this works 100% backwards compatible is due to section 4.2.2 and
section 4.3 of XEP-0301.   For retroactive RTT, to remain backwards
compatibility, I would always require event='reset' everytime you begin to
reference a retroactive edit.  Clients are REQUIRED to follow the
event='reset' behavior described in XEP-0301 section 4.2.2 ....
The client doesn't know it's a retroactive edit (it ignores the id
attribute), so the real-time message temporarily shows up as a new message
-- a *copy* of the previous line.   It's as if the user copy and pasted the
previous line, and began editing.  When the retroactive edit begins, the
end user see a copy of the previous message, because the software thinks
it's a new real-time message being started.   (event='reset' is treated as
event='new' thanks to the current version 0.3 wording of section 4.2.2)
 ... Now, when the retroactive edit is finished, the <body/> gets
delivered, which forces the real-time message to be cleared. (Section 4.3
says so)
Thus, the real-time message disappears when the edit is finished,
simultaneously with the previous message being replaced by this.  To the
user, it looks like the edit suddenly moves upwards to the previous line.

*Therefore: Disco is NOT needed.*

It is my opinion that it is simpler for an implementer to (1) tolerate the
'acceptable' behavior described above, *OR* (2) interpret the 'id'
attribute for better and more intuitive UI behavior.   Thus, adding new
disco is overkill (shooting a fly with a shotgun) when the developer
already has the full flexibility of choosing these two perfectly reasonable
choices, correct?  As a result, I'm somewhat stumped why you think disco is
necessary for this situation.

Can you re-explain why you still think disco is needed for the 301+308 case
without retroactive 301?

> Conversely, we're probably going to beat XEP-0308 to Draft status first --
> > so XEP-0301 as a Draft reference an Experimental spec.  Which is allowed
> to
> > change more dramatically, as Experimental.   Equally as bad, or worse,
> > right?   Pick your own poison, right?  :-)
> A not unreasonable point.
> > -- Since you are the primary author -- when do you plan to execute a LAST
> > CALL for XEP-0308?
> I'm not opposed to requesting one ~=now, if it's useful.

It's been less than 12 months since the spec was granted a number.  As long
as XEP-0001 rules allows it, then this could be a pretty quick LAST CALL
for an XEP.

If we can agree to call a simultaneous LAST CALL before the end of this
month (I was hoping for earlier, but there's been so much discussion), so
we can bring both 0301 and 0308 to Draft status roughly simultaneously -- I
will go ahead and immediately add the 'id' parameter to XEP-0301.

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120719/df024af5/attachment.html>

More information about the Standards mailing list