Re: [apps-discuss] Updating the status of SPF

[Frank Ellermann <[e-mail]>]

On 8 August 2011 20:22, Murray S. Kucherawy wrote:

> So far as I’m aware the only changes needed from that document are the
> creation of an extensions registry, some minor editorial stuff, and
> some kind of resolution of the IESG Statement that was added to it to
> address the collision with Sender ID (RFC4406/7).

Yes, the IESG review of the "errata hosted elsewhere" (= openspf.org)
resulted in "submit new RFC"; only HTTP got away with the slightly odd
approach of "hosting errata elsewhere".  Of course it was not odd when
the HTTP folks did it, but admittedly it is not more state of the art.

A new RFC can adopt the collected errata, and report various results
of the experiment, e.g., the test suite, a reference implementation,
and the missing EAI followup (= expired I-D unrelated to new EAI work).

IMHO 0.01% SenderID vs. 16% SPF in a DNS survey published 2010 is now a
not completely irrelevant result -- that SPF started earlier will never
change, and at some point in time adoption has to mean something.

DKIM started after SenderID, and it is already far beyond this level in
the same study.  It's not something that should be mentioned in an RFC,
but it is a motivation to work on a refresh version covering all errata,
and with updated references, e.g., RFC 5321/2 instead of RFC 2821/2.

The SPF modifier registry could be also started in a MARF RFC, starting
a registry as soon as it *might* be used can be too early if it is in
fact never updated later, starting it as soon as there is more than
one RFC needing values in the same namespace could be a good plan.
But for
the SPF modifiers it would be clearer to start the registry in 4408bis,
if that is possible, because the MARF use case are "special modifiers",
not the place where readers would expect details of a general concept.

-Frank