[JaumeGreen]

What I dislike of RFCs is that some are accepted, but still referred as RFC, for no apparent reason.

I specially dislike when some people try to do the same with internal documentation and still call "RFC 2029 Project Lifecycle" when it has been accepted by all the appropriate parties. It makes it harder to look for than needed, and it's not clear, by the name, if it has been passed or not.

[goku12]

They were going to have to choose a name for the entire document series, irrespective of the stage of evolution each document is in. I don't have a good answer to why they choose RFC for it, though a sibling comment does address that part. What you're looking for is an indicator for the stage in its evolution. That is fulfilled by the RFC's 'Status' [1][2]. You can use it as a search criterion on the rfc-editor website [3].

[1] https://www.ietf.org/process/rfcs/#statuses

[2] https://www.rfc-editor.org/rfc/rfc2026#section-4.1

[3] https://www.rfc-editor.org/search/rfc_search.php

[jibal]

Try this prompt: "I think there was a discussion that led to Steve Crocker naming "RFC" that ... do you have information on the discussion?"

[goku12]

You can do that prompt if you want to. I'm adding the information that I already know.

[jibal]

You wrote "I don't have a good answer to why they choose RFC for it" ... with that prompt you will get a summary of the reasons they chose it, with direct quotes from Steve Crocker and citations, all of which can be checked for accuracy.

But sorry for trying to be helpful. No good deed goes unpunished, as they say.

[goku12]

> But sorry for trying to be helpful. No good deed goes unpunished, as they say.

If that was your intention, I apologize. I misunderstood what you were trying to say. But looking at the score on that comment, I don't think I'm the only one who misunderstood it. These comments may need a bit more effort to avoid this confusion. Meanwhile, please don't take it personally - I wasn't trying to insult or be disrespectful. I was just trying to convey that it was annoying. Anyway, thanks for the pointer! I will check it out.

[jibal]

I appreciate the apology ... but the problem isn't a lack of effort on my part. Many people here make little effort to understand what others are trying to convey and take a hostile uncharitable attitude at a drop of the hat, especially at the mere suggestion that anyone might conceivably derive any benefit from an LLM. I myself am a close follower of Gary Marcus and have extreme reservations about the technology, but the fact is that for now they are useful tools.

BTW, you might want to look at a recent comment of mine,

https://news.ycombinator.com/item?id=45636185

It's because of my familiarity with RFCs and Steve Crocker, who originated the idea, that I had a recollection that he had discussed why they were called that, and prompted the LLM for details.

[ekr____]

This is only a tiny part of the trainwreck that is IETF and IETF-adjacent document nomenclature.

IETF documents start as Internet-Drafts, which officially are just draft documents that can be changed at any time. As a practical matter, some I-Ds really have no status and some have been accepted by WGs to work on. You can tell which are which because (mostly) the latter are named draft-ietf-something. As WG documents progress, it's not uncommon to see very wide deployment based on an I-D (this was the situation for QUIC and TLS 1.3), whereas other drafts are just totally half-baked and nobody is deploying. There is no good way to know which is which without paying attention.

Inside the IETF, RFCs can be published be any of Standards Track, BCP, Informational, or Experimental. Nominally, the first group are really standards (see asterisk below), whereas the BCPs are normative but not really standards (e.g., they might describe how the IETF is supposed to run), whereas the latter two are not standards. Except sometimes they are de facto standards, like RFC 6962, specifying Certificate Transparency (note that there is another RFC for CT, RFC 9162, which nominally supercedes RFC 6962, but is not widely implemented). There are two standards levels, Proposed Standard, and Standard (there used to be a middle one, Draft Standard), but as a practical matter lots of specifications stay at PS forever because the WG or authors can't be bothered to get them promoted to full standard. QUIC, TLS, and HTTP are all Proposed Standards.

Moreover, there are other IETF-adjacent organizations that publish RFCs, such as the Internet Architecture Board (IAB) and the Internet Research Task Force (IRTF). These documents aren't standards at all. Finally, there is an Independent Submissions Editor (ISE), appointed by the IAB, who basically can publish whatever he/she wants on the Independent Stream. Note that this is different from an Individual Submission, which is a document processed by the IETF without going through a WG.

[lanyard-textile]

The discussion continues for the lifetime of an RFC, even after its acceptance. The idea is to continually keep it in a challenged state so that we remember anything can be possible.

If we desire something new, the RFC invites us to build upon it and not accept it as gospel.

Whether you, your project, or your organization accept it is completely disconnected with the concept of the RFC. You may procedurally accept it as unchallengeable gospel, but the truth remains that you can always have an opinion about it regardless.

[CaptainOfCoit]

The nicer format is "X Change/Improvement Proposal" or something similar, shorted to "XCP/XIP". Not sure where it originally comes from, but is pretty popular in various protocol circles, Bitcoin Improvement Proposal (BIP) is one example.

[goku12]

There are NIPs (for Nostr), PEPs (for Python)... But they all have the problem that parent is complaining about. The possibilities/proposal part of the names remain even after they have been accepted or rejected.

[CaptainOfCoit]

It kind of makes sense! First you make a proposal, and then it's a accepted proposal or rejected one. Just because it changed state doesn't mean it's no longer a "proposal".

Compared to a RFC. If it's accepted/rejected, it's still a RFC, which isn't really true anymore, comments are no longer requested.