On Sat 13/Sep/2025 18:07:04 +0200 Murray S. Kucherawy wrote:
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".
I apologize for using an inappropriate term. I was referring to the HTML page
served by IANA for those registries; namely the Messaging Abuse Reporting
Format (MARF) Parameters registry group.
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.
Got it. I'll follow the Guidance for RFC Authors, which provides step by step
instructions[*].
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.
I don't see any point in repeating the entire list, except to create a new
registry. To update a document, describing the differences should be enough.
BTW, should Section 4 mention the number 6591 explicitly? For example like so:
4. Reporting Format, Update to RFC 6591
This kind of thing is very useful for those following the Updated-by chain.
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.
Agreed. Keynotfound was just an example to demonstrate that an extensible
registry might actually make sense. Since we haven't raised any issue with
that type of failure, we have no reason to add it.
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.
Of course, we can never predict what DKIM2 will discover. I've only mentioned
it as a possible source of future extensions to the Auth-Failure field, to show
that a registry might not be such a far-fetched idea after all. OTOH, recall
that DMARC failure reporting has had much wider adoption than other
applications of RFC 6591, so it's natural that this standardization would
somehow complement its specification. Creating a registry, as part of Section
6, is fully within our charter. The question is whether there is consensus
within the WG.
Best
Ale
--
[*] https://www.iana.org/help/protocol-registration#registries
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
