[rfc-i] Proper status for pre-IETF RFCs currently with "unknown"

Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail.com
Mon Nov 7 01:52:44 PST 2011

On 7 November 2011 04:38, "Martin J. Dürst" wrote:

> As a totally arbitrary example (and with apologies
> to Dave), let's look at
> http://tools.ietf.org/html/rfc822.

This is actually rather tricky, and as far as I'm
concerned STD 10 + 11 still include RFC 821 + 822
until 5321bis + 5322upd finish that business, or
until the new "two steps" magic does whatever it

Really getting rid of RFC 822 is even harder than
getting rid of RFC 1738 in favour of RFC 3986:

The MIME and HTTP draft standards use the parsing
specified in RFC 822.  With obscure details, such
as empty line <> line consisting of white space,
or "ASCII art consisting of commas can be valid".

Unlike "LEIRIs", where I'd say that this is only
a named W3C XML bug irrelevant for the Internet at
large, the <obs-FWS> was no nonsense, and getting
the STD stamp on 5322 or a 5322bis is still "work
in progress".  The HTTPbis folks are trying to
fix their part of the RFC 822 syntax consequences.

Touching MIME RFCs would be premature before STD 11
consists of RFCs published in this millennium.

There are more subtle points in RFC 822 with real
consequences, e.g., its concept of Resent- header
fields does not strictly agree with the concept in
2822/5322, and this had consequences for RFC 4407,
not limited to an appeal going up to the IAB some
years ago.

The discussion here wasn't about STD 11 + RFC 822,
it was about the "unknown" stamp on old RFCs such
as RFC 1032.  RFC 1032 is seriously obsolete, but
unlike RFC 981 it is NOT stamped as "obsolete" or

The main admin points in RFC 954 + "informational"
RFC 1591 are now covered by the "unknown" RFC 1032,
because they are certainly not covered by RFC 3912.

I'm fine with renaming "obsolete" to "arpanet" or
"legacy", because I'm used to the idea that LEGACY
means "some good stuff known to work for decades".

The discussion here was started by an RFC author
suggesting to reclassify some of "his" old RFCs to
"historic".  It would be very good to do this, as
an indication that it is not one of those tricky
cases such as STD 11, RFC 1591, or RFC 1032.  Just
an ordinary historic protocol not seen in the wild
for ten years, so *please* put a "historic" stamp
on it as suggested.

IMHO it makes sense to (ab)use the IESG as some
kind of plausibility control for such cases:  They
already check new IRTF and independent RFCs for
conflicts with IETF work.  IOW, an author stating
that some of his RFCs are now "historic" could be
wrong, e.g., this could introduce DOWNREFs in old
IETF RFCs, and that MUST NOT happen.


More information about the rfc-interest mailing list