> -----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.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
