On 5/20/2020 10:01 AM, Scott Kitterman wrote:
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.
DMARC is informational, not a proposed standard. My confused
understanding of the RFC7489 informational status DMARC draft, it has
removed the IANA registered "rf=" report format tag, continues to
describe the afrf and iodef format. But the XML schema is described as
the report format? Sound there is a lot of clean up to do. We
haven't even discussed 3rd party policy support. DMARC PS can not
ignore it. The rewrite kludge is not a preferred and acceptable concept.
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.
But XML was added unofficially? As I pointed out, Google doesn't even
mention the "rf=" tag and just described reports are in XML format.
If that is the decision for the initial DMARC proposed standard, I am
fine with the XML default, but it would be simple to add an optional
"prf=" tag with additional report format IANA registered well known
acronyms namely csv, json. XML will be registered for the PS so I am
suggesting to also register csv and json with optional implementation
semantics.
This may give verifiers (new or PS updated), preparedness to recognize
the "prf=" tag for future support. You are correct. The "prf=" can
alway be added but the format tags won't be registered. Another RFC to
cover the registration.
Thanks Scoot, I hope all is safe for you and family.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
