To my understanding Historic is a status change. Obsoletes is not. A status change like Historic implies (an explicit process to) changing the metadata of an RFC. Obsoletes is just metadata on a new RFC but effectively doesn’t change the old one.
What does that mean in practice? For the protocol it means historic should not be used anymore at all no matter what. And if you currently use it you should stop it. Obsoleted protocols might still be in used but there is a newer specification that clarifies or changes things and therefore should update your implementation. However, I guess for the reader it would be useful to have an indication of both. But maybe there is a way to indicate somehow this difference between an actually status change or rather just a link to a newer RFC. Mirja > Am 13.03.2025 um 03:24 schrieb Martin Thomson <m...@lowentropy.net>: > > On Thu, Mar 13, 2025, at 11:06, Pete Resnick wrote: >> I think we need to be careful about Historic. Obsolete is clearly >> strictly metadata and is defined only by the RFC Series, AFAIK. >> Historic, on the other hand, is defined in RFC 2026. While section 4.2.4 >> defines it as one of the "non-standards track maturity levels" like >> Informational or Experimental, sections 6.2, 6.3, and 6.4 describes >> Historic as a part of the IETF Standards Process, and the IESG treats >> moves to Historic much differently than it treats the Obsoletes metadata >> (more like advancements in the Standards Track). Historic has definitely >> been used in ways not consistent with 2026, and either way there is no >> doubt that it would be good if Historic (along with Proposed Standard >> and Internet Standard) status should be shown on RFCs, but we should >> probably tread lightly and avoid "crossing the streams". (A simple >> document clarifying the use of Historic would probably address the >> issue.) > > I'm not sure that I follow this reasoning. There is a different process by > which a document reaches Historic status, but the proposal here is to update > documents to reflect their status. I don't see how a difference in that > process necessitates a different treatment in terms of how it is displayed. > It might make sense to hyperlink the decision/announcement/whatever for a > Historic document, in exactly the way we might point to a replacement RFC > document from an obsoleted RFC. > > If the concern is about whether something that was "Standards Track" now no > longer has that marking (which affects boilerplate potentially), a link to a > document explaining what is (and isn't) updated when the status of a document > changes would seem to address that concern. The RFC this group publishes to > enact this change might serve that function. > > -- > rswg mailing list -- rswg@rfc-editor.org > To unsubscribe send an email to rswg-le...@rfc-editor.org -- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
