Thanks Brian and Pete All of this points me back to the original proposed solution with Paul’s change blended in:
- For pre-8650 RFCs (when RFCXML was introduced) if an RFC is either Obsoleted or categorised as Historic, then for PDF and Plain Text a new page should be appended to the front that states that and nothing else should change, whereas for HTML/HTMLised the header itself should change (so that this now differs from the PDF/Plain Text header). - For post-8650 RFCs (those using RFCXML as the definitive format) is an RFC is either Obsoleted or categorised as Historic then the publication Formats should be regenerated with the correct header. This is intended as a compromise between the various competing concerns around being fair to consumers, practicality of changing documents, and concerns about the slippery slope of mutability. For the STD 10 and STD 11 exceptions, that seems to me a stream decision that we should document as an allowed, though exceptional, choice. Jay > On 14 Mar 2025, at 11:57, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > On 14-Mar-25 10:59, Jay Daley wrote: >> So that I understand correctly, is this the current position? >> 1. An RFC can be (Standards Track, Best Current Practice, Informational, >> Experimental) and Obsolete > > Yes, but technically it's Obsoleted, because it's always "Obsoleted by > RFCxxxx". > >> 2. An RFC cannot be (Standards Track, Best Current Practice, Informational, >> Experimental) and Historic as the latter replaces the former > > Correct, but it can also be Unknown. > >> 3. An RFC cannot be in the STD subseries or BCP subseries, and Obsolete, as >> the latter removes it from subseries, even though it does not change the >> Standards Track or Best Current Practice category > > That's true if and only if the Obsoleting RFC replaces it in the numbered > series. > > That should be "usually". There are exceptions. In fact some can be found in > a list of all obsoleted normative RFCs that are not marked Historic that I > sent a few months ago. Pulling them out: > > The cases of STD10 and STD11: > https://www.rfc-editor.org/info/std10 > https://www.rfc-editor.org/info/std11 > > In these cases the STDs were obsoleted by Proposed Standards. There are > certainly others that my script missed. That's a standards process bug. > > RFC2489 (BCP29): Procedure for Defining New DHCP Options > RFC2611 (BCP33): URN Namespace Definition Mechanisms > RFC3152 (BCP49): Delegation of IP6.ARPA > RFC4148 (BCP108): IP Performance Metrics (IPPM) Metrics Registry > > I believe all of these were obsoleted by documents that were given a > different BCP number or no BCP number. > >> 4. An RFC can be both Obsolete and Historic (e.g. RFC 3300) > > Yes. There are 156 examples, from RFC0675 to RFC6732. > >> 5. The only time the header of an RFC (not the extra HTML header) says it >> is Historic is when it is published as Historic, otherwise the header still >> says (Standards Track, Best Current Practice, Informational, Experimental) > > Yes. > > Brian -- Jay Daley IETF Executive Director exec-direc...@ietf.org -- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
