| |
| RFC 2000 | Internet Official Protocol Standards |
| |
|
|
This memo describes the state of standardization of protocols used in the Internet as determined by the Internet Architecture Board (IAB). This memo is an Internet Standard. |
|
| |
| RFC 2001 | TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms |
| |
|
|
Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [2] and [3] provide some details on these algorithms, [4] provides examples of the algorithms in action, and [5] provides the source code for the 4.4BSD implementation. RFC 1122 requires that a TCP must implement slow start and congestion avoidance (Section 4.2.2.15 of [1]), citing [2] as the reference, but fast retransmit and fast recovery were implemented after RFC 1122. The purpose of this document is to document these four algorithms for the Internet. |
|
| |
| RFC 2002 | IP Mobility Support |
| |
|
|
This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. |
|
| |
| RFC 2003 | IP Encapsulation within IP |
| |
|
|
This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram.Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IPDestination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP. |
|
| |
| RFC 2004 | Minimal Encapsulation within IP |
| |
| Authors: | C. Perkins. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2004 |
|
This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header. Encapsulation may be serve a variety of purposes, such as delivery of a datagram to a mobile node usingMobile IP. |
|
| |
| RFC 2005 | Applicability Statement for IP Mobility Support |
| |
| Authors: | J. Solomon. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2005 |
|
As required by [RFC 1264], this report discusses the applicability ofMobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied. |
|
| |
| RFC 2006 | The Definitions of Managed Objects for IP Mobility Support using SMIv2 |
| |
| Authors: | D. Cong, M. Hamlen, C. Perkins. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2006 |
|
This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the MobileNode, Foreign Agent and Home Agent of the Mobile IP Protocol. |
|
| |
| RFC 2007 | Catalogue of Network Training Materials |
| |
| Authors: | J. Foster, M. Isaacs, M. Prior. |
| Date: | October 1996 |
| Formats: | txt html json |
| Also: | FYI 0029 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2007 |
|
The purpose of this document is to provide a catalogue of qualityNetwork Training Materials for use by Internet trainers in training their users. By providing such a collection of pointers to useful resources, it is hoped that trainers will be relieved of much of the load of producing current training materials. |
|
| |
| RFC 2008 | Implications of Various Address Allocation Policies for Internet Routing |
| |
|
|
The purpose of this document is to articulate certain relevant fundamental technical issues that must be considered in formulating unicast address allocation and management policies for the Public Internet, and to provide recommendations with respect to these policies. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2009 | GPS-Based Addressing and Routing |
| |
| Authors: | T. Imielinski, J. Navas. |
| Date: | November 1996 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2009 |
|
This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2010 | Operational Criteria for Root Name Servers |
| |
|
|
This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. |
|
| |
| RFC 2011 | SNMPv2 Management Information Base for the Internet Protocol using SMIv2 |
| |
|
|
This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK] |
|
| |
| RFC 2012 | SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 |
| |
|
|
This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK] |
|
| |
| RFC 2013 | SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 |
| |
|
|
This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK] |
|
| |
| RFC 2014 | IRTF Research Group Guidelines and Procedures |
| |
| Authors: | A. Weinrib, J. Postel. |
| Date: | October 1996 |
| Formats: | txt json html |
| Also: | BCP 0008 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2014 |
|
The Internet Research Task Force (IRTF) has responsibility for organizing groups to investigate research topics related to theInternet protocols, applications, and technology. IRTF activities are organized into Research Groups. This document describes the guidelines and procedures for formation and operation of IRTFResearch Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group(IRSG) and the Internet Architecture Board (IAB). The basic duties of IRTF participants, including the IRTF Chair, Research Group Chairs and IRSG members are defined. |
|
| |
| RFC 2015 | MIME Security with Pretty Good Privacy (PGP) |
| |
|
|
This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose InternetMail Extensions (MIME) security content types described in RFC1847. |
|
| |
| RFC 2016 | Uniform Resource Agents (URAs) |
| |
| Authors: | L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2016 |
|
This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. Not a generalized architecture for active objects that roam the Internet, these agents are modeled as extensions of existing pieces of the Internet information infrastructure. This experimental agent technology focuses on the necessary information structures to encapsulate Internet activities into objects that can be activated, transformed, and combined into larger structured activities. |
|
| |
| RFC 2017 | Definition of the URL MIME External-Body Access-Type |
| |
| Authors: | N. Freed, K. Moore, A. Cargille. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2017 |
|
This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK] |
|
| |
| RFC 2018 | TCP Selective Acknowledgment Options |
| |
| Authors: | M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoletes: | RFC 1072 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2018 |
|
TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received.
A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments.
This memo proposes an implementation of SACK and discusses its performance and related issues. |
|
| |
| RFC 2019 | Transmission of IPv6 Packets Over FDDI |
| |
|
|
This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK] |
|
| |
| RFC 2020 | IEEE 802.12 Interface MIB |
| |
| Authors: | J. Flick. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2020 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK] |
|
| |
| RFC 2021 | Remote Network Monitoring Management Information Base Version 2 using SMIv2 |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices. |
|
| |
| RFC 2022 | Support for Multicast over UNI 3.0/3.1 based ATM Networks |
| |
| Authors: | G. Armitage. |
| Date: | November 1996 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2022 |
|
Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task.This memo describes a mechanism to support the multicast needs ofLayer 3 protocols in general, and describes its application to IP multicasting in particular.
ATM based IP hosts and routers use a Multicast Address ResolutionServer (MARS) to support RFC 1112 style Level 2 IP multicast over theATM Forum's UNI 3.0/3.1 point to multipoint connection service.Clusters of endpoints share a MARS and use it to track and disseminate information identifying the nodes listed as receivers for given multicast groups. This allows endpoints to establish and manage point to multipoint VCs when transmitting to the group.
The MARS behaviour allows Layer 3 multicasting to be supported using either meshes of VCs or ATM level multicast servers. This choice may be made on a per-group basis, and is transparent to the endpoints. |
|
| |
| RFC 2023 | IP Version 6 over PPP |
| |
| Authors: | D. Haskin, E. Allen. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2472 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2023 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. |
|
| |
| RFC 2024 | Definitions of Managed Objects for Data Link Switching using SMIv2 |
| |
| Authors: | D. Chen, Ed., P. Gayek, S. Nix. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2024 |
|
This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw) [1].
This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI [2], and semantically identical to the SNMPv1 definitions [3]. |
|
| |
| RFC 2025 | The Simple Public-Key GSS-API Mechanism (SPKM) |
| |
| Authors: | C. Adams. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2025 |
|
This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism. |
|
| |
| RFC 2026 | The Internet Standards Process -- Revision 3 |
| |
| Authors: | S. Bradner. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1602, RFC 1871 |
| Updated by: | RFC 3667, RFC 3668, RFC 3932, RFC 3978, RFC 3979, RFC 5378, RFC 5657, RFC 5742, RFC 6410, RFC 7100, RFC 7127, RFC 7475, RFC 8179, RFC 8789, RFC 9282 |
| Also: | BCP 0009 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 2026 |
|
This memo documents the process used by the Internet 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 2027 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self- consistent, organized compilation of the process as it is known today. |
|
| |
| RFC 2028 | The Organizations Involved in the IETF Standards Process |
| |
|
|
This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF WorkingGroups and the relationship between the IETF and the InternetSociety. |
|
| |
| RFC 2029 | RTP Payload Format of Sun's CellB Video Encoding |
| |
| Authors: | M. Speer, D. Hoffman. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2029 |
|
This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. |
|
| |
| RFC 2030 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP)Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI[COL94] addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.
This memorandum obsoletes RFC-1769, which describes SNTP Version 3.Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 andOSI), which are also used for SNTP. A working knowledge of the NTPVersion 3 specification RFC-1305 is not required for an implementation of SNTP. |
|
| |
| RFC 2031 | IETF-ISOC relationship |
| |
|
|
This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. |
|
| |
| RFC 2032 | RTP Payload Format for H.261 Video Streams |
| |
| Authors: | T. Turletti, C. Huitema. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4587 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2032 |
|
This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK] |
|
| |
| RFC 2033 | Local Mail Transfer Protocol |
| |
| Authors: | J. Myers. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2033 |
|
SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2034 | SMTP Service Extension for Returning Enhanced Error Codes |
| |
| Authors: | N. Freed. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2034 |
|
This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK] |
|
| |
| RFC 2035 | RTP Payload Format for JPEG-compressed Video |
| |
| Authors: | L. Berc, W. Fenner, R. Frederick, S. McCanne. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2435 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2035 |
|
This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame.
This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s). |
|
| |
| RFC 2036 | Observations on the use of Components of the Class A Address Space within the Internet |
| |
| Authors: | G. Huston. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2036 |
|
This document is a commentary on the recommendation that IANA commence allocation of the presently unallocated components of theClass A address space to registries, for deployment within theInternet as class-less address blocks.
The document examines the implications for service providers and end clients within this environment. The document notes the major conclusion that widespread adoption of class-less routing protocols is required, within a relatively rapid timeframe for this recommendation to be effective. |
|
| |
| RFC 2037 | Entity MIB using SMIv2 |
| |
| Authors: | K. McCloghrie, A. Bierman. |
| Date: | October 1996 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2737 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2037 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK] |
|
| |
| RFC 2038 | RTP Payload Format for MPEG1/MPEG2 Video |
| |
| Authors: | D. Hoffman, G. Fernando, V. Goyal. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2250 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2038 |
|
This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. |
|
| |
| RFC 2039 | Applicability of Standards Track MIBs to Management of World Wide Web Servers |
| |
| Authors: | C. Kalbfleisch. |
| Date: | November 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2039 |
|
This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2040 | The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms |
| |
| Authors: | R. Baldwin, R. Rivest. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2040 |
|
This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2041 | Mobile Network Tracing |
| |
| Authors: | B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2041 |
|
Mobile networks are both poorly understood and difficult to experiment with. This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. The RFC is a status report on our work tracing mobile networks. Our goal is to begin discussion on a standard format for mobile network tracing as well as a testbed for mobile systems research. We present our format for collecting mobile network traces, and tools to produce from such traces analytical models of mobile network behavior.
We also describe a set of tools to provide network modulation based on collected traces. Modulation allows the emulation of wireless channel latency, bandwidth, loss, and error rates on private, wired networks. This allows system designers to test systems in a realistic yet repeatable manner. |
|
| |
| RFC 2042 | Registering New BGP Attribute Types |
| |
| Authors: | B. Manning. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2042 |
|
This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2043 | The PPP SNA Control Protocol (SNACP) |
| |
| Authors: | A. Fuqua. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2043 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP. |
|
| |
| RFC 2044 | UTF-8, a transformation format of Unicode and ISO 10646 |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. 16-bit characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range: US-ASCII characters are encoded in one octet having the usual US-ASCII value, and any octet with such a value can only be an US-ASCII character.This provides compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. |
|
| |
| RFC 2045 | Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions. |
|
| |
| RFC 2046 | Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types |
| |
|
|
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document,RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. |
|
| |
| RFC 2047 | MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than US-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This particular document is the third document in the series. It describes extensions to RFC 822 to allow non-US-ASCII text data inInternet mail header fields.
Other documents in this series include:
+ RFC 2045, which specifies the various headers used to describe the structure of MIME messages.
+ RFC 2046, which defines the general structure of the MIME media typing system and defines an initial set of media types,
+ RFC 2048, which specifies various IANA registration procedures for MIME-related facilities, and
+ RFC 2049, which describes MIME conformance criteria and provides some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC2049 describes differences and changes from previous versions. |
|
| |
| RFC 2048 | Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This fourth document, RFC 2048, specifies various IANA registration procedures for the following MIME facilities:
(1) media types,
(2) external body access types,
(3) content-transfer-encodings.
Registration of character sets for use in MIME is covered elsewhere and is no longer addressed by this document.
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. |
|
| |
| RFC 2049 | Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples |
| |
|
|
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet MailExtensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other thanUS-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other thanUS-ASCII.
These documents are based on earlier work documented in RFC 934, STD11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. The second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-
ASCII text data in Internet mail header fields. The fourth document,RFC 2048, specifies various IANA registration procedures for MIME- related facilities. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. Appendix B of this document describes differences and changes from previous versions. |
|
| |
| RFC 2050 | Internet Registry IP Allocation Guidelines |
| |
| Authors: | K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. |
| Date: | November 1996 |
| Formats: | txt html json |
| Obsoletes: | RFC 1466 |
| Obsoleted by: | RFC 7020 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2050 |
|
This document describes the registry system for the distribution of globally unique Internet address space and registry operations.Particularly this document describes the rules and guidelines governing the distribution of this address space.
This document describes the IP assignment policies currently used by the Regional Registries to implement the guidelines developed by theIANA. The guidelines and these policies are subject to revision at the direction of the IANA. The registry working group (IRE WG) will be discussing these issues and may provide advice to the IANA about possible revisions.
This document replaces RFC 1466, with all the guidelines and procedures updated and modified in the light of experience.
This document does not describe private Internet address space and multicast address space. It also does not describe regional and local refinements of the global rules and guidelines.
This document can be considered the base set of operational guidelines in use by all registries. Additional guidelines may be imposed by a particular registry as appropriate. |
|
| |
| RFC 2051 | Definitions of Managed Objects for APPC using SMIv2 |
| |
| Authors: | M. Allen, B. Clouston, Z. Kielczewski, W. Kwan, B. Moore. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2051 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK] |
|
| |
| RFC 2052 | A DNS RR for specifying the location of services (DNS SRV) |
| |
| Authors: | A. Gulbrandsen, P. Vixie. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2782 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2052 |
|
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). |
|
| |
| RFC 2053 | The AM (Armenia) Domain |
| |
| Authors: | E. Der-Danieliantz. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2053 |
|
The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2054 | WebNFS Client Specification |
| |
| Authors: | B. Callaghan. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2054 |
|
This document describes a lightweight binding mechanism that allowsNFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. In removing this overhead, WebNFS clients see benefits in faster response to requests, easy transit of packet filter firewalls and TCP-based proxies, and better server scalability. |
|
| |
| RFC 2055 | WebNFS Server Specification |
| |
| Authors: | B. Callaghan. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2055 |
|
This document describes the specifications for a server of WebNFS clients. WebNFS extends the semantics of versions 2 and 3 of the NFS protocols to allow clients to obtain filehandles more easily, without recourse to the portmap or MOUNT protocols. In removing the need for these protocols, WebNFS clients see benefits in faster response to requests, easy transit of firewalls and better server scalabilityThis description is provided to facilitate compatible implementations of WebNFS servers. |
|
| |
| RFC 2056 | Uniform Resource Locators for Z39.50 |
| |
| Authors: | R. Denenberg, J. Kunze, D. Lynch. |
| Date: | November 1996 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2056 |
|
Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK] |
|
| |
| RFC 2057 | Source Directed Access Control on the Internet |
| |
| Authors: | S. Bradner. |
| Date: | November 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2057 |
|
This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2058 | Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | C. Rigney, A. Rubens, W. Simpson, S. Willens. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2138 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2058 |
|
This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server. |
|
| |
| RFC 2059 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2060 | Internet Message Access Protocol - Version 4rev1 |
| |
|
|
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution ofIMAP4rev1, some aspects in the earlier protocol have become obsolete.Obsolete commands, responses, and data formats which an IMAP4rev1 implementation may encounter when used with an earlier implementation are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest. |
|
| |
| RFC 2061 | IMAP4 Compatibility with IMAP2bis |
| |
|
|
This document is intended to be read along with RFC 1176 and the most recent IMAP4 specification (RFC 2060) to assist implementors in creating an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2062 | Internet Message Access Protocol - Obsolete Syntax |
| |
| Authors: | M. Crispin. |
| Date: | December 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2062 |
|
This document describes obsolete syntax which may be encountered byIMAP4 implementations which deal with older versions of the InternetMail Access Protocol. IMAP4 implementations MAY implement this syntax in order to maximize interoperability with older implementations.
This document repeats information from earlier documents, most notably RFC 1176 and RFC 1730. |
|
| |
| RFC 2063 | Traffic Flow Measurement: Architecture |
| |
| Authors: | N. Brownlee, C. Mills, G. Ruth. |
| Date: | January 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2722 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2063 |
|
This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group. |
|
| |
| RFC 2064 | Traffic Flow Measurement: Meter MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. |
|
| |
| RFC 2065 | Domain Name System Security Extensions |
| |
|
|
The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases.
The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms.
In addition, the security extensions provide for the optional authentication of DNS protocol transactions. |
|
| |
| RFC 2066 | TELNET CHARSET Option |
| |
| Authors: | R. Gellens. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2066 |
|
This document specifies a mechanism for passing character set and translation information between a TELNET client and server. Use of this mechanism enables an application used by a TELNET user to send and receive data in the correct character set.
Either side can (subject to option negotiation) at any time request that a (new) character set be used. |
|
| |
| RFC 2067 | IP over HIPPI |
| |
| Authors: | J. Renwick. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | DRAFT STANDARD |
| DOI: | 10.17487/RFC 2067 |
|
ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation ofIEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. ANSI X3.222-1993 (HIPPI-SC[4]) describes the operation of HIPPI physical switches. The ANSI committee responsible for these standards chose to leave HIPPI networking issues largely outside the scope of their standards; this document describes the use of HIPPI switches as IP local area networks.
This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is intended to replace it in the Standards Track. RFC 1374 has been aProposed Standard since November, 1992, with at least 10 implementations of IP encapsulation and HIPPI switch discipline. No major changes to it are required. However, the ARP part of RFC 1374 has not had sufficient implementation experience to be advanced toDraft Standard. The present document contains all of RFC 1374 except for the description ARP, which has been moved into a separate document. |
|
| |
| RFC 2068 | Hypertext Transfer Protocol -- HTTP/1.1 |
| |
| Authors: | R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2616 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2068 |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods.A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1". |
|
| |
| RFC 2069 | An Extension to HTTP : Digest Access Authentication |
| |
| Authors: | J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2617 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2069 |
|
The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". Like Basic,Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use. |
|
| |
| RFC 2070 | Internationalization of the Hypertext Markup Language |
| |
| Authors: | F. Yergeau, G. Nicol, G. Adams, M. Duerst. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2854 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 2070 |
|
The Hypertext Markup Language (HTML) is a markup language used to create hypertext documents that are platform independent. Initially, the application of HTML on the World Wide Web was seriously restricted by its reliance on the ISO-8859-1 coded character set, which is appropriate only for Western European languages. Despite this restriction, HTML has been widely used with other languages, using other coded character sets or character encodings, at the expense of interoperability.
This document is meant to address the issue of the internationalization (i18n, i followed by 18 letters followed by n) of HTML by extending the specification of HTML and giving additional recommendations for proper internationalization support. A foremost consideration is to make sure that HTML remains a valid application of SGML, while enabling its use with all languages of the world. |
|
| |
| RFC 2071 | Network Renumbering Overview: Why would I want it and what is it anyway? |
| |
| Authors: | P. Ferguson, H. Berkowitz. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2071 |
|
The PIER [Procedures for Internet/Enterprise Renumbering] working group is compiling a series of documents to assist and instruct organizations in their efforts to renumber. However, it is becoming apparent that, with the increasing number of new Internet ServiceProviders (ISP's) and organizations getting connected to the Internet for the first time, the concept of network renumbering needs to be further defined. This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. |
|
| |
| RFC 2072 | Router Renumbering Guide |
| |
|
|
IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes inInternet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration.
Routers are the components that interconnect parts of the IP address space identified by unique prefixes. Obviously, they will be impacted by renumbering. Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering. The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort.
Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. |
|
| |
| RFC 2073 | An IPv6 Provider-Based Unicast Address Format |
| |
| Authors: | Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. |
| Date: | January 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2374 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2073 |
|
This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2074 | Remote Network Monitoring MIB Protocol Identifiers |
| |
| Authors: | A. Bierman, R. Iddon. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2895 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2074 |
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK] |
|
| |
| RFC 2075 | IP Echo Host Service |
| |
| Authors: | C. Partridge. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2075 |
|
This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. The effect is that datagrams sent to the echo host are sent back to the source, as if they originated at the echo host. |
|
| |
| RFC 2076 | Common Internet Message Headers |
| |
| Authors: | J. Palme. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2076 |
|
This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521,RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined. |
|
| |
| RFC 2077 | The Model Primary Content Type for Multipurpose Internet Mail Extensions |
| |
| Authors: | S. Nelson, C. Parks, Mitra. |
| Date: | January 1997 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2077 |
|
The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS- TRACK] |
|
| |
| RFC 2078 | Generic Security Service Application Program Interface, Version 2 |
| |
|
|
The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
This memo revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track. |
|
| |
| RFC 2079 | Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) |
| |
| Authors: | M. Smith. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2079 |
|
Uniform Resource Locators (URLs) are being widely used to specify the location of Internet resources. There is an urgent need to be able to include URLs in directories that conform to the LDAP and X.500 information models, and a desire to include other types of UniformResource Identifiers (URIs) as they are defined. A number of independent groups are already experimenting with the inclusion ofURLs in LDAP and X.500 directories. This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way. |
|
| |
| RFC 2080 | RIPng for IPv6 |
| |
| Authors: | G. Malkin, R. Minnear. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2080 |
|
This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in theIPv4 Internet.
This specification represents the minimum change to the RoutingInformation Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723[2], necessary for operation over IPv6 [3]. |
|
| |
| RFC 2081 | RIPng Protocol Applicability Statement |
| |
| Authors: | G. Malkin. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2081 |
|
As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet.This report is a prerequisite to advancing RIPng on the standards track. |
|
| |
| RFC 2082 | RIP-2 MD5 Authentication |
| |
| Authors: | F. Baker, R. Atkinson. |
| Date: | January 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4822 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2082 |
|
Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK] |
|
| |
| RFC 2083 | PNG (Portable Network Graphics) Specification Version 1.0 |
| |
| Authors: | T. Boutell. |
| Date: | March 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2083 |
|
This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement forGIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.
PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also,PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.
This specification defines the Internet Media Type image/png. |
|
| |
| RFC 2084 | Considerations for Web Transaction Security |
| |
| Authors: | G. Bossert, S. Cooper, W. Drummond. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2084 |
|
This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. Such services may be provided as extensions to HTTP, or as an encapsulating security protocol. Secondary requirements include ease of integration and support of multiple mechanisms for providing these services. |
|
| |
| RFC 2085 | HMAC-MD5 IP Authentication with Replay Prevention |
| |
| Authors: | M. Oehler, R. Glenn. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2085 |
|
This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. |
|
| |
| RFC 2086 | IMAP4 ACL extension |
| |
|
|
The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 2087 | IMAP4 QUOTA extension |
| |
|
|
The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 2088 | IMAP4 non-synchronizing literals |
| |
|
|
The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. [STANDARDS- TRACK] |
|
| |
| RFC 2089 | V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent |
| |
|
|
The goal of this memo is to document a common way of mapping anSNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). |
|
| |
| RFC 2090 | TFTP Multicast Option |
| |
| Authors: | A. Emberson. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2090 |
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.
This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in [2].
Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option set, two or more computers can download a file concurrently, thus increasing network efficiency.
This document assumes that the reader is familiar with the terminology and notation of both [1] and [2]. |
|
| |
| RFC 2091 | Triggered Extensions to RIP to Support Demand Circuits |
| |
| Authors: | G. Meyer, S. Sherry. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2091 |
|
This document defines a modification which can be applied toBellman-Ford (distance vector) algorithm information broadcasting protocols - for example IP RIP, Netware RIP or Netware SAP - which makes it feasible to run them on connection oriented Public DataNetworks.
This proposal has a number of efficiency advantages over the DemandRIP proposal (RFC 1582). |
|
| |
| RFC 2092 | Protocol Analysis for Triggered RIP |
| |
| Authors: | S. Sherry, G. Meyer. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2092 |
|
As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support DemandCircuits [2] and the current implementation experience.
As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted. |
|
| |
| RFC 2093 | Group Key Management Protocol (GKMP) Specification |
| |
| Authors: | H. Harney, C. Muckenhirn. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2093 |
|
This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols. |
|
| |
| RFC 2094 | Group Key Management Protocol (GKMP) Architecture |
| |
| Authors: | H. Harney, C. Muckenhirn. |
| Date: | July 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2094 |
|
This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols. |
|
| |
| RFC 2095 | IMAP/POP AUTHorize Extension for Simple Challenge/Response |
| |
| Authors: | J. Klensin, R. Catoe, P. Krumviede. |
| Date: | January 1997 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2195 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2095 |
|
While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734. |
|
| |
| RFC 2096 | IP Forwarding Table MIB |
| |
|
|
This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK] |
|
| |
| RFC 2097 | The PPP NetBIOS Frames Control Protocol (NBFCP) |
| |
| Authors: | G. Pall. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2097 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
The NBF protocol [3] was originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP.
The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms. |
|
| |
| RFC 2098 | Toshiba's Router Architecture Extensions for ATM : Overview |
| |
| Authors: | Y. Katsube, K. Nagami, H. Esaki. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2098 |
|
This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "CellSwitch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such asRSVP. |
|
| |
| RFC 2099 | Request for Comments Summary RFC Numbers 2000-2099 |
| |
| Authors: | J. Elliott. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2099 |
|
|
|
