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 <kevin.sm...@isode.com> 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.
>
> /K
>
> >
> > On 18 October 2016 at 10:57, Dave Cridland <d...@cridland.net> wrote:
> > 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
> > _______________________________________________
> >
> > _______________________________________________
> > 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
_______________________________________________

Reply via email to