RFC Abstracts

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