Fwd: IESG Statement on Designating RFCs as Historic [#254]

FYI. Our drafts state that they will obsolete 2145 and 2616, so we need to decide if we want to explicitly move them to Historic. We also have ticket #254, "move RFC 2817 to Historic status" <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/254>, so I'll add these to that ticket.

Cheers,



Begin forwarded message:

> From: IESG Secretary <iesg-secretary@ietf.org>
> Date: 28 June 2011 2:21:33 AM AEST
> To: IETF Announcement list <ietf-announce@ietf.org>
> Subject: IESG Statement on Designating RFCs as Historic 
> 
> Date: 27 June 2011
> 
> RFC 2026 states the following:
> 
> A specification that has been superseded by a more recent specification 
> or is for any other reason considered to be obsolete is assigned to the 
> "Historic" level.
> 
> In practice, the Historic status is not automatically assigned to RFCs 
> that have been "obsoleted". That is, when an RFC that contains the 
> "Obsoletes: RFC XXXX" header is published the RFC editor does not 
> automatically apply the Historic status to the XXXX RFC. Note that in 
> some situations this is perfectly acceptable because multiple versions 
> of an Internet Standard are permitted to "honor the installed base," as 
> per RFC 2026.
> 
> If authors wish to change the status of RFCs that are in the obsoletes 
> header to Historic, then the authors must include an explicit statement 
> for the RFC editor to do so; preferably in the abstract and 
> introduction. Further, when an AD sponsors a draft that includes the 
> obsoletes header, then the AD should ask the authors whether the authors 
> intended to move the RFC(s) listed in the obsoletes header to Historic 
> status.
> 
> If an author wishes to publish a document directly to Historic status 
> the preferred approach is to publish an I-D with the "Intended Status: 
> Historic" in the header.
> 
> As allowed by RFC 2026 Section 6.4, anyone may request that the IESG 
> move an RFC to Historic that is simply and obviously obsolete (and in 
> A/S terms "not recommended") without the need to produce an internet-
> draft. The IESG can issue Last Calls to request that the RFC in question 
> be moved to Historic.
> 
> If a document (whatever its intended status) moves another document to 
> "Historic" status, the Last-Call should go out saying, "Last 
> Call:<draft-blah-blah-blah> to Informational and RFC XXXX to Historic", 
> the document should be handled as a Protocol Action on the IESG agenda 
> using IESG Protocol Action procedures, and a "Protocol Action" 
> announcement should be sent out when the document is approved.
> 
> Moving a document to Historic status means that the document is "not 
> [an] Internet Standards in any sense," as per RFC 2026. 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 29 June 2011 03:39:37 UTC