Indeed. We can do what we've done in other cases: create a registry if/when we add something else later.
Barry On Mon, Aug 7, 2023 at 4:11 PM Scott Kitterman <skl...@kitterman.com> wrote: > > > > On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" <superu...@gmail.com> > wrote: > >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski <tjw.i...@gmail.com> wrote: > > > >> Based on the ABNF in -28, how about something like this: > >> > >> > >> dmarc-method = "dkim" / "spf" > >> > >> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method) > >> > >> > >> I think this "should"(*) allow for all permutations but also simplifies > >> it, and I agree with Barry it should be simpler. > >> > > > >This looks good to me, except to be consistent with DKIM (from which this > >general syntax was borrowed) I'd suggest: > > > >* using colon as the separator rather than comma > >* WSP and CFWS should follow whatever we did for other tags > >* don't allow an empty list; I can't think of any DKIM or DMARC tag that > >accepts a list and also allows an empty value > > > >If we think we might add "arc" or something else in the future, do we need > >a registry of supported methods? If not, we'll have to rev DMARC every > >time a new one comes into favor. > > I think we don't need a registry. Rationale: > > 1. There is no additional method that's being contemplated (whatever ARC is, > it's not a first class alternative to SPF or DKIM). > > 2. Currently, we have text in the specification to describe how to use the > output of SPF and DKIM for DMARC. I don't think there's much prospect any > new method wouldn't need something similar. > > I think a registry would only complicate things and wouldn't actually be > helpful. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
