Alex -

Good catch... and yeah, if the DMARC-bis version won't be incremented, I agree 
that the "version" field in the RUA should remain "1" for both RFC7489 and 
DMARC-bis so there's no disconnect in meaning of "version".

What about adding a field that'd expressly identifies which DMARC record 
discovery mechanism was used?

That way a report analyst would be able to handle differences in results from 
different evaluators (some using the RFC7489 "hop", and others using the -bis 
"tree walk") for the same set of published policies.

Perhaps something like:

  <!-- The mechanism used for DMARC record discovery. -->
  <xs:element name="discovery_mechanism" type="xs:string"
        minOccurs="0" maxOccurs="1"/>

The excepted values being the enumerated discovery mechanisms (e.g. something 
like "hop", "treewalk").

Thoughts?

- Trent



From: dmarc <dmarc-boun...@ietf.org> on behalf of "Brotman, Alex" 
<Alex_Brotman=40comcast....@dmarc.ietf.org>
Date: Wednesday, March 8, 2023 at 9:25 AM
To: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: [dmarc-ietf] Version in aggregate report

While reviewing something in the aggregate doc, I came across this bit in the 
XML specification. Unless I've missed something, we're not incrementing the 
version in the DMARC DNS record. <!-- The version declared in the DMARC record 
found. 


While reviewing something in the aggregate doc, I came across this bit in the 
XML specification.  Unless I've missed something, we're not incrementing the 
version in the DMARC DNS record.



  <!-- The version declared in the DMARC record found. -->

  <xs:element name="version_published" type="xs:decimal"

        minOccurs="0" maxOccurs="1"/>



So, if we're not changing that DNS record, obviously this "version" string has 
less meaning.  The prose describing the field says this would be "1" or "2".  
If we're going to stick to not incrementing the version string, I need to 
update this to reflect that.  Not a horrible task, just wanted to be clear 
before I make work for myself.



--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast



_______________________________________________

dmarc mailing list

dmarc@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to