I think cases 2 and 3 could be covered by UNSUPPORTED. Case 1 is MATURE. CASE 4 is SUPPORTED. The pathway from SUPPORTED through MATURE to UNSUPPORTED seems clear to me. Lloyd Wood lloyd.wood@xxxxxxxxxxx > On 6 Jan 2025, at 11:27, John C Klensin <john-ietf@xxxxxxx> 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. > > thanks, > john >
