|
RFC Home |
Full RFC Index |
Recent RFCs |
RFC Standards |
Best Current Practice |
RFC Errata |
1 April RFC |
|
||||||
RFC 748 | Telnet randomly-lose option |
Summary Publication date: 1 April 1978 Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features. |
RFC 1097 | Telnet subliminal-message option |
Summary Publication date: 1 April 1989 This RFC specifies a standard for the Internet community. Hosts on the Internet that display subliminal messages within the Telnet protocol are expected to adopt and implement this standard. Distribution of this memo is unlimited. |
RFC 1149 | Standard for the transmission of IP datagrams on avian carriers |
Summary Publication date: 1 April 1990 This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. Distribution of this memo is unlimited. |
RFC 1216 | Gigabit network economics and paradigm shifts |
Summary Publication date: 1 April 1991 The history of computer communication contains many examples of efforts to align the capabilities of processors to that of communication media. Packet switching is the classic case of a careful tradeoff between the costs of memory, processing, and communications bandwidth. With all of the attention and publicity focused on gigabit networks, not much notice has been given to small and largely unfunded research efforts which are studying innovative approaches for dealing with technical issues within the constraints of economic science. This memo defines one such paradigm. |
RFC 1217 | Memo from the Consortium for Slow Commotion Research (CSCR) |
Summary Publication date: 1 April 1991 This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". |
RFC 1313 | Today's Programming for KRFC AM 1313 Internet Talk Radio |
Summary Publication date: 1 April 1992 No summary available. |
RFC 1437 | The Extension of MIME Content-Types to a New Medium |
Summary Publication date: 1 April 1993 A previous document, RFC 1341, defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the matter-transport/sentient-life-form type. The matter- transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings. Other informally proposed subtypes, such as "non-sentient-life-form", "non-sentient-non-life-form", and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form", are not described in this memo. |
RFC 1438 | Internet Engineering Task Force Statements Of Boredom (SOBs) |
Summary Publication date: 1 April 1993 The IETF currently has no mechanism or means of publishing documents that express its deep concern about something important, but otherwise contain absolutely no useful information whatsoever. This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). |
RFC 1605 | SONET to Sonnet Translation |
Summary Publication date: 1 April 1994 Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation (SONNET). |
RFC 1606 | A Historical Perspective On The Usage Of IP Version 9 |
Summary Publication date: 1 April 1994 This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. |
RFC 1607 | A VIEW FROM THE 21ST CENTURY |
Summary Publication date: 1 April 1994 The letters below were discovered in September 1993 in a reverse time-capsule apparently sent from 2023. |
RFC 1776 | The Address is the Message |
Summary Publication date: 1 April 1995 The IPng WG has selected a packet format which includes 1696 bytes of address space. This length is a multiple of 53 and is completely compatible with ATM architecture. |
RFC 1924 | A Compact Representation of IPv6 Addresses |
Summary Publication date: 1 April 1996 IPv6 addresses, being 128 bits long, need 32 characters to write in the general case, if standard hex representation, is used, plus more for any punctuation inserted (typically about another 7 characters, or 39 characters total). This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. |
RFC 1925 | The Twelve Networking Truths |
Summary Publication date: 1 April 1996 This memo documents the fundamental truths of networking for the Internet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. |
RFC 1926 | An Experimental Encapsulation of IP Datagrams on Top of ATM |
Summary Publication date: 1 April 1996 This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. Distribution of this memo is unnecessary. |
RFC 1927 | Suggested Additional MIME Types for Associating Documents |
Summary Publication date: 1 April 1996 This memo proposes some additional MIME types for association documents, such as the Staple and "Paper" Clip. |
RFC 2100 | The Naming of Hosts |
Summary Publication date: 1 April 1997 This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. Distribution of this memo is unlimited. Except to TS Eliot. And, for that matter, to David Addison, who hates iambic pentameter. |
RFC 2321 | RITA -- The Reliable Internetwork Troubleshooting Agent |
Summary Publication date: 1 April 1998 A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. |
RFC 2322 | Management of IP numbers by peg-dhcp |
Summary Publication date: 1 April 1998 This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. It can also provide some fixed additional fields global for all clients like netmask and even autoproxyconfigs. It does not depend on a particular ip-stack. |
RFC 2323 | IETF Identification and Security Guidelines |
Summary Publication date: 1 April 1998 This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This document will shed further illumination on these problems and provide some possible solutions. This memo provides entertainment for the Internet community. It does not specify an Internet standard of any kind, but is rather unstandard, actually. Please laugh loud and hard. |
RFC 2324 | Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) |
Summary Publication date: 1 April 1998 This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. |
RFC 2325 | Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 |
Summary Publication date: 1 April 1998 This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. |
RFC 2549 | IP over Avian Carriers with Quality of Service |
Summary Publication date: 1 April 1999 This memo amends RFC 1149, "A Standard for the Transmission of IP Datagrams on Avian Carriers", with Quality of Service information. This is an experimental, not recommended standard. |
RFC 2550 | Y10K and Beyond |
Summary Publication date: 1 April 1999 As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem. Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000. Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail. This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). |
RFC 2551 | The Roman Standards Process -- Revision III |
Summary Publication date: 1 April 1999 This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. |
RFC 2795 | The Infinite Monkey Protocol Suite (IMPS) |
Summary Publication date: 1 April 2000 This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them. |
RFC 3091 | Pi Digit Generation Protocol |
Summary Publication date: 1 April 2001 This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. |
RFC 3092 | Etymology of 'Foo' |
Summary Publication date: 1 April 2001 Approximately 212 RFCs so far, starting with RFC 269, contain the terms 'foo', 'bar', or 'foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. |
RFC 3093 | Firewall Enhancement Protocol (FEP) |
Summary Publication date: 1 April 2001 Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1]. However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose the Firewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traverse a Firewall. Our methodology is to layer any application layer Transmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, since HTTP packets are typically able to transit Firewalls. This scheme does not violate the actual security usefulness of a Firewall, since Firewalls are designed to thwart attacks from the outside and to ignore threats from within. The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the security of a firewall, and transparent tunneling thought the firewall. |
RFC 3251 | Electricity over IP |
Summary Publication date: 1 April 2002 Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question. This document has also been written as a public service. The "Sub- IP" area has been formed to give equal opportunity to those working on technologies outside of traditional IP networking to write complicated IETF documents. There are possibly many who are wondering how to exploit this opportunity and attain high visibility. Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS control for random technologies) as highly amenable for producing a countless number of unimplementable documents. This document illustrates the key ingredients that go into producing any "foo- over-MPLS" document and may be used as a template for all such work. |
RFC 3252 | Binary Lexical Octet Ad-hoc Transport |
Summary Publication date: 1 April 2002 This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. |
RFC 3514 | The Security Flag in the IPv4 Header |
Summary Publication date: 1 April 2003 Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. |
RFC 3751 | Omniscience Protocol Requirements |
Summary Publication date: 1 April 2004 There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. |
RFC 4041 | Requirements for Morality Sections in Routing Area Drafts |
Summary Publication date: 1 April 2005 It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal. This document specifies a requirement for all new Routing Area Internet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. |
RFC 4042 | UTF-9 and UTF-18 Efficient Transformation Formats of Unicode |
Summary Publication date: 1 April 2005 ISO-10646 defines a large character set called the Universal Character Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions to ISO/IEC 646 track each other, so that the character repertoires and code point assignments remain in synchronization. The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet. This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. |
RFC 4824 | The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) |
Summary Publication date: 1 April 2007 This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). |
RFC 5241 | Naming Rights in IETF Protocols |
Summary Publication date: 1 April 2008 This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. |
RFC 5242 | A Generalized Unified Character Code: Western European and CJK Sections |
Summary Publication date: 1 April 2008 Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. |
RFC 5513 | IANA Considerations for Three Letter Acronyms |
Summary Publication date: 1 April 2009 Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to misconfiguration or other operating errors. |
RFC 5514 | IPv6 over Social Networks |
Summary Publication date: 1 April 2009 There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks. This will immediately add millions of IPv6 hosts to the existing IPv6 Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. |
RFC 5841 | TCP Option to Denote Packet Mood |
Summary Publication date: 1 April 2010 This document proposes a new TCP option to denote packet mood. |
RFC 5984 | Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding |
Summary Publication date: 1 April 2011 This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. |
RFC 6214 | Adaptation of RFC 1149 for IPv6 |
Summary Publication date: 1 April 2011 This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. |
RFC 6217 | Regional Broadcast Using an Atmospheric Link Layer |
Summary Publication date: 1 April 2011 Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan Area Networks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. |
RFC 8367 | Wrongful Termination of Internet Protocol (IP) Packets |
Summary Publication date: 1 April 2018 Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them. |
RFC 8369 | Internationalizing IPv6 Using 128-Bit Unicode |
Summary Publication date: 1 April 2018 It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the Unicode Consortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future 128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6. |