Re: [Standards] Proposed XMPP Extension: Message Deletion

[Kevin Smith]

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

[Guus der Kinderen]

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

[Kevin Smith]

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

[Guus der Kinderen]

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 

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Kevin Smith]

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

[Guus der Kinderen]

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

[Dave Cridland]

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

[Guus der Kinderen]

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

[Dave Cridland]

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] Proposed XMPP Extension: Message Deletion

[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 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.

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Christian Schudt]

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 edi...@xmpp.org:

 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

[Dave Cridland]

The usual terms are message recall, or retraction.
On 28 Aug 2015 17:59, Christian Schudt christian.sch...@gmx.de 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 edi...@xmpp.org:

  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.
 

[Standards] Proposed XMPP Extension: Message Deletion

[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

[Matthew Wild]

On 19 August 2015 at 16:44, 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 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

Re: [Standards] Proposed XMPP Extension: Message Deletion

[Edwin Mons]

On 19/08/15 23:44, Matthew Wild wrote:
 On 19 August 2015 at 16:44, 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 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