On 18 October 2016 at 09:55, Guus der Kinderen <guus.der.kinde...@gmail.com> 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 <d...@cridland.net> wrote: >> >> On 17 October 2016 at 20:45, XMPP Extensions Editor <edi...@xmpp.org> >> 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 <retracted/> 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 _______________________________________________
