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. —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
