On Sat, Sep 13, 2025 at 4:16 AM Alessandro Vesely <[email protected]> wrote:
> > On the assumption that we do want to do this (more on that below), > there's > > stuff missing like what registration policy you want that registry to > have, > > what valid values are for "Status" and what those values mean, possible > > instructions for a designated expert, etc. See the process laid out in > RFC > > 8126. > > Hmm, it seems there's no bonus to defining a new registry on a page where > registration procedures and experts are already defined. Not only does > the I-D > have to repeat these details, but it also needs to specify that the > registry > should be grouped there. Well, it's not overly difficult; I can do it... > I don't know what you mean by "page". Section 6 doesn't specify any other registries, so there's no statement nearby 6.3 that specifies what registration policy should be used or what advice to Designated Experts might be applied. If you mean the IANA page for other mail auth parameters, then I would say I've never seen express or implied "Do it like those other registries"; it's always been made explicit, and I think we should do that here. > My assessment is that Auth-Failure has a list of fixed values, extended by > this > document. The list appears incomplete (for example, keynotfound is > missing). > Most other fixed values for message feedback fields are referenced on the > same > IANA page. Considering that extending an extension has caused > difficulties > even in this list, and that there is confusion among the various types of > reports, perhaps adding this registry could make the whole picture a bit > clearer. > If we want to extend the list in one shot to add "dmarc", that's probably fine for this document to do simply by restating the list. If we think other useful values are or might be missing, like "keynotfound", then I think this is more reasonable, though I also start to wonder if we should be shoe-horning that into this document or doing a separate one that creates the registry and adds other values we think might have been missing since RFC 6591 was published. But since this is the first time I think that idea's been raised, I'm skeptical, and it also feels like scope creep. > That list has not been updated since RFC 6591 was published. If it's > > rarely, if ever, extended, then is it enough to just say "This document > > updates 6591" and "Here's the new list" rather than making something > almost- > > static for IANA to manage? > > The draft already states that it updates 6591, so yes, a developer can go > that > route[*]. DKIM2 provides for various levels of failure, since changes > will be > undoable; perhaps it will define new failure types accordingly? > I don't think this group is chartered to do things in anticipation of DKIM2. We have a very simple and restricted task here. -MSK
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
