1) It appears that the issue with l= is that implementers are not doing it correctly, and that there's even lazy-unto-hostile use of it. If this is the case, that implementers are not doing the spec properly, I don't see that changing the spec is going to fix the issue, that of implementers not doing the spec.
There is a basic reality that this situation demonstrates and that we should learn from: interoperability at scale is difficult to achieve and maintain. And when something is fragile like this, we should be careful about expecting actions that mess with it to work reliably, at scale.
So, for example, the pleasant idea of being able to reverse manipulations done by mailing lists ought to give everyone very considerable pause. We haven't done well with the first manipulation, so why should a second one do well?
2) If we get a couple implementers to lean hard in the other direction -- an anti-Postel's Law if you were, be conservative in what you generate and really obsessive about compliance on receipt -- then it wouldn't need to be changed in the spec.
Jon's dictum is often taken as permission to do whatever the heck the originator feels like and the receiver is obligated to adapt.
That's not what Jon intended at all. His guidance was for tolerating reasonable ambiguities in a specification. The originator-side 'conservative' is meant quite seriously. Absent a sender's doing their part, the receiver has no obligation to be liberal in accepting it.
Stated differently: When a specification detail is well-understood, failure to follow it warrants a rejection. When a specification detail can reasonably be interpreted with some variance, seek to tolerate that variance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
