[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
kevin at kismith.co.uk
Tue Apr 17 09:35:54 UTC 2012
Mild thread necromancy:
2011/11/11 Gunnar Hellström <gunnar.hellstrom at omnitor.se>:
> 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
That sounds largely reasonable to me.
> 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?
I think that you can just start rtt-ing on the previous message
without retransmitting it in advance, unless you care about the edge
case where a user has switched clients very quickly and so doesn't
have that message. I would think that case isn't work optimising for.
> 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?
It seems reasonable to me to keep this within 301.
More information about the Standards