On Thu, Jun 3, 2021 at 8:48 AM Brotman, Alex <Alex_Brotman= 40comcast....@dmarc.ietf.org> wrote:
> Hello folks, > > 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]. and I thought > we'd enhance that as we progressed. 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'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 > 2) Must extensions be IETF-approved > 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) > > Thank you for your continued feedback > > 1: > https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4 > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > 1) Extensions should be in their own extension and seperate from the core reporting. There is a reason we call them "extensions". 2) Extensions used in reporting under the standard should be IETF-approved. This is a standards body. Anyone can leverage standards for private use but our focus as an IETF working group is interoperability. By requiring IETF approval/registration it puts the extensions under IETF "Note Well" and makes the extension public. Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc