Recent Articles



































Request for comment



         


Alternate meaning: BambooWeb:Requests for comment

A Request for Comments (RFC) document is one of a series of numbered Internet informational documents and standards widely followed by commercial software and freeware in the Internet and Unix communities. The RFC series of documents on networking began in 1969 as part of the original ARPA wide area networking (ARPANET) project. Today, it is the official publication channel for the Internet Engineering Steering Group, Internet Architecture Board, and the broader Internet community. RFCs cover many topics in addition to Internet Standards, such as introductions to new research ideas and status memos about the Internet.

RFCs are published by the RFC Editor who is under the general direction of the IAB. Once published and issued a number, an RFC is never canceled or depublished; it is simply superseded by the publication of a new one. To determine which RFCs are actually active Internet standards and which ones have been superseded, one must consult the official list, Internet Standard 1 (STD 1), which itself is republished regularly as an RFC.

RFCs can be obtained on the Internet from http://www.ietf.org/rfc.html or many other sites, using anonymous FTP, gopher, and other Internet document-retrieval systems.

Every RFC is available as ASCII text and may be available in other formats, depending on the author. The definitive version of any standards-track specifications is always the ASCII version.

The RFCs are produced in a process that is different from that used in formal standards organizations such as ANSI. They can be floated by technical experts acting on their own initiative and reviewed by the Internet at large. Practically speaking, standards-track RFCs are usually produced by experts participating in working groups which first publish what the IETF calls Internet-Drafts; this facilitates initial rounds of review before documents become RFCs.

The RFC tradition of pragmatic, experience-driven, after-the-fact standard writing done by individuals or small working groups has important advantages over the more formal, committee-driven process typical of ANSI or ISO.

Emblematic of some of these advantages is the existence of a flourishing tradition of joke RFCs. Usually at least one a year is published, usually on April Fool's Day.

The RFCs are most remarkable for how well they work - they manage to have neither the ambiguities that are usually rife in informal specifications, nor the committee-perpetrated misfeatures that often haunt formal standards, and they define a network that has grown to truly worldwide proportions.

For more details about RFCs and the RFC process, see RFC 2026, "The Internet Standards Process, Revision 3".

RFC 1, entitled "Host Software", was written by Steve Crocker from the University of California, Los Angeles, and published on April 7, 1969.

A is available from the IETF website. Any published RFC can be directly found by appending the number to the URL: http://www.ietf.org/rfc/rfc#.txt. Replace # with the RFC number. See also this link: http://www.ietf.org/rfc/ .

[Top]

List of the most important RFCs

RFCSubject
RFC 768 User Datagram Protocol
RFC 791 Internet Protocol
RFC 792 Control message protocol
RFC 793 Transmission Control Protocol
RFC 821 Simple Mail Transfer Protocol, obsoleted by RFC 2821
RFC 822 Format of e-mail, obsoleted by RFC 2822
RFC 826 Address resolution protocol
RFC 894 IP over Ethernet
RFC 951 File Transfer Protocol
RFC 1034 Domain Name System - concepts
RFC 1035 DNS - implementation
RFC 1122 Host Requirements I
RFC 1123 Host Requirements II
RFC 1191 Path MTU discovery
RFC 1256 Router discovery
RFC 1323 High performance TCP
RFC 1350 Trivial File Transfer Protocol
RFC 1403 BGP OSPF Interaction
RFC 1498 Architectural discussion
RFC 1518 CIDR address allocation
RFC 1519 Classless inter-domain routing
RFC 1661 Point-to-Point Protocol
RFC 1738 Uniform Resource Locators
RFC 1771 A Border Gateway Protocol 4
RFC 1772 BGP application
RFC 1789 Telephone over Internet
RFC 1812 Requirements for IPv4 Routers
RFC 1889 Real-Time transport
RFC 1905 Simple network management protocol
RFC 1907 MIB
RFC 1918 "Network 10"
RFC 1939 POP3
RFC 2001 TCP performance extensions
RFC 2026 Internet Standards process
RFC 2045 MIME
RFC 2046
RFC 2047
RFC 2048
RFC 2049
RFC 2060 IMAP4, obsoleted by RFC 3501
RFC 2131 DHCP
RFC 2223 Instructions to RFC Authors
RFC 2231 Character Sets
RFC 2328 OSPF
RFC 2401 Security Architecture
RFC 2453 Routing Information Protocol
RFC 2525 TCP Problems
RFC 2535 DNS Security
RFC 2581 TCP congestion control
RFC 2616 HTTP
RFC 2663 Network address translation
RFC 2766 NAT-PT
RFC 2821 Simple Mail Transfer Protocol
RFC 2822 Format of e-mail
RFC 2960 SCTP
RFC 3010 Network File System
RFC 3031 MPLS architecture
RFC 3066 Language Tags
RFC 3092 Etymology of "Foo"
RFC 3098 Advertise Responsibly Using E-Mail
RFC 3160 Tao of IETF
RFC 3168 ECN
RFC 3501 IMAP4rev1


[Top]

See also

[Top]

Links to IETF RFCs

[Top]

Generic RFCs

[Top]

Host/Router Requirements RFCs

See also X.500
[Top]

Network Management RFCs

[Top]

E-Mail RFCs

This is an important early RFC from the IETF that specified the protocol for transferring e-mail messages between computers on the Internet. Many additions have been made to it, but it remained a standard for many years until obsoleted by RFC 2821 (the number is not a coincidence: it was reserved for this use).
[Top]

X.400 E-Mail RFCs

[Top]

MIME RFCs

RFC 2047 specifies a standard way of encoding non US-ASCII characters into a string that identifies both the character set to use and the actual characters. The result of the encoding will be US-ASCII, and can be transmitted in Internet mail and decoded appropriately on the receiving end. This encoding is necessary in the first place because many characters in non-English languages can not be represented in 7-bit ASCII.
There are some mail clients that are not RFC 2047 Compliant, if you are using one of this clients you are strongly encuraged to change your mail client or to update it to a compliant version:
Eudora 4: Double quote characters are encoded with a Windows codpage and are eight-bit characters. Eudora's MIME headers indicate the MIME type but not 8-bit encoding. Suggest enabling "quoted printable" encoding.
[Top]

April 1st RFCs

See April 1st RFC for complete list

[Top]

Random Support RFCs

[Top]

Random Application RFCs

This provides a way to register extensions of codes for language names in ISO 639. The current reviewer of new tags and maintainer of the is Michael Everson.
[Top]

Random RFCs

This is a memo and status report of the DARPA Internet Gateway. It deals with two areas: gateway procedures and message formats. Topics include information on the forwarding of internet datagrams, various protocols supported by the gateway, and specific gateway software. Unlike many other RFCs, it does not list any implementation specifics.
[Top]

References

This article was originally based on material from the Free On-line Dictionary of Computing and is used under the GFDL.

[Top]




  View Live Article   This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License