[Standards] Current OTR Info

Dave Cridland dave at cridland.net
Mon May 9 22:09:22 UTC 2016


On 9 May 2016 at 22:49, Brian Cully <bcully at gmail.com> wrote:

>
> > 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?
>

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.

Dave.


> -bjc
>
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160509/e8809278/attachment.html>


More information about the Standards mailing list