That sounds unnecessarily complicated, and, as you say: because report senders won't know if BetterZip is supported by the recipient's implementation or not, if they want to interoperate in an environment where they can't negotiate the algorithm, they can't use BetterZip and they just have to stay with GZip.
I think that unless we put the supported algorithms in the DMARC record we can't practically support optional algorithms. And I think it's more complexity than it's worth to put a list of supported algorithms into the DMARC record, given the small benefit. Barry On Thu, Nov 21, 2024 at 9:40 AM Brotman, Alex <[email protected]> wrote: > > I think I would prefer that we introduce a “z” tag into the DMARC record to > allow specifying one of a handful of existing compression algorithms, and if > absent, fall back to gzip. I realize that means Todd needs to alter the core > document, and we need to come up with a handful of permitted compression > algorithms. There would need to be language in the aggregate document that > report receivers and generators MUST support gzip as the common compression > as the fallback. If we do that, does everyone just end up using gzip anyway? > > > > -- > > Alex Brotman > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > From: Steven M Jones <[email protected]> > Sent: Thursday, November 21, 2024 12:31 AM > To: [email protected] > Subject: [dmarc-ietf] Re: Publication has been requested for > draft-ietf-dmarc-aggregate-reporting-21 > > > > On 11/21/24 12:41, Murray S. Kucherawy wrote: > > > > On Wed, Nov 20, 2024 at 6:48 PM Brotman, Alex <[email protected]> > wrote: > > > > * Section 2.6.2 requires gzip. What about other methods like zstd which can > provide better compression? > > > > This is the first time that has been asked. I suppose it could be changed, > though, it seems as though it would break existing report ingestion. Are > zipped reports large enough to benefit? > > > > The reason I bring it up is because compression mechanisms more modern than > gzip, such as Brotli and zstd, have been published as RFCs since RFC 7489, so > I wonder if there would be any advantage to allowing those. If there's never > been any need and we're satisfied with gzip, that's fine. I just figured I'd > ask the question. > > > > I'd be happy not to lock everything into gzip for the next X years, but can > we allow flexibility without creating an issue for existing code? We could > add something like (completely off-the-cuff) "+zstd" or "+brotli" at the end > of the "rua=" value, and if neither of those are present you stick to gzip? > > That'd have to go into the DMARCbis draft with the notation, allowed values, > and RFC references... Worth the effort? > > --S. > > > > > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
