You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 () specified immediately under the 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.
...
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
The text was updated successfully, but these errors were encountered:
abrotman
changed the title
Per Richard Gray
Per Richard Gray for Aggregate Reporting (from IETF list)
Feb 18, 2022
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 () specified immediately under the 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.
...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
The text was updated successfully, but these errors were encountered: