Richard, Thanks for the notes. I'll file a few trac issues to get these resolved, and try to get a new version released soon-ish. If you're okay with it, I may send you a preview version to ensure it resolves the items noted below. Thanks again
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <[email protected]> On Behalf Of Richard Gray > Sent: Tuesday, January 25, 2022 5:03 AM > To: [email protected] > Subject: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback > > Hi, > > I've been reading over the DMARC Aggregate Reporting draft and have some > feedback on the schema and sample report. > > * The ActionDispositionType type definition in the schema is missing a closing > </xs:simpleType> tag > > * The schema has the DMARC report version element (<version>) specified > immediately under the <feedback> root element and not under > <report_metadata> as stated in section 2.1 > > * The draft states that <policy_published> has mandatory fields domain, p, and > sp, and optional fields fo, adkim, aspf, and testing. > The schema for PolicyPublishedType has mandatory fields domain and > version_published, with all other fields optional. Should version_published be > mandatory or optional? > > * The schema for IdentifierType has header_from and envelope_from as > mandatory fields, and envelope_to as an optional field. The sample report > includes only header_from. The draft text in section 2.1 says "In most cases, > this > will be a header_from element, which will contain the 5322.From domain from > the message". Is it the intention of the draft that envelope_to should be > mandatory? > > * The schema for SPFAuthResultType has scope (mfrom/helo) as a mandatory > attribute but the sample report does not include a scope section. Should the > SPF > scope be a mandatory field? > > * The schema does not currently permit report extensions as described in the > draft (section 4). I am not sure if it is possible to define a schema > allowing an > arbitrary element name with a required definition attribute (pointing to the > extension spec). > > As an alternative, would it be better to have a standard element name > representing an arbitrary extension, with an attribute (even just the > definition > URI) to identify the specific extension in use? E.g. > > <extensions> > <extension > definition="https://urldefense.com/v3/__https://www.example.com/dmarc- > extension/0.1__;!!CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx- > YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahviZ7N-gj3w$ "> > ... > </extension> > </extensions> > > * Lastly, the draft states that reports have two primary sections, one with > descriptive information and the other with row-data for the report. The > "informative" section is broken into two sub-sections, which are > report_metadata and policy_published. Would it perhaps be clearer to say that > there are three main sections rather than two? > report_metadata and policy_published are subsections of the main feedback > element along with the record elements holding the row data. > The schema is clear in this instance, I just wondered if the wording in the > draft > might be improved. > > Regards, > Richard > > _______________________________________________ > dmarc mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;! > !CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx- > YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahvibu5fFB5w$ _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
