Le 2016-05-09 03:37, Brian Cully a écrit :
On 8-May-2016, at 15:08, Yann Leboulanger <[email protected]> wrote:
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.
Hi,
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.
--
Yann
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
