Aye same here, as of v3.2.2 we don't send receipt on decryption failure. It seems XEP-0184 leaves it open to not send a receipt for any reason, as long as the other side must never rely on the receipt / lack of receipt for.. anything.
We don't yet send an error response, but I'll take a look at what you've done. Ideally the sender should recognize the error message and automatically resend. On Mon, May 9, 2016 at 3:13 PM, Daniel Gultsch <[email protected]> wrote: > 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 <[email protected]>: > >> >> >> On 9 May 2016 at 22:49, Brian Cully <[email protected]> wrote: >> >>> >>> > On 9-May-2016, at 03:48, Dave Cridland <[email protected]> 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: [email protected] >>> _______________________________________________ >>> >> >> >> _______________________________________________ >> Standards mailing list >> Info: http://mail.jabber.org/mailman/listinfo/standards >> Unsubscribe: [email protected] >> _______________________________________________ >> >> > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
