Thanks. Does not surprise me; should have thought to look there. I
found two things of interest when I glanced through that document
(for the first time since 1988, if ever):
(1) It contains what appear to be two definitions, neither of which
is completely consistent with the other or with that IESG statement.
To save others looking through the document, they are:
(from Section 2):
Some protocols have been superseded by better protocols or
are otherwise unused. Such protocols are designated
"historic".
(from Section 5.1.5):
Historic Protocol
These are protocols that are unlikely to ever become
standards in the Internet either because they have been
superseded by later developments or due to lack of interest.
These are protocols that are at an evolutionary dead end.
Of course, RFC 1083, and the definitions it contains, are Historic,
By some definitions that have been proposed, that makes them useless
and inappropriate from which to quote.
I rather like "evolutionary dead end", but, IMO, this further
reinforces my view that we should neither try to come up with yet
another definition of "Historic" nor try to declare that one of the
definition is the One True One going forward: if we want to make
progress, we need a new term, preferable an made-up on that does not
have obvious non-IETF meaning(s).
(2) It also makes a distinction between "state" (e.g., Proposed,
Standard, Experimental) and a "status" (recommended, elective, not
recommended). I don't know why we dropped that (or, less important,
when), but it seems to me that, if we really want to go on an
adventure in reclassifying documents, it might be worth thinking
about a two dimensional structure again -- not necessarily to use to
use it but to inform our thinking about what we want to do and why.
john
--On Tuesday, December 31, 2024 09:51 -0500 Scott Bradner
<sob@xxxxxxxxx> wrote:
> fwiw - the term "historic" relative to RFCs shows up in RFC 1083
>
> Scott
>
>
>> On Dec 31, 2024, at 1:21 AM, John C Klensin <john-ietf@xxxxxxx>
>> wrote:
>>
>>
>>
>> --On Monday, December 30, 2024 17:29 -0800 Rob Sayre
>> <sayrer@xxxxxxxxx> wrote:
>>
>>> John C Klensin <john-ietf@xxxxxxx> wrote:
>>>> But, if we have to assign a label for some reason, "UNKNOWN"
>>>> probably isn't automatically it because, like "HISTORIC" [...]
>>>
>>> FWIW, I like this one. I think we could say "UNKNOWN" and
>>> "HISTORIC" are synonyms.
>>
>> But they are not because "HISTORIC" was intentionally assigned
>> (although, as the IESG statement you quote more or less points out,
>> the particular interpretation of that RFC 2026 text used varied
>> among those documents. Assuming, for the list of documents
>> identified as Historic between the first half of 1992 (RFC 1310 --
>> where the discussion and definitions in 2026 mostly come from --
>> and it implies that the term was in use much earlier but I don't
>> have time to try to do the research) and now, that the term has
>> the same meaning for each would be, well, silly.
>>
>>> My context goes back pretty far (maybe 20 years), but others have
>>> a lot more context than that.
>>
>> Depending on how one counts, I'm pushing past 50 but, after a
>> while, it stops making a difference.
>>
>>> I think the question here is whether "HISTORIC" means
>>> "MONUMENTAL". No, it does not, in this case. We could say
>>> "CURIO", but that's not quite right either.
>>>
>>> One could go for terms like "ANCIENT", "ARCHAIC", or "RELIC". All
>>> of these denigrate the original text a little bit, so they don't
>>> feel right to me. I think we should refine "HISTORIC". The current
>>> definition is here:
>>>
>>> https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on
>>> -d esignating-rfcs-as-historic-20140720/
>>
>> Actually, I'd describe that as specifying a mechanism for declaring
>> documents Historic and a way to better document why that was done.
>> The definition there is really not much better than that in RFCs
>> 1310/ 1602/ 2026. It seems to me that there are two additional
>> significant problems.
>>
>> (1) The document uses RFC 821 as an example but, as I read that
>> part of the description, it say that document can never be
>> Historic as long as SMTP is in use. At least once there is an
>> Internet Standard replacement, that can't be write... certainly we
>> don't want to encourage anyone to implement it and try to use it,
>> it isn't current, and it isn't recommended to use.
>>
>> (2) That document says "A document is labelled Historic when what
>> it describes is no longer considered current: no longer
>> recommended for use." But we have a very large number of
>> documents that meet that definition and, proportionately, almost
>> none of them have been so labeled. So that statement is factually
>> false and the document is, well, historic.
>>
>>> I think we should say that "Historic" RFCs may have been written
>>> in contexts we no longer have.
>>
>> Not sure what that would mean either, other than to add yet another
>> collection of documents that use the "Historic" term to mean
>> different things.
>>
>> The traditional --and most effective-- way out of this problem if
>> precision is needed is to define a complete new vocabulary with
>> precise definitions rather than trying to adapt terms that
>> different people will understand in different ways. Being lazy
>> about this sort of thing, I suggest we might use "Historic1",
>> "Historic2", "Historic3",..., create a glossary that defines each
>> precisely, and then describe "Historic" as a generic category that
>> subsumes all of those and maybe others and that is no longer newly
>> applied to individual documents.
>>
>> john
>>
>>
>
