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. I do like terms that try to avoid ambiguity, so nuances like “deprecated” vs “superseded” are not helpful, IMO. The ones I provided I believe are relatively unambiguous: protocols: experimental proposed standard standard legacy not recommended (could be “hazardous”) 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. Joe
