Apologies on the late response, holiday travel. I'm not opposed to changing to this style/format, but I think we need consensus from the group that they prefer one style or the other.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Daniel K. <[email protected]> > Sent: Friday, November 29, 2024 10:29 AM > To: [email protected] > Subject: [dmarc-ietf] Proposal for new prose describing the aggregate report > XML > > Artart review pointed out that the description of the XML format was next to > unreadable, and expressed his concern that it was only really defined in THE > XSD > in Appendix A. > > Here is the start of something I would like to get your feedback on before > writing > it all up. > > I was thinking this would replace everything in 2.1 after the longer list of > bullet > points. > > I've not decided about using the list of tags in the lines starting > "REQUIRED/OPTIONAL elements are ...", adding the REQUIRED-ness after the > "element" bullet, or a combination. I included it all to show both options. > > Please let me know if this is on the right track, completely bonkers, or > something > in between. I'll be grateful for any other input you may have. > > > ### Description of the content XML file > > The format for these reports is also defined in an XML Schema Definition > (XSD) in Appendix A. > > DMARC Aggregate Reports have the root element "feedback" with its XML > namespace set to the DMARC namespace. It contains up to 5 different types of > elements, in order: "version", "report_metadata", "policy_published", > "extension" > and "record". > > * "version": OPTIONAL; MUST have the value 1.0. > > * "report_metadata": REQUIRED; > > REQUIRED elements are "org_name", "email", "report_id", > and "date_range". > OPTIONAL elements are "extra_contact_info", "error", > and "generator". > > * "org_name": REQUIRED; > The name of the Reporting Organization > > * "email": REQUIRED; > Contact to be used when contacting the Reporting Organization > > * "extra_contact_info": OPTIONAL; > Additional contact details > > * "report_id": REQUIRED; > Unique Report-ID, see 2.5.1 > > * "date_range": REQUIRED > MUST contain the elements "begin" and "end" > as epoch timestamps. > > * "error": OPTIONAL; > Error messages when processing DMARC Policy Record > > * "generator": OPTIONAL; > The name of the software involved, helps the Report > Consumer in where to report bugs. > > * "policy_published": REQUIRED; > > Records the DMARC Policy Record configuration observed by the receiving > system. > > REQUIRED elements are "domain", "p", "sp". > OPTIONAL elements are "fo", "adkim", "aspf", "testing", > and "discovery_method". > > * "p" The value from the discovered "p" tag. > > [Needs fleshing out] > > * "extension": OPTIONAL; > > Provides for future extensibility. > > * "record": REQUIRED; > > A report MAY contain an unlimited number of "record" elements, at least one is > REQUIRED. > > [Needs fleshing out] > > > Daniel K. > > _______________________________________________ > 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]
