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] _______________________________________________
