[Standards] Current OTR Info

Brian Cully bcully at gmail.com
Mon May 9 01:37:14 UTC 2016

> On 8-May-2016, at 15:08, Yann Leboulanger <asterix at lagaule.org> wrote:
> On 05/08/2016 07:17 PM, Sam Whited wrote:
>> On Sun, May 8, 2016 at 12:05 PM, Sam Whited <sam at samwhited.com> wrote:
>>> On Wed, Apr 27, 2016 at 3:48 PM, Chris Ballinger <chris at chatsecure.org> 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.

	It’s a generic property of ability to render, or possibly even ability to understand. I think you easily end up in a quagmire when you look at it like that (if it’s a property of understandability, what should I do with lang=“something-i-dont-read”?).

	If certain protocols have needs beyond simply “yep, got the message”, they should probably be added as separate elements to those specifications, or, at most, use a set of common errors (e.g., <could-not-decrypt/>), but overloading delivery receipts for it complicates what is, at least for now, a rare case at the expense of the vastly more common case.


More information about the Standards mailing list