On 9 May 2016 at 02:37, Brian Cully <[email protected]> wrote: > > It’s a generic property of ability to render, or possibly even > ability to understand. I think you easily end up in a quagmire when you > look at it like that (if it’s a property of understandability, what should > I do with lang=“something-i-dont-read”?). > > If certain protocols have needs beyond simply “yep, got the > message”, they should probably be added as separate elements to those > specifications, or, at most, use a set of common errors (e.g., > <could-not-decrypt/>), but overloading delivery receipts for it complicates > what is, at least for now, a rare case at the expense of the vastly more > common case. > > I'm going to pick on you - sorry - I'm more or less picking on the entire thread really.
You're quite right, of course, that the semantics of delivery receipts don't match, and a careful examination of the generalized semantics actually required might lead into a rathole. But the basic user story (to probably misuse a term) is that users want to know if their message is likely to be read by the user or not. 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. Dave.
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
