Again, this is just proving my point so, once again and then I will
stop. _Any_ words we pick that have well-known external meanings and
connotations will be problematic. I think I agree with Brian about a
new set of magic words, but am suggesting they really need to be
IETF-unique (a close approximation to "magic" in this context).
Recommendation for consideration with the understanding that I don't
have any attachment to the words before the digit (and it is clearly
too long a string):
IETFStatusCategory1
IETFStatusCategory2
IETFStatusCategory3
IETFStatusCategory4
...
and as many more of those as we thing we might need. If we think
there might ever be more than nine, "01"..."04" might be better.
Then, with the advantage that no one could conclude that they knew
what those terms meant without looking them up (unlike, e.g.,
"Accepted", "Deprecated", "Superceded", or the not-yet-proposed
"Toadstool"), we write clear definitions of each and put them
somewhere easily found and/or prominently referenced. One important
statement needs to be past of that set of definitions, which is that
the digits have no ordinal value at all, i.e., "IETFStatusCategory1"
in not, in any inherent way, superior or inferior to
"IETFStatusCategory3" and "IETFStatusCategory2" is not somehow
intermediate between the two.
john
--On Monday, January 6, 2025 12:26 +1000 George Michaelson
<ggm@xxxxxxxxxxxx> wrote:
> Recommended
>
> Accepted
>
> Deprecated
>
> Not recommended
>
> Don't like supported has other readings
>
> On Mon, 6 Jan 2025, 11:54 Brian E Carpenter,
> <brian.e.carpenter@xxxxxxxxx> wrote:
>
>> 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
>>
>>
>>
>>
