I think that there are three sets of proposed state changes - what the author would like to do, what the working group if any agrees to do, and what the IESG wants to instruct the RFC Editor should ultimately be done. There is no reason they all have to be the same. For example, a document author might want to make a document a proposed standard, the working group decide it should be informational, and the IESG decide that at most it wants to make the document experimental - or make the document it obsoleted historic(al). Rather than put more data into the Internet Draft, I would suggest putting the Working Group's view into the Shepherd's Report, and the IESG's view into the announcement and the note to the RFC Editor. On Jun 2, 2011, at 12:17 PM, Sean Turner wrote: > The IESG is considering making this statement on the IESG Handling of Historic status. > > We would appreciate community feedback. > > Please can we have feedback by Thursday 9th June. > > Thanks > > spt > > <statement begins> > > 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. > > Moving a document to Historic status means that the document is "not [an] Internet Standards in any sense," as per RFC 2026. > > </statement ends> > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf