RFC Abstracts

RFC0818
This RFC is the specification of an application protocol. Any host that implements this application level service must follow this protocol.
RFC0817
This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly.
RFC0816
This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.
RFC0815
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.
RFC0814
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.
RFC0813
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.
RFC0812
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.
RFC0811
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.
RFC0810
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.
RFC0809
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.
RFC0808
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.
RFC0807
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.
RFC0806
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.
RFC0805
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.
RFC0804
This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.
RFC0803
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.
RFC0802
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.
RFC0801
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.
RFC0800
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.
RFC0698
Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.
RFC0697
Discusses FTP login access to "files only" directories.
RFC0696
Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687.
RFC0695
Corrects ambiguity concerning the ERR command; changes NIC 8246 and NIC 7104.
RFC0694
References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661.
RFC0692
A proposed solution to the problem of combined length of IMP and Host leaders; see also RFCs 696, 690 and 687.
RFC0691
Slight revision of RFC 686, on the subject of print files; see also RFCs 640, 630, 542, 454, 448, 414, 385 and 354.
RFC0690
Comments on suggestions in RFC 687; see also RFCs 692 and 696.
RFC0689
Describes the internal states of an NCP connection in the TENEX implementation.
RFC0687
Addressing hosts on more than 63 IMPs, and other backwards compatible expansions; see also RFCs 690 and 692.
RFC0686
Discusses difference between early and later versions of FTP; see also RFCs 691, 640, 630, 542, 454, 448, 414, 385 and 354.
RFC0685
The contribution of ARPANET communication to response time.
RFC0684
Issues in designing distributed computing systems. Shortcomings of RFC 674; see also RFCs 542 and 354.
RFC0683
Defines an extension to FTP for page-mode transfers between TENEX systems; also discusses file transfer reliability.
RFC0681
Capabilities as an ARPANET Mini-Host: standard I/O, Telnet, NCP, Hardware/Software requirements, reliability, availability.
RFC0680
Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822.
RFC0679
An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703.
RFC0678
For transmission of documents across different environments.
RFC0675
The first detailed specification of TCP; see RFC 793.
RFC0674
Host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.
RFC0672
Applicability of TIP/TENEX protocols beyond TIP accounting.
RFC0671
Experience with implementation in RSEXEC context.
RFC0669
An earlier poll of Telnet server implementation status. Updates RFC 702; see also RFCs 703 and 679.
RFC0667
Approved scheme to connect host ports to the network.
RFC0666
Discusses and proposes a common command language.
RFC0663
Proposed extension of host-host protocol; see also RFCs 534, 516, 512, 492 and 467.
RFC0662
Experimenting with host output buffers to improve throughput.
RFC0661
An old version; see RFC 694.
RFC0660
Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.
RFC0659
Options defined in RFCs 651-658.
RFC0647
Approaches to Front-End protocol processing using available hardware and software.