> On 8-May-2016, at 15:08, Yann Leboulanger <[email protected]> wrote:
>
> 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.
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.
-bjc
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
