On 12/23/2014 10:25 PM, Murray S. Kucherawy wrote:
> >> 11.1 Discovery
>
> > 6.2.1 in -08
> >
> >> Mail Receivers can also discover reporting requests from the
> >> Organizational Domain. That should be mentioned here. But I'm a
> little
> >> confused why we have another Discovery section at all.
> > The text's use of the word 'corresponds' handles the mapping to org
> > domain, IMO.
>
> This is more of a comment about document organization. The previous
> sections have been talking about things that follow discovery of the
> policy record, and now when talking about aggregate reports there's
> another section about discovery. Why here; isn't this a little
> redundant?
>
>
> It's mainly to say that there isn't a specific discovery process for
> aggregate report details; it's already done. This might be a legacy
> from ancient versions where there was a separate process. I'll tidy
> it up by merging it into the previous subsection.
>
>
> SHOULD isn't strong enough for the Report Receiver to depend on. There
> are other ways to get the information that is encoded into the
> filename.
>
>
> Like what?
In Appendix C, the section "Report generator metadata" seems to have
most if not all of that information. And that's where it belongs: in the
body of the report, not as metadata that may be conveyed by some
transports and not others. Currently the only transport that is defined
is email, but others may be added later.
For email, some of the metadata currently shows up in three places: (1)
encoded in the filename, (2) encoded in the subject, and (3) in the
metadata section of the report. It would help interoperability to define
one of those that the recipient should depend on, and I nominate the
metadata section of the report, so that other transports can be added
more easily if needed.
>
>
> If the spec wants to suggest, "here's a nice file name format that you
> MAY want to use", that's fine. But SHOULD is both too weak if the
> recipient can't depend on it and too strong if it's merely advice.
>
>
> I'm not so sure. If we're going to go with MAY, then we also need
> some kind of signal that the filename used does conform to the
> proposed encoding, or else there might be some attempt to extract
> report parameters that simply aren't there.
I'm suggesting that they shouldn't attempt to do so.New issue: Paragraph
3 refers to "Both report types" but since iodef was
>
> removed, it should just say "The AFRF report type".
>
>
> That refers to the aggregate and detailed reports ("rua" and "ruf"),
> not IODEF and AFRF.
Ah, thanks.
-Jim
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
