+1 I concur with Mike and Andrew. There's no no reason to ignore this element of the standard because there's no real barrier (other than lack of attention to the spec) preventing implementors from doing this correctly. And all we'd be doing is pushing the burden of handling ambiguity to the receivers.
Avoiding ambiguity is important for avoiding failure in interoperability. And to Dave's point, this item (and others like it) essentially serves as a "No Brown M&Ms" clause - https://www.npr.org/sections/therecord/2012/02/14/146880432/the-truth-about-van-halen-and-those-brown-m-ms .. If you're implementing a spec, it's important to pay attention to the details. Best, Peter On Wed, Jan 16, 2019 at 3:47 PM Dotzero <dotz...@gmail.com> wrote: > +1 > > Too many times we (collectively) have avoided the short term pain because > it is pain, but we have set ourselves up for greater pain at a later point. > Part of the problem with ignoring the requirements of a standard is that > while interoperability works in most cases, it sets up failure in corner > cases and opens up the potential for abuse in ways that are not easily > discerned. > > Michael Hammer > > On Wed, Jan 16, 2019 at 6:10 PM Andrew Sullivan <a...@anvilwalrusden.com> > wrote: > >> Hi, >> >> On Wed, Jan 16, 2019 at 11:34:56AM -0700, Grant Taylor wrote: >> > >> > However I feel like rejecting things because of additional white space >> (in >> > front of v=...) or the wrong case is being a little bit pedantic. >> >> I want to point out, because it's making me extremely itchy, that the >> DNS itself did this for years. One result is that vendors are about >> to have a flag day in which a whole bunch of things are deprecated at >> once in an effort to get rid of a lot of cruft. >> >> Vendors are going to have a difficult time rejecting any heuristic >> improvements if some of them work. Already it is hard for DNS >> providers to process these records because they're all TXT and the >> semantics of the RRTYPE say that anything is allowed. So I think >> stricter implementations overall are probably the better path to >> interoperability here, even if that hurts in the immediate term. >> >> A >> >> -- >> Andrew Sullivan >> a...@anvilwalrusden.com >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
