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

Mark Rejhon markybox at gmail.com
Wed Jul 18 00:19:12 UTC 2012

On Tue, Jul 17, 2012 at 7:47 PM, Lance Stout <lancestout at gmail.com> wrote:

> Imagine situations where the original message took 2 seconds to create
> (Enter was accidentally hit), but last message editing take minutes.    How
> do you replace 2 or 3 <rtt/> elements in a proper manner, with over 100 to
> 1000 <rtt/> elements, while preserving all behaviour of XEP-0301?  You
> could transmit 1000 action elements in a single <rtt/>, but that becomes
> quite unwieldly, especially, if you continue, and then go back to edit some
> more.  So for this reason, I feel that <rtt/> doesn't belong in <replace/>
> Ah, I think we had different scenarios playing in our heads then. I was
> imagining just tagging all of the RTT updates with the <replace /> element
> referring to the original, complete message that was being changed. Like so:
> <message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat"
> id="102">
>    <body>First Lixne</body>
> </message>
> ...
> <message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat"
> id="106">
>   <rtt xmlns="urn:xmpp:rtt:0" seq="4" event="reset"><t>First
> Lixne</t></rtt>
>   <replace id="102" xmlns='urn:xmpp:message-correct:0'/>
> </message>  <!-- begins replacement editing RTT by including <replace />
> -->
> <message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat"
> id="107">
>   <rtt xmlns="urn:xmpp:rtt:0" seq="5"><d p=8/></rtt>
>   <replace id="102" xmlns='urn:xmpp:message-correct:0'/>
> </message> <!-- replacement editing continues -->
> <message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat"
> id="108">
>    <body>First Line</body>
>    <replace id="102" xmlns='urn:xmpp:message-correct:0'/>
> </message> <!-- final replacement body for message 102  -->

As far as I understand it, this is illegal use of XEP-0308 --

>From my reading of XEP-0308, only a <body> can be replaced with a <body>.
 If I replace the <body> with something else, the message might technically
be considered removed (because the <body> is removed from the stanza being

Can the authors of XEP-0308 clarify as to the intent of XEP-0308 in
transmitting multiple replacement stanzas for the same message id, for
different purposes?

And consequently, can XEP-0308 be fixed to clarify on this ambiguity?
 (Either made compatible with Lance's interpretation of XEP-0308, or
compatible with my interpretation of XEP-0308).   If XEP-0308 is changed to
be clear with Lance's interpretation, this produces a good solution.   But
right now, it's illegal XEP-0308 from my interpretation.


> That wouldn't be a problem.
> This is because <rtt event='reset'/> is treated exactly like <rtt
> event='new'/> if there was no existing message.   My version 0.3 update
> made that clearer.   Can you clarify?
> I meant that XEP-0301 makes references to the use of those events in terms
> of real-time messages, which a message sent before RTT is enabled I would
> not think qualified under those terms. And, if RTT is enabled and
> immediately used to edit a message sent before RTT, then the current text
> mandates that an event="new" be sent instead of event="reset" (since it is
> the first <rtt /> element containing action elements). A very minor issue
> and I'm probably just confused by the particular scenario used in your
> example, but I just want to be sure there isn't an edge case complicating
> things.

I designed XEP-0301 to recover, even if:
1. You switch computers while composing message #1
2. You switch computers after message #1 but before composing message #2
3. You switch computers while composing message #2

A. You enable RTT while composing message #1
B. You enable RTT after message #1 but before composing message #2
C. You enable RTT while composing message #2.

(or replace the word "enable" with "disable")
In fact, you can combine any 1,2,3 with any A,B,C (and even within this,
RTT can be different from different computers).

The info about recovering RTT is the "Message Reset" section.
And "Keeping Real Time Text Synchronized"

So as long as proper business rules are followed, it's not problematic at
all, no matter what combination of enabling/disabling RTT
and what combinations of switching computers/switching windows/switching

Since this already works with regular XEP-0301, it would by extension,
automatically work just fine with XEP-0308 too, as long as the busines
rules of XEP-0301 is sync'd up with XEP-0308, in terms of simply treating
retroactive edits to a non-existent message, as a new message instead.
(this may slightly screw up the order of messages, i.e. edited message #1
showing up underneath message #2 when computers a switched between message
#1 and #2)

For example, if a user switches computers after message #1 before composing
message #2, meaning only message #2 shows up on the new screen. It would
still work, because <rtt event='reset'> repopulates the message #1.  The
edited message #1 simply shows up underneath the message #2.  (both for the
real time text and for the final delivered edit)  Unless you sort message
id's alphabetically, then the order could be correct.

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

More information about the Standards mailing list