Below -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> -----Original Message----- > From: Mark E. Mallett <[email protected]> > Sent: Thursday, November 21, 2024 7:41 PM > To: [email protected] > Subject: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-22 > > > Sorry for the new thread. I seem to have lost the publication notice to anchor > this message to. > > I have a few mostly nitpicky comments. I probably wouldn't send them except > that this one sticks out a bit: > > 2.1 says, > > Both the "spf" and "dkim" results may optionally include a > "human_readable" field > > however the Appendis A schema has "human_results" > Resolved > > Now that I'm here.. .other picky remarks, in random order of pettiness-- > > The intro says > > DMARC Aggregate Reports MUST contain two primary sections > ("metadata" & "data" below) ... > > I find it interesting that these named sections are never really referred to > by > those names again. i.e. those section names aren't called out. Most other > references are made with other terms, not section names. The meaning of > "metadata" and "data" can, of course, be inferred. > Both are used in the respective next sections, but not encapsulated in quotes. I can do that if you'd prefer. > ---- > > Relatedly, the terms "element" and "field" seem to be used interchangeably > (not to mention "sub-element"). I think I'd like it a bit more if xml elements > were called one thing (like "element") and not "field," especially where > "field" > sometimes has other meaning like in "header field." There's no bright line > between those terms, and I must say I have not really been completely > confused by this, so it's probably a trivial remark. Still. > I'll see if I can get those cleaned up. > ---- > > This kind of nomenclature issue comes into play a bit in references to > "report- > id" as a field when there is a report_id element in the scheme (and indeed is > called "report-id" in a comment in the schema). And I did find this a little > confusing.(*) > I'll resolve > ---- > > 2.1.2 says > > ... there is a preference as to which signatures are included. > > and then there's a numbered list of signatures followed by > > A report SHOULD contain no more than 100 signatures for a given > "row", in decreasing priority. > > two things about "priority" vs "preference" (did I mention the > pickiness)?: > > The list says there is a preference, but it doesn't really say what the > preference > is, nor what the numbers mean in relation to a priority or a decreasing in > priority. Maybe add "in the following order" in the introduction to the list. > The > summary line could say something like Resolved I believe. > > A report SHOULD contain no more than 100 most preferential > signatures for a given "row." > > -mm- > > (*)even having read multiple interations of this document multiple times. > > _______________________________________________ > 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]
