On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote: > >> -----Original Message----- >> From: dmarc <[email protected]> On Behalf Of Alessandro Vesely >> Sent: Thursday, December 3, 2020 6:24 AM >> To: [email protected] >> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56) >> >> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote: >>> >>> While this ticket/enhancement specifically mentions ARC, I could >>> perhaps see the usefulness in other places. It seems like it would be >>> more beneficial to create a method by which other documents could >>> provide XML- based "extensions" to the report. This would allow >>> mechanisms relying on DMARC to independently define their reporting >>> schema to be included in DMARC aggregate reports. Alternately, we could >>> focus specifically on ARC, and work to include that in the base XML. >>> This means that any later reporting requirements could again require >>> changes to the core drafts.>>> >> >> >> Another possibility is for ARC to define its own report format. Hijacking >> rua= targets to send a different kind of report should be allowed. >> Otherwise, we could define a new tag, e.g. rue= (e for Extension).>> >> In either case, as we're introduce variations in aggregate report content, >> we have to devise a method for determining what version/kind of report is >> attached to a given message.>> > > We could add an element called "<extensions>", and we allow ARC or whatever > it may be to exist under that element. The Aggregate Reporting document > needs to specify that any extensions are expected to be proper XML, and if > there are no extensions, an empty element is sufficient. We could create a > bit more structure as a requirement if we wanted:> > <extensions> > <extension name="arc" standard="ARC_DMARC_REPORTING_EXTENSION_DEFINITION"> > ... (as defined in referenced standard) > </extension> > </extensions> > > If a report parser doesn't know what ARC is (or any of the extensions), it > could skip the processing. I do understand this means that <extensions> > element may break existing parsers, even when empty, though, I expect many of > the things we're proposing may fracture the expected XML.
We can do a better job at producing aggregate reports with an automatically verifiable content. For example, prepending stuff like this: <?xml version="1.0" encoding="UTF-8"?> <dmarc:feedback xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1"; xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1 rua.xsd"> <report_metadata> ... (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1"; for the version) But then, would the <extensions> imply dmarc-xml grammar should be upgraded every time ARC (or whatever) is upgraded? Separate reports sounds simpler. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
