Re: [Standards] Business rules of Last Message Correction
> I don't want to put words in anybody's mouth, but to me it looks like > Kev said it would be better to bump this than to have a second > specification, not that changing this spec needs a bump. "That was my original expectation too, but Kev suggested the bump would be preferable. [...to a second spec.]" There wasn't meant to be an additional implication of the bump being necessary (just that a bump would be preferable to a new spec.) > I must admit I didn't saw this as a possible interpretation of LMC. The > business rules indeed don't say what to do with an LMC that violates the > business rules. It was just the most obvious to me to add it as a new > message. I think this is another point that should be clarified in the > XEP. And if there are any clients that actually delete the message if it > has a violating LMC reference, we might actually need a namespace bump. > Still, I hope this is not the case. The first business rule talks about the ID being required to prevent incorrect replacements being caused by re-routed messages; the implication of this is that it's possible to receive corrections to messages that you never received. (With RMC, older LMC-only clients will see such corrections this way.) So there are two potential responses: present the correction as a new message, or discard it because it's a correction for a message you don't have. Thinking about it now, the first is the more sensible option. But, yes, it's not specified and so should be. And maybe investigate how clients will actually handle this situtation. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
> This wouldn’t be an issue if clients use sufficiently unique IDs. I'm not sure that magically fixes the issue. New RMC clients can and should use unique IDs - and we can mandate that - but the issue here is with older LMC non-RMC-aware clients.So, if those clients expect LMC to only ever be applied to the single recent message (possibly naive, but the XEP explicitly advises against doing older corrections without further negotiation) then upon discovering that the correction's ID does not match the most recent message, it can only assume that it never received the message that was to be corrected. This is true regardless of the uniqueness of the IDs (the ID of the last message and the correction don't match - which they shouldn't, because the correction is for an older message.) > Also funny is by the way the question what counts as "Message" in this > context. If I send a message and my client sends a CSN afterwards (because I > switched to another tab maybe) and then I do a correction, is the CSN (which > comes in its own ) a new message, which should be prohibiting me > from correcting my last actual text message? One would hope (ha!) that implementations handle this in a sensible way; but it's probably worth being more explicit in specifying. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
* Tedd Sterr [2018-06-11 18:31]: > That was my original expectation too, but Kev suggested the bump would be > preferable. I don't want to put words in anybody's mouth, but to me it looks like Kev said it would be better to bump this than to have a second specification, not that changing this spec needs a bump. > The protocol itself functionally supports Recent Message Correction > (RMC) without modification, but without a way to differentiate between > the two, LMC clients may silently drop RMC messages, rather than > blindly append them as new messages. I must admit I didn't saw this as a possible interpretation of LMC. The business rules indeed don't say what to do with an LMC that violates the business rules. It was just the most obvious to me to add it as a new message. I think this is another point that should be clarified in the XEP. And if there are any clients that actually delete the message if it has a violating LMC reference, we might actually need a namespace bump. Still, I hope this is not the case. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
On Montag, 11. Juni 2018 18:29:50 CEST Tedd Sterr wrote: > Upon receiving an RMC message, an LMC client would check whether the ID > matches its last message and see that it doesn't -- the first business rule > suggests that means it is a correction to a message directed to another > resource, and so this client would quietly eat the message (because the > correction is for another resource.) This wouldn’t be an issue if clients use sufficiently unique IDs. Also funny is by the way the question what counts as "Message" in this context. If I send a message and my client sends a CSN afterwards (because I switched to another tab maybe) and then I do a correction, is the CSN (which comes in its own ) a new message, which should be prohibiting me from correcting my last actual text message? kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
> It sounded to me like this would be a new distinct namespace > older-than-previous-message corrections, a namespace bump may be more > contentious in a draft XEP. That was my original expectation too, but Kev suggested the bump would be preferable. > As I see it, the *worst* thing that will happen if we allow > Last-Message-Correction to affect also the last-but-N messages, is: > Clients which implement the LMC spec strictly will display the update as a > new message, instead of as a correction of the old one. I did mention it already, but I'm not sure this is completely true. The protocol itself functionally supports Recent Message Correction (RMC) without modification, but without a way to differentiate between the two, LMC clients may silently drop RMC messages, rather than blindly append them as new messages. Upon receiving an RMC message, an LMC client would check whether the ID matches its last message and see that it doesn't -- the first business rule suggests that means it is a correction to a message directed to another resource, and so this client would quietly eat the message (because the correction is for another resource.) So, assuming I'm understanding that correctly, it needs cleaning up and the bump is necessary to avoid silently dropping messages. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
On 11 Jun 2018, at 15:20, Sam Whited wrote: > > On Mon, Jun 11, 2018, at 09:15, Kevin Smith wrote: >> I’m not sure that’s necessary, given that the current protocol was >> designed to allow exactly this. > > Was it? I was reading this whole conversation in the context of: > >> support for this SHOULD NOT be assumed without further negotiation. Yeah, I meant the protocol rather than the business rules. > which I assumed meant a new namespace that is advertised alongside the > existing one. Right. I think you can simply add another namespace to disco, and not change anything else, and be guaranteed ok. > That being said, I'm not against a namespace bump by any means and now that > you mention it I'm also not sure that one would be necessary, if we can get > away with no new protocol or namespaces I'd be very happy. Right :) /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
* Sam Whited [2018-06-11 16:20]: > I'm also not sure that one would be necessary, if we can get away with > no new protocol or namespaces I'd be very happy. Which is exactly why I asked the (non-rhetorical, seriously intended) question I asked further above in this thread, which nobody seems to have answered yet. As I see it, the *worst* thing that will happen if we allow Last-Message-Correction to affect also the last-but-N messages, is: Clients which implement the LMC spec strictly will display the update as a new message, instead of as a correction of the old one. Also, now might be the right moment in time to remind everybody that relying on a single client's advertised features when sending messages to the user of that client has a bunch of inherent problems, which is why I've spoken out against resource-binding in the past. The specific problems are: - Carbons and MAM-archived messages are delivered to other clients which you potentially haven't checked the disco#info of - Race conditions between you sending and the client going offline / changing availability might get that message re-routed - In a MUC, do you send according to the sub-set or the super-set of all joined users' features? What happens if you can't even discover their features because they are hidden by MSN weirdness? Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
On Mon, Jun 11, 2018, at 09:15, Kevin Smith wrote: > I’m not sure that’s necessary, given that the current protocol was > designed to allow exactly this. Was it? I was reading this whole conversation in the context of: > support for this SHOULD NOT be assumed without further negotiation. which I assumed meant a new namespace that is advertised alongside the existing one. That being said, I'm not against a namespace bump by any means and now that you mention it I'm also not sure that one would be necessary, if we can get away with no new protocol or namespaces I'd be very happy. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
On 11 Jun 2018, at 15:11, Sam Whited wrote: > > On Mon, Jun 11, 2018, at 09:02, Tedd Sterr wrote: >> As long as it doesn't confuse existing implementations, hopefully >> nothing; but I suppose that's what the namespace bump is for. > > It sounded to me like this would be a new distinct namespace > older-than-previous-message corrections, a namespace bump may be more > contentious in a draft XEP. I’m not sure that’s necessary, given that the current protocol was designed to allow exactly this. (I’m not *entirely* sure that a namespace bump is even needed at the moment, but nor am I sure it isn’t) /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
On Mon, Jun 11, 2018, at 09:02, Tedd Sterr wrote: > As long as it doesn't confuse existing implementations, hopefully > nothing; but I suppose that's what the namespace bump is for. It sounded to me like this would be a new distinct namespace older-than-previous-message corrections, a namespace bump may be more contentious in a draft XEP. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
> What is the worst thing that happens if we just change this Draft? As long as it doesn't confuse existing implementations, hopefully nothing; but I suppose that's what the namespace bump is for. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
> Is that essentially https://xmpp.org/extensions/inbox/message-retraction.html > ? The intent is roughly the same, though this looks to be aimed more at use in MUC, and has additional complexities as a result. I think considering deletion as a correction makes some sense, though I can see how it might feel like over-stuffing. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
* Tedd Sterr [2018-06-11 15:53]: > > I think an ns bump in 308 is better than a duplicate spec, really (unless > > there’s something I’m missing). > > I'm not strongly for a new spec. What is the worst thing that happens if we just change this Draft? Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
> I think an ns bump in 308 is better than a duplicate spec, really (unless > there’s something I’m missing). I'm not strongly for a new spec., though I thought it might be more appropriate in this case given the aversion to changing Drafts and that it's already well implemented; also avoiding possible old-0048/new-0048 type issues. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
On 11 Jun 2018, at 13:52, Tedd Sterr wrote: > and add deletion too (functionally, replacing the message with "This message > was deleted.", but semantically different from literally replacing the > message with that text.) Is that essentially https://xmpp.org/extensions/inbox/message-retraction.html ? /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
On 11 Jun 2018, at 13:52, Tedd Sterr wrote: > > I have considered this issue previously and concluded that, while there > appears to be no technical reason to disallow correcting older messages, > (some) current implementations only support correction of the last message > (in line with this limitation.) > > Maybe Kev can shed some light on why this limitation was added (?) There was heated discussion back at the time, most of which I can’t remember. I think we’re in a different place now, with correction from different clients and the suchlike also being likely where it wasn’t before, so I think updating 308 makes sense. > As the XEP is in Draft and has been widely implemented, it's probably not a > good idea to just remove it from the XEP; as a result of: > > "The 'id' attribute is included on the replace to prevent situations where > > messages being routed to a different resource than the intended cause > > incorrect replacements." > a receiving client would assume the message id that it can't find must have > gone to a different resource and so will ignore the correction. > > I think a fix would preferably have a new namespace, and so it's probably > best to just create "(Recent) Message Correction" as a new XEP, even though > it would be near identical to 0308. And I'd take the opportunity to tighten > the business rules and add deletion too (functionally, replacing the message > with "This message was deleted.", but semantically different from literally > replacing the message with that text.) I think an ns bump in 308 is better than a duplicate spec, really (unless there’s something I’m missing). /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
I have considered this issue previously and concluded that, while there appears to be no technical reason to disallow correcting older messages, (some) current implementations only support correction of the last message (in line with this limitation.) Maybe Kev can shed some light on why this limitation was added (?) As the XEP is in Draft and has been widely implemented, it's probably not a good idea to just remove it from the XEP; as a result of: > "The 'id' attribute is included on the replace to prevent situations where > messages being routed to a different resource than the intended cause > incorrect replacements." a receiving client would assume the message id that it can't find must have gone to a different resource and so will ignore the correction. I think a fix would preferably have a new namespace, and so it's probably best to just create "(Recent) Message Correction" as a new XEP, even though it would be near identical to 0308. And I'd take the opportunity to tighten the business rules and add deletion too (functionally, replacing the message with "This message was deleted.", but semantically different from literally replacing the message with that text.) I don't mind writing this up, if there are no objections (?) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
пн, 11 июн. 2018 г. в 14:21, Georg Lukas : > The XEP requires the sending client to generate IDs: > > | Clients MUST send ids on messages if they allow the user to correct > | messages. > > I wish it would require *unique* IDs, but that's what we've got, and a > reasonable client will use unique IDs anyway. I remember coming upon some client that was using autoincrementing integers for message IDs, resetting it on each restart. Can't remember what client it was though. However, this experience has led me to formulate a principle that server should not trust clients IDs and must reassign them server ID. Eventually, that developed into our method of reliable message delivery. But that's a story for another time. > I think there is a compelling reason to allow correcting more than just > the last message - imagine typing multiple lines in a row, and only then > reading what you sent, to realize a typo / incorrectness. The border here is not a technical limitation, but a user experience. Do I want someone to alter or delete message history days after conversation happened? For me, definitely no, I like to keep my message history and not content with someone editing it. One way to address it is to show the history of editing for each message, but it taxes clients to be able to show that consistently. Also, while it is technically possible to keep all versions of existing messages, existing message archive doesn't suit for this task and programming it would require some yet another abnormal ways to use archive - like storing read receipts there with an empty body. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
* Ненахов Андрей [2018-06-11 11:05]: > The only technical reason for doing only last message correction is a > possible absence of unique id in sent message. The XEP requires the sending client to generate IDs: | Clients MUST send ids on messages if they allow the user to correct | messages. I wish it would require *unique* IDs, but that's what we've got, and a reasonable client will use unique IDs anyway. > Proprietary services like Telegram, for example, set arbitrary > business rules that only messages in the last 48 hours can be > retracted/edited. I think such business rules are hard to enforce in > federated service, I think there is a compelling reason to allow correcting more than just the last message - imagine typing multiple lines in a row, and only then reading what you sent, to realize a typo / incorrectness. > Maybe It's better not to try doing things you can't do well. If the worst thing that can happen is a "duplication" of the message, where the receiver can see both the original and the correction, I think it makes sense to try. I'd prefer to have had a business rule defining an arbitrarily set time limit like in Telegram (48h) or a smaller one (2h?) instead of the current strict last-message-only approach; but on the other hand, the XEP does not forbid changing older messages, it just makes the interop inconsistent, which I'm used to live with from other XEPs. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
> I really dislike that part of the XEP, because you can not rely on > anything here. My client will allow modifying messages older than the > last one (there is really no *technical* need for this restriction), and > you can't prevent abuse of this feature anyway. The only technical reason for doing only last message correction is a possible absence of unique id in sent message. Not having unique id is wrong so if someone wants to permit changes or retraction of own messages, it's a matter of the choice whether to do it or not. Proprietary services like Telegram, for example, set arbitrary business rules that only messages in the last 48 hours can be retracted/edited. I think such business rules are hard to enforce in federated service, and that poses a question if such functionality should be permitted at all. Maybe It's better not to try doing things you can't do well. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Business rules of Last Message Correction
* Klaus Herberth [2018-06-11 10:49]: > The XEP just says: "While it is possible to use this protocol to > correct messages older than the most recent received from a full JID, > such use is out of scope for this document and support for this SHOULD > NOT be assumed without further negotiation.", I really dislike that part of the XEP, because you can not rely on anything here. My client will allow modifying messages older than the last one (there is really no *technical* need for this restriction), and you can't prevent abuse of this feature anyway. > but what should I do with such a message? > Drop it? Show it as new message? If you can not find the referenced @id, or it is not deemed as "correctable", you should just display this message as a new one. This way, the content isn't lost. Georg signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Business rules of Last Message Correction
Hi everyone, I plan to implement XEP-0308 Last Message Correction [1] and I'm asking myself how I should handle corrections of older messages. The XEP just says: "While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation.", but what should I do with such a message? Drop it? Show it as new message? Best regards, Klaus [1] https://xmpp.org/extensions/xep-0308.html signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
