If the problem we are trying to solve is how developers decide which RFC to
implement in this situation, perhaps all we need to do is make sure that the
status conveys all the relevant information. The rfc-index file currently
lists 821 as
(Obsoletes RFC0788) (Obsoleted by RFC2821) (Also STD0010) (Status: STANDARD)
while 5321 is listed as
(Obsoletes RFC2821) (Updates RFC1123) (Status: DRAFT STANDARD)
All the information is there, but you have to work to track it down. 821 is
listed as obsoleted by 2821, which is listed as obsoleted by 5321. It's
understandable if people miss the point, but the info is all there, so it's an
information presentation issue. We just need to make it clearer.
A simple way to do that would be to say that anything with a STANDARD or DRAFT
STANDARD status should have that status clearly modified by any "Obsoleted"
clause, which should point straight to the most current version. Thus, for
821, we might have:
(Obsoletes RFC0788) ( (Also STD0010) (Status: STANDARD -- Obsoleted by RFC5321)
I think most developers would have a hard time ignoring that phrasing, and it
doesn't require any formal action to change the status of the older draft. --
On Jun 29, 2010, at 5:08 AM, Simon Josefsson wrote:
Phillip Hallam-Baker <hallam(_at_)gmail(_dot_)com> writes:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current system that does not
We could write a draft to move RFC 821 to Historic, though. Then it
would lose its full standard status. Are there any reasons not to do
I don't think we want implementers to read RFC 821 except for historical
purposes, and instead want them to read RFC 5321. Moving RFC 821 to
Historic would convey that message, I believe.
Ietf mailing list
Ietf mailing list