On 18 Oct 2016, at 10:31, Guus der Kinderen <guus.der.kinde...@gmail.com> wrote:
> On 18 October 2016 at 11:18, Kevin Smith <kevin.sm...@isode.com> wrote:
>> On 18 Oct 2016, at 10:16, Guus der Kinderen <guus.der.kinde...@gmail.com>
>> > 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.
>> > 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.
Standards mailing list