--On Sunday, January 5, 2025 19:41 -0800 touch@xxxxxxxxxxxxxx wrote: > Hi, John, > >> On Jan 5, 2025, at 7:29 PM, John C Klensin <john-ietf@xxxxxxx> >> wrote: >> >> 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 > > But then we need to define the terms and inevitably will find > ourselves back to the same problem. Up to a point, yes. But we at least then don't need to try to overcome years of history and knowledge about what words mean everywhere else. > I do like terms that try to avoid ambiguity, so nuances like > "deprecated" vs "superseded" are not helpful, IMO. Agreed. And I like your two-dimensional idea too. > The ones I provided I believe are relatively unambiguous: > protocols: > experimental > proposed standard > standard > legacy > not recommended (could be "hazardous") I think that works but see below and note that, even among these, "proposed standard" today is a relatively mature document with the expectation in many cases of one or more tested implementations, while, back in the early 1990s, a document could get into that category when it was not much more than a design proposal as long as there were no known outstanding design issues, was well-understood, etc., with no requirement and usually no expectation of implementations of implementation or operational experience (see RFC 1310 Section 3.2.1). So even that set of terms may be relatively unambiguous, but only relatively so. One also needs to account for Informational and BCP documents, which can also descend into "legacy", "not recommended", or "path not chosen" (which is really neither of those two), or, at least in principle in the former case, ascend into Proposed Standard or BCP. > documents: > (no label) implies current > "revised by" indicates a better document is available > > Documents are revised when needed, but there is NO reason to say > that the spec for NFSv3 is "revised by" the spec for NFSv4. We > revise documents as we did for RFC793 and RFC2401, but NOT (IMO) > when we create a new protocol per se. The spec for NFSv3 is not > "revised" by the spec for NFSv4; the *protocol* is. That case is clear but consider two others (about which I'm obviously sensitive) and tell me where they fit: (i) RFC 1425 adds a command and significant logic to RFC 821. RFC 821 had no provision for that sort of change. In 1993, RFC 1425 was not listed as updating 821; today it probably would be. However it clearly revises 821 somewhat even though it does not in any way replace it. At the time implementations of 1425 started to appear, we hoped that no one would implement 821 alone because 1425 provided new and important features, but 1425 was no a "better document" than 821 because it merely added functionality in a forward-compatible way. To further complicate this example, RFC 974 updated 821 by changing the mail routing architecture but is not listed as having updated/revised it and, AFAIK, the use of the mail routing mechanism described in 974 did not become the required replacement for that described in 821 until RFC 1123 (which is not listed as updating either of them). Tell us how your proposed system would deal with that can of worms and others like it, at least without case by case reanalysis of every older protocol. (ii) Moving on, we have RFC 5321 which succeeded (sic) RFC 2821, which revised and replaced, not only 821 and 1869 (the replacement for 1425 once removed) but RFC 974. Now 5321 is clearly a "better document than" 2821, but its relationship to the earlier specs is a bit unclear. FWIW, there has been an extended discussion on another list initiated by someone who has insisted that it is perfectly reasonable to implement RFC 821 today because, while it is listed as being obsoleted by 2821, is still an Internet Standard (as part of STD0010). The other two parts of STD0010 are RFC 1869 (see above), also listed as an Internet Standard, and RFC 974 which someone managed to get classified as Historic. At a very minimum, the above suggests to me that we have made rather a mess that mere juggling with terminology is not going to fix unless we have enough terminology categories to deal with some rather odds cases or combinations of them. best, john
