[Standards] Current OTR Info
asterix at lagaule.org
Mon May 9 07:27:32 UTC 2016
Le 2016-05-09 03:37, Brian Cully a écrit :
>> On 8-May-2016, at 15:08, Yann Leboulanger <asterix at lagaule.org> wrote:
>> All that is not specific to OTR. All encryption mechanisms are
>> (GPG for example). Currently, one can send a GPG encrypted message
>> 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.
I agree it's not the job of delivery receipt. But encryption is part of
what you call "vastly more common case" At least it should be and should
be our goal.
So we need a global solution for that kind of problems.
More information about the Standards