Please note: My real time text standard is chat-based, just like AOL AIM 6.8 or later in "AIM Real Time IM" (Google that string). It is highly desirable by deaf users, in message-based chat. However, when combined with retroactive editing, it becomes more collaboration. Boundaries get blurred. It's no longer orthogonal.
See the problem: 1. Even for ONE message back, this standards are incompatible. This needs to be fixed. Retroactive editing is useful for real time text chats too! 2. And, what if, there was ever a reason, for MORE than one message back, such as for court reporting? Same retroactive edit standard? Or create new standard? See the problem? One standard or two??? It may be easier to keep it as two separate retroactive editing standards, to cover all use cases. If chat based, we should merge to one. (We *ARE* blurring the lines between chat and collaboration when we use both of our standards in the same chat software) As it stands, I'm using a chat-based real time text standard which is great for conversations between the deaf (google "AOL Real-Time IM" for some mainstream chat background info) SUGGESTED timeline: - I work quickly to finish my Version 0.02 rewrite of my standard and submit to XMPP.org (this has lit a fire under me to do so, more quickly) - During the "experimental" stage of the standard, work towards compatibility using minor tweaks to both of our standards - Make sure our standards are compatible. Remember.... - Real Time Text may someday become a mainstream opt-in "assistive" feature of chat clients - AOL AIM -- now has Real Time IM that can be activated via a menu option - Jabber / GTalk / iChat -- My XMPP RTT standard (and I already have a Google contact I may petition to add RTT support to GMAIL's chat), which is modelled the same way but as an open standard rather than proprietary. - etc. And may all be required to interoperate someday, too. But we have plenty of time. I like the idea of your retroactive editing standard. But we have very different ideas how to approach the retroactive edit problem. So, the question becomes: One standard or two? (I already have a private extension, with a configurable X-lines-allowed of retroactive editing -- including limiting to only 1 or 2 lines of retroactivity -- which I originally was not going to submit) Sincerely, Mark Rejhon
