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.
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
On 17 Oct 2024, at 16:09, Murray S. Kucherawy wrote:
I think that's a safe change to make to the already-approved document. Please proceed.-MSK
On Thu, Oct 17, 2024 at 2:41 PM John C Klensin <john-ietf@xxxxxxx> wrote:
--On Wednesday, October 16, 2024 11:55 -0400 Barry Leiba
<barryleiba@xxxxxxxxxxxx> wrote:
> Just on one point:
>
>> That does suggest one addition to the document. In Section 1.2,
>> the paragraph starting "It obsoletes" should perhaps contain an
>> additional sentence explicitly removing the "Internet Standard"
>> status from RFC 821. If that is needed, draft-emailcore-rfc5322bis
>> should be similarly patched. Do you (and others) think such a fix
>> would be desirable?
>
> I do think this would be easy and a good idea (and otherwise
> harmless), particularly given how many people still consider RFC 821
> (and 822) to be the standard(s).
Based on the above and my own instincts, I'm tentatively making that
change in the working draft. It seems to me that, as Barry suggests,
it would be helpful in some cases and, absent adding another line or
two to an already too-long document, harmless in any others.
However, as I suggested above, Murray or the WG should decide
whether, to maintain consistence between the two documents and in RFC
metadata, a late patch should be made to rfc5322bis. IMO, it would
be quite sad (as well as a waste of IESG and RPC time) to see an
errata report posted within hours after rfc5322bis is published
pointing out the omission.
thanks,
john
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
