Re: [dmarc-ietf] DMARC bis: ticket 49: remove normative requirement on policy tag placement

[Alessandro Vesely <[e-mail]>]

On Fri 15/May/2020 20:26:30 +0200 Seth Blank wrote:
> https://trac.ietf.org/trac/dmarc/ticket/49
> 
> The penultimate paragraph
> of https://tools.ietf.org/html/rfc7489#section-6.3 states:
> 
> the "v" and "p" tags MUST be present and MUST
>    appear in that order.


Actually, the text says:


   A DMARC policy record MUST *comply with the formal specification* found
   in Section 6.4 in that the "v" and "p" tags MUST be present and MUST
   appear in that order.


I agree to relax that rule, but that entails changing the spec in Section 6.4.
 A possible way is be like so:


OLD
     dmarc-record    = dmarc-version dmarc-sep
                       [dmarc-request]
                       [dmarc-sep dmarc-srequest]
                       [dmarc-sep dmarc-auri]
                       [dmarc-sep dmarc-furi]
                       [dmarc-sep dmarc-adkim]
                       [dmarc-sep dmarc-aspf]
                       [dmarc-sep dmarc-ainterval]
                       [dmarc-sep dmarc-fo]
                       [dmarc-sep dmarc-rfmt]
                       [dmarc-sep dmarc-percent]
                       [dmarc-sep]
                       ; components other than dmarc-version and
                       ; dmarc-request may appear in any order


NEW
     dmarc-record    = dmarc-version *(dmarc-sep dmarc-tag)

     dmarc-tag       = dmarc-request /
                       dmarc-srequest /
                       dmarc-auri /
                       dmarc-furi /
                       dmarc-adkim /
                       dmarc-aspf /
                       dmarc-ainterval /
                       dmarc-fo /
                       dmarc-rfmt /
                       dmarc-percent
                       ; components other than dmarc-version may
                       ; appear in any order


The latter syntax allows repeating the same tag more than once.  Should we add
that in such cases it is undefined which value an implementation retains?


> While the v= tag pretty universally appears first, the p= tag does not in many
> records, and no implementation appears to care.
> 
> The v= tag must appear first, or the policy discovery mechanism as defined
> in https://tools.ietf.org/html/rfc7489#section-6.6.3 would break.
> 
> But there doesn't appear to be any real reason to keep the normative
> requirement that the p= tag MUST be second in the record after the v= tag, nor
> does this requirement seem to have any impact on interoperability or general
> record parsing in theory or in practice.
> 
> Should we remove this normative requirement?


Yes.



Best
Ale
--