Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Sat, Oct 13, 2012 at 6:46 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: My conclusions are: 1. The feature will be allowed. ( deduced from your answer that Kev is asked do do an update ) 2. How edits are presented to the receiving user is out of scope, but a recommendation to make it clearly displayed that there was an edit will be included. 3. Edit any previous will be included. It is up to the transmitter to use it or not. Receivers should be prepared to act on editing any previous. I have updated 308 in Git. I believe I've addressed all feedback other than allowing editing of any previous - for this I've made a note that the protocol can be used as such, but that signalling is out of scope and so 308 without further negotiation is only for the last message. It's then easy to either add support to 308 later (I think better not), or to add signalling to another XEP that needs or wants it; the doors open, but we're not inviting anyone in just yet. I ended up wanting not to add it to 308 because this thread has made it clear that the security implications are nastier then, and I think there's value in clients being able to implement the simple version (indeed, I'm not sure I want to implement multi-message correction myself any more). /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On 2013-02-24 17:20, Kevin Smith wrote: On Sat, Oct 13, 2012 at 6:46 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: My conclusions are: 1. The feature will be allowed. ( deduced from your answer that Kev is asked do do an update ) 2. How edits are presented to the receiving user is out of scope, but a recommendation to make it clearly displayed that there was an edit will be included. 3. Edit any previous will be included. It is up to the transmitter to use it or not. Receivers should be prepared to act on editing any previous. I have updated 308 in Git. I believe I've addressed all feedback other than allowing editing of any previous - for this I've made a note that the protocol can be used as such, but that signalling is out of scope and so 308 without further negotiation is only for the last message. That is fine. I fully respect your decision and am glad that XEP-0308 will be rescued from deferred state. /Gunnar
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Sat, Oct 13, 2012 at 1:46 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-10-13 04:24, Peter Saint-Andre wrote: I know that Kev has been quite busy, but he's quire reliable and I'm sure he will incorporate the Last Call feedback as he has promised to do. Was there any last call conclusion? The feedback was so varied, some saying that the feature was essential, some saying that it should not be allowed, some requiring that the edited message shall be shown last with changemarks, some accepting the change made in place. Edit any versus strictly edit last was also discussed. My conclusions are: 1. The feature will be allowed. ( deduced from your answer that Kev is asked do do an update ) 2. How edits are presented to the receiving user is out of scope, but a recommendation to make it clearly displayed that there was an edit will be included. 3. Edit any previous will be included. It is up to the transmitter to use it or not. Receivers should be prepared to act on editing any previous. This is my preference as well, though I seemed to recall that Kevin was going to keep it as is, for editing just the last message. Regardless, the XEP-0301 protocol will be compatible with either method. As for my XEP-0301 updates, keep tuned. Workload and certain priorities has increased as of late, but I will be catching up. I know that the U.S. access board has inquired asking about when it'll be ready. Thanks, Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
I have not seen any progress on XEP-0308 for a while. We dared to put in a reference to this useful feature in XEP-0301. Can we still hope that XEP-0308 will come out healthy from Last Call and not block completion of XEP-0301? Regards Gunnar ___ Gunnar Hellström Omnitor gunnar.hellst...@omnitor.se +46708204288 On 2012-08-30 21:10, Kevin Smith wrote: On Thu, Aug 30, 2012 at 8:02 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-07-31 22:52, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL:http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Was there any conclusion on this last call? I'm going to address the assorted comments, and then Council'll see whether another Last Call is justified. /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/12 3:05 PM, Gunnar Hellström wrote: I have not seen any progress on XEP-0308 for a while. We dared to put in a reference to this useful feature in XEP-0301. Can we still hope that XEP-0308 will come out healthy from Last Call and not block completion of XEP-0301? I know that Kev has been quite busy, but he's quire reliable and I'm sure he will incorporate the Last Call feedback as he has promised to do. Speaking of XEP-0301, I'm sure Mark has been busy as well, but if I recall correctly he said that an updated version would be forthcoming. I look forward to reviewing the revised spec. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlB40PoACgkQNL8k5A2w/vwDUgCeLn7TQGK+INcrLA8bg8UpXb5v zeIAoN0kdadvbeyyHkWmbzYRcCCUrw+C =phkz -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On 2012-10-13 04:24, Peter Saint-Andre wrote: I know that Kev has been quite busy, but he's quire reliable and I'm sure he will incorporate the Last Call feedback as he has promised to do. Was there any last call conclusion? The feedback was so varied, some saying that the feature was essential, some saying that it should not be allowed, some requiring that the edited message shall be shown last with changemarks, some accepting the change made in place. Edit any versus strictly edit last was also discussed. My conclusions are: 1. The feature will be allowed. ( deduced from your answer that Kev is asked do do an update ) 2. How edits are presented to the receiving user is out of scope, but a recommendation to make it clearly displayed that there was an edit will be included. 3. Edit any previous will be included. It is up to the transmitter to use it or not. Receivers should be prepared to act on editing any previous. Right? /Gunnar
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Oh, if you take it out of context like that, then yes... I was talking about my suggestion of a removable prefix. On Sep 6, 2012 3:37 AM, Mark Rejhon marky...@gmail.com wrote: On Fri, Aug 31, 2012 at 7:09 AM, Dave Cridland d...@cridland.net wrote: Although this needs some thought to handle XHTML-IM, and it may prove impossible - though we've done worse things with FLOTs before. Been away, so replying late, too. From first glance, XEP-0308 doesn't seem incompatible with XHTML-IM. It seems to be naturally usable with stanzas containing XHTML-IM -- just send a standard XHTML-IM message (with both body/ and html/) but also include a replace/ in stanza. Problem solved. The exact same reasonable UI suggestion can be followed as well. Can you explain the situation of impossibility? I am interested in your POV. Thanks, Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Thu, Sep 6, 2012 at 2:02 AM, Dave Cridland d...@cridland.net wrote: Oh, if you take it out of context like that, then yes... I was talking about my suggestion of a removable prefix Ok, my apologies -- I didn't realize it was sender-appended prefixes. Much like the me XEP-0245, where /me is a prefix transmitted as cleartext by the sender. In that case, I'm not sure I like the transmitted removable prefix idea, either. I generally prefer it be a recipient-appended prefix (if prefixes are used), not a sender-appended-and-transmitted prefix. I feel that implementations should decide how to highlight corrections and edits, and there's many completely reasonable ways to highlight edits (recipient-added prefixes, highlights, color codes, Edited tags, etc). For example, one implementation of doing things with XEP-0308 is that when edits are made, the message can also be moved orthographically to the bottom of the history and an Edited tag added. Enhancements in a specific client, such as selecting (or even mouseovering) the Edited tag, could possibly expand a list of previous versions of the same message and the timestamps for them. All of that can automatically be done by a client implementation, without modifications to XEP-0308. Then again, I also see the legitimacy of a removable prefix in backwards-compatible situations, including MUC (clients with and without 0308 support). As long as an algorithm is clearly defined for prefixes transmitted in XHTML-IM -- the simplest algorithm for prefix removal in XHTML-IM is simply iterate through the XHTML tree to the first non-blank innertext, and remove the leading prefix from it if a match for the prefix is found at the first non-blank innertext in the XHTML-IM tree. (I wonder if that's how XEP-0245 works over XHTML-IM?)
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
I'm going to stagger in horribly late on this. Firstly, I think this XEP is warranted - message correction is a useful feature, and whilst it's a technical solution to a social problem, I really don't see why this is an argument against it - if it weren't ultimately solving a social problem at all, that would be a powerful argument against it. Secondly, I, like many people, am concerned with the other social problems this technology may introduce, as well as the technical problems: 1) As written, the specification allows replacement of an IBB stanza with an IM message - possibly. This concerns me. The specification appears to not only allow this, but encourage its support - I think that changes of purpose should be ruled out of scope, very firmly. 2) I'm concerned that silent correction of previous messages could be dangerous. The last received message restriction is probably unwarranted, but needs to be balanced with a warning to implementors that the message flow will need to be maintained, as well as replacements being clearly indicated. That is, in Kurt's scenario, you should see: Kurt: Question? Me: Yes Kurt: Really? And when the correction comes in: Kurt: Question? *REPLACED* Me: Yes Kurt: Really? *CORRECTION* Me: No Me: Yes Or some such - that is, replacing messages other than the last in a message stream should not remove the original from view. I'm still concerned that replacing any but the author's last message is likely to cause problems with accurately presenting the data. Essentially, this should be heavily discussed in the Security Considerations section. 3) The naive fallback case is somewhat unpleasant, as PSA comments. My thought is that if the messages were specifically annotated in the body of the message, this would not be an issue: message bodyCorrection: But soft, what light through yonder window breaks?/body replace id='bad1' prefix='Correction: ' xmlns='...'/ /message Although this needs some thought to handle XHTML-IM, and it may prove impossible - though we've done worse things with FLOTs before. Overall, although I'm relatively happy with the XEP as-is, I think it needs more thought in terms of the more esoteric uses it might receive before advancement.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Aug 31, 2012, at 4:09 AM, Dave Cridland d...@cridland.net wrote: I'm still concerned that replacing any but the author's last message is likely to cause problems with accurately presenting the data. I generally think it best to separately display the corrected text (as a new message) in the presentation stream with annotations that it is a replacement for a previously presented text, whether it's the last message or not. This not only for security reasons, but to maintain conversational flow. -- Kurt
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/31/12 6:27 AM, Kurt Zeilenga wrote: On Aug 31, 2012, at 4:09 AM, Dave Cridland d...@cridland.net wrote: I'm still concerned that replacing any but the author's last message is likely to cause problems with accurately presenting the data. I generally think it best to separately display the corrected text (as a new message) in the presentation stream with annotations that it is a replacement for a previously presented text, whether it's the last message or not. This not only for security reasons, but to maintain conversational flow. That seems like a reasonable user interface (not automagically changing the original). Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBA60sACgkQNL8k5A2w/vy37QCfdUijfj7AACvYi0+Ff//s2v3k tOUAn2yjq+KOnS5s8EBLB4WC5ODSs285 =rxDI -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On 2012-07-31 22:52, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL:http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Was there any conclusion on this last call? Thanks /Gunnar
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Thu, Aug 30, 2012 at 8:02 PM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-07-31 22:52, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL:http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Was there any conclusion on this last call? I'm going to address the assorted comments, and then Council'll see whether another Last Call is justified. /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
In fact, I'd argue that this spec is a technical solution to a social problem I note, after drafting many more acerbic replies, that this is consistent with all specs. Messaging is a social problem. /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/15/12 8:28 AM, Kevin Smith wrote: In fact, I'd argue that this spec is a technical solution to a social problem I note, after drafting many more acerbic replies, that this is consistent with all specs. Messaging is a social problem. Most people handle slight mistakes in messages quite gracefully by typing some text in a new message (oops, I meant thought, not though). We've all seen it and done it. Why after all this time is it imperative that we give folks the ability to make such corrections by changing the last message instead of explaining the error in a new message? Realistically, so few clients will support this extension that it'll be as if it doesn't exist. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlArtiQACgkQNL8k5A2w/vwLtwCgydLS3lI/zCHwKe90mgeGclvq Lz8AoPSh8vuID7HZ/cqKQ9R2Y9gA923h =pLRh -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Aug 15, 2012, at 7:28 AM, Kevin Smith ke...@kismith.co.uk wrote: In fact, I'd argue that this spec is a technical solution to a social problem I note, after drafting many more acerbic replies, that this is consistent with all specs. Messaging is a social problem. Yes. My concern is how effective our solution is in solving the social problem, messaging between humans. XMPP IM (without 308) has demonstrated itself to be an effective solution. XMPP IM with 308 implemented universally would also likely an effective solution. It seems to me that XMPP IM, with some clients supporting 308 and some not, will be less effective than either of the above solutions, simply because key information (this message is a correction) is lost on fallback in clients not supporting 308. I do suspect that a social solution to this issue will be found. I don't object to progressing 308 to Draft. -- Kurt
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/15/12 8:51 AM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 3:45 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 8/15/12 8:28 AM, Kevin Smith wrote: In fact, I'd argue that this spec is a technical solution to a social problem I note, after drafting many more acerbic replies, that this is consistent with all specs. Messaging is a social problem. Most people handle slight mistakes in messages quite gracefully by typing some text in a new message (oops, I meant thought, not though). We've all seen it and done it. Why after all this time is it imperative that we give folks the ability to make such corrections by changing the last message instead of explaining the error in a new message? I would have hoped that the wrong-headedness of We shouldn't change things, we can make do with what we have would be self-evident, but it doesn't seem so. Now, if you'll excuse me, I've got a chisel and some slate that need interfacing. Sorry, stone tools are too advanced for me. :P /psa -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAruF4ACgkQNL8k5A2w/vypWACgtwXsECD6dXcKLGw3NuzCh0iC 9ikAn0v0TBTRjR87euF8NeMemXiPZSFh =+Ude -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 15, 2012, at 08:54, Kurt Zeilenga wrote: On Aug 15, 2012, at 7:28 AM, Kevin Smith ke...@kismith.co.uk wrote: In fact, I'd argue that this spec is a technical solution to a social problem I note, after drafting many more acerbic replies, that this is consistent with all specs. Messaging is a social problem. Yes. My concern is how effective our solution is in solving the social problem, messaging between humans. XMPP IM (without 308) has demonstrated itself to be an effective solution. XMPP IM with 308 implemented universally would also likely an effective solution. It seems to me that XMPP IM, with some clients supporting 308 and some not, will be less effective than either of the above solutions, simply because key information (this message is a correction) is lost on fallback in clients not supporting 308. I do not completely agree that key information will (always) be lost. It does indeed matter significantly how a client renders corrected text: 1) delete of old, overwrite with new (lost information) 2) strikethrough of old, place new immediately next to it (no lost information) And there's a couple of other ways I can see this going... - - mm Matthew A. Miller http://goo.gl/LK55L -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJQK7meAAoJEJq6Ou0cgrSPlGgH/idyONFgZueMp0vHgieGX2jx uaQ6JwlBrJ/QCSgf7IjOWDBSENxJhg2Th72TI9RjmBCJv9842qXHmaKu2cf5nCNb cle6rThuvqCeI0BTgsg8d9hgj2jdA65Tn4ljnyrL05JQlPMeg8wSaHIK+kmh7Z+2 DViszYVZXvJPLgNC98ZpttvJZsL9GXYS+zc5UO1JC0Ehgdr3/WdPMai8J8KVpnGl pqWHHVTUieZc+jv25WgnIa89V+6YlCQlAj8bl4/5Cs6r/Dzx3uB19T+twFW2b/oh gDnj1xlk0coQ6FUxeTSruPaCDxC90vdxH1Te2cCyktdEU9KhXnR2/Pu0aLeyfTA= =5hoj -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/15/12 9:16 AM, Kevin Smith wrote: On Wed, Aug 15, 2012 at 4:02 PM, Peter Saint-Andre stpe...@stpeter.im wrote: In a chatroom I frequent, someone just used last message correction, which my client does not support... [08:18:52] user i though the old IPs work again? [08:18:56] user i thought the old IPs work again? That user's client gave them a warning before sending the correction to the MUC, mind, saying that some users in the MUC didn't support message correction and would see it as a duplicate message. I perceived it as retyping the entire message to make the correction, which I suppose was reasonable. However, whether the retyped message makes sense depends on how much was changed. This would have been strange... [08:18:52] user i though the old IPs work again? [08:18:56] user did I hear correctly that the old IPs work again? or even... [08:18:52] user i though the old IPs work again? [08:18:56] user Peter, you're a loser I do suspect that a social solution to this issue will be found. Socially speaking, I think most corrections are slight. But potentially they could be significant and subject to abuse. It certainly introduces ways for people to do odd things, but in terms of abuse I'm not convinced. That is - 308 is already clear (I think, and I can make it clearer) that clients will need to let the user know that the message has been modified, Actually it says: A client SHOULD alert the user that the displayed message has been edited since it was originally sent. Isn't that a UI thing that doesn't deserve or require a SHOULD? ;-) And does the alert/warning apply to the sending user, the receiving users, or both? so there isn't much of a window for tricking people here (and I think a good UI is to expose the original message as well, although simply saying that the message has been edited is probably sufficient). If there are real attacks here, rather than just a feeling that it's a bit odd and unexpected, we should enumerate them and address them. So far it seems odd and unexpected, and open to pranks more than serious attacks. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlArwF0ACgkQNL8k5A2w/vxpeQCgwAbTkZcYa7MyBAqnOVX23f1b +YoAoOwoHfrhLr6L8tnVje+aDA3xu3ze =5HeO -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
I think someone else also suggested this: I would rename the title from Last Message Correction to Message Correction and also eliminate last from the rest of the text, of the last sent message - of a sent message the most recently sent message - a sent message I will suggest to the Jitsi and buddycloud developers to implement XEP-0308. Cheers, Andreas
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 1:06 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: The spec originally allowed previous non-last correction, and the community cried foul I found a thread that occurred during the initial consideration of the XEP (when it was proposed), starting at: http://mail.jabber.org/pipermail/standards/2011-November/025394.html I noticed that the original title did say Last. I see Ben Langfeld arguing that it shouldn't be restricted to last. I see Dave Cridland being mildly terrified about allowing change to any previous message. And your response. Not much crying. Was there some other thread? Ok, perhaps it's just illustrates the need to be very plainly clear within Security Considerations -- about the privacy/security implications of permitting message correction, and to mention that the UI needs to be very plainly clear that message correction is going on. In fact, message correction doesn't have to defacto replace the old stanza, but display it as an addendum (with a very clear EDITED tag or icon).Discussion forums, Facebook, etc, allowing editing -- they often to give you access to old versions of the text (revision history accessible by end user). And the edited version can be color coded out. Implementers are smart enough to be creative here, but we don't need to include such implementation detail. So I'd say, just enhance the Security Considerations to satisfy the terrified people -- obvious stuff to make sure implementers avoid abuse. We know we don't want it to be 'abused' for general-purpose messaging, and the pressure for accountability will ensure that implementers do it properly, if implementers choose to permit it during general-purpose messaging. Also, make sure that the protocol and spec is written as such that multi-message correction doesn't screw up with 1-message orrection. As I've learned with 0301 (har har) there's also the temptation to include the kitchen sink (e.g. disco for # of messages allow to correct, server disco for permissions, disco for time limit of message correction, etc) but I'd leave that out today -- and theoretically that can be dealt with separately someday (e.g. separate Message Correction Extensions XEP), provided the protocol is written generically enough today to be acceptable without that now, while being co-operative with future disco extensions. Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/12 3:03 PM, Andreas Kuckartz wrote: Kurt Zeilenga: From a user perspective, often what I want to correct isn't the last stanza I sent. I support that argument. Several Social Networking Services provide similar features and I expect XMPP to also support that. rantLook, folks, if we want the ability to reach back and edit everything under the sun, then by all means let's define that using pubsub under something like XEP-0277. IM, by contrast, is an ever-flowing stream and sometimes you make mistakes when typing such messages (as people do in email messages to lists like this one). Do you have the ability to edit every email message you've ever sent? No, so just get over it./rant Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqdAYACgkQNL8k5A2w/vy1bACggPxlTVpMwyUnQVvojBO6DOfO d4cAoJnZ+wBlRfP9gpUerv0DiLCf0PEd =gHS2 -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/12 9:51 AM, Peter Saint-Andre wrote: On 8/13/12 3:03 PM, Andreas Kuckartz wrote: Kurt Zeilenga: From a user perspective, often what I want to correct isn't the last stanza I sent. I support that argument. Several Social Networking Services provide similar features and I expect XMPP to also support that. rantLook, folks, if we want the ability to reach back and edit everything under the sun, then by all means let's define that using pubsub under something like XEP-0277. IM, by contrast, is an ever-flowing stream and sometimes you make mistakes when typing such messages (as people do in email messages to lists like this one). Do you have the ability to edit every email message you've ever sent? No, so just get over it./rant In fact, I'd argue that this spec is a technical solution to a social problem, and thus is wrongheaded. It's easy enough to send a new message correcting the old one (e.g., sorry, I meant to say Y instead of X or s/X/Y/). People do that all the time. Magically and invisibly changing a message after the fact strikes me as a really bad idea. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqdXEACgkQNL8k5A2w/vxNAgCguIGgTZYYLeXFm/TkGPPkonQM YFcAniN5KfWX2x9uY3jbasHs8+WDW9pT =xURZ -END PGP SIGNATURE-
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
I think XEP 308 is actually going to lead to a lot of user confusion. The problem is that corrections are actually counter to the chat or conversational model. In the real world (i.e., face-to-face conversation), there's no rewind button. If you make an error, you have to say something like: Pardon me, I meant no when I said yes. And in today's XMPP IM use, we have shorthands for this, like, I can send: s/yes/no/ to correct a previous yes. The problem I have with XEP 308, is that that the fact that's a correction is a correction will be lost upon users which don't use clients which support XEP 308. Illustration: you: Question? me: yes then as you send Really?, I send correction from yes to no. If your client doesn't support corrections, you see: you: Really? me: no and I see: you: Question? me: no you: Really? to which I now respond, yes. So we've conclude our discussion, but without understanding that I corrected my first answer to your first question. Now if XEP 308 were only sent when the client new the receiving client(s) supported XEP 308, then we'd assured to that at some indication of correction was presented to the reader. But 308 doesn't require sending clients do discovery and not offer correction when the receiving clients(s) don't support XEP 308. And even if 308 did mandate such, many client developers would likely ignore the requirement. But a mandate would be a good start. Use in MUC will always be problematic, me thinks. -- Kurt
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Aug 14, 2012, at 8:57 AM, Peter Saint-Andre stpe...@stpeter.im wrote: In fact, I'd argue that this spec is a technical solution to a social problem, and thus is wrongheaded. It's easy enough to send a new message correcting the old one (e.g., sorry, I meant to say Y instead of X or s/X/Y/). People do that all the time. Magically and invisibly changing a message after the fact strikes me as a really bad idea. The more I think about it, the more I think I that this XEP is a bad idea. Basically, the kind of user confusion I illustrated in by prior post can really only be addressed if this extension is mandatory to implement (for all clients). And, I don't think extensions should be mandatory to implement. They should be truly optional. -- Kurt
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On 2012-08-14 20:09, Kurt Zeilenga wrote: On Aug 14, 2012, at 8:57 AM, Peter Saint-Andre stpe...@stpeter.im wrote: In fact, I'd argue that this spec is a technical solution to a social problem, and thus is wrongheaded. It's easy enough to send a new message correcting the old one (e.g., sorry, I meant to say Y instead of X or s/X/Y/). People do that all the time. Magically and invisibly changing a message after the fact strikes me as a really bad idea. The more I think about it, the more I think I that this XEP is a bad idea. Basically, the kind of user confusion I illustrated in by prior post can really only be addressed if this extension is mandatory to implement (for all clients). And, I don't think extensions should be mandatory to implement. They should be truly optional. -- Kurt I think this extension gets rid of one annoying characteristic of XMPP IM. - The message borderline being an artificial borderline for corrections. If an implementer really thinks it is risky, and that it can cause undetected modifications, then the implementation can require from the user that there is no text in the current message before the last message may be entered for correction. So, if you have started to type the new current message, you need to erase it before entering the previous message for correcting it. That will make corrections appear with care and only when it is felt efficient by the typing user. There is no difference in the protocol for this feature, so it does not need to influence the specification. I hope that the current discussion, with some voices saying that correction of last message should not be allowed, will not influence the acceptance of XEP-0308. /Gunnar
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Tue, Aug 14, 2012 at 1:44 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: I think XEP 308 is actually going to lead to a lot of user confusion. The problem is that corrections are actually counter to the chat or conversational model. In the real world (i.e., face-to-face conversation), there's no rewind button. If you make an error, you have to say something like: Pardon me, I meant no when I said yes. And in today's XMPP IM use, we have shorthands for this, like, I can send: s/yes/no/ to correct a previous yes. The problem I have with XEP 308, is that that the fact that's a correction is a correction will be lost upon users which don't use clients which support XEP 308. Illustration: you: Question? me: yes then as you send Really?, I send correction from yes to no. If your client doesn't support corrections, you see: you: Really? me: no and I see: you: Question? me: no you: Really? to which I now respond, yes. So we've conclude our discussion, but without understanding that I corrected my first answer to your first question. Now if XEP 308 were only sent when the client new the receiving client(s) supported XEP 308, then we'd assured to that at some indication of correction was presented to the reader. But 308 doesn't require sending clients do discovery and not offer correction when the receiving clients(s) don't support XEP 308. And even if 308 did mandate such, many client developers would likely ignore the requirement. But a mandate would be a good start. Use in MUC will always be problematic, me thinks. Kurt brings up a good case for making 0308 disco a requirement, though several considerations first, arguing towards 0308 from another angle: 1. Kurt's scenario can also occur during traditional corrections no - oops, yes, when there's a high network latency for delivery. (causing message-crossed-each-other scenarios) In such a situation, the message history order on the recipient is not necessarily the same as the message history order on the sender. This problem is widespread when network latencies become very high (and when message delivery receipts timestamps are not used to reorder the messages to sync message history order on both sender and recipient). It's a common problem on other networks, such as SMS. It's already caused huge numbers of misunderstandings, when the word yes references a different message at the recipient end than sender end. Also, overloaded servers, including for MUC, inject latency sufficient enough to cause message-crossed-each-other scenarios too. 2. In such scenarios (overloading) user behaviour has already adapted to be cautious of sending one-word responses to rapid questions. Users already adapt to behavior. 3. The advantages outweigh the disadvantages. Present instant messaging has its own existing social problems, and general purpose instant messaging (or even texting) is already a (mostly great) technical solution to many of them already. Messaging is an artificial invented solution that has its own excellent pros and cons. I'll compare the social problems with the social advantages in a balanced way: -- e.g. messaging social problems include multitasking distractions, wrong-window messaging, lack of emotion transmission, message boundaries preventing natural conversation afforded via alternate means (e.g. audio, video, real time text), the average increase of information overload for the average human, etc. Instant messaging is already an artifical solution to life in society. -- e.g. messaging social advantages include catering to fastest human method of input: reading - humans can speedread hundreds of WPM (usually faster than listening), ability to re-read text easily (you can't replay a live telephone conversation easily), asynchronousness of message-by-message makes it easier to multitask multiple conversations at the same time discreetly, the quietness of text based communications keeping work environments less noisy, the ease of logging text-based conversations, etc. Given such a perspective (chat is just a technical solution to a social problem), I believe it's just merely status quo feelings that is providing 0308 resistance. Thanks Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 8:00 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: On 2012-07-31 22:52, XMPP Extensions Editor wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL: http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, it is a quite important usability improvement. 2. Does the specification solve the problem stated in the introduction and requirements? Yes 3. Do you plan to implement this specification in your code? If not, why not? Yes 4. Do you have any security concerns related to this specification? No other than other last call comments have expressed. 5. Is the specification accurate and clearly written? Yes. However. It does not explicitly state what element of the message/ that is replaced. It is clear from the examples that body/ is what the author thought of. It mentions some items that shall not be replaced, but apart from that it seems to be open for replacing anything that has been delivered in a message/. That is both an opportunity and a risk. It is an opportunity for other extensions adding elements to the message/ to consider if they want to utilize XEP-0308 for replacing the contents. ( this could possibly be utilized by XEP-0301 instead of specifying its own way of doing replacements of real-time text, but it requires some more specific rules in XEP-0301 about how to apply it in that environment.) It is a risk that if other extensions adding new message elements do not specify if XEP-0308 can replace the contents of the new element. interoperability problems may appear, with a sender replacing an element that the recipient is not made for replacing. This could be moderated by inserting a sentence in the Business rules: Extensions specifying message/ contents should specify if and how it can be replaced by the XEP-0308 'replace'. Thanks for the feedback. The XEP says that a correction is a replacement for the entire stanza. I'll make sure I add text to make this clearer. /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. -- Kurt On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL: http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
It may be that I'm reading a restriction into the spec that wasn't intended by the authors. If so, then maybe a simple clarification is needed (like drop the Last from the title). On Aug 13, 2012, at 9:15 AM, Kurt Zeilenga kurt.zeile...@isode.com wrote: Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. -- Kurt On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL: http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. The spec originally allowed previous non-last correction, and the community cried foul so I removed it. I can add it back in if the community has now changed its mind! /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Aug 13, 2012, at 9:22 AM, Kevin Smith ke...@kismith.co.uk wrote: On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: Why is this restriction restricted to editing the last stanza sent? Is this due to presentation issues? If so, I think the clients are going to have to deal with them no matter what restrictions we place on senders... because a sender cannot control other senders. In short, receiving clients have to appropriately deal with replacements for non-last stanzas. And as clients are certainly going to have to deal with this MUC, seems no big deal for them to deal with it general. Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. The spec originally allowed previous non-last correction, and the community cried foul I found a thread that occurred during the initial consideration of the XEP (when it was proposed), starting at: http://mail.jabber.org/pipermail/standards/2011-November/025394.html I noticed that the original title did say Last. I see Ben Langfeld arguing that it shouldn't be restricted to last. I see Dave Cridland being mildly terrified about allowing change to any previous message. And your response. Not much crying. Was there some other thread? Anyways, here's my argument. From a user perspective, often what I want to correct isn't the last stanza I sent. And when I receive corrections, I rather my client not replace the original message in the presentation stream. I rather the client simply add the replacement message to the message stream (as it would any other new message) and provide me some indication that it's a replacement for another message and what that message is. And, I note, if a client receives a correction for a stanza it doesn't have, it still make use of the replace/ element, by using it to trigger that the newly presented content is a replacement for non-presented content. Now, I can see some clients would replace the content in the presented stream it the replaced message last received message (before the replacement)... but that's an implementation detail. No matter what what, clients need to be able to deal replaces coming in for something other than the last received message, like treating it as if the replace/ element was absent. From a protocol perspective, I see little reason to have the last sent restriction as clients have to deal with replace referencing non-last (possibly not previously seen) messages. so I removed it. I can add it back in if the community has now changed its mind! /K
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 12:22 PM, Kevin Smith ke...@kismith.co.uk wrote: Anyways, if there's no particularly strong reason to have the last message restriction, I think it should be removed. The spec originally allowed previous non-last correction, and the community cried foul so I removed it. I can add it back in if the community has now changed its mind! It's useful for real-time text situations -- it goes hand-in-hand with transcription/caption corrections, when using instant messaging as a conduit of transmitting transcriptions, and needing to retroactively fix transcription errors, or manually editing voice-recognition errors. It is a niche case, but certainly a legitimate one. However, please bring the original people who cried foul, back into this discussion. I'd like to see if they now agree with the use cases. The only thing is that you need to either: 1. Define the bounds of corrections (e.g. X messages ago) --or-- 2. Define what to do if 'id' points to a non-existent message (i.e. refers to a message that no longer exists on recipient's client -- this can happen in multiple login situations, reconnect situations, MUC situations with new participants joining after a message is already sent) For simplicity you may want to go for scenario (2) for now. Treat unrecognized id's as a new stanza. The only problem is that we don't really know how many messages ago it was -- for example, we don't know if it was 2 or 3 messages ago -- or 6 messages ago. So corrections done in a random-access manner, and out-of-order transmission, will show potential jumbling of order. But that's acceptable, and potentially a client implementation could automatically sort the 'id' parameter alphabetically, since the 'id' is often always incrementing (either numerically or alphabetically), though that's not always reliable. Thanks, Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 3:00 AM, Gunnar Hellström gunnar.hellst...@omnitor.se wrote: That is both an opportunity and a risk. It is an opportunity for other extensions adding elements to the message/ to consider if they want to utilize XEP-0308 for replacing the contents. ( this could possibly be utilized by XEP-0301 instead of specifying its own way of doing replacements of real-time text, but it requires some more specific rules in XEP-0301 about how to apply it in that environment.) In addition, it would likely be non-backwards compatible in a graceful degrade manner, e.g. MUC A mixed MUC with all kinds of participants simultaneously: - Clients that don't support XEP-0301 - Clients that support XEP-0301 but not XEP-0308 - Clients that support XEP-0308 but not XEP-0301 - Clients that support both XEP-0301 and XEP-0308 The way both me and Kevin has currently specified, ensures that both 0301 and 0308 will work and interop fine in mixed-MUC situations. Therefore, I like the way XEP-0308 is specified: full stanza replacement only, and keeping 0301 retroactive editing separate of 0308 retroactive. It's far simpler and far more forgiving than trying to specify ways of replacing specific rtt/ elements. Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Am 13.08.2012 22:05, schrieb Mark Rejhon: In addition, it would likely be non-backwards compatible in a graceful degrade manner, e.g. MUC [...] The way both me and Kevin has currently specified, ensures that both 0301 and 0308 will work and interop fine in mixed-MUC situations. Frankly, I would recommend MUCs to filter out any RTT stuff. Unless they want to take part in amplification attacks of course. But that's not for the 0308 LC, is a problem that 0045 has in general and only shows when dealing with heavy traffic.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 4:23 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.08.2012 22:05, schrieb Mark Rejhon: In addition, it would likely be non-backwards compatible in a graceful degrade manner, e.g. MUC [...] The way both me and Kevin has currently specified, ensures that both 0301 and 0308 will work and interop fine in mixed-MUC situations. Frankly, I would recommend MUCs to filter out any RTT stuff. Unless they want to take part in amplification attacks of course. But that's not for the 0308 LC, is a problem that 0045 has in general and only shows when dealing with heavy traffic. Not an option. Some demos of Next Generation 911 uses MUC combined with XEP-0301 Better option: Server control of enabling/disabling 0301 on a per-chat-room basis Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Am 13.08.2012 19:06, schrieb Kurt Zeilenga: I rather the client simply add the replacement message to the message stream (as it would any other new message) and provide me some indication that it's a replacement for another message and what that message is. I like that notion. It doesn't change the 'oh, I meant to say...' model that is (probably) widely used today, but still gives a hint which message is affected.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Mon, Aug 13, 2012 at 4:38 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.08.2012 19:06, schrieb Kurt Zeilenga: I rather the client simply add the replacement message to the message stream (as it would any other new message) and provide me some indication that it's a replacement for another message and what that message is. I like that notion. It doesn't change the 'oh, I meant to say...' model that is (probably) widely used today, but still gives a hint which message is affected. Agreed -- I suggest Kevin make a mention suggesting such behavior. Note, replace/ has no better/worse potential for amplification attacks than XEP-0301 does (assuming you follow reasonable rules, such as automatically transmit traffic when receiving traffic, etc -- neither of which is required for 0301 or 0308)
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Kurt Zeilenga: From a user perspective, often what I want to correct isn't the last stanza I sent. I support that argument. Several Social Networking Services provide similar features and I expect XMPP to also support that. Cheers, Andreas
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Thanks Kurt. On Fri, Aug 3, 2012 at 6:24 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. Edit suggestion: s/marking/indicating/ Don't feel strongly. URL: http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. In Section 2, the text If a server implements message correction ought to be If a client implements message correction or possibly If an XMPP entity implements message correction. Thanks. I note that the discovery example shows a query against a full jid, which of course requires knowledge of the full jid to perform. There may be use cases where the full jid is not known. It may be appropriate to note that decloaking (XEP 276) can be used here. Will mention decloaking, ta. There's no discussion of whether or not this extension can be used in MUC rooms, and if so, what if any discovery is required. Will add, ta. I'd argue that, given the nature of this extension, there's little need for any discovery. [[Because corrections are likely to be infrequent and there's fallback built into the protocol.]] Regardless of whether the expectation is or is not that clients send corrections without performing discovery first, the expectation should be stated. I think the expectation is that it's OK to send corrections without support being known (MUC etc.), as the body itself acts as a correction even without support and no extra stanzas are involved (you're going to be sending the correction one way or the other anyway), but that it'd be smart to tell the sending user that support isn't know. I'll add some text, ta. I thought a bit about correcting messages with multiple body elements, or various elements (e.g., xhtml/), and I think the specification is reasonably clear already that the replacement stanza is a complete replacement of the referenced stanza. But it still might worth being even more clear, adding to the end of 3: The payload of the original message is completely replaced by the payload of the replacement message payload. Will do, ta. In section 4, I found To deal with multiple payloads, the sender MUST re-send the entire stanza with only the id and the corrections changed to be bit confusing as there are other changes to the stanza to be made, in particular the addition of the replace/ element. Some rewording might in order here. Will mangle it a bit, ta. The specification is not clear as whether a corrected message can be corrected. I suggest the specification not, without very good reason, limit itself to a single edit. It sometimes takes me multiple edits to get a message right. I suggest the XEP state whether or not multiple corrections are allowed, and if allowed, make sure the re-send text is appropriately worded and an example provided. Multiple corrections are fine, but I should make this explicit, ta. In the security consideration section, I think the 'warn' in The replacement message could have an entirely different meaning from the original message, so clients will need to warn users that the displayed message has been edited is a bit too strong. I suggest: The replacement message could have an entirely different meaning from the original message. The receiving client SHOULD indicate whether a stanza has been replaced. It is also suggested that the receiving client provide access to the original message. I don't feel all that strongly one way or the other, will change. There are certain sorts of replacements that I think should be precluded or, at least, cause warnings. For instance, if the original message was digitally signed and the replacement not, it would be appropriate I think to warn the reader. I would like to see the digital signed issue specifically mentioned in the security consideration section of this XEP. Additionally, any XEP providing for digital signatures should cover this. I'll add some text for this. Also, it also may be appropriate to limit what portions of the original payload can be altered. In particular, I believe it generally inappropriate for the original and replacement message to have different XEP 258 labels. This is because different labels implies different authorizations, and this implies that one might receive one or the other of the messages, and this is somewhat problematic in certain security domains. I might be appropriate to say something like: The XEP 258 securitylabel/ element SHOULD NOT be edited. It might be appropriate to add a note to XEP 258 as well here. I'll add a note saying that labels shouldn't be replaced, although I think this
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Fri, 10 Aug 2012, Kevin Smith wrote: There's no discussion of whether or not this extension can be used in MUC rooms, and if so, what if any discovery is required. Will add, ta. I'd argue that, given the nature of this extension, there's little need for any discovery. [[Because corrections are likely to be infrequent and there's fallback built into the protocol.]] Regardless of whether the expectation is or is not that clients send corrections without performing discovery first, the expectation should be stated. I think the expectation is that it's OK to send corrections without support being known (MUC etc.), as the body itself acts as a correction even without support and no extra stanzas are involved (you're going to be sending the correction one way or the other anyway), but that it'd be smart to tell the sending user that support isn't know. I'll add some text, ta. A MUC service might rewrite the id attribute, see http://xmpp.org/extensions/xep-0045.html#message Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122) I bet some services do this... making the id at the recipient unpredictable.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Aug 10, 2012, at 4:56 AM, Philipp Hancke fi...@goodadvice.pages.de wrote: On Fri, 10 Aug 2012, Kevin Smith wrote: There's no discussion of whether or not this extension can be used in MUC rooms, and if so, what if any discovery is required. Will add, ta. I'd argue that, given the nature of this extension, there's little need for any discovery. [[Because corrections are likely to be infrequent and there's fallback built into the protocol.]] Regardless of whether the expectation is or is not that clients send corrections without performing discovery first, the expectation should be stated. I think the expectation is that it's OK to send corrections without support being known (MUC etc.), as the body itself acts as a correction even without support and no extra stanzas are involved (you're going to be sending the correction one way or the other anyway), but that it'd be smart to tell the sending user that support isn't know. I'll add some text, ta. A MUC service might rewrite the id attribute, see http://xmpp.org/extensions/xep-0045.html#message Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122) I bet some services do this... making the id at the recipient unpredictable. Oh, and maybe I can replace your messages. -- Kurt
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122) I bet some services do this... making the id at the recipient unpredictable. Oh, and maybe I can replace your messages. or rewrite the chat history after I left... even a same-fulljid requirement doesn't help against that (is there one currently?)
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
I think the expectation is that it's OK to send corrections without support being known (MUC etc.), as the body itself acts as a correction even without support and no extra stanzas are involved (you're going to be sending the correction one way or the other anyway), but that it'd be smart to tell the sending user that support isn't know. I'll add some text, ta. I'd note that the same rationale applies to the (silly) muc service replacing the id. No harm, simply works better with services that don't behave like this.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
since I'm halfway through anyway... 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Well, I think sending a message with s/airlock/window/ would be sufficient, but i'm rather old-fashioned :-) 2. Does the specification solve the problem stated in the introduction and requirements? Piggybacking on the id seems like a dirty hack, but for the sake of traffic it's better than adding a new xml element to each message stanza. 3. Do you plan to implement this specification in your code? If not, why not? server-dev, N/A 4. Do you have any security concerns related to this specification? See my other messages. 5. Is the specification accurate and clearly written? I would reorder the business rules in section 4 so that they deal with the topics in a less random order. Proposed order would be 1+4 (dealing with the id on the sender side), 5+6 (dealing with the sender) and 3+4 last (dealing with the receiver). The discovery examples in section 2 use a server jid which seems awkward, probably related to the text at the start of the section. THIS PROTOXEP in the registrar considerations should have probably been replaced by XEP-0308 upon publication.
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Fri, Aug 10, 2012 at 8:56 AM, Kevin Smith ke...@kismith.co.uk wrote: A MUC service might rewrite the id attribute, see http://xmpp.org/extensions/xep-0045.html#message Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in RFC 4122) I bet some services do this... making the id at the recipient unpredictable. We should probably fix MUC on this - I hadn't noticed in the examples what was going on and read the text to mean The id sent to the room may not be the id you specified not Everyone in the room may get a different id - which will break things. So maybe define what happens if the id is not what you expect. This should also cover simultaneous login scenarios: 1. Login starts typing a message and sends it. 2. New participant joins 3. Login starts correcting message. 4. New participant receives a replace for an id that does not exist. On the topic of simultaneous logins, don't forget to cover scenario #2, where full JID is not available: 1. Login starts typing message, sends to MUC. 2. Simultaneous login starts typing message #2, sends to MUC. 3. Login starts doing message correction, it now refers to a message 2 messages ago. (id is valid). So what you need to do, is essentially specify that unrecognized or unhandled 'id' should mean replace should be ignored and the re-transmitted message displayed as a brand new message. Probably the simplest solution. Thanks, Mark Rejhon
Re: [Standards] LAST CALL: XEP-0308 (Last Message Correction)
On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor edi...@xmpp.org wrote: This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. Edit suggestion: s/marking/indicating/ URL: http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. In Section 2, the text If a server implements message correction ought to be If a client implements message correction or possibly If an XMPP entity implements message correction. I note that the discovery example shows a query against a full jid, which of course requires knowledge of the full jid to perform. There may be use cases where the full jid is not known. It may be appropriate to note that decloaking (XEP 276) can be used here. There's no discussion of whether or not this extension can be used in MUC rooms, and if so, what if any discovery is required. I'd argue that, given the nature of this extension, there's little need for any discovery. [[Because corrections are likely to be infrequent and there's fallback built into the protocol.]] Regardless of whether the expectation is or is not that clients send corrections without performing discovery first, the expectation should be stated. I thought a bit about correcting messages with multiple body elements, or various elements (e.g., xhtml/), and I think the specification is reasonably clear already that the replacement stanza is a complete replacement of the referenced stanza. But it still might worth being even more clear, adding to the end of 3: The payload of the original message is completely replaced by the payload of the replacement message payload. In section 4, I found To deal with multiple payloads, the sender MUST re-send the entire stanza with only the id and the corrections changed to be bit confusing as there are other changes to the stanza to be made, in particular the addition of the replace/ element. Some rewording might in order here. The specification is not clear as whether a corrected message can be corrected. I suggest the specification not, without very good reason, limit itself to a single edit. It sometimes takes me multiple edits to get a message right. I suggest the XEP state whether or not multiple corrections are allowed, and if allowed, make sure the re-send text is appropriately worded and an example provided. In the security consideration section, I think the 'warn' in The replacement message could have an entirely different meaning from the original message, so clients will need to warn users that the displayed message has been edited is a bit too strong. I suggest: The replacement message could have an entirely different meaning from the original message. The receiving client SHOULD indicate whether a stanza has been replaced. It is also suggested that the receiving client provide access to the original message. There are certain sorts of replacements that I think should be precluded or, at least, cause warnings. For instance, if the original message was digitally signed and the replacement not, it would be appropriate I think to warn the reader. I would like to see the digital signed issue specifically mentioned in the security consideration section of this XEP. Additionally, any XEP providing for digital signatures should cover this. Also, it also may be appropriate to limit what portions of the original payload can be altered. In particular, I believe it generally inappropriate for the original and replacement message to have different XEP 258 labels. This is because different labels implies different authorizations, and this implies that one might receive one or the other of the messages, and this is somewhat problematic in certain security domains. I might be appropriate to say something like: The XEP 258 securitylabel/ element SHOULD NOT be edited. It might be appropriate to add a note to XEP 258 as well here. I have to wonder if there's other payload elements which should or should not be changed during correction. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? I believe this specification fills a small gap in the XMPP protocol stack. 2. Does the specification solve the problem stated in the introduction and requirements? Yes. 3. Do you plan to implement this specification in your code? If not, why not? As a server developer, nothing for me to implement here. 4. Do you have any security concerns related to this specification? Yes, see above. 5. Is the specification accurate and clearly written? For the most part, see above. Your feedback is
[Standards] LAST CALL: XEP-0308 (Last Message Correction)
This message constitutes notice of a Last Call for comments on XEP-0308 (Last Message Correction). Abstract: This specification defines a method for marking a message as a correction of the last sent message. URL: http://xmpp.org/extensions/xep-0308.html This Last Call begins today and shall end at the close of business on 2012-08-17. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
