On Wed, 29 Sep 2004, Mark Lentczner wrote:
Hi all -
I don't post much here, so many of you may not know me: I'm your
humble standards editor and co-author with Meng.
Those of us more active from MARID WG know you quite well and would like
to thank you for all your efforts and hard work on protocol draft!
We (Meng and I), as authors of drafts that were part of the MARID
working group, have been asked to "put forward their documents as
non-working group submissions for Experimental RFC status".
Experimental RFC status is granted to a draft that "is part of some
research or development effort" and "is published for the general
information of the Internet technical community and as an archival
record of the work" (to quote RFC 2026).
Experimental RFCs can include both existing experiment and what is expected
to be conducted in the short term future. Existing is more important in
general but most experimental RFCs seem to have been published on sonething
that is just starting as a way to encorage the development of that
experimental. Archival-only experimental RFCs I think that part of RFC
is understand as that its intention that information about experiment be
kept for archival purposes even if experiment does not succeed.
The question before me is, what do I include in such a submitted draft?
I would say that SPF Classic v1 definetely deserves to go to experimental
RFC status so that those who are using this know exactly what it is and
even if we move to SPF v2 we'd have an archival record of what v1 was.
That probably means you will need to incorporate apporpriate comments
regarding marid-protocol draft text (but not anything that would change
how SPFv1 works) into http://spf.pobox.com/spf-draft-200406.txt.
Make sure the draft is called "spf1" and specifically says "Sender
Plicy Framework (SPF) version 1.0" in the title.
Separately from that we need to consider what to do with MARID work.
This depends quite a bit on what we want to do as far as moving
from SPF1 to UnifiedSPF. It can be considered that MARID drafts
were first steps toward UnifiedSPF, however the only drafts that
you actually done for marid as far unified spf scoping system goes
are marid-protocol and marid-mailfrom. Both of these together is
basicly the same as SPFv1 and publishing those two if you publish
existing SPF1 does not make sense.
I think it would be better to work further on UnifiedSPF first and
come to the consensus on what will be included in this system. This
includes both decision on syntax for supporting UnifedSPF scoping
and if there is really a need to create entirely new SPF version
record or if it can be done as upgrade to existing spf1 allowing
people to use existing base of spf1 records. This means decisions
on what identities would be checked as part of Unified SPF and
drafts (similar to marid-mailfrom) for each of those identities
and a separate draft on what "unified" really means and how results
of verification of one identity would change results of another.
Once we have UnifiedSPF worked out drafts about it would need to be
published and only after drafts are published for several months
and we actually have working code for unified spf (remember -
experiment requires working code!) then on 2nd or 3rd version of
drafts it would make sense to ask them be published as EXPERIMENTAL RFC.
That means probably a wait of 2-6 months between publishing SPFv1 as
experimental RFC and publishing Unified SPF drafts as experimental RFCs.
Separately from all this, we need to ask appropriate people how to
register DNS record for SPF and what kind of document is needed there.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/