> 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?
-bjc
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
