1) #33 suggests to add a versioned XML namespace declaration in the root <feedback> element. https://trac.ietf.org/trac/dmarc/ticket/33
I support the use of the namespace declaration. A report with namespace declaration allows for automatic syntax checks with XML Schema Validation. XSD validators refuse to work without the declaration. It should be added to the examples in the I-D. Example report: <dmarc:feedback xmlns:dmarc="http://dmarc.org/dmarc-xml/0.2"> ... </dmarc:feedback> A shorter variant is possible if we change the schema slightly: <feedback xmlns="http://dmarc.org/dmarc-xml/0.2"> ... </feedback> Adapted schema with elementFormDefault: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://dmarc.org/dmarc-xml/0.2" xmlns="http://dmarc.org/dmarc-xml/0.2" elementFormDefault="qualified"> Nit: I'd use 2.0 instead of 0.2. 2) #33 goes further and suggests to remove the <version> tag below <feedback>, because it is redundant with the namespace declaration. I wouldn't recommend the removal. RFC 7489 has introduced tag <version>1.0</version> and existing implementations will rely on its existence. Without <version>, chances are the report consumer interprets the report as pre-IETF draft version. 3) #70 introduces a new <version> field, but this one is below <report_metadata> and seems to have the purpose to inform about which DMARC standard has been used for validation. https://trac.ietf.org/trac/dmarc/ticket/70 Is it useful to announce separate version numbers for the DMARC algorithm and the report format? I imagine, the RFC 7489 <version> would do the job for both purposes. 4) How does the report generator know which format version the consumer supports? Ideas: a) Send new format and don't care about old versions. b) Send new format but avoid compatibility breaking changes in the XML design. Add new fields, but do not change existing ones like <disposition> (cf. #51, #75). c) Consumer announces supported version in DNS record ("rua2=" or whatever). d) Send both versions (... for how long?). Regards, Matt _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
