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 <[email protected]> wrote: > On 18 Oct 2016, at 10:09, Guus der Kinderen <[email protected]> > 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 <[email protected]> wrote: > > On 18 October 2016 at 09:55, Guus der Kinderen > > <[email protected]> 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 <[email protected]> wrote: > > >> > > >> On 17 October 2016 at 20:45, XMPP Extensions Editor <[email protected]> > > >> 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: [email protected] > > >> > _______________________________________________ > > >> _______________________________________________ > > >> Standards mailing list > > >> Info: https://mail.jabber.org/mailman/listinfo/standards > > >> Unsubscribe: [email protected] > > >> _______________________________________________ > > > > > > > > > > > > _______________________________________________ > > > Standards mailing list > > > Info: https://mail.jabber.org/mailman/listinfo/standards > > > Unsubscribe: [email protected] > > > _______________________________________________ > > > > > _______________________________________________ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: [email protected] > > _______________________________________________ > > > > _______________________________________________ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: [email protected] > > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
