[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
markybox at gmail.com
Fri Jul 20 20:54:05 UTC 2012
On Fri, Jul 20, 2012 at 2:49 PM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:
> Your current sentence is:
>>>> "to have improved presentation of real-time text during message
> 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?
(1) The modified text specifies that a message reset is used whenever
switching between messages. That solves the problem, irregardless of
whether the clients acts on the 'id' attribute.
(2) The [[[Body Element]]] part of XEP-0301 requires you to clear the
real-time message when a body is delivered.
But actually, I just realized this point is 100% moot....because it is
cleared/replaced anyway in the next <rtt event='new'/> or <rtt
event='reset'/> anyway. Which is exactly what also will occur when
switching between messages (last message and current message). A chat
session only has one real-time message per sender, and it is always
cleared/replaced by event='new' / event='reset'
(Note: Message resets are also used when switching computers, switching
windows, and switching chat programs between the same participants)
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?
If several people say so, I can consider that.
But I agree with Kevin that XEP-0301 and XEP-0308 can be usable by senders
and/or recipients not using 'id'
I'd rather fix the rest of the spec to be unambigiously clear about
business rules -- let me know if there are confusing sentences in XEP-0301
that can be clarified, to ensure spec compliance (for full XEP-0301 /
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards