[Standards] Current OTR Info

Sam Whited sam at samwhited.com
Tue May 10 13:16:01 UTC 2016

On Mon, May 9, 2016 at 5:09 PM, Dave Cridland <dave at cridland.net> wrote:
> Fair comment. Either (or both) is good. The questions are:
> a) Does the proposal cause an interoperability issue, and
> b) Does the proposal cause any security concerns, and
> c) Will it result in a better experience for the user.
> As long as it's "No", "No", and "Yes" respectively anything else is getting
> alarmingly close to a bikeshed - either approach (or indeed both) satisfies
> the concern that the user can be made aware that something is wrong and the
> messages aren't getting through.
> So I'd be happy to have the spec allow (and maybe encourage) clients to not
> return delivery receipts for message stanzas they cannot process, and by all
> means send errors as long as they don't provide any oracles etc.

This makes sense to me; I think I'm convinced. I still worry that not
having explicit behavior would get confusing when switching between
sending to clients that support OTR (or an encryption mechanism in
general) and one that doesn't, but I suppose if Daniel and Chris and
the other client implementers haven't seen this confusion in the real
world it's not worth being concerned about.


Sam Whited
pub 4096R/54083AE104EA7AD3

More information about the Standards mailing list