RFCs are published as ASCII text documents. But different formats may be available for the RFC as well, which can contain graphical diagram and other elements. But as per the guidelines, the ASCII text version of the RFC should be treated as the definitive reference.
The archive of RFCs is maintained by RFC Editor. The web site for the RFC editor is
RFC Editor is the publisher of the RFCs and is responsible for the final editorial review of the documents.
Non-standard track RFCs are further categorized into Best Current Practice RFC (BCP), and Informational RFC (FYI).
Standard Track RFC
Standard Track RFCs document Internet Standards. These RFCs form the 'STD' sub-series of the RFC series. When a standard track RFC gets accepted as a standard it gets an additional STDxxx label (where xxx is a number) in addition to the RFC number it had been assigned when it was proposed.
Non-Standard Track RFCs
Best Current Practice RFC
Some RFCs standardize the results of community deliberations about statements of principle or conclusions about what is the best way to perform some operations or IETF process function. These RFCs form the specification has been adopted as a BCP, it is given the additional label "BCPxxx", but it keeps its RFC number and its place in the RFC series.
Not all specifications of protocols or services for the Internet should or will become Internet Standards or BCPs. Such non-standards track specifications are not subject to the rules for Internet standardization. Non-standards track specifications may be published directly as "Experimental" or "Informational" RFCs at the discretion of the RFC Editor in consultation with the IESG. Informational RFCs used to be given FYI labels, but this has been dis-continued as of 2011. However, informational RFCs will still be published.
Maturity Levels of RFC
Before any concept is accepted as a standard (whether it is Standard Track, Best Current Practice or Informational), it is first presented as Internet Draft for reviews. It is constantly reviewed and modified until it reaches the final maturity level. Once a RFC has been published as a standard, no further modifications can be made to that RFC. If the matured RFC needs to be enhanced, then a new RFC needs to be submitted which would have a new RFC number.
Submitting a RFC
Submissions for RFCs can come from IETF, IRTF, IAB, or Independent submissions. First the draft versions of the document are made available for informal review and comment by placing them in the IETF's "Internet-Drafts" directory, which is replicated on a number of Internet hosts. After several iterations and revisions these Internet Drafts mature into RFCs.
If a draft remains unchanged in the Internet-Drafts directory or hasn't been published as an RFC for more than 6 months, then it is removed.
THE INTERNET STANDARDS TRACK
RFCs that are supposed to define internet standards go through the Internet standards track, until they are matured enough to become an accepted standard. The internet drafts evolve through a set of maturity levels in the standards track. These maturity levels are -- "Proposed Standard", "Draft Standard", and "Standard". If the recommendation matures to the "Standard" maturity level then it can be regarded as an Internet Standard. There is a set of rules which determine how the Internet draft would move to "Proposed Standard", then to "Draft Standard" and then to "Standard" status.
The Internet standards process
There is a set of guidelines which IESG follows before taking any action, which may result in advancing a RFC from one maturity level to another, removing the RFC or draft from the standards track. Normally an action in standards track is initiated by the recommendation of IETF. The IESG then determines whether the recommended action is applicable for the specification or not. the IESG will also determine whether the requested category, technical content and quality is at par with the RFC standards or not, and may call for technical reviews in order to do this.
The IESG will send a "Last-Call" email notification to the IETF Announce mailing list to submit any comments. The Last-Call period is generally two weeks, or four weeks (if the action was not proposed by IETF), or it may extend the last call period if required.
If an action is approved, a notification is sent to RFC editor to make the changes.
The entry-level maturity for the standards track is "Proposed Standard". After the Internet Draft has been posted for at-least two weeks (allowing sufficient review time for Internet community) it is published by IESG as an RFC with maturity level as "Proposed Standard". A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances to next maturity level.
Implementors should treat Proposed Standards as immature specifications. It is desirable to implement them in order to gain experience and to validate, test, and clarify the specification. However, since the content of Proposed Standards may be changed if problems are found or better solutions are identified, deploying implementations of such standards into a disruption-sensitive environment is not recommended.
A specification shall remain at the Proposed Standard level for at least six months before it can advance to next maturity level.
A specification from which at least two independent and interoperable implementations from different code bases have been developed for all the features specified in the RFC, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. Here "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful.
A specification shall remain at the Draft Standard level for at least four months, or until at least one IETF meeting has occurred, whichever comes later before moving on to the next maturity level.
When a standards-track specification has not reached the Internet Standard level but has remained at the same maturity level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG shall approve termination or continuation of the development effort, at the same time the IESG shall decide to maintain the specification at the same maturity level or to move it to Historic status. This decision shall be communicated to the IETF by electronic mail to the IETF Announce mailing list to allow the Internet community an opportunity to comment. This provision is not intended to threaten a legitimate and active Working Group effort, but rather to provide an administrative mechanism for terminating a moribund effort.
A specification for which significant implementation and successful operational experience has been obtained may be elevated to the Internet Standard level. An Internet Standard (which may simply be referred to as a Standard) is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.
A specification that reaches the status of Standard is assigned a number in the STD series while retaining its RFC number.
Specifications that are not intended to be Internet standards, such as Best practices or Informational RFCs, proceed on the non-standards track. While in this track they can be labeled with one of these "off-track" maturity levels: "Experimental", "Informational", "Best Current Practice", "Historic", or "Unknown". The documents bearing these labels are not Internet Standards in any sense.
Procedures for Experimental and Informational RFCs
Unless they are the result of IETF Working Group action, documents intended to be published with Experimental or Informational status should be submitted directly to the RFC Editor. The RFC Editor will publish any such documents as Internet-Drafts which have not already been so published. In order to differentiate these Internet-Drafts they will be labeled or grouped in the I-D directory so they are easily recognizable. The RFC Editor will wait two weeks after this publication for comments before proceeding further. The RFC Editor may refuse to publish a document which, in the expert opinion of the RFC Editor, is unrelated to Internet activity or falls below the technical and/or editorial standard for RFCs.
The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process. An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution.
An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process
A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level.
BEST CURRENT PRACTICE (BCP) RFCs
The BCP sub-series of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents.
BCP Review Process
The BCP process is similar to proposed standards documents. The BCP is submitted to the IESG for review, and the existing review process applies, including a Last-Call on the IETF Announce mailing list. However, once the IESG has approved the document, the process ends and the document is published. The resulting document is viewed as having the technical approval of the IETF. Specifically, a document to be considered for the status of BCP must undergo the procedures outlined in sections 6.1, and 6.4 of this document. The BCP process may be appealed according to the procedures in section 6.5. Because BCPs are meant to express community consensus but are arrived at more quickly than standards, BCPs require particular care. Specifically, BCPs should not be viewed simply as stronger Informational RFCs, but rather should be viewed as documents suitable for a content different from Informational RFCs. A specification, or group of specifications, that has, or have been approved as a BCP is assigned a number in the BCP series while retaining its RFC number(s).
Changes in the Internet Standards
Revising a Standard
If modifications or enhancements are required to be done in an established Internet Standard, a new version of the standard needs to be formulated. This new version containing all the changes must progress through the full Internet standardization process as if it were a completely new specification. Once the new version has reached the Standard level, it will usually replace the previous version, which will be moved to Historic status. However, in some cases both versions may remain as Internet Standards to honor the requirements of an installed base. In this situation, the relationship between the previous and the new versions must be explicitly stated in the text of the new version or in another appropriate document.
Retiring a Standard
It is possible for an existing standard to become obsolete by another new standard. In this case, or when it is felt for some other reason that an existing standards track specification should be retired, the IESG shall approve a change of status of the old specification(s) to Historic. This recommendation shall be issued with the same Last-Call and notification procedures used for any other standards action. A request to retire an existing standard can originate from a Working Group, an Area Director or some other interested party.
An individual (whether a participant in the relevant Working Group or not) may disagree with a Working Group recommendation based on his or her belief that either
(a) his or her own views have not been adequately considered by the Working Group, or
(b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy.
The first issue is a difficulty with Working Group process; the latter is an assertion of technical error. These two types of disagreement are quite different, but both are handled by the same process of review.
A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s), who may involve other members of the Working Group (or the Working Group as a whole) in the discussion.
- If the disagreement cannot be resolved in this way, any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute.
- If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole. The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing.
- If the disagreement is not resolved to the satisfaction of the parties at the IESG level, any of the parties involved may appeal the decision to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed and with respect to all questions of technical merit.
Incorporation of External specifications
Specification from external groups (such as ANSI, IEEE, ITU-T, or other bodies) may also be incorporated as standard. Any open standard or other proprietary specification which has been accepted as a Industry standard may be intruded as a RFC. In such scenarios IESG has to determine if the new standard is redundant or not, conflicts with existing standard, should not be subject to confidentiality, or intellectual property rights.
Creating Internet standards is a serious business, but once in a while the IETF catches a break and introduces humor in their work. Starting from 1973, IETF publishes a humorous RFC on 1 April (April Fool's Day) of every year. These RFCs are generally submitted by general public and one these RFCs are published as joke RFCs by IETF. These have to be submitted directly to RFC editor and do not have to become a Internet Draft first.http://www.rfc-editor.org/rfcfaq.html#april