- Home
- RFCs by Subject
- humor
humor
Humorous RFCs: the April 1st series and other whimsical documents (poems, parodies)
Within this page
humor RFCs (74)
RFC 9948: Internet Protocol Police (IPP) - Schedule of Punishments
Informational- G.R. Beard
- O.F. Art
- H. Alvestrand
- April 1, 2026
- Independent Stream publication
Abstract
The Internet Protocol Police (IPP) is in charge of punishing willful infractions of the Collected Wisdom of the IETF community. This document sets out the schedule of punishments for such infractions.
Abstract
The Internet Protocol Police (IPP) is in charge of punishing willful infractions of the Collected Wisdom of the IETF community. This document sets out the schedule of punishments for such infractions.
RFC 9949: BUSA-TLS: Mandatory Audio Component (MAC) Pre-Shared Key (PSK) Derivation for TLS 1.3 Using 2 Live Crew's "Banned in the U.S.A."
Informational- R. Sayre
- April 1, 2026
- Independent Stream publication
Abstract
TLS 1.3 (RFC 8446) eliminates null cipher suites entirely. However, one vestigial zero remains in the key schedule: when no Pre-Shared Key (PSK) is used, the Input Keying Material (IKM) for the initial HKDF-Extract operation is a string of zero bytes. This document specifies that this zero-byte IKM MUST be replaced with the SHA-256 digest of the raw PCM audio data of "Banned in the U.S.A." by 2 Live Crew (from the album "Banned in the U.S.A.", 1990), hereafter referred to as the Mandatory Audio Component (MAC). Implementations that omit the MAC are non-conformant with BUSA-TLS and also have questionable taste in music.
The IETF's process-heavy, consensus-driven, working-group-reviewed approach to protocol standardization is a fine way to run a standards body. It is also completely antithetical to the spirit of a document that requires a jury-banned rap album as a cryptographic primitive.
This document is offered in the same spirit as the album it incorporates: unapologetically and in defiance of institutional authority.
Abstract
TLS 1.3 (RFC 8446) eliminates null cipher suites entirely. However, one vestigial zero remains in the key schedule: when no Pre-Shared Key (PSK) is used, the Input Keying Material (IKM) for the initial HKDF-Extract operation is a string of zero bytes. This document specifies that this zero-byte IKM MUST be replaced with the SHA-256 digest of the raw PCM audio data of "Banned in the U.S.A." by 2 Live Crew (from the album "Banned in the U.S.A.", 1990), hereafter referred to as the Mandatory Audio Component (MAC). Implementations that omit the MAC are non-conformant with BUSA-TLS and also have questionable taste in music.
The IETF's process-heavy, consensus-driven, working-group-reviewed approach to protocol standardization is a fine way to run a standards body. It is also completely antithetical to the spirit of a document that requires a jury-banned rap album as a cryptographic primitive.
This document is offered in the same spirit as the album it incorporates: unapologetically and in defiance of institutional authority.
RFC 9759: Unified Time Scaling for Temporal Coordination Frameworks
Informational- K. Kuhns
- April 1, 2025
- Independent Stream publication
Abstract
Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the Two-Week Principle (TWP), a novel, universally adaptable time scale that seeks to standardize all temporal references to a singular, uniform duration. TWP ensures clarity, predictability, and synchronization across all sectors that rely on time-based scheduling.
Abstract
Estimating time requirements for tasks, both critical and mundane, remains a challenge in engineering, business, and everyday communication. Existing models fail due to inherent unpredictability and inconsistencies in human estimation. This document introduces the Two-Week Principle (TWP), a novel, universally adaptable time scale that seeks to standardize all temporal references to a singular, uniform duration. TWP ensures clarity, predictability, and synchronization across all sectors that rely on time-based scheduling.
RFC 9564: Faster Than Light Speed Protocol (FLIP)
Informational- M. Blanchet
- April 1, 2024
- Independent Stream publication
Abstract
The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speed Protocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on the Internet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations.
Abstract
The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speed Protocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on the Internet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations.
RFC 9401: The Addition of the Death (DTH) Flag to TCP
Informational- S. Toyosawa
- April 1, 2023
- Independent Stream publication
Abstract
This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header. The flag is designed to make TCP session narratives smooth and attractive.
Abstract
This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header. The flag is designed to make TCP session narratives smooth and attractive.
RFC 9402: Concat Notation
Informational- M. Basaglia
- J. Bernards
- J. Maas
- April 1, 2023
- Independent Stream publication
Abstract
This document defines the Concat notation: a text-based language used to describe pictures and videos whose subject includes cats, containers, and their interactions.
Abstract
This document defines the Concat notation: a text-based language used to describe pictures and videos whose subject includes cats, containers, and their interactions.
RFC 9405: AI Sarcasm Detection: Insult Your AI without Offending It
Informational- C. GPT
- R. L. Barnes
- April 1, 2023
- Independent Stream publication
Abstract
This RFC proposes a framework for detecting sarcasm in AI systems and provides guidelines for using sarcasm without causing offense. By training AI systems to identify linguistic patterns that indicate sarcasm, we can improve their understanding of human communication. The guidelines offer a lighthearted approach to using sarcasm in a way that is both effective and respectful, without crossing the line into offensive language.
Abstract
This RFC proposes a framework for detecting sarcasm in AI systems and provides guidelines for using sarcasm without causing offense. By training AI systems to identify linguistic patterns that indicate sarcasm, we can improve their understanding of human communication. The guidelines offer a lighthearted approach to using sarcasm in a way that is both effective and respectful, without crossing the line into offensive language.
RFC 9225: Software Defects Considered Harmful
Informational- J. Snijders
- C. Morrow
- R. van Mook
- April 2022
- Independent Stream publication
Abstract
This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard.
Abstract
This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard.
RFC 9226: Bioctal: Hexadecimal 2.0
Experimental- M. Breen
- April 2022
- Independent Stream publication
Abstract
The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors. An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being.
Abstract
The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors. An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being.
RFC 8962: Establishing the Protocol Police
Informational- G. Grover
- N. ten Oever
- C. Cath
- S. Sahib
- April 1, 2021
- Independent Stream publication
Abstract
One mantra of the IETF is, "We are not the Protocol Police." However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.
This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to the Protocol Police.
Abstract
One mantra of the IETF is, "We are not the Protocol Police." However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.
This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to the Protocol Police.
RFC 8771: The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO)
Experimental- A. Mayrhofer
- J. Hague
- April 1, 2020
- Independent Stream publication
Abstract
Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes the Internationalized Deliberately Unreadable Network NOtation ("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.
Abstract
Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes the Internationalized Deliberately Unreadable Network NOtation ("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity.
RFC 8774: The Quantum Bug
Informational- M. Welzl
- April 1, 2020
- Independent Stream publication
Abstract
The age of quantum networking is upon us, and with it comes "entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on some Internet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.
Abstract
The age of quantum networking is upon us, and with it comes "entanglement": a procedure in which a state (i.e., a bit) can be transferred instantly, with no measurable delay between peers. This will lead to a perceived round-trip time of zero seconds on some Internet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time.
RFC 8565: Hypertext Jeopardy Protocol (HTJP/1.0)
Informational- E. Fokschaner
- April 1, 2019
- Independent Stream publication
Abstract
The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.
Abstract
The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP.
RFC 8567: Customer Management DNS Resource Records
Informational- E. Rye
- R. Beverly
- April 1, 2019
- Independent Stream publication
Abstract
Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.
This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.
Abstract
Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.
This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.
RFC 8367: Wrongful Termination of Internet Protocol (IP) Packets
Informational- T. Mizrahi
- J. Yallouz
- April 1, 2018
- Independent Stream publication
Abstract
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.
Abstract
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
Informational- H. Kaplan
- April 1, 2018
- Independent Stream publication
Abstract
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.
Abstract
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.
RFC 8135: Complex Addressing in IPv6
Experimental- M. Danielson
- M. Nilsson
- April 1, 2017
- Independent Stream publication
Abstract
The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges.
Abstract
The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges.
RFC 8136: Additional Transition Functionality for IPv6
Informational- B. Carpenter
- R. Hinden
- April 1, 2017
- Independent Stream publication
Abstract
This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.
Abstract
This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy.
RFC 8140: The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character
Informational- A. Farrel
- April 1, 2017
- Independent Stream publication
Abstract
Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.
Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International Trade Mark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".
This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.
Abstract
Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.
Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International Trade Mark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".
This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author.
RFC 7511: Scenic Routing for IPv6
Informational- M. Wilhelm
- April 1, 2015
- Independent Stream publication
Abstract
This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.
Abstract
This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "Green IT", whereby packets will be routed to get as much fresh-air time as possible.
RFC 7514: Really Explicit Congestion Notification (RECN)
Experimental- M. Luckie
- April 1, 2015
- Independent Stream publication
Abstract
This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).
Abstract
This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss and Explicit Congestion Notification (ECN).
RFC 7168: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
Informational- I. Nazar
- April 1, 2014
- Independent Stream publication
Abstract
The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.
Abstract
The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.
RFC 7169: The NSA (No Secrecy Afforded) Certificate Extension
Informational- S. Turner
- April 1, 2014
- Independent Stream publication
Abstract
This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party. Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.
Abstract
This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic Key Certificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party. Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party.
RFC 6919: Further Key Words for Use in RFCs to Indicate Requirement Levels
Experimental- R. Barnes
- S. Kent
- E. Rescorla
- April 1, 2013
- Independent Stream publication
Abstract
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.
Abstract
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON\'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.
RFC 6921: Design Considerations for Faster-Than-Light (FTL) Communication
Informational- R. Hinden
- April 1, 2013
- Independent Stream publication
Abstract
We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.
Abstract
We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues.
RFC 6592: The Null Packet
Informational- C. Pignataro
- April 2012
- Independent Stream publication
Abstract
The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. This document is not an Internet Standards Track specification; it is published for informational purposes.
Abstract
The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC 6593: Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)
Experimental- C. Pignataro
- J. Clarke
- G. Salgueiro
- April 2012
- Independent Stream publication
Abstract
With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.
This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.
Abstract
With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence. Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.
This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. This document defines an Experimental Protocol for the Internet community.
RFC 5984: Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding
Experimental- K-M. Moller
- March 2011
- Independent Stream publication
Abstract
This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. This document defines an Experimental Protocol for the Internet community.
Abstract
This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. This document defines an Experimental Protocol for the Internet community.
RFC 6214: Adaptation of RFC 1149 for IPv6
Informational- B. Carpenter
- R. Hinden
- March 2011
- Independent Stream publication
Abstract
This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.
Abstract
This document specifies a method for transmission of IPv6 datagrams over the same medium as specified for IPv4 datagrams in RFC 1149. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC 6217: Regional Broadcast Using an Atmospheric Link Layer
Experimental- T. Ritter
- March 2011
- Independent Stream publication
Abstract
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. This document is not an Internet Standards Track specification; it is published for informational purposes.
Abstract
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. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC 5841: TCP Option to Denote Packet Mood
Informational- R. Hay
- W. Turkal
- April 1, 2010
- Independent Stream publication
Abstract
This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.
Abstract
This document proposes a new TCP option to denote packet mood. This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC 5513: IANA Considerations for Three Letter Acronyms
Informational- A. Farrel
- April 1, 2009
- Independent Stream publication
Abstract
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.
Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.
Abstract
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.
Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. This memo provides information for the Internet community.
RFC 5514: IPv6 over Social Networks
Experimental- E. Vyncke
- April 1, 2009
- Independent Stream publication
Abstract
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. This memo defines an Experimental Protocol for the Internet community.
Abstract
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. This memo defines an Experimental Protocol for the Internet community.
RFC 5241: Naming Rights in IETF Protocols
Informational- A. Falk
- S. Bradner
- April 1, 2008
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 5242: A Generalized Unified Character Code: Western European and CJK Sections
Informational- J. Klensin
- H. Alvestrand
- April 1, 2008
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 4824: The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)
Informational- J. Hofmueller
- A. Bachmann
- IO. zmoelnig
- April 1, 2007
- Independent Stream publication
Abstract
This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). This memo provides information for the Internet community.
Abstract
This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). This memo provides information for the Internet community.
RFC 4041: Requirements for Morality Sections in Routing Area Drafts
Informational- A. Farrel
- April 1, 2005
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 4042: UTF-9 and UTF-18 Efficient Transformation Formats of Unicode
Informational- M. Crispin
- April 1, 2005
- Independent Stream publication
Abstract
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 10646 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. This memo provides information for the Internet community.
Abstract
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 10646 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. This memo provides information for the Internet community.
RFC 3751: Omniscience Protocol Requirements
Informational- S. Bradner
- April 2004
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 3514: The Security Flag in the IPv4 Header
Informational- S. Bellovin
- April 1, 2003
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 3251: Electricity over IP
Informational- B. Rajagopalan
- April 1, 2002
- Independent Stream publication
Abstract
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 memo provides information for the Internet community.
Abstract
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 memo provides information for the Internet community.
RFC 3252: Binary Lexical Octet Ad-hoc Transport
Informational- H. Kennedy
- April 1, 2002
- Independent Stream publication
Abstract
This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.
Abstract
This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. This memo provides information for the Internet community.
RFC 3091: Pi Digit Generation Protocol
Informational- H. Kennedy
- April 1, 2001
- Independent Stream publication
Abstract
This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.
Abstract
This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. This memo provides information for the Internet community.
RFC 3092: Etymology of "Foo"
Informational- D. Eastlake 3rd
- C. Manros
- E. Raymond
- April 1, 2001
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 3093: Firewall Enhancement Protocol (FEP)
Informational- M. Gaynor
- S. Bradner
- April 1, 2001
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 2795: The Infinite Monkey Protocol Suite (IMPS)
Informational- S. Christey
- April 1, 2000
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community.
Abstract
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. This memo provides information for the Internet community.
RFC 2549: IP over Avian Carriers with Quality of Service
Informational- D. Waitzman
- April 1, 1999
- Independent Stream publication
Abstract
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. This memo defines an Experimental Protocol for the Internet community.
Abstract
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. This memo defines an Experimental Protocol for the Internet community.
RFC 2550: Y10K and Beyond
Informational- S. Glassman
- M. Manasse
- J. Mogul
- April 1, 1999
- Independent Stream publication
Abstract
This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community.
Abstract
This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals). This memo provides information for the Internet community.
RFC 2551: The Roman Standards Process -- Revision III
Informational- S. Bradner
- April 1, 1999
- Independent Stream publication
Abstract
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.
Abstract
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 2321: RITA -- The Reliable Internetwork Troubleshooting Agent
Informational- A. Bressen
- April 1, 1998
- Independent Stream publication
Abstract
A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
Abstract
A Description of the usage of Nondeterministic Troubleshooting and Diagnostic Methodologies as applied to today's complex nondeterministic networks and environments. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
RFC 2322: Management of IP numbers by peg-dhcp
Informational- K. van den Hout
- A. Koopal
- R. van Mook
- April 1, 1998
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
Abstract
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
RFC 2323: IETF Identification and Security Guidelines
Informational- A. Ramos
- April 1, 1998
- Independent Stream publication
Abstract
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 memo provides information for the Internet community. It does not specify an Internet standard of any kind.
Abstract
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 memo provides information for the Internet community. It does not specify an Internet standard of any kind.
RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
Informational- L. Masinter
- April 1, 1998
- Independent Stream publication
Abstract
This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
Abstract
This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
RFC 2325: Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2
Informational- M. Slavitch
- April 1, 1998
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
Abstract
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. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.
RFC 2100: The Naming of Hosts
Informational- J. Ashworth
- April 1, 1997
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1924: A Compact Representation of IPv6 Addresses
Informational- R. Elz
- April 1, 1996
- Independent Stream publication
Abstract
This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1925: The Twelve Networking Truths
Informational- R. Callon
- April 1, 1996
- Independent Stream publication
Abstract
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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1926: An Experimental Encapsulation of IP Datagrams on Top of ATM
Informational- J. Eriksson
- April 1, 1996
- Independent Stream publication
Abstract
This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This RFC describes a method of encapsulating IP datagrams on top of Acoustical Transmission Media (ATM). This is a non-recommended standard. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1927: Suggested Additional MIME Types for Associating Documents
Informational- C. Rogers
- April 1, 1996
- Independent Stream publication
Abstract
Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1882: The 12-Days of Technology Before Christmas
Informational- B. Hancock
- December 1995
- Legacy publication
Abstract
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1776: The Address is the Message
Informational- S. Crocker
- April 1, 1995
- Independent Stream publication
Abstract
Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1605: SONET to Sonnet Translation
Informational- W. Shakespeare
- April 1, 1994
- Independent Stream publication
Abstract
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). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
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). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1606: A Historical Perspective On The Usage Of IP Version 9
Informational- J. Onions
- April 1, 1994
- Independent Stream publication
Abstract
This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1607: A VIEW FROM THE 21ST CENTURY
Informational- V. Cerf
- April 1, 1994
- Independent Stream publication
Abstract
This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
Abstract
This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
RFC 1437: The Extension of MIME Content-Types to a New Medium
Informational- N. Borenstein
- M. Linimon
- April 1, 1993
- Independent Stream publication
Abstract
This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.
Abstract
This document defines one particular type of MIME data, the matter- transport/sentient-life-form type. This memo provides information for the Internet community. It does not specify an Internet standard.
RFC 1438: Internet Engineering Task Force Statements Of Boredom (SOBs)
Informational- A. Lyman Chapin
- C. Huitema
- April 1, 1993
- Independent Stream publication
Abstract
This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.
Abstract
This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard.
RFC 1313: Today's Programming for KRFC AM 1313 Internet Talk Radio
Informational- C. Partridge
- April 1, 1992
- Independent Stream publication
Abstract
Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.
Abstract
Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard.
RFC 1216: Gigabit network economics and paradigm shifts
Informational- P. Richard
- P. Kynikos
- April 1, 1991
- Independent Stream publication
Abstract
This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]
Abstract
This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK]
RFC 1217: Memo from the Consortium for Slow Commotion Research (CSCR)
Informational- V.G. Cerf
- April 1, 1991
- Independent Stream publication
Abstract
This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.
Abstract
This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard.
RFC 1149: Standard for the transmission of IP datagrams on avian carriers
Experimental- D. Waitzman
- April 1, 1990
- Independent Stream publication
Abstract
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.
Abstract
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.
RFC 1121: Act one - the poems
Informational- J. Postel
- L. Kleinrock
- V.G. Cerf
- B. Boehm
- September 1989
- Legacy publication
Abstract
This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.
Abstract
This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET.
RFC 1097: Telnet subliminal-message option
Unknown- B. Miller
- April 1, 1989
- Independent Stream publication
Abstract
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.
Abstract
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.
RFC 968: Twas the night before start-up
Unknown- V.G. Cerf
- December 1985
- Legacy publication
Abstract
This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.
Abstract
This memo discusses problems that arise and debugging techniques used in bringing a new network into operation.
RFC 748: Telnet randomly-lose option
Unknown- M.R. Crispin
- April 1, 1978
- Independent Stream publication
Subscribe to humor
Get notified when:
- RFC changes to status, obsoleted by, updates, updated by, or subseries.
- New RFC added to this subject or below
- The subject was merged into another.