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...
Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA +1-508-634-2066 (home) [email protected] On Thu, Jan 6, 2011 at 4:45 PM, Doug Ewell <[email protected]> wrote: > Lixia Zhang <lixia at cs dot ucla dot edu> wrote: > >> PS: on the other hand, what would a "historical status" imply? the ideas >> obsolete? > > Every now and then, someone proposes to move a given RFC to Historic, > not merely to reflect an observation that a process or protocol is > obsolete, but as an active attempt to deprecate it, regardless of its > currency or relevance. > > I remember a few months ago, it was proposed (evidently not for the > first time) to move FTP to Historic, on the basis of its lack of > airtight 21st-century security features, with no consideration for the > innumerable existing systems and processes that have no need for > top-notch security, and rely daily on FTP. > > I often see comments on this list about whether the "outside world" > views the IETF as irrelevant. Declaring a commonly used, core process > or protocol as Historic because something better exists might be a > perfect example of this. > > -- > Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org > RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s > > > _______________________________________________ > Ietf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
