On Wednesday, May 20, 2020 8:49:13 AM EDT 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.
>
> > Hector, you realize that for this to work reliably you would need to code
> > up support for everything so that you wouldn't have undeliverable
> > reports?
> 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.
>
> I can see where certain 3rd party report handlers would only need XML
> and they generate readable reports for their DMARC customers. But we
> can't assume all publishers will be using a 3rd party report handler.
>
> So its about being ready for the future and DMARC not be obsolete
> fixed with XML only. In my opinion, JSON is the direction most systems
> are heading too.
>
> > Have you implemented the XML format already and you're willing to code up
> > the alternatives too?
> I can support any format. Easily done with reporting/output templates
> for CSV, JSON or XML -- single sourced output generator.
>
> This benefits customers, consumers, publishers who will have tools
> already, today, that imports certain common formats already, and
> generally, it would begin with a CSV format. Just consider, all
> spreadsheets apps, Microsoft, Google, etc, all support CSV today, but
> not JSON or XML. Most or not all, SQL packages, support CSV and
> probably XML and maybe JSON. Let me double check with Google Docs
> ...... no. It supports
>
> csv, txt, tab, htm, html, xls, xlsx, xlsm, xlt, xltm, xltx, ods
>
> I don't know if the list will strip attachments, but this link shows
> an image of the Google Docs popup I got:
>
> https://secure.winserver.com/public/files/google-json-no-support.png
>
> So, from a product design standpoint, for immediate consumer "pay
> off," at the very least, csv should be the default option, not XML.
You're several years too late on deciding a default.
If I understand your proposal correctly, everyone would still need to
implement XML ("At a minimum, XML is what publisher (or report handler) will
get"). If there's no avoiding implementing XML (which is what I thought the
original point was), why would this need to be defined now? It seems like it
could easily be added later if there was a significant demand signal.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
