[Standards] Current OTR Info

Brian Cully bcully at gmail.com
Mon May 9 21:49:58 UTC 2016

> On 9-May-2016, at 03:48, Dave Cridland <dave at cridland.net> wrote:
> 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.

	I’d say there’s already a generic way to handle this by sending message of type ‘error’ back with some condition describing it. Clients already process those stanzas, and in cases where an ‘id’ is present on the initiating message (such as every message requesting delivery receipts), can even tie the error to the specific stanza that caused it.

	Why do we need to add behavior to delivery receipts when there’s already a generic mechanism for handling errors on received messages?


More information about the Standards mailing list