On 06-Jan-25 12:21, John C Klensin wrote:
--On Monday, January 6, 2025 11:33 +1300 Jay Daley
<exec-director@xxxxxxxx> wrote:
On 29 Dec 2024, at 09:57, John C Klensin <john-ietf@xxxxxxx> wrote:
I think that there are two levels here and this is where the term
fails:
1) the protocol is done, and extensions are unwelcome.
(keep using it as you prefer).
2) the protocol is unsafe and not only should you not extend it,
but you need to plan to stop using it.
There are at least two more:
3) The protocol is obsolete and no one cares any more but, while
there is nothing inherently unsafe about it, we advise against its
use. Example: there is nothing fundamentally wrong with RFC 594,
at least if one has a working IMP floating around (but those
devices are, themselves, Historic).
4) The protocol specification has been superceded by newer
specifications but the document is still identified as Standards
Track (sometimes even Internet Standard) and there is nothing
unsafe about it (at least any more so than the successor
documents).
In most cases we mean (1), but the industry hears (2).
Except when we mean (3) or (4) -- or should be using some variation
on "Historic" but have not bothered -- in which case "the industry"
just gets confused and maybe questions either our sanity or
willingness to take responsibility.
In software releases, all four of these cases would be covered by
the term "deprecated".
More or less, yes (and I think your observation is very helpful
although possibly not for the reason you intended).
The first of the four is a little marginal because "deprecated" has
some negative implications while the first might just be "frozen".
For software -- which RFC specifications are not -- "frozen and we
aren't going to fix any bugs that might appear" might have some
negative implications, but might also mean "carefully tested and,
after long experience, believed (with high confidence) to either be
bug free or that any bugs are known and tolerable". For a technical
specification, much closer to the latter since there is no
implication in (1) of "you should stop using this" which "deprecated"
certainly implies.
Is that hair-splitting? Absolutely so, but that was, to a
considerable extent the point. If we are ok with a fuzzy definition
that leaves doubt about exactly what is meant, "deprecated" is
probably ok, but so is "historic". If we think precision is
important, then we probably need to invent some new terms rather than
trying to find a single, blanket term that is least pessimal for the
collection of cases being covered.
There are many shades of grey on this bikeshed, but I think we can agree
that "Historic" as a catch-all category was always a bad choice.
Plato's "Metaphysics" is historic but certainly not deprecated. RFC 3068
is "HISTORIC (changed from PROPOSED STANDARD)" and "Obsoleted", but you
have to read RFC 7526 to know that it's deprecated, and to discover that:
In this document, the word "deprecate" and its derivatives are used
only in their generic sense of "criticize or express disapproval" and
do not have any specific normative meaning. A deprecated function
might exist in the Internet for many years to allow backwards
compatibility.
I think we need to decide on a better set of magic words, and then
retrofit them to the RFC metadata.
Brian
