Alex, isn't it time we try and release a version which allows XSD automated validation?
Recall, for example, Matt's suggestions in https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3EwRc/ Thank you Ale -------- Forwarded Message -------- Subject: Re: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback Date: Wed, 26 Jan 2022 01:40:48 +0000 From: Brotman, Alex <[email protected]> To: Richard Gray <[email protected]>, [email protected] <[email protected]> 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
