I wanted to bring this topic into a visibly different thread, as it's
really about further splitting up of the base DMARC document.
In digging through recent messages, I think I see what Ale meant. The
topic was Jim Fenton's suggestion of splitting the policy section out
into a separate document. This would be the relevant reference from
Ale's message on Nov 5th, subject "Announcing DMARCbis Editors" - Ale is
responding to Todd Herr in this snippet:
Moving discussion of policy to a second specification would render
any base
specification to be no more than effectively a table of contents
pointing
to other documents, which seems to me to be a pointless document to
produce.
Operators who don't need policy, for example external report receivers
who just want to publish verification records, would find the relevant
info in the base spec.
A good point of Jim's proposal is that having policy in a separate
spec, in the same manner as reports, avoids the unintended effect of
classifying reports as a 2nd class, generally-not-used feature.
Alessandro: Correct me if I'm wrong, but it seems from this quotation
that you were just constructing a case were a valid DMARC role (third
party report receiver) would need to use the "base" spec (without policy
content), and the reporting specs, without direct need for a
separate/split-out "policy" spec.
While you have a point, I would think that any report receiver would
need to reference that policy spec as soon as they receive a report and
need to interpret it. In which case, I would need a more compelling
reason or benefit to split the policy section out into a separate document.
With regard to the "Optional p= makes no sense" thread, I think the
quotation with too-little context gave the impression of a different or
larger issue.
--Steve.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
