[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
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