On 05/08/2016 07:17 PM, Sam Whited wrote: > On Sun, May 8, 2016 at 12:05 PM, Sam Whited <[email protected]> wrote: >> On Wed, Apr 27, 2016 at 3:48 PM, Chris Ballinger <[email protected]> >> wrote: >>> A quick fix would be to only send delivery receipts if the message could be >>> successfully decrypted. >> I think this makes sense as a recommendation for the informational >> XEP, but I'd love to know if anyone is actually doing it in the wild. >> /cc Daniel > I just sent this response, and then almost immediately did an about > face and changed my mind (I'm fickle that way). I actually think it is > a bad idea to send delivery receipts only if the message can be > decrypted; my reasoning is as follows: > > Because the delivery receipt spec was not intended for this (and > semantically is just supposed to express "delivery" not > "readability"), and because there is no current consensus on when > delivery receipts are sent during an OTR session, differnt clients > will do different things; by allowing delivery receipts to be used for > both, we'd be encouraging confusion and a lack of interoperability > between clients (some clients may want to convey delivery and > redability separately, as you mentioned). A practical example of this > being confusing might be something like the following: Imagine I had a > client open and I establish an OTR session with a remote resource and > begin sending messages. I get back delivery receipts after those > messages are decrypted. Then, for some reason, I send a message to > another resource (maybe there was a network blip and the resource I > was talking too loses their connection) that does not support OTR at > all: I continue to get message delivery receipts and never notice > anything has changed, even though the remote resource can no longer > read my messages. This feels poor. > > In fact, in the delivery receipts introduction it states: > >> Note well that this specification does not distinguish between delivery and >> display, as was done in the message events protocol, in part because no >> implementations of XEP-0022 made that distinction. However, in the absence >> of such a distinction, readers need to understand that this protocol can >> provide only a notification that a message has been received at a client, >> i.e. delivered to a client, not that the message has been actively read or >> understood by a human user (if any). > For this reason I think a separate XEP should be written, and the > recommendation in this informational XEP (if any) would be to send > delivery receipts on receipt of a message, not after decryption. > > Thoughts welcome.
All that is not specific to OTR. All encryption mechanisms are concerned (GPG for example). Currently, one can send a GPG encrypted message with a bad key, and never know something goes wrong because we receive delivery receipts. -- Yann _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
