The charter explicitly says to make changes grounded in operational experience.
We've discussed many things as a group around operational challenges and needs to improve the spec, and not once has anyone on the sending or receiving side of reports raised the compression algorithms as needing a change. I personally like the idea of being able to use better compression schemes. John mentions a report that was 4k which expanded to 1.6m. We receive reports that uncompress to Gigs. But the truth is, it's no skin off our back and gzip doesn't represent a current operational challenge, just a future nicety. I'd argue we save compression mechanisms for a future revision of the aggregate reporting spec, if it becomes an actual challenge to those who are sending or processing reports. Seth, participating On Thu, Nov 21, 2024 at 10:29 AM John Levine <[email protected]> wrote: > It appears that Brotman, Alex <[email protected]> said: > >* Section 2.6.2 says the message has to comply with both RFC5322 and > RFC2045. What's going on here? Why is it required to be MIME? > >Could it not be a plain message that happens to contain XML? Or are we > trying to say there has to be a text/xml part that contains > >the report, and maybe other parts that provide additional information for > humans? This question might be answered by the next > >paragraph, in which case this might just need some copy editing. > > > >I feel like I’m reading this is meant to be an attachment with that > specified type, but isn’t explicitly stated. I’m not > >sure if that’s the expectation of others on the list. > > > >This is what I thought, but it's not really stated clearly. If we're > both right, I think we should be explicit that the report is > >expected to be in a MIME-encoded text/xml part (if uncompressed) or > application/gzip (if compressed), and the remaining MIME > >structure of the message is at the discretion of the generator; the only > thing the receiver cares about is that one part. > > > >I’ll make this more explicit as being expected to be an attachment. > > It needs to be a MIME part of application/gzip. It would be OK if that > were the only part in the message > rather than an attachment so long as it's got the proper type. > > In practice you have to sniff the attachments since some are still ZIP > even though > they say application/gzip or vice versa but let's not go there. > > R"s, > John > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Seth Blank | Chief Technology Officer Email: [email protected] This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
