[Standards] Current OTR Info

Dave Cridland 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
thread really.

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...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160509/25407d31/attachment-0001.html>

More information about the Standards mailing list