The process for publishing an RFC begins when an Internet-Draft is approved by one of the publication streams:
Once a document is approved, it enters the publication queue and is managed by the RFC Production Center (RPC). From this point on, the RPC has change control of the document. This means that the RPC now manages the document in their own repository, and that all changes the authors wish to make must go through the RPC. Any non-technical changes, such as updating the contact information, will normally be accepted directly, but any technical updates will require stream approval.
When a document enters the publication queue, it is assigned an initial state, and this state is updated as the document progresses through the queue. Any time the document's state changes, an automatic email message summarizing the state change is sent to the authors.
The following diagram shows the states, their codes, and the flow through the queue:
The state of a document can include one or more flags and a generation number (more details below).
Sometimes groups of documents are managed together as a cluster. This can be for two reasons:
Clusters can include both documents that are in the queue and those that are either already published or not yet in the queue (shown as NOT-RECEIVED).
Clusters are assigned IDs and linked to each document in the cluster. The Active Clusters page shows the current clusters and the state of each document in the cluster.
A document waiting for a normative reference, such as in a cluster, or stream-specified dependency to enter the queue is placed in MISSREF state. The MISSREF state is further sub-divided by generation numbers:
1G has a reference to a NOT-RECEIVED document2G has a reference to a document that references a NOT-RECEIVED document3G has a reference to a document that references a doc that references a NOT-RECEIVED documentDocuments in a cluster can sometimes wait for a long time for the dependencies on the other documents to be resolved. Once the dependencies are resolved, the document moves out of the MISSREF state and into the EDIT state.
Once a document is approved and submitted for publication, control is handed over to the professional editors of the RFC Publication Center (RPC) and the document moved into EDITstate. They start by putting the document through an extensive editing process with multiple stages.
If the document is not already in RFCXML, it is converted into RFCXML. The RFCXML is examined and may be restructured to ensure consistency and readability. The editors perform the following updates:
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<reference anchor="URI" target="https://www.rfc-editor.org/info/rfc3986">
...
</reference>
is changed to the following:
<displayreference target="RFC3986" to="URI"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
The document is copy edited to find and correct errors and to ensure that the document conforms to the style guide. See Language and Style for specific details.
The references in the document are checked for accuracy and stability and, where needed, edited for correctness.
A document that belongs to a cluster is placed in REF state once its EDIT state has finished until the editing of the other documents in the cluster is complete so that all cluster documents will enter the final quality-control state RFC-EDITOR together.
If the document contains IANA actions, such as creating or updating an IANA registry, then IANA will start their processing when the document is approved for publication. IANA processing usually takes place in parallel with editing, and until the processing is completed, the document's queue state will have the *A (IANA) flag appended to it (e.g., EDIT*A).
Occasionally IANA processing can take longer than editing, for example, if IANA is waiting for a designated expert to respond. In which case, the document will be moved to IANA state, where it will stay until the IANA processing is complete. Once IANA has completed their actions, the document will enter RFC-EDITOR state.
During the final internal review, a senior editor reviews the formatting, copy edits, and the team's proposed questions to authors.
If there is an IANA Considerations section, the senior editor reviews the messages regarding IANA actions, compares the information within the document to the information within the registry, and updates the section. If there are any issues with the IANA registry itself, these are noted for discussion with IANA during the Authors' Final Approval stage.
If there are code components such as YANG modules, XML, ABNF, or MIBs, the senior editor validates them with automated tools and notes any issues to discuss with authors during final approval.
Once the final review is complete, the senior editor lauches the Author's Final Approval stage (AUTH48).
After editing, the document then enters the Authors' Final Approval stage, referred to as AUTH48 as historically this was expected to take 48 hours to complete, though it can take a week or more depending on the authors' schedules. In AUTH48 the changes made by the RPC are shared with the authors for their approval.
AUTH48 begins with an email sent to the authors asking them to complete the following actions:
Instructions are provided on how an author can submit changes and how to give final approval for the document to be published. This process can involve multiple discussions about the edits, alternative edits proposed by the authors and much negotiation.
If the authors make any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes, then the RPC will seek approval for those changes from the originating stream.
AUTH48 finishes when all authors of the document give their final approval.
If it was determined that an IANA registry needed updates, the RPC editor will request IANA make those updates after all author approvals are received.
There may be an occasion when one of the authors is no longer available, in which case the remaining authors can opt for one of the following paths:
Option 3 is typically used in instances where the unavailable author made significant contributions to the document, so the other authors are not comfortable removing the individual from the author list.
There are a number of states that occur in exceptional circumstances.
Sometimes the editors have questions for the authors that need to be resolved before they can move forward with copy editing the document. When this is the case, the document is put into AUTH state until the answers are received from the authors.
Occasionally, at the end of AUTH48 publication of the document is on hold pending the resolution of an issue with the software tools used to create the pubished versions. For example, if there is an error in the PDF generation. In these circumstances, the document is moved into TI state until the issue is resolved.
Editing sometimes raises issues that lead to technical discussions involving the working group and an Area Director. If the delay is significant, the document is put into IESG state until the issue is resolved.
A document may occasionally “fall out” of the queue at any time, e.g., because a working group, an author, or an Area Director requests that it be withdrawn, in which case the state is set to WITHDRAWN.
When an RFC is published it is moved to PUBLISHED state and an announcement is sent to ietf-announce and rfc-dist mailing lists. The URL for the info page of an RFC is of the form: https://www.rfc-editor.org/info/rfcXXXX. The RFC Editor maintains a list of most recently published RFCs (RSS Feed).