On 1/7/11 7:39 AM, Mykyta Yevstifeyev wrote: > 07.01.2011 8:30, Donald Eastlake wrote: >> I have also seen attempts to make a standard Historic with the >> supposed reason being to "clear things out" for the introduction of >> some better replacement. That seems like just nonsense to me. If it is >> so obvious that a replacement is superior, the replacement document >> can do the move of earlier document to Historic... > As I've mentioned before, I think that the problem is the definition > of Historic status. It is not correct. It duplicates the obsoleted-by > status (if that can be called like this). It is really inappropriate > for its real reason - indicating the deprecated (but not obsoleted) > docs. Moreover, 'obsoleted' means the same as 'deprecated' or > 'non-current' (see http://www.synonym.com/synonyms/obsolete/ or > http://dictionary.sensagent.com/obsolete/en-en/#synonyms). So it is a > problem in RFC2026. As an exercise some time ago, we looked at the 2000 RFCs to determine which of the Proposed Standards could be deprecated. We found 61 out of 125 such memos could be marked as Historic, the point being that we wanted to the RFC Editor series to reflect the fact that in the IETF's opinion, nobody was using the work. Not that the work was bad or broken. In this case, it would have been impractical to list 61 documents as "Obsoletes/Obsoleted-by". See RFC-4450 for a more complete description of what happened. Eliot _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf