On Wed 20/May/2020 14:49:13 +0200 Hector Santos wrote: > On 5/19/2020 8:46 PM, Scott Kitterman wrote: >> >> Please don't. This is a large stack of protocol and implementation >> complexity for little or no gain. >> > > Rhetorically, I feel the same about reporting. What is gained from it? But > that is just my opinion since the proposed ideas for reporting came and it was > mostly rejected with SSP. It's redundant overhead. If reporting is going to > be > optional feature to possibly implement, it might as well be useful for > consumers and that is where the gain will be.
Other people here consider reporting the (only) useful innovation of DMARC. I agree we should consider ways to increase the report generators base, but requiring support for multiple formats goes in exactly the opposite direction. Although automatic converters exist, having to provide multiple formats can be a showstopper. > The proposal is more to IANA register the formats (the common ones mostly used > in practice) and not to mandate implementers use them all. XML would be the > fall back. At a minimum, XML is what publisher (or report handler) will get > despite the publisher stating a preferred reporting format, like: > > prf=csv, json, xml. > > That's asking the verifier, if you can handle a csv or json format, please > send > us these reports. Hector, what are you talking about? > I can support any format. Easily done with reporting/output templates for CSV, > JSON or XML -- single sourced output generator. Can you show us how does a CSV report look like? Let me recall that DMARC reports consist of a header part and a series of record with a varying number of columns. XML, like JSON, support complex template schemata. CSV templates require fixed columns. I doubt you're talking seriously if you make such claims. DMARC reports are supposed to be machine-readable. To define multiple formats, we'd need to supply schemata for each. We'll likely have to update the schema version for PS DMARC. Given that automatic translation /of schemata/ is going to lack for some more years, how would we manage equivalence proofs of all those formats? > So, from a product design standpoint, for immediate consumer "pay off," at the > very least, csv should be the default option, not XML. Yes, and I am Catherine Deneuve... Can we get back to work, please? Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
