Re: [Standards] Proposed XMPP Extension: Message Deletion
On 18 Oct 2016, at 10:31, Guus der Kinderen wrote: > On 18 October 2016 at 11:18, Kevin Smith wrote: >> >> On 18 Oct 2016, at 10:16, Guus der Kinderen >> wrote: >> > On 18 October 2016 at 11:12, Kevin Smith wrote: >> >> On 18 Oct 2016, at 10:09, Guus der Kinderen >> >> wrote: >> >> > I don't have much of an argument other than the obvious: both affect >> >> > data 'after-the-fact'. Concerns raised against one should likely also >> >> > be tested against the other - it's pretty much the same thing. As for >> >> > the non-IM case: that could also apply to 'correction' of data, rather >> >> > than only deletion. Implementation-wise, it'd make sense to combine >> >> > both efforts too, I'd say. >> >> >> >> I agree with all of this, but believe these are distinct operations that >> >> deserve distinct protocol. >> >> >> > Why, when the use case, business rules and security considerations are >> > pretty much the same (or perhaps: should be pretty much the same)? >> > Wouldn't it be enough to perhaps have a distinct operation identifier in >> > the same protocol? >> >> I don’t see a difference between "different protocol" and “the same protocol >> with different identifiers”. If it’s which XEP number this goes into, I care >> much less than that I don’t think deletion should be an edit to zero length. > Not sure if I get what you're trying to say. I don't think that deletion > should be an edit-to-empty, I think we're in agreement there. > > When defined in distinct XEPs, I think both XEPs would be (or should be) near > copies of each-other, which would be needlessly complex. > > I propose to have one XEP, that defines distinct keywords for 'correction' > and 'deletion'. A reference to the original message is desirable for a > correction for many of the same reasons as it is desirable for a deletion. I don’t have strong feelings on merging the XEPs versus not. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
Not sure if I get what you're trying to say. I don't think that deletion should be an edit-to-empty, I think we're in agreement there. When defined in distinct XEPs, I think both XEPs would be (or should be) near copies of each-other, which would be needlessly complex. I propose to have one XEP, that defines distinct keywords for 'correction' and 'deletion'. A reference to the original message is desirable for a correction for many of the same reasons as it is desirable for a deletion. On 18 October 2016 at 11:18, Kevin Smith wrote: > On 18 Oct 2016, at 10:16, Guus der Kinderen > wrote: > > On 18 October 2016 at 11:12, Kevin Smith wrote: > >> On 18 Oct 2016, at 10:09, Guus der Kinderen < > guus.der.kinde...@gmail.com> wrote: > >> > I don't have much of an argument other than the obvious: both affect > data 'after-the-fact'. Concerns raised against one should likely also be > tested against the other - it's pretty much the same thing. As for the > non-IM case: that could also apply to 'correction' of data, rather than > only deletion. Implementation-wise, it'd make sense to combine both efforts > too, I'd say. > >> > >> I agree with all of this, but believe these are distinct operations > that deserve distinct protocol. > >> > > Why, when the use case, business rules and security considerations are > pretty much the same (or perhaps: should be pretty much the same)? Wouldn't > it be enough to perhaps have a distinct operation identifier in the same > protocol? > > I don’t see a difference between "different protocol" and “the same > protocol with different identifiers”. If it’s which XEP number this goes > into, I care much less than that I don’t think deletion should be an edit > to zero length. > > /K > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
On 18 Oct 2016, at 10:16, Guus der Kinderen wrote: > On 18 October 2016 at 11:12, Kevin Smith wrote: >> On 18 Oct 2016, at 10:09, Guus der Kinderen >> wrote: >> > I don't have much of an argument other than the obvious: both affect data >> > 'after-the-fact'. Concerns raised against one should likely also be tested >> > against the other - it's pretty much the same thing. As for the non-IM >> > case: that could also apply to 'correction' of data, rather than only >> > deletion. Implementation-wise, it'd make sense to combine both efforts >> > too, I'd say. >> >> I agree with all of this, but believe these are distinct operations that >> deserve distinct protocol. >> > Why, when the use case, business rules and security considerations are pretty > much the same (or perhaps: should be pretty much the same)? Wouldn't it be > enough to perhaps have a distinct operation identifier in the same protocol? I don’t see a difference between "different protocol" and “the same protocol with different identifiers”. If it’s which XEP number this goes into, I care much less than that I don’t think deletion should be an edit to zero length. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
Why, when the use case, business rules and security considerations are pretty much the same (or perhaps: should be pretty much the same)? Wouldn't it be enough to perhaps have a distinct operation identifier in the same protocol? On 18 October 2016 at 11:12, Kevin Smith wrote: > On 18 Oct 2016, at 10:09, Guus der Kinderen > wrote: > > I don't have much of an argument other than the obvious: both affect > data 'after-the-fact'. Concerns raised against one should likely also be > tested against the other - it's pretty much the same thing. As for the > non-IM case: that could also apply to 'correction' of data, rather than > only deletion. Implementation-wise, it'd make sense to combine both efforts > too, I'd say. > > I agree with all of this, but believe these are distinct operations that > deserve distinct protocol. > > /K > > > > > On 18 October 2016 at 10:57, Dave Cridland wrote: > > On 18 October 2016 at 09:55, Guus der Kinderen > > wrote: > > > Has the functional overlap with XEP-0308 "Last message correction" > already > > > been discussed? What's the reason for creating a distinct XEP? Would > it be > > > good to have the new XEP include 'correction', and replace 308? > > > > > > > It was discussed - we could do this as a message correction to a > > zero-length message - but firstly I think the semantics are somewhat > > different, and secondly I think this might be usable in some non-IM > > cases. > > > > I'm open to argument, mind. > > > > > On 18 October 2016 at 10:44, Dave Cridland wrote: > > >> > > >> On 17 October 2016 at 20:45, XMPP Extensions Editor > > >> wrote: > > >> > The XMPP Extensions Editor has received a proposal for a new XEP. > > >> > > > >> > Title: Message Deletion > > >> > > > >> > Abstract: This specification defines a method for indicating that a > > >> > message should be retracted. > > >> > > > >> > URL: http://xmpp.org/extensions/inbox/message-retraction.html > > >> > > > >> > The council will decide in the next two weeks whether to accept this > > >> > proposal as an official XEP. > > >> > > > >> > > >> Blocking: > > >> > > >> The XEP title hasn't changed; we really need to avoid the "Deletion" > > >> word to properly describe what this XEP is doing. (Or rather, what > > >> it's not doing). > > >> > > >> Non-Blocking (feel free to dispute these): > > >> > > >> 1) MAM access. > > >> > > >> I'm concerned that there exists a mechanism for abuse if messages are > > >> ever truly expunged from the archive. I think this XEP should include > > >> a MAM extension for accessing the unexpunged message for > > >> administrative users. > > >> > > >> The risk here is that an abusive and/or spam message is sent to a > > >> chatroom, that is then (immediately) removed from the archive. We want > > >> administrators to be able to see the original message, I think. > > >> > > >> It could be that administrators *always* see the original message and > > >> the indicator. > > >> > > >> 2) Tombstone Privacy > > >> > > >> At the opposite end of the scale, I wonder if by requiring the > > >> original JID in the tombstone, we expose more data than we need to. If > > >> the administrator can see the full data (as above), then i think we > > >> can safely remove more data from the retraction tombstone. > > >> > > >> > ___ > > >> > Standards mailing list > > >> > Info: https://mail.jabber.org/mailman/listinfo/standards > > >> > Unsubscribe: standards-unsubscr...@xmpp.org > > >> > ___ > > >> ___ > > >> Standards mailing list > > >> Info: https://mail.jabber.org/mailman/listinfo/standards > > >> Unsubscribe: standards-unsubscr...@xmpp.org > > >> ___ > > > > > > > > > > > > ___ > > > Standards mailing list > > > Info: https://mail.jabber.org/mailman/listinfo/standards > > > Unsubscribe: standards-unsubscr...@xmpp.org > > > ___ > > > > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > > > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _
Re: [Standards] Proposed XMPP Extension: Message Deletion
On 18 Oct 2016, at 10:09, Guus der Kinderen wrote: > I don't have much of an argument other than the obvious: both affect data > 'after-the-fact'. Concerns raised against one should likely also be tested > against the other - it's pretty much the same thing. As for the non-IM case: > that could also apply to 'correction' of data, rather than only deletion. > Implementation-wise, it'd make sense to combine both efforts too, I'd say. I agree with all of this, but believe these are distinct operations that deserve distinct protocol. /K > > On 18 October 2016 at 10:57, Dave Cridland wrote: > On 18 October 2016 at 09:55, Guus der Kinderen > wrote: > > Has the functional overlap with XEP-0308 "Last message correction" already > > been discussed? What's the reason for creating a distinct XEP? Would it be > > good to have the new XEP include 'correction', and replace 308? > > > > It was discussed - we could do this as a message correction to a > zero-length message - but firstly I think the semantics are somewhat > different, and secondly I think this might be usable in some non-IM > cases. > > I'm open to argument, mind. > > > On 18 October 2016 at 10:44, Dave Cridland wrote: > >> > >> On 17 October 2016 at 20:45, XMPP Extensions Editor > >> wrote: > >> > The XMPP Extensions Editor has received a proposal for a new XEP. > >> > > >> > Title: Message Deletion > >> > > >> > Abstract: This specification defines a method for indicating that a > >> > message should be retracted. > >> > > >> > URL: http://xmpp.org/extensions/inbox/message-retraction.html > >> > > >> > The council will decide in the next two weeks whether to accept this > >> > proposal as an official XEP. > >> > > >> > >> Blocking: > >> > >> The XEP title hasn't changed; we really need to avoid the "Deletion" > >> word to properly describe what this XEP is doing. (Or rather, what > >> it's not doing). > >> > >> Non-Blocking (feel free to dispute these): > >> > >> 1) MAM access. > >> > >> I'm concerned that there exists a mechanism for abuse if messages are > >> ever truly expunged from the archive. I think this XEP should include > >> a MAM extension for accessing the unexpunged message for > >> administrative users. > >> > >> The risk here is that an abusive and/or spam message is sent to a > >> chatroom, that is then (immediately) removed from the archive. We want > >> administrators to be able to see the original message, I think. > >> > >> It could be that administrators *always* see the original message and > >> the indicator. > >> > >> 2) Tombstone Privacy > >> > >> At the opposite end of the scale, I wonder if by requiring the > >> original JID in the tombstone, we expose more data than we need to. If > >> the administrator can see the full data (as above), then i think we > >> can safely remove more data from the retraction tombstone. > >> > >> > ___ > >> > Standards mailing list > >> > Info: https://mail.jabber.org/mailman/listinfo/standards > >> > Unsubscribe: standards-unsubscr...@xmpp.org > >> > ___ > >> ___ > >> Standards mailing list > >> Info: https://mail.jabber.org/mailman/listinfo/standards > >> Unsubscribe: standards-unsubscr...@xmpp.org > >> ___ > > > > > > > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
I don't have much of an argument other than the obvious: both affect data 'after-the-fact'. Concerns raised against one should likely also be tested against the other - it's pretty much the same thing. As for the non-IM case: that could also apply to 'correction' of data, rather than only deletion. Implementation-wise, it'd make sense to combine both efforts too, I'd say. On 18 October 2016 at 10:57, Dave Cridland wrote: > On 18 October 2016 at 09:55, Guus der Kinderen > wrote: > > Has the functional overlap with XEP-0308 "Last message correction" > already > > been discussed? What's the reason for creating a distinct XEP? Would it > be > > good to have the new XEP include 'correction', and replace 308? > > > > It was discussed - we could do this as a message correction to a > zero-length message - but firstly I think the semantics are somewhat > different, and secondly I think this might be usable in some non-IM > cases. > > I'm open to argument, mind. > > > On 18 October 2016 at 10:44, Dave Cridland wrote: > >> > >> On 17 October 2016 at 20:45, XMPP Extensions Editor > >> wrote: > >> > The XMPP Extensions Editor has received a proposal for a new XEP. > >> > > >> > Title: Message Deletion > >> > > >> > Abstract: This specification defines a method for indicating that a > >> > message should be retracted. > >> > > >> > URL: http://xmpp.org/extensions/inbox/message-retraction.html > >> > > >> > The council will decide in the next two weeks whether to accept this > >> > proposal as an official XEP. > >> > > >> > >> Blocking: > >> > >> The XEP title hasn't changed; we really need to avoid the "Deletion" > >> word to properly describe what this XEP is doing. (Or rather, what > >> it's not doing). > >> > >> Non-Blocking (feel free to dispute these): > >> > >> 1) MAM access. > >> > >> I'm concerned that there exists a mechanism for abuse if messages are > >> ever truly expunged from the archive. I think this XEP should include > >> a MAM extension for accessing the unexpunged message for > >> administrative users. > >> > >> The risk here is that an abusive and/or spam message is sent to a > >> chatroom, that is then (immediately) removed from the archive. We want > >> administrators to be able to see the original message, I think. > >> > >> It could be that administrators *always* see the original message and > >> the indicator. > >> > >> 2) Tombstone Privacy > >> > >> At the opposite end of the scale, I wonder if by requiring the > >> original JID in the tombstone, we expose more data than we need to. If > >> the administrator can see the full data (as above), then i think we > >> can safely remove more data from the retraction tombstone. > >> > >> > ___ > >> > Standards mailing list > >> > Info: https://mail.jabber.org/mailman/listinfo/standards > >> > Unsubscribe: standards-unsubscr...@xmpp.org > >> > ___ > >> ___ > >> Standards mailing list > >> Info: https://mail.jabber.org/mailman/listinfo/standards > >> Unsubscribe: standards-unsubscr...@xmpp.org > >> ___ > > > > > > > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
On 18 October 2016 at 09:55, Guus der Kinderen wrote: > Has the functional overlap with XEP-0308 "Last message correction" already > been discussed? What's the reason for creating a distinct XEP? Would it be > good to have the new XEP include 'correction', and replace 308? > It was discussed - we could do this as a message correction to a zero-length message - but firstly I think the semantics are somewhat different, and secondly I think this might be usable in some non-IM cases. I'm open to argument, mind. > On 18 October 2016 at 10:44, Dave Cridland wrote: >> >> On 17 October 2016 at 20:45, XMPP Extensions Editor >> wrote: >> > The XMPP Extensions Editor has received a proposal for a new XEP. >> > >> > Title: Message Deletion >> > >> > Abstract: This specification defines a method for indicating that a >> > message should be retracted. >> > >> > URL: http://xmpp.org/extensions/inbox/message-retraction.html >> > >> > The council will decide in the next two weeks whether to accept this >> > proposal as an official XEP. >> > >> >> Blocking: >> >> The XEP title hasn't changed; we really need to avoid the "Deletion" >> word to properly describe what this XEP is doing. (Or rather, what >> it's not doing). >> >> Non-Blocking (feel free to dispute these): >> >> 1) MAM access. >> >> I'm concerned that there exists a mechanism for abuse if messages are >> ever truly expunged from the archive. I think this XEP should include >> a MAM extension for accessing the unexpunged message for >> administrative users. >> >> The risk here is that an abusive and/or spam message is sent to a >> chatroom, that is then (immediately) removed from the archive. We want >> administrators to be able to see the original message, I think. >> >> It could be that administrators *always* see the original message and >> the indicator. >> >> 2) Tombstone Privacy >> >> At the opposite end of the scale, I wonder if by requiring the >> original JID in the tombstone, we expose more data than we need to. If >> the administrator can see the full data (as above), then i think we >> can safely remove more data from the retraction tombstone. >> >> > ___ >> > Standards mailing list >> > Info: https://mail.jabber.org/mailman/listinfo/standards >> > Unsubscribe: standards-unsubscr...@xmpp.org >> > ___ >> ___ >> Standards mailing list >> Info: https://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: standards-unsubscr...@xmpp.org >> ___ > > > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
Has the functional overlap with XEP-0308 "Last message correction" already been discussed? What's the reason for creating a distinct XEP? Would it be good to have the new XEP include 'correction', and replace 308? On 18 October 2016 at 10:44, Dave Cridland wrote: > On 17 October 2016 at 20:45, XMPP Extensions Editor > wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Message Deletion > > > > Abstract: This specification defines a method for indicating that a > message should be retracted. > > > > URL: http://xmpp.org/extensions/inbox/message-retraction.html > > > > The council will decide in the next two weeks whether to accept this > proposal as an official XEP. > > > > Blocking: > > The XEP title hasn't changed; we really need to avoid the "Deletion" > word to properly describe what this XEP is doing. (Or rather, what > it's not doing). > > Non-Blocking (feel free to dispute these): > > 1) MAM access. > > I'm concerned that there exists a mechanism for abuse if messages are > ever truly expunged from the archive. I think this XEP should include > a MAM extension for accessing the unexpunged message for > administrative users. > > The risk here is that an abusive and/or spam message is sent to a > chatroom, that is then (immediately) removed from the archive. We want > administrators to be able to see the original message, I think. > > It could be that administrators *always* see the original message and > the indicator. > > 2) Tombstone Privacy > > At the opposite end of the scale, I wonder if by requiring the > original JID in the tombstone, we expose more data than we need to. If > the administrator can see the full data (as above), then i think we > can safely remove more data from the retraction tombstone. > > > ___ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > ___ > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
On 17 October 2016 at 20:45, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Deletion > > Abstract: This specification defines a method for indicating that a message > should be retracted. > > URL: http://xmpp.org/extensions/inbox/message-retraction.html > > The council will decide in the next two weeks whether to accept this proposal > as an official XEP. > Blocking: The XEP title hasn't changed; we really need to avoid the "Deletion" word to properly describe what this XEP is doing. (Or rather, what it's not doing). Non-Blocking (feel free to dispute these): 1) MAM access. I'm concerned that there exists a mechanism for abuse if messages are ever truly expunged from the archive. I think this XEP should include a MAM extension for accessing the unexpunged message for administrative users. The risk here is that an abusive and/or spam message is sent to a chatroom, that is then (immediately) removed from the archive. We want administrators to be able to see the original message, I think. It could be that administrators *always* see the original message and the indicator. 2) Tombstone Privacy At the opposite end of the scale, I wonder if by requiring the original JID in the tombstone, we expose more data than we need to. If the administrator can see the full data (as above), then i think we can safely remove more data from the retraction tombstone. > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Deletion
The usual terms are message recall, or retraction. On 28 Aug 2015 17:59, "Christian Schudt" wrote: > Hi, > > the wording is very inconsistent. > > It sometimes says delete/deletion, sometimes remove/removal, even when > referring to the same use case ("removal request“, "deletion request“). > > Even the namespace (delete) is different from the element name (remove). > > I suggest to clean this up. I am no native speaker and the difference > might be subtle, but from what I’ve read „remove“ feels more appropriate > here. > > Otherwise looks well. Skype uses this feature, too. > > — Christian > > > > Am 19.08.2015 um 17:44 schrieb XMPP Extensions Editor : > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > Title: Message Deletion > > > > Abstract: This specification defines a method for indicating that a > message should be removed. > > > > URL: http://xmpp.org/extensions/inbox/message-deletion.html > > > > The XMPP Council will decide in the next two weeks whether to accept > this proposal as an official XEP. > > > >
Re: [Standards] Proposed XMPP Extension: Message Deletion
Hi, the wording is very inconsistent. It sometimes says delete/deletion, sometimes remove/removal, even when referring to the same use case ("removal request“, "deletion request“). Even the namespace (delete) is different from the element name (remove). I suggest to clean this up. I am no native speaker and the difference might be subtle, but from what I’ve read „remove“ feels more appropriate here. Otherwise looks well. Skype uses this feature, too. — Christian Am 19.08.2015 um 17:44 schrieb XMPP Extensions Editor : > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Deletion > > Abstract: This specification defines a method for indicating that a message > should be removed. > > URL: http://xmpp.org/extensions/inbox/message-deletion.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP. >
Re: [Standards] Proposed XMPP Extension: Message Deletion
On 19/08/15 23:44, Matthew Wild wrote: > On 19 August 2015 at 16:44, XMPP Extensions Editor wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Message Deletion >> >> Abstract: This specification defines a method for indicating that a message >> should be removed. >> >> URL: http://xmpp.org/extensions/inbox/message-deletion.html >> >> The XMPP Council will decide in the next two weeks whether to accept this >> proposal as an official XEP. >> > It's good. I wonder if it would make sense to standardize a way to say > "This message has been removed"? Both MAM and MUC would benefit from > such a thing. I would like some language stating that a service MAY deny / not execute own message removal even though it advertises the feature, e.g., when your policy only allows admins to remove messages, especially if a more generic way would include MAM as well. Edwin
Re: [Standards] Proposed XMPP Extension: Message Deletion
On 19 August 2015 at 16:44, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Message Deletion > > Abstract: This specification defines a method for indicating that a message > should be removed. > > URL: http://xmpp.org/extensions/inbox/message-deletion.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > It's good. I wonder if it would make sense to standardize a way to say "This message has been removed"? Both MAM and MUC would benefit from such a thing. Regards, Matthew