On Mon, May 9, 2016 at 5:09 PM, Dave Cridland <[email protected]> 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 -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
