Subject: [dmarc-ietf] Trac #6 - Normative filename construction

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 12 Aug 2021 20:26:57 +0000

https://trac.ietf.org/trac/dmarc/ticket/6

Folks,

I'd like to get a bit of feedback on this one. I realized I'd changed this to a SHOULD, which doesn't really address the "fuzzy" complaint.  Seems like the proper thing to do is make this a MUST, though I'd be interested in opposing thoughts.  Instead of "The filename SHOULD be constructed using the following ABNF:", it would be convert to a "MUST be constructed".

Relevant section in the current draft: https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-2.6.1

(there's another nit in the ticket, though I don't think that requires discussion)

Thanks

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: "John Levine" <[email-masked]>
Date: 12 Aug 2021 17:48:43 -0400

It appears that Brotman, Alex <[email-masked]> said:
>I'd like to get a bit of feedback on this one. I realized I'd changed this to a SHOULD, which doesn't really address the "fuzzy"
>complaint.  Seems like the proper thing to do is make this a MUST, though I'd be interested in opposing thoughts.  Instead of "The
>filename SHOULD be constructed using the following ABNF:", it would be convert to a "MUST be constructed".
>

I think MUST is appropriate, do this if you want to interoperate.

I don't ever recall seeing a report file with a name that didn't follow the pattern.  I do still
see a lot of .zip rather than .xml.gz

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 Aug 2021 19:17:13 +0200

> I'd like to get a bit of feedback on this one. I realized I'd changed this to a SHOULD, which doesn't really address the "fuzzy" complaint.  Seems like the proper thing to do is make this a MUST, t…

I'd raise to MUST the media type, but leave the filename at SHOULD. 
The MUST can be limited to the components, so that the same content 
results in identical filenames.

I'm not sure the filename is required for interoperability.  Do report 
consumers rely on the filename or on the values contained in it?  What 
do they trust if they differ?  (Do they even compare them?)

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 13 Aug 2021 14:53:11 -0400

>do they trust if they differ?  (Do they even compare them?)

If I see an identical filename I assume it's a duplicate.

Has anyone ever seen a report filename that didn't follow the rules?
I haven't, so might as well make it a MUST so people aren't tempted to cheat.

R's,
John

---

From: Grant Taylor <[email-masked]>
Date: Fri, 13 Aug 2021 14:43:35 -0600

> If I see an identical filename I assume it's a duplicate.

I would argue that the unique-id would benefit from a SHOULD status, 
likely with a comment about avoiding the very interpretation that you 
have.  An interpretation I tend to share.

-- 
Grant. . . .
unix || die

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 14 Aug 2021 17:24:07 +0200

> have.  An interpretation I tend to share.

It is important that the converse holds too:  duplicates MUST have 
identical filenames, irrespective of unique-id (and of format, if it's 
going to stay at SHOULD.)

Best
Ale
--