Re: [Standards] Correcting last message
On Tue, Jul 20, 2010 at 11:19, Kevin Smith ke...@kismith.co.uk wrote: Following a discussion in jdev, I've thrown together the skeleton of a XEP for correcting previous messages. I'll clean it up before submitting, but the rough gist is at: http://www.doomsong.co.uk/extensions/render/xep-correct.html Discussion welcome. Hi all, Not much discussion on this, it either means it is perfect... or no-one has interest in it. ;-) We are nearing a release of OneTeam Desktop beta2, with a real UI/UX for the correction feature. For now we are just sending and interpreting a substitution string à la vi (s/wrong/right/). It can be considered a fallback to this XEP. So we are ready to implement it. Can we advance this XEP? Regards -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 2:43 PM, Nicolas Vérité nicolas.ver...@gmail.com wrote: On Tue, Jul 20, 2010 at 11:19, Kevin Smith ke...@kismith.co.uk wrote: Following a discussion in jdev, I've thrown together the skeleton of a XEP for correcting previous messages. I'll clean it up before submitting, but the rough gist is at: http://www.doomsong.co.uk/extensions/render/xep-correct.html Discussion welcome. Hi all, Not much discussion on this, it either means it is perfect... or no-one has interest in it. ;-) We are nearing a release of OneTeam Desktop beta2, with a real UI/UX for the correction feature. For now we are just sending and interpreting a substitution string à la vi (s/wrong/right/). It can be considered a fallback to this XEP. So we are ready to implement it. Can we advance this XEP? Or turn it into a XEP, even. Council have roughly agreed (two weeks ago, I think) to publish this as soon as I finish off a couple of details that I now forget. I've just been pretty busy. I will move it up my priority pile. /K
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 15:46, Kevin Smith ke...@kismith.co.uk wrote: On Fri, Mar 25, 2011 at 2:43 PM, Nicolas Vérité nicolas.ver...@gmail.com wrote: On Tue, Jul 20, 2010 at 11:19, Kevin Smith ke...@kismith.co.uk wrote: Following a discussion in jdev, I've thrown together the skeleton of a XEP for correcting previous messages. I'll clean it up before submitting, but the rough gist is at: http://www.doomsong.co.uk/extensions/render/xep-correct.html Discussion welcome. Hi all, Not much discussion on this, it either means it is perfect... or no-one has interest in it. ;-) We are nearing a release of OneTeam Desktop beta2, with a real UI/UX for the correction feature. For now we are just sending and interpreting a substitution string à la vi (s/wrong/right/). It can be considered a fallback to this XEP. So we are ready to implement it. Can we advance this XEP? Or turn it into a XEP, even. Council have roughly agreed (two weeks ago, I think) to publish this as soon as I finish off a couple of details that I now forget. I've just been pretty busy. I will move it up my priority pile. Ah, good news, excellent! Then maybe we can start implementing it. Just one common feedback from our most technical users: we should: 1/ forbid the edition/correction of other messages than the last 2/ authorize the correction only once Because otherwise: A/ you could mess up with client and servers histories/logs B/ you could have a real time conversation with someone, but afterwards correct everything Summary: * only one edit * only the latest message We could also suggest client and logger implementors to provide a UI to switch back and forth to the original and corrected messages. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On 3/25/11 8:53 AM, Nicolas Vérité wrote: Just one common feedback from our most technical users: we should: 1/ forbid the edition/correction of other messages than the last 2/ authorize the correction only once Because otherwise: A/ you could mess up with client and servers histories/logs B/ you could have a real time conversation with someone, but afterwards correct everything Summary: * only one edit * only the latest message Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Correcting last message
Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM message right :-) I don't see a reason to put in arbitrary restrictions in the protocol (different use cases can warrant different limits); i wouldn't mind recommendations, though. As long as the client indicates that a message has been edited X times (and provides the original message), i don't really see any issues. cheers, Remko
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 15:59, Peter Saint-Andre stpe...@stpeter.im wrote: On 3/25/11 8:53 AM, Nicolas Vérité wrote: Just one common feedback from our most technical users: we should: 1/ forbid the edition/correction of other messages than the last 2/ authorize the correction only once Because otherwise: A/ you could mess up with client and servers histories/logs B/ you could have a real time conversation with someone, but afterwards correct everything Summary: * only one edit * only the latest message Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. In fact, no, it's not too restrictive. Besides, it is really a common user feedback we had in our private alpha period. People want restrictions. Or else, they fear that the history is changed. We thought like you before, but we had to listen to our users. If you were wrong, just don't say oops, just correct you message... 5 messages is far too many, since it could totally change a discussion. More than one edit, is also too many. OK, let's think this stupid example (sorry, I got no imagination): Nyco: Hi Peter, how are you? Peter: I'm fine, thank you Nyco: and how is your work? Peter: it is fine too Nyco: OK, bye Peter has left the conversation Now since I'm malicious, I'll change my messages. Here is the modified history: Nyco: Hi Peter, how are you since you were painted in blue? Peter: I'm fine, thank you Nyco: and how about being dressed in green penguin with tentacles? Peter: it is fine too Nyco: wow, then Peter has left the conversation How can we prevent this? (because we must prevent this... do you disagree?) -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
2011/3/25 Remko Tronçon re...@el-tramo.be: Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM message right :-) I don't see a reason to put in arbitrary restrictions in the protocol (different use cases can warrant different limits); i wouldn't mind recommendations, though. As long as the client indicates that a message has been edited X times (and provides the original message), i don't really see any issues. Well, the Standards ML and the Council can do what it wants of the implementor and user feedback... Who else has implemented a correction feature? What user have said about it? Don't forget that we are in the proces of allowing to modify (a) past message(s)... it is a huge trickery concern. Also, what do you want to do with encrypted messages? -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On Fri Mar 25 15:12:19 2011, Nicolas Vérité wrote: OK, let's think this stupid example (sorry, I got no imagination): Nyco: Hi Peter, how are you? Peter: I'm fine, thank you Nyco: and how is your work? Peter: it is fine too Nyco: OK, bye Peter has left the conversation Now since I'm malicious, I'll change my messages. Here is the modified history: Nyco: Hi Peter, how are you since you were painted in blue? Peter: I'm fine, thank you Nyco: and how about being dressed in green penguin with tentacles? Peter: it is fine too Nyco: wow, then Peter has left the conversation How can we prevent this? (because we must prevent this... do you disagree?) I don't see that this is dependent on being able to edit messages. Consider: 1) Peter's client can maintain the history *including edits*, thus defeating this. 2) Your client could fabricate the entire conversation *without edits*, and you could hand it out. If you want to defeat such things, we need message integrity and authentication, which basically means signing. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Correcting last message
On 3/25/11 9:12 AM, Nicolas Vérité wrote: On Fri, Mar 25, 2011 at 15:59, Peter Saint-Andre stpe...@stpeter.im wrote: On 3/25/11 8:53 AM, Nicolas Vérité wrote: Just one common feedback from our most technical users: we should: 1/ forbid the edition/correction of other messages than the last 2/ authorize the correction only once Because otherwise: A/ you could mess up with client and servers histories/logs B/ you could have a real time conversation with someone, but afterwards correct everything Summary: * only one edit * only the latest message Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. In fact, no, it's not too restrictive. Besides, it is really a common user feedback we had in our private alpha period. People want restrictions. Or else, they fear that the history is changed. We thought like you before, but we had to listen to our users. If you were wrong, just don't say oops, just correct you message... 5 messages is far too many, since it could totally change a discussion. More than one edit, is also too many. OK, let's think this stupid example (sorry, I got no imagination): Nyco: Hi Peter, how are you? Peter: I'm fine, thank you Nyco: and how is your work? Peter: it is fine too Nyco: OK, bye Peter has left the conversation Now since I'm malicious, I'll change my messages. Here is the modified history: Nyco: Hi Peter, how are you since you were painted in blue? Peter: I'm fine, thank you Nyco: and how about being dressed in green penguin with tentacles? Peter: it is fine too Nyco: wow, then Peter has left the conversation How can we prevent this? (because we must prevent this... do you disagree?) That's a social problem, not a technical problem. :) I'm more worried about: Nÿco: Hi Peter, how are you? Peter: I'm fine, think you Peter: oops Peter: damn, I'm not allowed to correct the typo! Peter: I meant to say, I'm fine, thank you Nÿco: heh Nÿco: maybe I was wrong about correcting only the last message /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 16:30, Kevin Smith ke...@kismith.co.uk wrote: On Fri, Mar 25, 2011 at 2:53 PM, Nicolas Vérité For only one edit, I'm not sure this is necessary for interop (and therefore to include in the spec) - but clients are free to not render an edit as an edit if they feel they don't want to for some reason. Drrring. Wrong. This is a strong user demand, maybe the strongest. It is mandatory to clearly state an edit as an edit. Or show the original along with the corrected (strike formatting, or whatever, if you want). -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
Hello, I am authoring the Real Time Text, along with members of realtimetext.org (Gunnar, etc). The old draft is at http://www.realjabber.org/realtimemtext.html ... but is currently being rewritten and simplified for 0.02 resubmission. I have a private extension to my real time text standard that allows unlimited retroactive editing via indexing the message line via a msg parameter. It would have been useful for: - critical writing where deep-retroactive edits are desirable. - Real time transcription of court reporting - Real time captioning workflows where a caption editor works at the same time as a transcriber on adjacent computers. - it is MUC compatible (although not supported by my 0.02 spec except as a private extension) for one-to-many transmission, like to multiple audience members or several TV stations, that needs a hook into the feed. They can reject or accept edits before X lines automatically, as needed... Logging would have been done by: - Retransmitting any changed lines in a body element, everytime Enter is hit, or cursor arrow up/down goes out of bounds of the current line (cursor moves to adjacent line) Edits prievious to the current line can be automatically color-coded and highlighted automatically, to make it much harder to miss edits. My real time text standard also includes support for cursor position transmissions (which can be optionally rendered for a visible cursor) which makes it even easier to watch somebody make an edit. The retroactive editing feature is not an official part of my real time text standard as I had decided to leave it out, but to allow it to be added on as a private extension, if needed. Please be noted all of this is being left out of 0.02 of my real time text standard for simplicity. However, it would be worth some thought how your retroactive edit standard, may help (or interfere) with my technique of retroactive editing, and to make sure that our standards are compatible. Thanks! Mark Rejhon (Authoring the XMPP Real Time Text Standard) On 3/25/11, Remko Tronçon re...@el-tramo.be wrote: Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM message right :-) I don't see a reason to put in arbitrary restrictions in the protocol (different use cases can warrant different limits); i wouldn't mind recommendations, though. As long as the client indicates that a message has been edited X times (and provides the original message), i don't really see any issues. cheers, Remko -- Sent from my mobile device
Re: [Standards] Correcting last message
On Fri Mar 25 15:42:21 2011, Mark Rejhon wrote: I am authoring the Real Time Text, along with members of realtimetext.org (Gunnar, etc). The old draft is at http://www.realjabber.org/realtimemtext.html ... but is currently being rewritten and simplified for 0.02 resubmission. I do think that in principle, RTT should end up such that it should be simple to implement a bare bones version for the use case of editing a previous message.
Re: [Standards] Correcting last message
Am 25.03.2011 16:48, schrieb Kevin Smith: On Fri, Mar 25, 2011 at 3:41 PM, Nicolas Vérité nicolas.ver...@gmail.com wrote: On Fri, Mar 25, 2011 at 16:30, Kevin Smith ke...@kismith.co.uk wrote: On Fri, Mar 25, 2011 at 2:53 PM, Nicolas Vérité For only one edit, I'm not sure this is necessary for interop (and therefore to include in the spec) - but clients are free to not render an edit as an edit if they feel they don't want to for some reason. Drrring. Wrong. This is a strong user demand, maybe the strongest. It is mandatory to clearly state an edit as an edit. Or show the original along with the corrected (strike formatting, or whatever, if you want). Right, clients are free to render this however they want to. Perhaps I should add an I wasn't willing to render this as an edit error? That way if a client wanted to reject edits after the first one, it could, and if it wanted to allow them, it could. Does that work for your user requirements (your users would never send a subsequent message, of course, so would never encounter the error - but would send it if a more liberal client were try and edit something)? Since I have a feeling there might be a slight misunderstanding here I'm gonna ask: By Not render this as an edit do you mean: a) Ignore the stanza an pretend there was no edit b) Do the edit, but provide no visible feedback of this I suspect you meant a), but Nicolas thought you meant b).
Re: [Standards] Correcting last message
On Fri, Mar 25, 2011 at 17:01, Florian Zeitz florian.ze...@gmx.de wrote: Am 25.03.2011 16:48, schrieb Kevin Smith: On Fri, Mar 25, 2011 at 3:41 PM, Nicolas Vérité nicolas.ver...@gmail.com wrote: On Fri, Mar 25, 2011 at 16:30, Kevin Smith ke...@kismith.co.uk wrote: On Fri, Mar 25, 2011 at 2:53 PM, Nicolas Vérité For only one edit, I'm not sure this is necessary for interop (and therefore to include in the spec) - but clients are free to not render an edit as an edit if they feel they don't want to for some reason. Drrring. Wrong. This is a strong user demand, maybe the strongest. It is mandatory to clearly state an edit as an edit. Or show the original along with the corrected (strike formatting, or whatever, if you want). Right, clients are free to render this however they want to. Perhaps I should add an I wasn't willing to render this as an edit error? That way if a client wanted to reject edits after the first one, it could, and if it wanted to allow them, it could. Does that work for your user requirements (your users would never send a subsequent message, of course, so would never encounter the error - but would send it if a more liberal client were try and edit something)? Since I have a feeling there might be a slight misunderstanding here I'm gonna ask: By Not render this as an edit do you mean: a) Ignore the stanza an pretend there was no edit b) Do the edit, but provide no visible feedback of this I suspect you meant a), but Nicolas thought you meant b). Ah, seems like native English speaker do understand themselves, as much as non-native English speakers understand each other... ;-) -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
It also operates in chat too. Back in 1992, I created the equivalent of Unix 'talk' that allowed cursor up/down, going back even to the beginning of the conversation. The real time text standard also allows representation as either a traditional IM conversation, and splitscreen, so the same effect can be achieved. That said, all the concerns about not allowing deep retroactivity is valid, and that is why I leave it out. However, I did like the deep retroactive feature during conversations -- it was useful, and due to the cursor movement capability (which also exists in the real time text standard), it allows the remote person to backscroll too -- so was useful for showing me stuff I missed, too. Mark Rejhon On 3/25/11, Nicolas Vérité nicolas.ver...@gmail.com wrote: Please just don't forget that chat is completely different text _editing_... On Fri, Mar 25, 2011 at 16:42, Mark Rejhon marky...@gmail.com wrote: Hello, I am authoring the Real Time Text, along with members of realtimetext.org (Gunnar, etc). The old draft is at http://www.realjabber.org/realtimemtext.html ... but is currently being rewritten and simplified for 0.02 resubmission. I have a private extension to my real time text standard that allows unlimited retroactive editing via indexing the message line via a msg parameter. It would have been useful for: - critical writing where deep-retroactive edits are desirable. - Real time transcription of court reporting - Real time captioning workflows where a caption editor works at the same time as a transcriber on adjacent computers. - it is MUC compatible (although not supported by my 0.02 spec except as a private extension) for one-to-many transmission, like to multiple audience members or several TV stations, that needs a hook into the feed. They can reject or accept edits before X lines automatically, as needed... Logging would have been done by: - Retransmitting any changed lines in a body element, everytime Enter is hit, or cursor arrow up/down goes out of bounds of the current line (cursor moves to adjacent line) Edits prievious to the current line can be automatically color-coded and highlighted automatically, to make it much harder to miss edits. My real time text standard also includes support for cursor position transmissions (which can be optionally rendered for a visible cursor) which makes it even easier to watch somebody make an edit. The retroactive editing feature is not an official part of my real time text standard as I had decided to leave it out, but to allow it to be added on as a private extension, if needed. Please be noted all of this is being left out of 0.02 of my real time text standard for simplicity. However, it would be worth some thought how your retroactive edit standard, may help (or interfere) with my technique of retroactive editing, and to make sure that our standards are compatible. Thanks! Mark Rejhon (Authoring the XMPP Real Time Text Standard) On 3/25/11, Remko Tronçon re...@el-tramo.be wrote: Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM message right :-) I don't see a reason to put in arbitrary restrictions in the protocol (different use cases can warrant different limits); i wouldn't mind recommendations, though. As long as the client indicates that a message has been edited X times (and provides the original message), i don't really see any issues. cheers, Remko -- Sent from my mobile device -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr -- Sent from my mobile device
Re: [Standards] Correcting last message
2011/3/25 Mark Rejhon marky...@gmail.com: It also operates in chat too. Back in 1992, I created the equivalent of Unix 'talk' that allowed cursor up/down, going back even to the beginning of the conversation. The real time text standard also allows representation as either a traditional IM conversation, and splitscreen, so the same effect can be achieved. That said, all the concerns about not allowing deep retroactivity is valid, and that is why I leave it out. However, I did like the deep retroactive feature during conversations -- it was useful, and due to the cursor movement capability (which also exists in the real time text standard), it allows the remote person to backscroll too -- so was useful for showing me stuff I missed, too. Mark Rejhon Having experienced chat clients with editing features, I can oppose two clearly different behaviours: 1/ only one edit, only last message: ** no cheat, users feel safe with other's chat messages ** you know what you can do or not, and learn to live with 2/ infinite edits, all messages: ** you just restrict yourself, because you deeply know it's wrong to edit everything every time ** users do not trust the client, nor the contact ** lots of unwanted side-effects in histories and logs ** uncompatible clients suffer ** etc. If it does not appear as mandatory in the XEP, it needs at least to be strongly adviced. On 3/25/11, Nicolas Vérité nicolas.ver...@gmail.com wrote: Please just don't forget that chat is completely different text _editing_... On Fri, Mar 25, 2011 at 16:42, Mark Rejhon marky...@gmail.com wrote: Hello, I am authoring the Real Time Text, along with members of realtimetext.org (Gunnar, etc). The old draft is at http://www.realjabber.org/realtimemtext.html ... but is currently being rewritten and simplified for 0.02 resubmission. I have a private extension to my real time text standard that allows unlimited retroactive editing via indexing the message line via a msg parameter. It would have been useful for: - critical writing where deep-retroactive edits are desirable. - Real time transcription of court reporting - Real time captioning workflows where a caption editor works at the same time as a transcriber on adjacent computers. - it is MUC compatible (although not supported by my 0.02 spec except as a private extension) for one-to-many transmission, like to multiple audience members or several TV stations, that needs a hook into the feed. They can reject or accept edits before X lines automatically, as needed... Logging would have been done by: - Retransmitting any changed lines in a body element, everytime Enter is hit, or cursor arrow up/down goes out of bounds of the current line (cursor moves to adjacent line) Edits prievious to the current line can be automatically color-coded and highlighted automatically, to make it much harder to miss edits. My real time text standard also includes support for cursor position transmissions (which can be optionally rendered for a visible cursor) which makes it even easier to watch somebody make an edit. The retroactive editing feature is not an official part of my real time text standard as I had decided to leave it out, but to allow it to be added on as a private extension, if needed. Please be noted all of this is being left out of 0.02 of my real time text standard for simplicity. However, it would be worth some thought how your retroactive edit standard, may help (or interfere) with my technique of retroactive editing, and to make sure that our standards are compatible. Thanks! Mark Rejhon (Authoring the XMPP Real Time Text Standard) On 3/25/11, Remko Tronçon re...@el-tramo.be wrote: Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM message right :-) I don't see a reason to put in arbitrary restrictions in the protocol (different use cases can warrant different limits); i wouldn't mind recommendations, though. As long as the client indicates that a message has been edited X times (and provides the original message), i don't really see any issues. cheers, Remko -- Sent from my mobile device -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr -- Sent from my mobile device -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
Note again - I'm leaving retroactivity out of the real time text standard. I'm just requesting to make sure that there is compatibility between standards... -- Even if only editing the last line, there's some potential interplay/incompatibility that I (or you or we) might need to resolve. -- Even without retroactive editing, we might need to say our standards are incompatible with each other depending on what the group agrees on (ie, enabling real time text may disable the edit-last-line standard) -- Wild idea out of the blue: what about the idea of a different standard (third standard) called a message indexing standard, a method of referencing a specific historical line, that both your standard and possible future versions of my standard, can take advantage of? Probably not a pratical idea, but it might reduce future headaches. Retroactive editing is very useful for real-time-text, and it is in my interests to see compatibility. You can download my realjabber test software -- or email me to ask for a copy. (Has no retroactive editing, but may give you ideas of how to make our standards compatible) Mark Rejhon On 3/25/11, Mark Rejhon marky...@gmail.com wrote: It also operates in chat too. Back in 1992, I created the equivalent of Unix 'talk' that allowed cursor up/down, going back even to the beginning of the conversation. The real time text standard also allows representation as either a traditional IM conversation, and splitscreen, so the same effect can be achieved. That said, all the concerns about not allowing deep retroactivity is valid, and that is why I leave it out. However, I did like the deep retroactive feature during conversations -- it was useful, and due to the cursor movement capability (which also exists in the real time text standard), it allows the remote person to backscroll too -- so was useful for showing me stuff I missed, too. Mark Rejhon On 3/25/11, Nicolas Vérité nicolas.ver...@gmail.com wrote: Please just don't forget that chat is completely different text _editing_... On Fri, Mar 25, 2011 at 16:42, Mark Rejhon marky...@gmail.com wrote: Hello, I am authoring the Real Time Text, along with members of realtimetext.org (Gunnar, etc). The old draft is at http://www.realjabber.org/realtimemtext.html ... but is currently being rewritten and simplified for 0.02 resubmission. I have a private extension to my real time text standard that allows unlimited retroactive editing via indexing the message line via a msg parameter. It would have been useful for: - critical writing where deep-retroactive edits are desirable. - Real time transcription of court reporting - Real time captioning workflows where a caption editor works at the same time as a transcriber on adjacent computers. - it is MUC compatible (although not supported by my 0.02 spec except as a private extension) for one-to-many transmission, like to multiple audience members or several TV stations, that needs a hook into the feed. They can reject or accept edits before X lines automatically, as needed... Logging would have been done by: - Retransmitting any changed lines in a body element, everytime Enter is hit, or cursor arrow up/down goes out of bounds of the current line (cursor moves to adjacent line) Edits prievious to the current line can be automatically color-coded and highlighted automatically, to make it much harder to miss edits. My real time text standard also includes support for cursor position transmissions (which can be optionally rendered for a visible cursor) which makes it even easier to watch somebody make an edit. The retroactive editing feature is not an official part of my real time text standard as I had decided to leave it out, but to allow it to be added on as a private extension, if needed. Please be noted all of this is being left out of 0.02 of my real time text standard for simplicity. However, it would be worth some thought how your retroactive edit standard, may help (or interfere) with my technique of retroactive editing, and to make sure that our standards are compatible. Thanks! Mark Rejhon (Authoring the XMPP Real Time Text Standard) On 3/25/11, Remko Tronçon re...@el-tramo.be wrote: Only the latest message seems overly restrictive (especially if the last message you send it oops). I'd say a buffer of, say, the last 5 messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM message right :-) I don't see a reason to put in arbitrary restrictions in the protocol (different use cases can warrant different limits); i wouldn't mind recommendations, though. As long as the client indicates that a message has been edited X times (and provides the original message), i don't really see any issues. cheers, Remko -- Sent from my mobile device -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com
Re: [Standards] Correcting last message
On Tue, Jul 20, 2010 at 11:19, Kevin Smith ke...@kismith.co.uk wrote: Following a discussion in jdev, I've thrown together the skeleton of a XEP for correcting previous messages. I'll clean it up before submitting, but the rough gist is at: http://www.doomsong.co.uk/extensions/render/xep-correct.html Discussion welcome. Additionally, we can also forbid, or deeply advice to forbid, message deletion. -- Nicolas Vérité (Nÿco) mailto:nicolas.ver...@gmail.com Jabber ID : xmpp:n...@jabber.fr
Re: [Standards] Correcting last message
On 25 March 2011 20:38, Gregg Vanderheiden g...@trace.wisc.edu wrote: 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. Everything you listed pertains to the client/UI and not the protocol. I think this is conflating the unconflatable (to quote a wise man). There's a difference between deciding how we inform someone of a change and how their client displays it. The XEP already contains warnings to client developers that they should make edits clear, and as long as we keep this then I don't see how such an extension is changing XMPP significantly at all. Regards, Matthew
Re: [Standards] Correcting last message
At this point in the discussion, I'd like to ensure that people commenting have read the suggested spec, as some comments coming through suggest they haven't. In particular, it does say that messages should be clearly marked. It makes no suggestion about changing any chat transcripts that a client stores. It says that clients may be able to advertise that don't support (or rather, not advertise that they do support) editing of messages older than the most recent. Thanks. /K
Re: [Standards] Correcting last message
I agree with Gregg for the most part. That said, it's still a concern of standards interoperability even when limiting retroactive editing to just only the last message (or two). That's a concern right now, even if I say, I permanently give up the possibility of using a private extension to allow retroactive editing beyond the last message. (Which I would rather not -- just to keep the door open for 'niche usage') Yes, the standards have a method of highlighting edits. There are many methods of edit highlighting, and those are virtually all a UI implementation issue. Also, my spouse is a court reporter. You'd be surprised at the low quality of some of the software available (I've seen with my own eyes) that XMPP would be a big improvement, especially if combined with some of the security-improving XMPP standards. Thanks! Mark Rejhon On Fri, Mar 25, 2011 at 4:38 PM, Gregg Vanderheiden g...@trace.wisc.eduwrote: 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 RD 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
Re: [Standards] Correcting last message
2011/3/25 Mark Rejhon marky...@gmail.com: Note again - I'm leaving retroactivity out of the real time text standard. I'm just requesting to make sure that there is compatibility between standards... I think that if you want to RTT a correction, you just need to use a correction payload with the RTT update. I don't see a great incompatibility between the two ideas. /K
Re: [Standards] Correcting last message
Hi Kevin. my concern is that should does not forbid. not mentioning does not prevent So the issues raised continue to exist if there is not a prohibition of them. And given feature-mania it is likely that anything that is not prevented can occur and is likely to be implemented. Buyer beware should apply but this is not something that consumers look for. My comments were made only because - once the technology gets a bad name by security minded admins... it is hard to get it back.** Perhaps we can shift that conversation, if it occurs, over to focusing the bad rap on bad clients rather than the technology. My comments were meant to suggest that perhaps we should think nefariously, and see if anything we are doing can be used for mischief, and if so, if there was something simple we can do to avoid it. I also think that simplicity and predictable behavior will serve us better in the long run than complicated or unexpected behavior (by consumers) like editing text that is offscreen. Standards usually enable - rather than restrict. But when it comes to safety, restrictions sometimes enable. that's all Thanks Gregg --- Gregg Vanderheiden Ph.D. Director Trace RD Center Professor Industrial Systems Engineering and Biomedical Engineering University of Wisconsin-Madison On Mar 25, 2011, at 9:49 PM, Kevin Smith wrote: At this point in the discussion, I'd like to ensure that people commenting have read the suggested spec, as some comments coming through suggest they haven't. In particular, it does say that messages should be clearly marked. It makes no suggestion about changing any chat transcripts that a client stores. It says that clients may be able to advertise that don't support (or rather, not advertise that they do support) editing of messages older than the most recent. Thanks. /K
Re: [Standards] Correcting last message
On Sat, Jul 24, 2010 at 11:43 AM, Jonathan Schleifer js-xmpp-standa...@webkeks.org wrote: I think referencing the old message by content is not a good idea. First, there might have been another message with the exact same content. Second, it is unnecessary traffic. I'd recommend something like this: message id=bad bodywrong message/body /message message id=good bodycorrected message/body replaces id=bad/ /message This will also be backwards-compatible with clients that don't support it and the overhead is so minimal that you might even skip checking for that feature. I agree. That's why your suggestion is almost a copy and paste of the example in my proposal. /K
Re: [Standards] Correcting last message
Am 24.07.2010 um 12:51 schrieb Kevin Smith: I agree. That's why your suggestion is almost a copy and paste of the example in my proposal. Oh, sorry, early in the morning and somehow thought you were referencing the content. NVM then. -- Jonathan
[Standards] Correcting last message
Following a discussion in jdev, I've thrown together the skeleton of a XEP for correcting previous messages. I'll clean it up before submitting, but the rough gist is at: http://www.doomsong.co.uk/extensions/render/xep-correct.html Discussion welcome. /K
Re: [Standards] Correcting last message
First thoughts: perhaps you should add a section that informs how to handle child elements of the message stanza other than body. XHTML-IM adds an child element that's typically related to the message body content, for example. Other child elements might not (nicknames, for example). Should the XEP allow overriding other child elements like that (for XHTML-IM, I would think so). What should be the business rules if: - the original stanza contains such additional child elements, and the replacement one has not? - the original stanza does not contains suchs additional child elements, but the replacement one does? - both stanzas have different additional child elements? On 20 July 2010 05:19, Kevin Smith ke...@kismith.co.uk wrote: Following a discussion in jdev, I've thrown together the skeleton of a XEP for correcting previous messages. I'll clean it up before submitting, but the rough gist is at: http://www.doomsong.co.uk/extensions/render/xep-correct.html Discussion welcome. /K
Re: [Standards] Correcting last message
La cuenta correo a la que ha escrito, se encuentra inactiva, en caso de necesitar contactar con el Departamento de Informática, ruego se pongan en contacto con nosotros por teléfono. Gracias y disculpe las molestias.
Re: [Standards] Correcting last message
La cuenta correo a la que ha escrito, se encuentra inactiva, en caso de necesitar contactar con el Departamento de Informática, ruego se pongan en contacto con nosotros por teléfono. Gracias y disculpe las molestias.
Re: [Standards] Correcting last message
On Tue, Jul 20, 2010 at 11:41 AM, Guus der Kinderen guus.der.kinde...@gmail.com wrote: First thoughts: perhaps you should add a section that informs how to handle child elements of the message stanza other than body. XHTML-IM adds an child element that's typically related to the message body content, for example. Other child elements might not (nicknames, for example). Should the XEP allow overriding other child elements like that (for XHTML-IM, I would think so). What should be the business rules if: the original stanza contains such additional child elements, and the replacement one has not? the original stanza does not contains suchs additional child elements, but the replacement one does? both stanzas have different additional child elements? Thanks - I've put in some placeholder text for this. Roughly - senders MUST send the same stanza, just corrected. /K
Re: [Standards] Correcting last message
On Tue, Jul 20, 2010 at 3:01 PM, Kevin Smith ke...@kismith.co.uk wrote: Thanks - I've put in some placeholder text for this. Roughly - senders MUST send the same stanza, just corrected. And what if correction means changing the attached elements? For example: Message body: I send you these two contacts Attachments: one roster item Correction: Message body: I send you these two contacts Attachments: two roster items Cheers! -- Sergei Golovan
Re: [Standards] Correcting last message
On Tue, Jul 20, 2010 at 12:11 PM, Sergei Golovan sgolo...@nes.ru wrote: On Tue, Jul 20, 2010 at 3:01 PM, Kevin Smith ke...@kismith.co.uk wrote: Thanks - I've put in some placeholder text for this. Roughly - senders MUST send the same stanza, just corrected. And what if correction means changing the attached elements? Thanks - I've made a note about only doing this for messaging messages (yes, the text needs wordsmithing!). /K
