What you should know about the Internet Standards process. - Page 3

By Pete Loshin | Posted Sep 20, 1999
Page 3 of 5   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Part 3: RFCs states and status


RFC State and Status

RFCs can have a state, meaning what kind of an RFC it is; and a status, meaning whether or not the protocol specified in the RFC should be implemented (or how it should be implemented). Valid RFC states include:

Standard Protocol
These are Internet Standards with a capital "S", which means that the IESG has approved it as a standard. If you are going to do what the protocol in the RFC does, you have to do it the way the RFC says to do it. Very few RFCs represent full Internet Standards.
Draft Standard Protocol
Draft standards are usually already widely implemented, and are under active consideration by the IESG for approval. A draft standard is quite likely to eventually become an Internet Standard, but is also likely to require some modification (based on feedback from implementers as well as from the standards bodies) and the authors are supposed to be prepared to deal with that (by making the changes that have to be made).
Proposed Standard Protocol
Proposed standards are being proposed for consideration by the IETF in the future. A proposed standard protocol must be implemented and deployed, so it can be tested and evaluated, to be given proposed standard state. Proposed standards almost always get revised (sometimes revised significantly) before advancing along the standards track.
Experimental Protocol
Experimental RFCs describe protocols that are not intended for general use, and that are, well, considered experimental. In other words, don't try this at home.
Informational Protocol
Informational RFCs are often published without the intention of putting the protocol on the standards track, but rather because they provide useful information for the Internet community. For example, the Network File System (NFS) protocol was published as an Informational so that implementers other than Sun Microsystems could build NFS clients and servers.
Historical Protocol
Though most of the other designations are included in first page of the RFC, an RFC that was once on the standards track can be redefined as historical if the protocol is no longer relevant, was never accepted, or was proved flawed in some way.

The status of a particular protocol relates to how necessary it is to implement. The status levels include:

Required Protocol
A required protocol must be implemented on all systems.
Recommended Protocol
All systems should implement a recommended protocol, and should probably have a very good reason not to implement it if they don't. It's not really optional, but it's not entirely required either.
Elective Protocol
A system may choose to implement an elective protocol. But if it does implement the protocol, the system has to implement it exactly as defined in the specification.
Limited Use Protocol
Probably not a good idea to implement this type of protocol, because it is either experimental, limited in scope or function, or no longer relevant.
Not Recommended Protocol
Not recommended for general use. In other words, there's probably no good reason for you to implement this protocol.




Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter