[Standards] Current OTR Info

Daniel Gultsch daniel at gultsch.de
Mon May 9 22:13:13 UTC 2016


FWIW Conversations does exactly this: Not send the delivery receipt and
send and error message if the message is unreadable. (But otherwise
correctly addressed to our full jid)

2016-05-10 0:09 GMT+02:00 Dave Cridland <dave at cridland.net>:

>
>
> 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
>> _______________________________________________
>>
>
>
> _______________________________________________
> 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/20160510/dca5cccc/attachment.html>


More information about the Standards mailing list