diff options
Diffstat (limited to 'doc/rfc/rfc899.txt')
| -rw-r--r-- | doc/rfc/rfc899.txt | 1062 |
1 files changed, 1062 insertions, 0 deletions
diff --git a/doc/rfc/rfc899.txt b/doc/rfc/rfc899.txt new file mode 100644 index 0000000..251689e --- /dev/null +++ b/doc/rfc/rfc899.txt @@ -0,0 +1,1062 @@ + + +Network Working Group J. Postel +Request for Comments: 899 A. Westine + ISI + May 1984 + + + Requests For Comments Summary + Notes: 800-899 + +Status of this Memo + + This RFC is a slightly annotated list of the 100 RFCs from RFC 800 + through RFC 899. This is a status report on these RFCs. + +RFC Author Date Title +--- ------ ---- ----- + +899 Postel Apr 84 Requests For Comments Summary + + This memo. + +898 Hinden Apr 84 Gateway Special Interest Group Meeting + Notes + + This memo is a report on the Gateway Special Interest Group Meeting + that was held at ISI on 28 and 29 February 1984. Robert Hinden of + BBNCC chaired, and Jon Postel of ISI hosted the meeting. + Approximately 35 gateway designers and implementors attended. These + notes are based on the recollections of Jon Postel and Mike Muuss. + Under each topic area are Jon Postel's brief notes, and additional + details from Mike Muuss. This memo is a report on a meeting. No + conclusions, decisions, or policy statements are documented in this + note. + +897 Postel Feb 84 Domain Name System Implementation + Schedule + + This memo is a policy statement on the implementation of the Domain + Style Naming System in the Internet. This memo is a partial update + of RFC 881. The intent of this memo is to detail the schedule for + the implementation for the Domain Style Naming System. The names of + hosts will be changed to domain style names. Hosts will begin to use + domain style names on 14-Mar-84, and the use of old style names will + be completely phased out before 2-May-84. This applies to both the + ARPA research hosts and the DDN operational hosts. This is an + official policy statement of the ICCB and the DARPA. + + + + + + + + + +Postel & Westine [page 1] + + + +RFC 899 May 1984 + + +896 Nagle Jan 84 Congestion Control in IP/TCP + Internetworks + + This memo discusses some aspects of congestion control in IP/TCP + Internetworks. It is intended to stimulate thought and further + discussion of this topic. While some specific suggestions are made + for improved congestion control implementation, this memo does not + specify any standards. + +895 Postel Apr 84 A Standard for the Transmission of + IP Datagrams over Experimental Ethernet + Networks + + This RFC specifies a standard method of encapsulating Internet + Protocol (IP) datagrams on an Experimental Ethernet. This RFC + specifies a standard protocol for the ARPA Internet community. + +894 Hornig Apr 84 A Standard for the Transmission of + IP Datagrams over Ethernet Networks + + This RFC specifies a standard method of encapsulating Internet + Protocol (IP) datagrams on an Ethernet. This RFC specifies a + standard protocol for the ARPA-Internet community. + +893 Leffler Apr 84 Trailer Encapsulations + + This RFC discusses the motivation for use of "trailer encapsulations" + on local-area networks and describes the implementation of such an + encapsulation on various media. This document is for information + only. This is NOT an official protocol for the ARPA Internet + community. + +892 ISO Dec 83 ISO Transport Protocol Specification + + This is a draft version of the transport protocol being standardized + by the ISO. This version also appeared in the ACM SIGCOMM Computer + Communication Review (V.12, N.3-4) July-October 1982. This version + is now out of date. + +891 Mills Dec 83 DCN Local-Network Protocols + + This RFC provides a description of the DCN protocols for maintaining + connectivity, routing, and clock information in a local network. + These procedures may be of interest to the designers and implementers + of other local networks. + + + + + + + +Postel & Westine [page 2] + + + +RFC 899 May 1984 + + +890 Postel Feb 84 Exterior Gateway Protocol + Implementation Schedule + + This memo is a policy statement on the implementation of the Exterior + Gateway Protocol in the Internet. This is an official policy + statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb + gateways in the Internet. Every gateway must be a member of some + autonomous system. Some gateway of each autonomous system must + exchange routing information with some gateway of the core autonomous + system using the Exterior Gateway Protocol. + +889 Mills Dec 83 Internet Delay Experiments + + This memo reports on some measurements of round-trip times in the + Internet and suggests some possible improvements to the TCP + retransmission timeout calculation. This memo is both a status + report on the Internet and advice to TCP implementers. + +888 Seamonson Jan 84 "Stub" Exterior Gateway Protocol + + This RFC describes the Exterior Gateway Protocol used to connect Stub + Gateways to an Autonomous System of core Gateways. This document + specifies the working protocol, and defines an ARPA official + protocol. All implementers of Gateways should carefully review this + document. + +887 Accetta Dec 83 Resource Location Protocol + + This RFC specifies a draft standard for the ARPA Internet community. + It describes a resource location protocol for use in the ARPA + Internet. It is most useful on networks employing technologies which + support some method of broadcast addressing, however it may also be + used on other types of networks. For maximum benefit, all hosts + which provide significant resources or services to other hosts on the + Internet should implement this protocol. Hosts failing to implement + the Resource Location Protocol risk being ignored by other hosts + which are attempting to locate resources on the Internet. + +886 Rose Dec 83 Proposed Standard for Message Header + Munging + + This RFC specifies a draft standard for the ARPA Internet community. + It describes the rules to be used when transforming mail from the + conventions of one message system to those of another message system. + In particular, the treatment of header fields, and recipient + addresses is specified. + + + + + + +Postel & Westine [page 3] + + + +RFC 899 May 1984 + + +885 Postel Dec 83 Telnet End of Record Option + + This RFC specifies a standard for the ARPA Internet community. It + specifies a method for marking the end of records in data transmitted + on Telnet connections. + +884 Solomon Dec 83 Telnet Terminal Type Option + + This RFC specifies a standard for the ARPA Internet community. It + specifies a method for exchanging terminal type information in the + Telnet protocol. + +883 Mockapetris Nov 83 Domain Names - Implementation and + Specification + + This RFC discusses the implementation of domain name servers and + resolvers, specifies the format of transactions, and discusses the + use of domain names in the context of existing mail systems and other + network software. + +882 Mockapetris Nov 83 Domain Names - Concepts and Facilities + + This RFC introduces domain style names, their use for ARPA Internet + mail and host address support, and the protocol and servers used to + implement domain name facilities. + +881 Postel Nov 83 The Domain Names Plan and Schedule + + This RFC outlines a plan and schedule for the implementation of + domain style names throughout the DDN/ARPA Internet community. The + introduction of domain style names will impact all hosts on the + DDN/ARPA Internet. + +880 Reynolds Oct 83 Official Protocols + + This RFC identifies the documents specifying the official protocols + used in the ARPA Internet. Annotations identify any revisions or + changes planned. Obsoletes RFC 840. + +879 Postel Nov 83 The TCP Maximum Segment Size and + Related Topics + + This RFC discusses the TCP Maximum Segment Size Option and related + topics. The purposes is to clarify some aspects of TCP and its + interaction with IP. This memo is a clarification to the TCP + specification, and contains information that may be considered as + "advice to implementers". + + + + + +Postel & Westine [page 4] + + + +RFC 899 May 1984 + + +878 Malis Dec 83 The ARPANET 1822L Host Access Protocol + + This RFC specifies the ARPANET 1822L Host Access Protocol, which is a + successor to the existing 1822 Host Access Protocol. The 1822L + procedure allows ARPANET hosts to use logical identifiers as well as + 1822 physical interface identifiers to address each other. + +877 Korb Sep 83 A Standard for the Transmission of IP + Datagrams Over Public Data Networks + + This RFC specifies a standard adopted by CSNET, the VAN gateway, and + other organizations for the transmission of IP datagrams over the + X.25-based public data networks. + +876 Smallberg Sep 83 Survey of SMTP Implementations + + This RFC is a survey of implementation status. It does not specify + an official protocol, but rather notes the status of implementation + of aspects of a protocol. It is expected that the status of the + hosts reported on will change. This information must be treated as a + snapshot of the state of these implemetations. + +875 Padlipsky Sep 82 Gateways, Architectures, and Heffalumps + + This RFC is a discussion about the role of gateways in an + internetwork, especially the problems of translating or mapping + protocols between different protocol suites. The discussion notes + possible functionality mis-matches, undesirable routing "singularity + points", flow control issues, and high cost of translating gateways. + Originally published as M82-51 by the MITRE Corporation, Bedford, + Massachusetts. + +874 Padlipsky Sep 82 A Critique of X.25 + + This RFC is an analysis of X.25 pointing out some problems in the + conceptual model, particularly the conflict between the interface + aspects and the end-to-end aspects. The memo also touches on + security, and implementation issues. Originally published as M82-50 + by the MITRE Corporation, Bedford, Massachusetts. + +873 Padlipsky Sep 82 The Illusion of Vendor Support + + This memo takes issue with the claim that international standards in + computer protocols presently provide a basis for low cost vendor + supported protocol implementations. Originally published as M82-49 + by the MITRE Corporation, Bedford, Massachusetts. + + + + + + +Postel & Westine [page 5] + + + +RFC 899 May 1984 + + +872 Padlipsky Sep 82 TCP-ON-A-LAN + + This memo attacks the notion that TCP cannot be appropriate for use + on a Local Area Network. Originally published as M82-48 by the MITRE + Corporation, Bedford Massachusetts. + +871 Padlipsky Sep 82 A Perspective on the Arpanet Reference + Model + + This RFC is primarily intended as a perspective on the ARM and points + out some of the differences between the ARM and the ISORM which were + expressed by members in NWG general meetings, NWG protocol design + committee meetings, the ARPA Internet Working Group, and private + conversations over the intervening years. Originally published as + M82-47 by the MITRE Corporation, Bedford, Massachusetts. + +870 Reynolds Oct 83 Assigned Numbers + + This RFC documents the list of numbers assigned for networks, + protocols, etc. Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755, + 750, 739, 604. + +869 Hinden Dec 83 A Host Monitoring Protocol + + This RFC specifies the Host Monitoring Protocol used to collect + information from various types of hosts in the Internet. Designers + of Internet communications software are encouraged to consider this + protocol as a means of monitoring the behavior of their creations. + +868 Postel May 83 Time Protocol + + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet that choose to implement a Time Protocol are + expected to adopt and implement this standard. This protocol + provides a site-independent, machine readable date and time. The + Time service sends back to the originating source the time in seconds + since midnight on January first 1900. + +867 Postel May 83 Daytime Protocol + + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet that choose to implement a Daytime Protocol are + expected to adopt and implement this standard. The Daytime service + simply sends the current date and time as a character string without + regard to the input. + + + + + + + +Postel & Westine [page 6] + + + +RFC 899 May 1984 + + +866 Postel May 83 Active Users + + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet that choose to implement an Active Users + Protocol are expected to adopt and implement this standard. The + Active Users service simply sends a list of the currently active + users on the host without regard to the input. + +865 Postel May 83 Quote of the Day Protocol + + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet that choose to implement a Quote of the Day + Protocol are expected to adopt and implement this standard. The + Quote of the Day service simply sends a short message without regard + to the input. + +864 Postel May 83 Character Generator Protocol + + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet that choose to implement a Character Generator + Protocol are expected to adopt and implement this standard. The + Character Generator service simply sends data without regard to the + input. + +863 Postel May 83 Discard Protocol + + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet that choose to implement a Discard Protocol are + expected to adopt and implement this standard. The Discard service + simply throws away any data it receives. + +862 Postel May 83 Echo Protocol + + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet that choose to implement a Echo Protocol are + expected to adopt and implement this standard. The Echo service + simply sends back to the originating source any data it receives. + +861 Postel May 83 Telnet Extended Options - List Option + + This Telnet Option provides a mechanism for extending the set of + possible options. This RFC specifies a standard for the ARPA + Internet community. Hosts on the ARPA Internet are expected to adopt + and implement this standard. Obsoletes NIC 16239. + + + + + + + + +Postel & Westine [page 7] + + + +RFC 899 May 1984 + + +860 Postel May 83 Telnet Timing Mark Option + + This Telnet Option provides a way to check the roundtrip path between + two Telnet modules. This RFC specifies a standard for the ARPA + Internet community. Hosts on the ARPA Internet are expected to adopt + and implement this standard. Obsoletes NIC 16238. + +859 Postel May 83 Telnet Status Option + + This Telnet Option provides a way to determine the other Telnet + module's view of the status of options. This RFC specifies a + standard for the ARPA Internet community. Hosts on the ARPA Internet + are expected to adopt and implement this standard. Obsoletes RFC 651 + (NIC 31154). + +858 Postel May 83 Telnet Suppress Go Ahead Option + + This Telnet Option disables the exchange of go-ahead signals between + the Telnet modules. This RFC specifies a standard for the ARPA + Internet community. Hosts on the ARPA Internet are expected to adopt + and implement this standard. Obsoletes NIC 15392. + +857 Postel May 83 Telnet Echo Option + + This Telnet Option enables remote echoing by the other Telnet module. + This RFC specifies a standard for the ARPA Internet community. Hosts + on the ARPA Internet are expected to adopt and implement this + standard. Obsoletes NIC 15390. + +856 Postel May 83 Telnet Binary Transmission + + This Telnet Option enables a binary data mode between the Telnet + modules. This RFC specifies a standard for the ARPA Internet + community. Hosts on the ARPA Internet are expected to adopt and + implement this standard. Obsoletes NIC 15389. + +855 Postel May 83 Telnet Option Specifications + + This memo specifies the general form for Telnet options and the + directions for their specification. This RFC specifies a standard + for the ARPA Internet community. Hosts on the ARPA Internet are + expected to adopt and implement this standard. Obsoletes RFC 651, + NIC 18640. + + + + + + + + + +Postel & Westine [page 8] + + + +RFC 899 May 1984 + + +854 Postel May 83 Telnet Protocol Specifications + + This is the specification of the Telnet protocol used for remote + terminal access in the ARPA Internet. The purpose of the TELNET + Protocol is to provide a fairly general, bi-directional, eight-bit + byte oriented communications facility. Its primary goal is to allow + a standard method of interfacing terminal devices and + terminal-oriented processes to each other. It is envisioned that the + protocol may also be used for terminal-terminal communication + ("linking") and process-process communication (distributed + computation). This RFC specifies a standard for the ARPA Internet + community. Hosts on the ARPA Internet are expected to adopt and + implement this standard. Obsoletes NIC 18639. + +853 Not issued yet. + +852 Malis Apr 83 The ARPANET Short Blocking Feature + + This RFC specifies the ARPANET Short Blocking Feature, which will + allow ARPANET hosts to optionally shorten the IMP's host blocking + timer. This Feature is a replacement of the ARPANET non-blocking + host interface, which was never implemented, and will be available to + hosts using either the 1822 or 1822L Host Access Protocol. This RFC + is also being presented as a solicitation of comments on the Short + Blocking Feature, especially from host network software implementers + and maintainers. + +851 Malis Apr 83 The ARPANET 1822L Host Access Protocol + + This RFC specifies the ARPANET 1822L Host Access Protocol, which is a + successor to the existing 1822 Host Access Protocol. 1822L allows + ARPANET hosts to use logical names as well as 1822's physical port + locations to address each other. This RFC is also being presented as + a solicitation of comments on 1822L, especially from host network + software implementers and maintainers. Obsoletes RFC 802. + +850 Horton Jun 83 Standard for Interchange of USENET + Messages + + This memo is distributed as an RFC only to make this information + easily accessible to researchers in the ARPA community. It does not + specify an Internet standard. This RFC defines the standard format + for interchange of Network News articles among USENET sites. It + describes the format for articles themselves, and gives partial + standards for transmission of news. The news transmission is not + entirely standardized in order to give a good deal of flexibility to + the individual hosts to choose transmission hardware and software, + whether to batch news and so on. + + + + +Postel & Westine [page 9] + + + +RFC 899 May 1984 + + +849 Crispin May 83 Suggestions for Improved Host Table + Distribution + + This RFC actually is a request for comments. The issue dealt with is + that of a naming registry update procedure, both as exists currently + and what could exist in the future. None of the proposed solutions + are intended as standards at this time; rather it is hoped that a + general consensus will emerge as the appropriate solution, leaving + eventually to the adoption of standards. + +848 Smallberg Mar 83 Who provides the "Little" TCP Services? + + This RFC lists those hosts which provide any of these "little" TCP + services: The list of hosts were taken from the NIC hostname table + of 24-Feb-83. The tests were run on February 23 and 24, and March 3 + and 5 from ISI-VAXA.ARPA. + +847 Westine Feb 83 Summary of Smallberg Surveys + + This is a summary of the surveys of Telnet, FTP and Mail (SMTP) + servers conducted by David Smallberg in December 1982, January and + February 1983 as reported in RFC 832-843, 845-846. This memo + extracts the number of hosts that accepted the connection to their + server for each of Telnet, FTP, and SMTP, and compares it to the + total host in the Internet (not counting TACs or ECHOS). + +846 Smallberg Feb 83 Who Talks TCP? -- Survey of 22 February + 1983 + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 + from ISI-VAXA.ARPA. + +845 Smallberg Feb 83 Who Talks TCP? -- Survey of 15 February + 1983 + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 + from ISI-VAXA.ARPA. + + + + + + + + + + + +Postel & Westine [page 10] + + + +RFC 899 May 1984 + + +844 Clements Feb 83 Who Talks ICMP, too? Survey of 18 + February 1983 + + This survey determines how many hosts are able to respond to TELENET + connections from a user at a class C site. This requires, in + addition to IP and TCP, participation in gateway routing via ICMP and + handling of Class C addresses. The list of hosts was taken from RFC + 843, extracting only those hosts which are listed there as accepting + TELNET connection. The tests were run on 18-Feb-83. + +843 Smallberg Feb 83 Who Talks TCP? -- Survey of 8 February + 1983 + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 + and on 9-Feb-83 from ISI-VAXA.ARPA. + +842 Smallberg Feb 83 Who Talks TCP? -- Survey of 1 February + 1983 + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 + and on 2-Feb-83 ISI-VAXA.ARPA. + +841 FIPS PUB 98 Jan 83 Specification for Message Format for + Computer Based Message Systems + + This RFC is FIPS 98. The purpose of distributing this document as an + RFC is to make it easily accessible to the ARPA research community. + This RFC does not specify a standard for the ARPA Internet. + Obsoletes RFC 806. + +840 Postel Apr 83 Official Protocols + + This RFC has been revised, see RFC 880. + +839 Smallberg Jan 83 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 31-Dec-82. The tests were run on + 25-Jan-83. + + + + + + + + +Postel & Westine [page 11] + + + +RFC 899 May 1984 + + +838 Smallberg Jan 83 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 31-Dec-82. The tests were run on + 18-Jan-83. + +837 Smallberg Jan 83 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 31-Dec-82. The tests were run on + 11-Jan-83. + +836 Smallberg Jan 83 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 20-Dec-82. The tests were run on 4-Jan-83 + through 5-Jan-83. + +835 Smallberg Dec 82 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 + through 5-Jan-83. + +834 Smallberg Dec 82 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82. + +833 Smallberg Dec 82 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82. + +832 Smallberg Dec 82 Who Talks TCP? + + This RFC is a survey of hosts to identify the implementation status + of Telnet, FTP, and Mail on TCP. The list of hosts was taken from + the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82. + + + + + + + +Postel & Westine [page 12] + + + +RFC 899 May 1984 + + +831 Braden Dec 82 Backup Access to the European Side of + SATNET + + The purpose of this RFC is to focus discussion on a particular + Internet problem: a backup path for software maintenance of the + European sector of the Internet, for use when SATNET is partitioned. + We propose a mechanism, based upon the Source Routing option of IP, + to reach European Internet sites via the VAN Gateway and UCL. This + proposal is not intended as a standard at this time. + +830 Zaw-Sing Su Oct 82 A Distributed System for Internet Name + Service + + This RFC proposes a distributed name service for DARPA Internet. Its + purpose is to focus discussion on the subject. It is hoped that a + general consensus will emerge leading eventually to the adoption of + standards. + +829 Cerf Oct 82 Packet Satellite Technology Reference + Sources + + This RFC describes briefly the packet satellite technology developed + by the Defense Advanced Research Projects Agency and several other + participating organizations in the U.K. and Norway and provides a + bibliography of relevant papers for researchers interested in + experimental and operational experience with this dynamic + satellite-sharing technique. + +828 Owen Aug 82 Data Communications: IFIP's + International "Network" of Experts + + This RFC is distributed to inform the ARPA Internet community of the + activities of the IFIP technical committee on Data Communications, + and to encourage participation in those activities. + +827 Rosen Oct 82 Exterior Gateway Protocol (EGP) + + This RFC is proposed to establish a standard for Gateway to Gateway + procedures that allow the Gateways to be mutually suspicious. This + document is a DRAFT for that standard. Your comments are strongly + encouraged. + +826 Plummer Nov 82 An Ethernet Address Resolution Protocol + + The purpose of this RFC is to present a method of Converting Protocol + Addresses (e.g., IP addresses) to Local Network Addresses (e.g., + Ethernet addresses). This is an issue of general concern in the ARPA + Internet Community at this time. The method proposed here is + presented for your consideration and comment. This is not the + specification of an Internet Standard. + + +Postel & Westine [page 13] + + + +RFC 899 May 1984 + + +825 Postel Nov 82 Request for Comments on Requests for + Comments + + This RFC is intended to clarify the status of RFCs and to provide + some guidance for the authors of RFCs in the future. It is in a + sense a specification for RFCs. + +824 MacGregor Aug 82 The Cronus Virtual Local Network + + The purpose of this note is to describe the CRONUS Virtual Local + Network, especially the addressing related features. These features + include a method for mapping between Internet Addresses and Local + Network addresses. This is a topic of current concern in the ARPA + Internet community. This note is intended to stimulate discussion. + This is not a specification of an Internet Standard. + +823 Hinden Sep 82 The DARPA Internet Gateway + + This RFC is a status report on the Internet Gateway developed by BBN. + It describes the Internet Gateway as of September 1982. This memo + presents detailed descriptions of message formats and gateway + procedures, however, this is not an implementation specification, and + such details are subject to change. + +822 Crocker Aug 82 Standard for the Format of ARPA + Internet Text Messages + + This document revises the specifications in RFC 733, in order to + serve the needs of the larger and more complex ARPA Internet. Some + of RFC 733's features failed to gain adequate acceptance. In order + to simplify the standard and the software that follows it, these + features have been removed. A different addressing scheme is used, + to handle the case of internetwork mail; and the concept of + re-transmission has been introduced. Obsoletes RFC 733, NIC 41952. + +821 Postel Aug 82 Simple Mail Transfer Protocol + + The objective of Simple Mail Transfer Protocol (SMTP) is to transfer + mail reliably and efficiently. SMTP is independent of the particular + transmission subsystem and requires only a reliable ordered data + stream channel. Obsoletes RFC 788, 780, and 772. + +820 Postel Jan 82 Assigned Numbers + + This RFC is an old version, see RFC 870. + + + + + + + +Postel & Westine [page 14] + + + +RFC 899 May 1984 + + +819 Zaw-Sing Su Aug 82 The Domain Naming Convention for + Internet User Applications + + This RFC is an attempt to clarify the generalization of the Domain + Naming Convention, the Internet Naming Convention, and to explore the + implications of its adoption for Internet name service and user + applications. + +818 Postel Nov 82 The Remote User Telnet Service + + This RFC is the specification of an application protocol. Any host + that implements this application level service must follow this + protocol. + +817 Clark Jul 82 Modularity and Efficiency in Protocol + Implementation + + This RFC will discuss some of the commonly encountered reasons why + protocol implementations seem to run slowly. + +816 Clark Jul 82 Fault Isolation and Recovery + + This RFC describes the portion of fault isolation and recovery which + is the responsibility of the host. + +815 Clark Jul 82 IP Datagram Reassembly Algorithms + + This RFC describes an alternate approach of dealing with reassembly + which reduces the bookkeeping problem to a minimum, and requires only + one buffer for storage equal in size to the final datagram being + reassembled, which can reassemble a datagram from any number of + fragments arriving in any order with any possible pattern of overlap + and duplication, and which is appropriate for almost any sort of + operating system. + +814 Clark Jul 82 Name, Addresses, Ports, and Routes + + This RFC gives suggestions and guidance for the design of the tables + and algorithms necessary to keep track of these various sorts of + identifiers inside a host implementation of TCP/IP. + +813 Clark Jul 82 Window and Acknowledgement Strategy in + TCP + + This RFC describes implementation strategies to deal with two + mechanisms in TCP, the window and the acknowledgement. It also + presents a particular set of algorithms which have received testing + in the field, and which appear to work properly with each other. + With more experience, these algorithms may become part of the formal + specification, until such time their use is recommended. + + +Postel & Westine [page 15] + + + +RFC 899 May 1984 + + +812 Harrenstien Mar 82 NICNAME/WHOIS + + This RFC gives a description of what the NICNAME/WHOIS Server is and + how to access it. This server together with the corresponding + Identification Data Base provides online directory look-up equivalent + to the ARPANET Directory. + +811 Harrenstien Mar 82 Hostnames Server + + This RFC gives a description of what the Hostnames Server is and how + to access it. The function of this particular server is to deliver + machine-readable name/address information describing networks, + gateways, hosts, and eventually domains, within the internet + environment. + +810 Feinler Mar 82 DoD Internet Host Table Specification + + This RFC specifies a new host table format applicable to both ARPANET + and Internet needs. In addition to host name to host address + translation and selected protocol information, we have also included + network and gateway name to address correspondence, and host + operating system information. This RFC obsoletes the host table + described in RFC 608. + +809 Chang Feb 82 UCL Facsimile System + + This RFC describes the features of the computerised facsimile system + developed in the Department of Computer Science at UCL. First its + functions are considered and the related experimental work are + reported. Then the disciplines for system design are discussed. + Finally, the implementation of the system are described, while + detailed description are given as appendices. + +808 Postel Mar 82 Summary of Computer Mail Services + Meeting Held at BBN on 10 January 1979 + + This RFC is a very belated attempt to document a meeting that was + held three years earlier to discuss the state of computer mail in the + ARPA community and to reach some conclusions to guide the further + development of computer mail systems such that a coherent total mail + service would continue to be provided. + +807 Postel Feb 82 Multimedia Mail Meeting Notes + + This RFC consists of notes from a meeting held at USC Information + Sciences Institute on the 12th of January to discuss common interests + in multimedia computer mail issues and to agree on some specific + initial experiments. + + + + +Postel & Westine [page 16] + + + +RFC 899 May 1984 + + +806 NBS Sep 81 Specification for Message Format for + Computer Based Message Systems + + This RFC deals with Computer Based Message systems which provides a + basis for interaction between different CBMS by defining the format + of messages passed between them. This RFC is replaced by RFC 841. + +805 Postel Feb 82 Computer Mail Meeting Notes + + This RFC consists of notes from a meeting that was held at USC + Information Sciences Institute on 11 January 1982, to discuss + addressing issues in computer mail. The major conclusion reached at + the meeting is to extend the "username@hostname" mailbox format to + "username@host.domain", where the domain itself can be further + strutured. + +804 CCITT Jan 82 CCITT Draft Recommendation T.4 + + This is the CCITT standard for group 3 facsimile encoding. This is + useful for data compression of bit map data. + +803 Agarwal Nov 81 Dacom 450/500 Facsimile Data + Transcoding + + The first part of this RFC describes in detail the Dacom 450 data + compression algorithms and is an update and correction to an earlier + memorandum. The second part of this RFC describes briefly the Dacom + 500 data compression algorithm as used by the INTELPOST + electronic-mail network under development by the US Postal Service + and several foreign administrators. + +802 Malis Nov 81 The ARPANET 1822L Host Access Protocol + + This document proposed two major changes to the current ARPANET host + access protocol. The first change will allow hosts to use logical + addressing (i.e., host addresses that are independent of their + physical location on the ARPANET) to communicate with each other, and + the second will allow a host to shorten the amount of time that it + may be blocked by its IMP after it presents a message to the network + (currently, the IMP can block further input from a host for up to 15 + seconds). See RFCs 852 and 851. + +801 Postel Nov 81 NCP/TCP Transition Plan + + This RFC discusses the conversion of hosts from NCP to TCP. And + making available the principle services: Telnet, File Transfer, and + Mail. These protocols allow all hosts in the ARPA community to share + a common interprocess communication environment. + + + + +Postel & Westine [page 17] + + + +RFC 899 May 1984 + + +800 Postel Nov 82 Requests for Comments Summary + + This RFC is a slightly annotated list of the 100 RFCs from RFC 700 + through RFC 799. This is a status report on these RFCs. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel & Westine [page 18] + |