I think that we should be very careful with retro-editing. Any edits should be plainly visible as edits. There will be a lot of business carried out in this medium. And much of it will be carried out by people who not only don't pay attention to settings, but may not even know there are settings in their client -- or that all clients do not behave the same.
So having someone able to edit the RECORD of the chat, not only on their machine, but on the machines of others. And to allow them to edit text that has scrolled off screen (say on a phone), would allow them to change the RECORD of a conversation without the person knowing about it. Hence either 1) don't allow retro editing OR 2) mark edits so it is clear what was said, and that it was subsequently edited. OR 3) when a block is edited -- it is auto-copied to the bottom and re-transmitted. (This takes no action by the standard -- and can be done today in any client). Court reporters use special secure technologies and do not use IM. Remote captioning services would use RTT - and would also have to clearly mark edits for a number of reasons. We don't want to have something we do cause this IM to be viewed as less safe for business than others. Gregg ----------------------- Gregg Vanderheiden Ph.D. Director Trace R&D Center Professor Industrial & Systems Engineering and Biomedical Engineering University of Wisconsin-Madison On Mar 25, 2011, at 6:25 PM, Mark Rejhon wrote: > 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
