Very pragmatic, I like it. It's basically the language used to present the feature that seems to be most at conflict, and as long as it's clear that this isn't guaranteed to delete on the other end, I think we're good. However, I think "deletionrequest" is redundant and it should just be recommended for clients to delete by default, and optional behavior to keep expired messages left up to the implementor.
On Sun, Nov 6, 2016 at 5:41 AM, Stefan Hamacher <[email protected]> wrote: > Hello everybody, > > if I may make a suggestion: I agree with both positions on this: > > a) A message deletion/destruction feature requested on the senders side > for the receiving side is not possible to implement reliably in an open > protocol/environment where the receiving client just can ignore that > request. > Users can therefore be mislead and wonder why that feature does not work > as expected. > > b) As being said a general demand still exists for such a feature. On > the one hand we just have users who will compare XMPP programs with > other solutions and will probably always keep asking for this. On the > other hand there are certain environments where the users really have a > use (and perhaps need) for such a feature, see Brian Cully's answer for > example. > > So why not try to accommodate both realitys and define a feature which > is called "Invalidation of Messages" or similar instead of "Destructible > Messages". The goal of this feature should be to mark messages in a way, > that the client somehow can mark the message as "not being relevant > anymore" or something like that. So it could still be displayed but > grayed out for example telling the receiver that the message can be > ignored. > Additionally there could then be added an attribute "deletionrequest" > which can be set for clients which really want to have destructible > messages like Signal does. > > This is of course not perfect either, because such a request can be > ignored as well, but I think it would be a good compromise between the > two extremes not defining such a feature at all (-> there will be > unstandardized implementations) and defining it specificly as > destructive messages feature (-> users are mislead). The term > "invalidation" does not implicate that directly. > > > Regards, > Stefan Hamacher > _______________________________________________ > 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] _______________________________________________
