Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

[Matthäus Wander <[e-mail]>]

Alessandro Vesely wrote on 2021-08-19 13:18:
> I'd swap SHOULD and MUST between the following sentences:
> 
>      If a report generator needs to re-send a report, the system
>      SHOULD use the same filename as the original report.

The paragraph is justified by deduplication:

    If a report generator needs to re-send a report, the system SHOULD
    use the same filename as the original report.  This would allow the
    receiver to overwrite the data from the original, or discard second
    instance of the report.

But this works only if the sender ensures to leave the filename 
unchanged. So it's either a MUST or the paragraph can be omitted altogether.

> and
> 
>      The RFC5322.Subject field for individual report submissions
>      MUST conform to the following ABNF:
> 
> For the subject, alternatively, "Report-Id" msg-id could be optional, as 
> it is with the filename.  It is very noisy and doesn't seem to be much 
> useful if it doesn't match the filename, let alone its uniqueness.

The Report-ID is also justified by deduplication:

    The purpose of the Report-ID: portion of the field is to enable the
    Domain Owner to identify and ignore duplicate reports that might be
    sent by a Mail Receiver.

1. So Report-ID is either a MUST to allow deduplication,
2. or Report-ID is not required for deduplication,
(In the filename it's optional, but the filename has a mandatory time 
range, which the subject has not. Deduplication requires one of these 
two information. You might use the RFC5322.Date, but this introduces 
another dependency.)
3. or deduplication via subject is not supposed to be supported.
Is there another use case for a formal ABNF spec of the subject?

Regards,
Matt