<div dir="ltr">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.<div><div><br></div><div>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.<div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 3:13 PM, Daniel Gultsch <span dir="ltr"><<a href="mailto:daniel@gultsch.de" target="_blank">daniel@gultsch.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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)<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-05-10 0:09 GMT+02:00 Dave Cridland <span dir="ltr"><<a href="mailto:dave@cridland.net" target="_blank">dave@cridland.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On 9 May 2016 at 22:49, Brian Cully <span dir="ltr"><<a href="mailto:bcully@gmail.com" target="_blank">bcully@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On 9-May-2016, at 03:48, Dave Cridland <<a href="mailto:dave@cridland.net" target="_blank">dave@cridland.net</a>> wrote:<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
</span>        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.<br>
<br>
        Why do we need to add behavior to delivery receipts when there’s already a generic mechanism for handling errors on received messages?<br></blockquote><div><br></div></span><div>Fair comment. Either (or both) is good. The questions are:</div><div><br></div><div>a) Does the proposal cause an interoperability issue, and</div><div>b) Does the proposal cause any security concerns, and</div><div>c) Will it result in a better experience for the user.</div><div> </div><div>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.</div><div><br></div><div>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.</div><span><font color="#888888"><div><br></div><div>Dave.</div></font></span><span><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
-bjc<br>
<br>
_______________________________________________<br>
Standards mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">http://mail.jabber.org/mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
_______________________________________________<br>
</div></div></blockquote></span></div><br></div></div>
<br>_______________________________________________<br>
Standards mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">http://mail.jabber.org/mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
_______________________________________________<br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Standards mailing list<br>
Info: <a href="http://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">http://mail.jabber.org/mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org">Standards-unsubscribe@xmpp.org</a><br>
_______________________________________________<br>
<br></blockquote></div><br></div>