--On Thursday, October 17, 2024 23:58 -0500 Pete Resnick <resnick=40episteme.net@xxxxxxxxxxxxxx> wrote: > I think I disagree with this, on a purely procedural ground: > Obsoleting is not a formal part of 2026; it's a claim in a document > that it makes a previous document obsolete. Moving a document to > Internet Standard is a formal part of 2026 (or 6410 if you like) > which declares a status and assigns an STD number to it. In this > case, we are removing the STD numbers from two documents, STD 10 > from 821 and STD 11 from 822, and assigning them to these two new > documents. That's a Protocol Action that is outside of the document > itself. That should be mentioned in the Protocol Action > announcement, and the RFC Editor should do the right thing their > Internet Standard status page, but it doesn't need to be said in > the document. Compare RFC 9293, which is now STD 7, and obsoleted > RFC 793, but nowhere does it say that it is "removing the Internet > Standard status" from 793. > > I say leave things as they are in the document. Pete, The only thing that causes me to feel strongly about this is that encountered a situation fairly recently where someone claimed that an implementation that conformed to RFC 5321 was incorrect because RFC 821 was the Internet Standard for mail transport by SMTP. In an odd way, your example involving using RFC 793 supports my point: if you retrieve the text form rfc-index from the RFC Editor site, you will find that, while the "STD 7" designation is gone, the Status listed is not, e.g., Historic but "Internet Standard". Same issue if one goes to https://rfc-editor.org/ end enters "793" in the search box: the page that turns up says "Internet Standard" in the Status column. Now if, in one of your other capacities, you want to push through a rule that says that, when one document obsoletes another, the status of the obsoleted one is changed to Historic (or something else, but not a BCP or Standards Track designation), I'd be delighted. Of course, that would need IESG and RSAB signoff, community consensus or at least consultation, possibly a published document, etc. That should ideally get done before IETF 121 ends so as to not hold up either 5322bis or 5321bis. I would, of course, also like a pony. best, john > > pr -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
