Meng Weng Wong wrote:
Putting an expiration date into an RFC is a
pretty radical move, though. I don't know
if it's been done before.
It has, RFC3701 for example (as an anecdote, the date we picked, 6-6-06,
did not raise much fears of someone rising out of the flames of
somewhere :-). However, I don't remember a single instance of building
an expiration date on the first RFC that describes a protocol. The IETF
is generally not too hot with built-in obsolescence.
Besides, even if a protocol/RFC is being obsoleted by a newer one (which
is the standard IETF way to go), there is no direct relation with what
is being done in the real world about it: I still occasionally bump into
FTP servers that don't implement PASV, for example. And there still are
MTAs that implement RFC 821, not 2821; they should be retired and
eventually will be, but it takes some time.
But legislators do it all the time: they write
laws that expire, and are either renewed at the
time of expiration, allowed to lapse, or are
updated with new language. Why shouldn't RFCs,
the laws of the Internet, do the same?
Don't over-estimate the influence of RFCs. There are numerous domains
where RFCs catch up with what is being done in the field so the IETF
does not look too bad. In the case of SPF, there is enough momentum
about it to proceed without it being an RFC (which it is not as of now
and will take some time anyway).
Time-to-market is everything; SPF has both the running code and the
rough consensus already, IMHO the priority now should be large-scale
deployment.
Michel.