On Thu 03/Jun/2021 14:47:21 +0200 Brotman, Alex wrote:
During our interim call last week the topic of extensions within the DMARC aggregate report came up. There was a discussion about how to best introduce these, but also how they might be best used. I noted three cases that I could see today; ARC, PSD, and BIMI. And indeed we have tickets relating to the first two. The original thought was that the aggregate draft would allow a place for extensions, and then additional drafts would define those within the IETF. When -02 was originally being worked on, there was a thread about how we might like to see this, though not many responses. The result is in section 4 of the -02 draft [1].
I have some comments about that attempt. First, it shows extensions right below <feedback>, while it seems more useful to have them as child of <record>. Second, I'm not sure we need an <extensions> container. I'd go for an example like, say, so: <feedback xmlns="http://ietf.org/xml-namesapaces/dmarc-xml/1.0";> <report_metadata> ... </report_metadata> <policy_published> ... </policy_published> <extension_metadata name="bimi" xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0";> ... </extension_metadata> <record> <row> ... </row> <identifiers> ... </identifiers> <auth_results> ... </auth_results> ... <extension name="bimi" xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0";> ... </extension> </record> <record> ... </record> </feedback> Third, we need to grasp how XML grammars can be composed, and insert it in Appendix A.
At the time, I didn't intend to limit the extensions to IETF-approved extensions, though wasn't sure how else this might be used by reporting entities (I mentioned domain reputation-ish things during the call). I'd consider that if we don't enforce IETF-registered extensions, the receivers could still ignore extensions they don't want to handle.
I assume no one reads the XML directly, except for debugging. If report consumers don't know about an extension, its content will never reach human eyeballs. Extension existence will have to be advertised, and a IANA page could be a decent means of doing that.
I'm also aware this could bloat a report in terms of size, though we've already indicated we don't seem overly concerned with the size of the XML body. A few things I'd like to see the group reach consensus on are: 1) Extensions in their own section (as it is now) or within each <row> element
Both, and both optional. An extension can have some data to add in some <record>, but not necessarily in all of them.
2) Must extensions be IETF-approved
We cannot stop non-registered extensions. Yet, developers may want to see an RFC before implementing code that extracts a given extension's content.
3) If (2) is true, do we want to define any during the DMARCbis process (essentially a demonstration of how it is to be done)
It would be a good way to show how to define them. Not our primary task, though. Best Ale --
1: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
