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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Fri Nov 11 23:09:57 UTC 2011

I agree that for scenario 1, replace in message mode, XEP-0301 and 
XEP-0308 seems to be able to co-exist without any change. The real-time 
text user will find it a bit unexpected that a complete previous message 
is suddenly replaced, without a sign of the other party doing editing. 
But it is possible.

For scenario 2, real-time text editing in previous messages, I would 
like to explore this a bit more.

Mark says: "2. Allow real time text (RTT) to occur with previous 
messages.  I would add an optional 'id' attribute to <rtt> elements.  "

I can imagine that the action will be something like this:
1.The transmitting user positions the cursor to a point in the previous 
message, and start adding, deleting or replacing some text.
2.That should generate messages with <rtt> elements and <id> elements at 
1 second intervals as long as changes are made.
3. When the change of the message is complete, the transmitting user 
client sends the complete message with <body> and <replaces> with <id>. 
That finalizes the change.
4. Next character typed will cause an <rtt><new> element, with new <id> 
and the display will be done to show that a new message is started after 
all earlier.

a. Would we need to retransmit the message up to the point of change in 
the first <rtt> element to be sure that it can be displayed correctly, 
or can we just start with the positioning or first modification within 
that message?

b. Can we keep the description about Last Message real-time correction 
by <rtt> completely within XEP-0301, and let the implementor understand 
that the modified message <body>  after all <rtt> elements shall be sent 
with a <replaces> and<id> element? Or do we need to mention XEP-0301 in 
XEP-0308 and XEP-0308 in XEP-0301 and synchronize their approvals?


Mark Rejhon skrev 2011-11-11 22:52:
> On Thu, Nov 10, 2011 at 12:59 PM, XMPP Extensions Editor 
> <editor at xmpp.org <mailto:editor at xmpp.org>> wrote:
>     Version 0.1 of XEP-0308 (Last Message Correction) has been released.
> About interop between standards:
> XEP-0308 - http://xmpp.org/extensions/xep-0308.html (Last Message 
> Correction)
> XEP-0301 - http://xmpp.org/extensions/xep-0301.html 
> <http://xmpp.org/extensions/xep-0308.html> (In-Band Real Time Text)
> Me and other users of real time text XEP-0301 (i.e. text that is 
> streamed as it is typed) has thought of how XEP-301 may be improved 
> for maximum compatibility with Last Message Correction.  For continued 
> compatibility, <rtt> elements must be transmitted in separate 
> <message> payloads as <replace> elements.  Although it is not 
> necessarily required, the XEP-0308 spec suggests this.
> Within this, there are two approaches I see easily:
> 1. Only allow real time text (XEP-0301) on the most recent message 
> (default scenario).  Last message correction (XEP-0308) would suddenly 
> update the previous message, rather than incrementally.   This works 
> fine with existing spec as long as best practice is followed:
> (a) Use separate <message> payload for <replace> transmission.
> (b) Do not transmit any <rtt> elements while a last-message is being 
> edited.
> 2. Allow real time text (RTT) to occur with previous messages.  I 
> would add an optional 'id' attribute to <rtt> elements.  (we actually 
> intentionally designed RTT to permit backwards compatibility with 
> theoretical future retroactive edit capability, by adding an optional 
> id attribute).   It would be compatible with XEP-0308.  This would 
> require modification to the XEP-0301 spec, but would allow RTT editing 
> to work on previous messages (limit 1 message ago, or even 
> configurable max X messages ago)
> The door is open for scenario 1 (works with existing 0301/0308 specs) 
> and scenario 2 (future improvement to XEP-0301)
> Sincerely,
> Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20111112/98d8b9fc/attachment.html>

More information about the Standards mailing list