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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Fri Jul 20 18:49:46 UTC 2012

Your current sentence is:
>>>"to have improved presentation of real-time text during message correction"

I understand now that there may be real-time display during last message 
correction. And that full support causes improved presentation. So you 
may keep the sentence.

I am a bit afraid that all the cases you describe of mixed support or 
not for XEP-0301 and XEP-0308, and transmitting features with or without 
completed negotiation contain a lot of risks for unexpected behavior.

Will it for example be possible to return to appending text in a normal 
way at the end of the current message after you have completed editing 
corrections if your receiver does not understand the rtt id attribute 
but receive them and act on them. Do you have any rules for how to leave 
the current message, and how to return to it? Will the received messages 
with <body/> really erase the right part of the real-time delivered text?

Would it not be safer to say that you must support receiving id= and 
reacting properly if you declare support of both XEP-0301 and XEP-0308, 
and that you shall not send id attributes if negotiation for support of 
both XEP-0308 and XEP-0301 fail?


More information about the Standards mailing list