[Standards] Current OTR Info
dave at cridland.net
Mon May 9 07:48:00 UTC 2016
On 9 May 2016 at 02:37, Brian Cully <bcully at gmail.com> wrote:
> 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'm going to pick on you - sorry - I'm more or less picking on the entire
You're quite right, of course, that the semantics of delivery receipts
don't match, and a careful examination of the generalized semantics
actually required might lead into a rathole.
But the basic user story (to probably misuse a term) is that users want to
know if their message is likely to be read by the user or not.
Lack of a delivery receipt isn't perfect, but it's a backwards-compatible
solution that will match the overall semantic of "this message stands no
chance of being read". Over-analysis would push us into a horrible place
where we're trying to gauge the user's linguistic ability or contextual
knowledge, and that's not actually going to be a useful solution.
Sending errors to allow some technical problem to be remediated is useful -
but it's a secondary concern to ensuring the user is aware there's *some*
kind of communications problem.
This thinking is why I've ended up preferring loose behaviours in
specifications - there's no interoperability concern in having receipts not
sent for (say) bad crypto, or even not sending a receipt for message half
in cyrillic selling pwned computers - but the semantic indicated is a
better match than following the "pure delivery" semantic slavishly.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards