RFC 1000
Request For Comments reference guide
that one can obtain a reliable implementation of this protocol
standard. This note points out three errors with this
specification. This note also proposes solutions to these
problems.
963 Sidhu Nov 85 Some Problems with the Specification
of the Military Standard Internet
Protocol
The purpose of this RFC is to provide helpful information on the
Military Standard Internet Protocol (MIL-STD-1777) so that one can
obtain a reliable implementation of this protocol. This paper
points out several problems in this specification. This note also
proposes solutions to these problems.
962 Padlipsky Nov 85 TCP-4 Prime
This memo is in response to Bob Braden's call for a transaction
oriented protocol (RFC-955), and continues the discussion of a
possible transaction oriented transport protocol. This memo does
not propose a standard.
961 Reynolds Dec 85 Official ARPA-Internet Protocols
This RFC has been replaced by RFC 991.
960 Reynolds Dec 85 Assigned Numbers
This RFC has been replaced by RFCs 997 and 990.
959 Postel Oct 85 File Transfer Protocol (FTP)
This memo is the official specification of the File Transfer
Protocol (FTP) for the DARPA-Internet community. The primary
intent is to clarify and correct the documentation of the FTP
specification, not to change the protocol. The following new
optional commands are included in this edition of the
specification: Change to Parent Directory (CDUP), Structure Mount
(SMNT), Store Unique (STOU), Remove Directory (RMD), Make
Directory (MKD), Print Directory (PWD), and System (SYST). Note
that this specification is compatible with the previous edition.
958 Mills Sep 85 Network Time Protocol (NTP)
This document describes the Network Time Protocol (NTP), a
protocol for synchronizing a set of network clocks using a set of
distributed clients and servers. NTP is built on the User
Datagram Protocol (UDP), which provides a connectionless transport
mechanism. It evolved from the Time Protocol and the ICMP
Timestamp message and is a suitable replacement for both. This
RFC suggests a proposed protocol for the ARPA-Internet community,
and requests discussion and suggestions for improvements.
957 Mills Sep 85 Experiments in Network Clock
Synchronization
This RFC discusses some experiments in clock synchronization in
the ARPA-Internet community, and requests discussion and
suggestions for improvements. One of the services frequently
neglected in computer network design is a high-quality,
time-of-day clock capable of generating accurate timestamps with
small errors compared to one-way network delays. Such a service
would be useful for tracing the progress of complex transactions,
synchronizing cached data bases, monitoring network performance
and isolating problems. In this memo, one such clock service
design will be described and its performance assessed. This
design has been incorporated as an integral part of the network
routing and control protocols of the Distributed Computer Network
(DCnet) architecture.
956 Mills Sep 85 Algorithms for Synchronizing Network
Clocks
This RFC discussed clock synchronization algorithms for the
ARPA-Internet community, and requests discussion and suggestions
for improvements. The recent interest within the Internet
community in determining accurate time from a set of mutually
suspicious network clocks has been prompted by several occasions
in which errors were found in usually reliable, accurate clock
servers after thunderstorms which disrupted their power supply.
To these sources of error should be added those due to
malfunctioning hardware, defective software and operator mistakes,
as well as random errors in the mechanism used to set and
synchronize clocks. This report suggests a stochastic model and
algorithms for computing a good estimator from time-offset samples
measured between clocks connected via network links. Included in
this report are descriptions of certain experiments which give an
indication of the effectiveness of the algorithms.
955 Braden Sep 85 Towards a Transport Service for
Transaction Processing Applications
The DoD Internet Protocol Suite includes two alternative transport
service protocols, TCP and UDP, which provide virtual circuit and
datagram service, respectively. These two protocols represent
points in the space of possible transport service attributes which
are quite "far apart". We want to examine an important class of
applications, those which perform what is often called
"transaction processing". We will see that the communication
needs for these applications fall into the gap "between" TCP and
UDP -- neither protocol is very appropriate.
954 Harrenstien Oct 85 NICNAME/WHOIS
This RFC is the official specification of the NICNAME/WHOIS
protocol. This memo describes the protocol and the service. This
is an update of RFC 812. Obsoletes RFC 812.
953 Harrenstien Oct 85 Hostname Server
This RFC is the official specification of the Hostname Server
Protocol. This edition of the specification includes minor
revisions to RFC 811 which brings it up to date. Obsoletes RFC
811.
952 Harrenstien Oct 85 DoD Internet Host Table
Specification
This RFC is the official specification of the format of the
Internet Host Table. This edition of the specification includes
minor revisions to RFC 810 which brings it up to date. Obsoletes
RFCs 810, 608.
951 Croft Sep 85 Bootstrap Protocol (BOOTP)
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which
allows a diskless client machine to discover its own IP address,
the address of a server host, and the name of a file to be loaded
into memory and executed. The bootstrap operation can be thought
of as consisting of TWO PHASES. This RFC describes the first
phase, which could be labeled `address determination and bootfile
selection'. After this address and filename information is
obtained, control passes to the second phase of the bootstrap
where a file transfer occurs. The file transfer will typically
use the TFTP protocol, since it is intended that both phases
reside in PROM on the client. However BOOTP could also work with
other protocols such as SFTP or FTP. This RFC suggests a proposed
protocol for the ARPA-Internet community, and requests discussion
and suggestions for improvements.
950 Mogul Aug 85 Internet Standard Subnetting
Procedure
This memo discusses the utility of "subnets" of Internet networks,
which are logically visible sub-sections of a single Internet
network. For administrative or technical reasons, many
organizations have chosen to divide one Internet network into
several subnets, instead of acquiring a set of Internet network
numbers. This memo specifies procedures for the use of subnets.
These procedures are for hosts (e.g., workstations). The
procedures used in and between subnet gateways are not fully
described. Important motivation and background information for a
subnetting standard is provided in RFC-940. This RFC specifies a
protocol for the ARPA-Internet community. If subnetting is
implemented it is strongly recommended that these procedures be
followed.
949 Padlipsky Jul 85 FTP Unique-Named Store Command
There are various contexts in which it would be desirable to have
an FTP command that had the effect of the present STOR but rather
than requiring the sender to specify a file name istead caused the
resultant file to have a unique name relative to the current
directory.
This RFC proposes an extension to the File Transfer Protocol for
the ARPA-Internet community, and requests discussion and
suggestions for improvements.
948 Winston Jun 85 Two Methods for the Transmission of
IP Datagrams Over IEEE 802.3
Networks
This memo describes two methods of encapsulating Internet Protocol
(IP) datagrams on an IEEE 802.3 network.
947 Lebowitz Jun 85 Multi-Network Broadcasting Within
the Internet
This RFC describes the extension of a network's broadcast domain
to include more than one physical network through the use of a
broadcast packet repeater.
946 Nedved May 85 Telnet Terminal Location Number
Option
Many systems provide a mechanism for finding out where a user is
logged in from usually including information about telephone
extension and office occupants names. The information is useful
for physically locating people and/or calling them on the phone.
In 1982 CMU designed and implemented a terminal location database
and modified existing network software to handle a 64-bit number
called the Terminal Location Number (or TTYLOC). It now seems
appropriate to incorporate this mechanism into the TCP-based
network protocol family. The mechanism is not viewed as a
replacement for the Terminal Location Telnet Option
(SEND-LOCATION) but as a shorthand mechansim for communicating
terminal location information between hosts in a localized
community. This RFC proposes a new option for Telnet for the
ARPA-Internet community, and requests discussion and suggestions
for improvements.
945 Postel May 85 A DoD Statement on the NRC Report
In May 1983, the National Research Council (NRC) was asked jointly
by the DoD and NBS to study the issues and recommend a course of
action. The final report of the NRC committee was published in
February 1985 (see RFC-942). The enclosed letter is from Donald C.
Latham (ASDC3I) to DCA transmitting the NRC report and requesting
specific actions relative to the recommendations of the report.
This RFC reproduces a letter from the Assistant Secretary of
Defense for Command, Control, Communications, and Intelligence
(ASDC3I) to the Director of the Defense Communications Agency
(DCA). This letter is distributed for information only.
944 Reynolds Apr 85 Official ARPA-Internet Protocols
This RFC has been replaced by RFC 991.
943 Reynolds Apr 85 Assigned Numbers
This RFC has been replaced by RFCs 997 and 990.
942 NRC Feb 85 Transport Protocols for Department
of Defense Data Networks
This RFC reproduces the National Research Council report resulting
from a study of the DoD Internet Protocol (IP) and Transmission
Control Protocol (TCP) in comparison with the ISO Internet
Protocol (ISO-IP) and Transport Protocol level 4 (TP-4).
941 ISO Apr 85 Addendum to the Network Service
Definition Covering Network Layer
Addressing
This Addendum to the Network Service Definition Standard, ISO
8348, defines the abstract syntax and semantics of the Network
Address (Network Service Access Point Address). The Network
Address defined in this Addendum is the address that appears in
the primitives of the connection-mode Network Service as the
calling address, called address, and responding address
parameters, and in the primitives of the connectionless-mode
Network Service as the source address and destination address
parameters.
This document is distributed as an RFC for information only. It
does not specify a standard for the ARPA-Internet.
940 GADS Apr 85 Toward an Internet Standard Scheme
for Subnetting
Several sites now contain a complex of local links connected to
the Internet via a gateway. The details of the internal
connectivity are of little interest to the rest of the Internet.
One way of organizing these local complexes of links is to use the
same strategy as the Internet uses to organize networks, that is,
to declare each link to be an entity (like a network) and to
interconnect the links with devices that perform routing functions
(like gateways). This general scheme is called subnetting, the
individual links are called subnets, and the connecting devices
are called subgateways (or bridges, or gateways). This RFC
discusses standardizing the protocol used in subnetted
environments in the ARPA-Internet. Distribution of this memo is
unlimited. The author of this RFC is the Gateway Algorithms and
Data Structures (GADS) Task Force, chaired by David L. Mills.
939 NRC Feb 85 Executive Summary of the NRC Report
on Transport Protocols for
Department of Defense Data Networks
This RFC reproduces the material from the "front pages" of the
National Research Council report resulting from a study of the DOD
Internet Protocol (IP) and Transmission Control Protocol (TCP) in
comparison with the ISO Internet Protocol (ISO-IP) and Transport
Protocol level 4 (TP-4). The point of this RFC is to make the
text of the Executive Summary widely available in a timely way.
The order of presentation has been altered, and the pagination
changed.
938 Miller Feb 85 Internet Reliable Transaction
Protocol Functional and Interface
Specification
This RFC is being distributed to members of the DARPA research
community in order to solicit their reactions to the proposals
contained in it. While the issues discussed may not be directly
relevant to the research problems of the DARPA community, they may
be interesting to a number of researchers and implementors. This
RFC suggests a proposed protocol for the ARPA-Internet community,
and requests discussion and suggestions for improvements.
937 Reynolds Feb 85 Post Office Protocol - Version 2
This RFC suggests a simple method for workstations to dynamically
access mail from a mailbox server. This RFC specifies a proposed
protocol for the ARPA-Internet community, and requests discussion
and suggestions for improvement. This memo is a revision of
RFC 918.
936 Karels Feb 85 Another Internet Subnet Addressing
Scheme
There have been several proposals for schemes to allow the use of
a single Internet network number to refer to a collection of
physical networks under common administration which are reachable
from the rest of the Internet by a common route. Such schemes
allow a simplified view of an otherwise complicated topology from
hosts and gateways outside of this collection. They allow the
complexity of the number and type of these networks, and routing
to them, to be localized. Additions and changes in configuration
thus cause no detectable change, and no interruption of service,
due to slow propagation of routing and other information outside
of the local environment. These schemes also simplify the
administration of the network, as changes do not require
allocation of new network numbers for each new cable installed.
This proposal discusses an alternative scheme, one that has been
in use at the University of California, Berkeley since April 1984.
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for
improvements.
935 Robinson Jan 85 Reliable Link Layer Protocols
This RFC discusses protocols proposed recently in RFCs 914 and
916, and suggests a proposed protocol that could meet the same
needs addressed in those memos. The stated need is reliable
communication between two programs over a full-duplex,
point-to-point communication link, and in particular the RFCs
address the need for such communication over an asynchronous link
at relatively low speeds. The suggested protocol uses the methods
of existing national and international data link layer standards.
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for
improvements.
934 Rose Jan 85 Proposed Standard for Message
Encapsulation
This memo concerns itself with message forwarding. Forwarding can
be thought of as encapsulating one or more messages inside
another. Although this is useful for transfer of past
correspondence to new recipients, without a decapsulation process
(which this memo terms "bursting"), the forwarded messages are of
little use to the recipients because they can not be distributed,
forwarded, replied-to, or otherwise processed as separate
individual messages. In order to burst a message it is necessary
to know how the component messages were encapsulated in the draft.
At present there is no unambiguous standard for interest group
digests. This RFC proposes a proposed protocol for the
ARPA-Internet community, and requests discussion and suggestions
for improvements.
933 Silverman Jan 85 Output Marking Telnet Option
This proposed option would allow a Server-Telnet to send a banner
to a User-Telnet so that this banner would be displayed on the
workstation screen independently of the application software
running in the Server-Telnet.
932 Clark Jan 85 A Subnetwork Addressing Scheme
This RFC proposes an alternative addressing scheme for subnets
which, in most cases, requires no modification to host software
whatsoever. The drawbacks of this scheme are that the total
number of subnets in any one network are limited, and that
modification is required to all gateways.
931 StJohns Jan 85 Authentication Server
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for
improvements. This is the second draft of this proposal
(superseding RFC 912) and incorporates a more formal description
of the syntax for the request and response dialog, as well as a
change to specify the type of user identification returned.
930 Solomon Jan 85 Telnet Terminal Type Option
This RFC specifies a standard for the ARPA-Internet community.
Hosts on the ARPA-Internet that exchange terminal type information
within the Telnet protocol are expected to adopt and implement
this standard. Distribution of this memo is unlimited. This
standard supersedes RFC 884. The only change is to specify that
the TERMINAL-TYPE IS sub-negotiation should be sent only in
response to the TERMINAL-TYPE SEND sub-negotiation.
929 Lilienkamp Dec 84 Proposed Host-Front End Protocol
The Host-Front End Protocol introduced in RFC 928 is described in
detail in this memo. The first order of business is to declare
that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the second
order of business is to request that any readers of these
documents who are able to do test implementations (a) do so and
(b) coordinate their efforts with the author. This RFC suggests a
proposed protocol for the ARPA-Internet community, and requests
discussion and suggestions for improvements.
928 Padlipsky Dec 84 Introduction to Proposed DOD
Standard H-FP
The broad outline of the Host-Front End Protocol introduced here
and described in RFC 929 is the result of the deliberations of a
number of experienced H-FP designers, who sat as a committee of
the DoD Protocol Standards Technical Panel. It is the intent of
the designers that the protocol be subjected to multiple test
implementations and probable iteration before being agreed upon as
any sort of "standard". Therefore, the first order of business is
to declare that THIS IS A PROPOSAL, NOT A FINAL STANDARD, and the
second order of business is to request that any readers of these
documents who are able to do test implementations (a) do so and
(b) coordinate their efforts with the author. This RFC suggests a
proposed protocol for the ARPA-Internet community, and requests
discussion and suggestions for improvements.
927 Anderson Dec 84 TACACS User Identification Telnet
Option
The following is the description of a Telnet option designed to
facilitate double login avoidance. It is intended primarily for
TAC connections to target hosts on behalf of TAC users, but it can
be used between any two consenting hosts. For example, all hosts
at one site (e.g., BBN) can use this option to avoid double login
when TELNETing to one another.
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for
improvements.
926 ISO Dec 84 Protocol for Providing the
Connectionless-Mode Network Services
This note is the draft ISO protocol roughly similar to the DoD
Internet Protocol. This document has been prepared by retyping
the text of ISO DIS 8473 of May 1984, which is currently
undergoing voting within ISO as a Draft International Standard
(DIS). This document is distributed as an RFC for information
only. It does not specify a standard for the ARPA-Internet.
925 Postel Oct 84 Multi-LAN Address Resolution
The problem of treating a set of local area networks (LANs) as one
Internet network has generated some interest and concern. It is
inappropriate to give each LAN within a site a distinct
ARPA-Internet network number. It is desirable to hide the details
of the interconnections between the LANs within a site from
people, gateways, and hosts outside the site. The question arises
on how to best do this, and even how to do it at all. In RFC 917,
Jeffery Mogul makes a case for the use of "explicit subnets" in a
multi-LAN environment. The explicit subnet scheme is a call to
recursively apply the mechanisms the ARPA-Internet uses to manage
networks to the problem of managing LANs within one network. In
this note I urge another approach: the use of "transparent
subnets" supported by a multi-LAN extension of the Address
Resolution Protocol. This RFC suggests a proposed protocol for
the ARPA-Internet community, and requests discussion and
suggestions for improvements.
924 Reynolds Oct 84 Official ARPA-Internet Protocols
This RFC has been replaced by RFC 991.
923 Reynolds Oct 84 Assigned Numbers
This RFC has been replaced by RFCs 997 and 990.
922 Mogul Oct 84 Broadcasting Internet Datagrams in
the Presence of Subnets
We propose simple rules for broadcasting Internet datagrams on
local networks that support broadcast, for addressing broadcasts,
and for how gateways should handle them.
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for
improvements.
921 Postel Oct 84 Domain Name System Implementation
Schedule - Revised
This memo is a policy statement on the implementation of the
Domain Style Naming System in the ARPA-Internet. This memo is an
update of RFC 881, and RFC 897. This is an official policy
statement of the IAB and the DARPA. The intent of this memo is to
detail the schedule for the implementation for the Domain Style
Naming System. The explanation of how this system works is to be
found in the references.
920 Postel Oct 84 Domain Requirements
This memo states the requirements on establishing a Domain, and
introduces the limited set of top level domains. This memo is a
policy statement on the requirements of establishing a new domain
in the ARPA-Internet and the DARPA research community. This is an
official policy statement of the IAB and the DARPA.
919 Mogul Oct 84 Broadcasting Internet Datagrams
This RFC proposes simple rules for broadcasting Internet datagrams
on local networks that support broadcast, for addressing
broadcasts, and for how gateways should handle them. This RFC
suggests a proposed protocol for the ARPA-Internet community, and
requests discussion and suggestions for improvements.
918 Reynolds Oct 84 Post Office Protocol (POP)
Updated by RFC 937.
917 Mogul Oct 84 Internet Subnets
This memo discusses subnets and proposes procedures for the use of
subnets, including approaches to solving the problems that arise,
particularly that of routing. A subnet of an Internet network is
a logically visible sub-section of a single Internet network. For
administrative or technical reasons, many organizations have
chosen to divide one Internet network into several subnets,
instead of acquiring a set of Internet network numbers. This RFC
suggests a proposed protocol for the ARPA-Internet community, and
requests discussion and suggestions for improvements.
916 Finn Oct 84 Reliable Asynchronous Transfer
Protocol (RATP)
This paper proposes and specifies a protocol which allows two
programs to reliably communicate over a communication link. It
ensures that the data entering one end of the link if received
arrives at the other end intact and unaltered. The protocol,
named RATP, is designed to operate over a full duplex
point-to-point connection. It contains some features which tailor
it to the RS-232 links now in common use.
This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for
improvements.
915 Elvy Dec 84 Network Mail Path Service
The network mail path service fills the current need of people to
determine mailbox addresses for hosts that are not part of the
ARPA-Internet but can be reached by one or more relay hosts that
have Unix to Unix Copy (UUCP) mail, CSNET mail, MAILNET mail,
BITNET mail, etc. Anyone can use the service if they have
TCP/TELENET to one of the hosts with a mail path server. This RFC
proposes a new service for the ARPA-Internet community and
requests discussion and suggestions for improvements.
914 Farber Sep 84 A Thinwire Protocol
This document focuses discussion on the particular problems in the
ARPA-Internet of low speed network interconnection with personal
computers, and possible methods of solution. None of the proposed
solutions in this document are intended as standards for the
ARPA-Internet. Rather, it is hoped that a general consensus will
emerge as to the appropriate solution to the problems, leading
eventually to the adoption of standards.
913 Lottor Sep 84 Simple File Transfer Protocol
This memo describes a proposed Simple File Transfer Protocol
(SFTP). It fills the need of people wanting a protocol that is
more useful than TFTP but easier to implement (and less powerful)
than FTP. SFTP supports user access control, file transfers,
directory listing, directory changing, file renaming, and
deleting. Discussion of this proposal is encouraged, and
suggestions for improvements may be sent to the author.
912 StJohns Sep 84 Authentication Service
This memo describes a proposed authentication protocol for
verifying the identity of a user of a TCP connection. Given a TCP
port number pair, it returns a character string which identifies
the owner of that connection on the server's system. Suggested
uses include automatic identification and verification of a user
during an FTP session, additional verification of a TAC dial up
user, and access verification for a generalized network file
server.
911 Kirton Aug 84 EGP Gateway under Berkeley Unix 4.2
This memo describes an implementation of the Exterior Gateway
Protocol (EGP) (in that sense it is a status report). The memo
also discusses some possible extentions and some design issues (in
that sense it is an invitation for further discussion).
910 Forsdick Aug 84 Multimedia Mail Meeting Notes
This memo is a report on a meeting about the experimental
multimedia mail system (and in a sense a status report on that
experiment). The meeting was held at Bolt Beranek and Newman on
23-24 July 1984 to discuss recent progress by groups who are
building multimedia mail systems and to discuss a variety of
issues related to the further development of multimedia systems.
Representatives were present from BBN, ISI, SRI and Linkabit.
Distribution of this memo is unlimited.
909 Welles Jul 84 Loader Debugger Protocol
The Loader Debugger Protocol (LDP) is an application layer
protocol for loading, dumping, and debugging target machines from
hosts in a network environment. This RFC specifies a proposed
protocol for the ARPA-Internet and DARPA research community, and
requests discussion and suggestions for improvements.
908 Velten Jul 84 Reliable Data Protocol
The Reliable Data Protocol (RDP) is designed to provide a reliable
data transport service for packet-based applications. This RFC
specifies a proposed protocol for the ARPA-Internet and DARPA
research community, and requests discussion and suggestions for
improvemts.
907 Storch Jul 84 Host Access Protocol Specification
This document specifies the Host Access Protocol (HAP). Although
HAP was originally designed as the network-access level protocol
for the DARPA/DCA sponsored Wideband Packet Satellite Network, it
is intended that it evolve into a standard interface SATNET and
TACNET (aka MATNET) as well as the Wideband Network. HAP is an
experimental protocol, and will undergo further revision as new
capabilities are added and/or different satellite networks are
suported. Implementations of HAP should be performed in
coordination with satellite network development and operations
personnel.
906 Finlayson Jun 84 Bootstrap Loading Using TFTP
It is often convenient to be able to bootstrap a computer system
from a communications network. This RFC proposes the use of the
IP/TFTP protocol for bootstrap loading in this case.
905 ISO Apr 84 ISO Transport Protocol Specification
(ISO DP 8073)
This is the current specification of the ISO Transport Protocol.
This document is the text of ISO/TC97/SC16/N1576 as corrected by
ISO/TC97/SC16/N1695. This is the specification currently being
voted on in ISO as a Draft International Standard (DIS). This
document is distributed as an RFC for your information only, it
does not specify a standard for the ARPA-Internet or DARPA
research community. Our thanks to Alex McKenzie of BBN for making
this online version available. Please note the size of this
document, the file contains 258,729 characters.
904 Mills Apr 84 Exterior Gateway Protocol Formal
Specification
This is the specification of the Exterior Gateway Protocol (EGP).
This memo updates portions of RFC 888 and RFC 827. This RFC
specifies an official protocol of the DARPA community for use
between gateways of different autonomous systems in the
ARPA-Internet.
903 Finlayson Jun 84 A Reverse Address Resolution
Protocol
This RFC suggests a method for workstations to dynamically find
their protocol address (e.g., their Internet Address), when they
know only their hardware address (e.g., their attached physical
network address). This RFC specifies a proposed protocol for the
ARPA-Internet community, and requests discussion and suggestions
for improvement.
902 Postel Jul 84 ARPA-Internet Protocol Policy
The purpose of this memo is to explain how protocol standards are
adopted for the ARPA-Internet and the DARPA research community.
There are three important aspects to be discussed: the process,
the authority, and the complex relationship between the DARPA
community and the DDN community. This memo is a policy statement
on how protocols become official standards for the ARPA-Internet
and the DARPA research community. This is an official policy
statement of the ICCB and the DARPA.
901 Reynolds Jun 84 Official ARPA-Internet Protocols
This RFC has been replaced by RFC 991.
900 Reynolds Jun 84 Assigned Numbers
This RFC has been replaced by RFCs 997 and 990.
899 Postel Apr 84 Requests For Comments Summary
A summary of the Request for Comments documents from RFC 800-898.
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 the
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 ARPA-Internet. This memo is a
partial update of RFC 881. The intent of this memo is to detail
the schedule for the implementation of 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.
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.
890 Postel Feb 84 Exterior Gateway Protocol
Implementation Schedule
This memo is a policy statement on the implementation of the
Exterior Gateway Protocol (EGP) in the ARPA-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 ARPA-Internet and advice to TCP implementers.
888 Seamonson Jan 84 "Stub" Exterior Gateway Protocol
This RFC describes the Exterior Gateway Protocol (EGP) 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 ARPA-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 ARPA-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.
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
DDN/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 has been replaced by RFC 991.
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 purpose 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".
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.
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 has been replaced by RFCs 997 and 990.
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.
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.
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.
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 Never Issued.
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-Internet 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.
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 ARPA-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.
844 Clements Feb 83 Who Talks ICMP, too? Survey of 18
February 1983
This survey determines how many hosts are able to respond to
Telnet 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 replaced by RFC 991.
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.
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.
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 ARPA-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 ARPA-Internet Standard.
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
ARPA-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 RFCs 788, 780, 772.
820 Postel Jan 82 Assigned Numbers
This RFC is is replaced by RFCs 997 and 990.
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 ARPA-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.
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.
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
structured.
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.
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.
799 Mills Sep 81 Internet Name Domains
This document suggests that, as the Internet grows, the space of
host names cannot remain a flat space of globally unique names,
therefore a hierarchy of name domains must be introduced; see also
RFC 822.
798 Katz Sep 81 Decoding Facsimile Data From the
Rapicom 450
A description of the encoding/decoding procedure for Rapicom 450
facsimile machine.
797 Katz Sep 81 Format for Bitmap Files
The description of a simple file format for bitmap data.
796 Postel Sep 81 Address Mappings
A description of the way the addresses of a few actual networks
are mapped into internet addresses.
795 Postel Sep 81 Service Mappings
A description of how the internet type of service is mapped into
the actual service parameters of a few particular networks, and
vice versa.
794 Cerf Sep 81 Pre-Emption
Discusses how pre-emption of TCP connection can be implemented.
Replaces IEN 125.
793 Postel Sep 81 Transmission Control Protocol
The specification of TCP. Replaces RFCs 761 and 675.
792 Postel Sep 81 Internet Control Message Protocol
The specification of ICMP. Replaces RFCs 777 and 760.
791 Postel Sep 81 Internet Protocol
An updated specification of IP. Replaces RFC 760.
790 Postel Sep 81 Assigned Numbers
The RFC is replaced by RFCs 997 and 990.
789 Rosen Jul 81 Vulnerabilities of Network Control
Protocols: An Example
A description of an outage in ARPANET service and the process of
determining the cause; also, subtleties of designing network
protocols.
788 Postel Nov 81 Simple Mail Transfer Protocol
An old version; see RFC 821.
787 Chapin Jul 81 Connectionless Data Transmission
Survey/Tutorial
A discussion of datagram service. Intended for submission to
international standards bodies.
786 Sluizer Jul 81 Mail Transfer Protocol: ISI TOPS-20
MTP-NIMAIL Interface
The description of the way mail is passed between the MTP and the
NIMAIL programs in ISI TOPS-20. Outdated.
785 Sluizer Jul 81 Mail Transfer Protocol: ISI TOPS-20
File Definitions
The description of the file format for passing mail to the MTP
program from user mail programs in ISI TOPS-20. Outdated.
784 Sluizer Jul 81 Mail Transfer Protocol: ISI TOPS-20
Implementation
The description of the program structure for the MTP
implementation in the ISI TOPS-20. Outdated.
783 Sollins Jun 81 The TFTP Protocol Revision 2
The specification of TFTP. Replaces RFCs 768, 764 and IEN 133.
782 Nabielsky undated A Virtual Terminal Management Model
A description of the elements of a virtual terminal and the
management of communications between them.
781 Su May 81 A Specification of the Internet
Protocol IP Timestamp Option
The description of IP Timestamp option, now included in the IP
specification (RFC 791).
780 Sluizer May 81 Mail Transfer Protocol
An outdated Mail protocol; see RFC 821.
779 Killian Apr 81 Telnet Send-Location Option
Definition of this Telnet option.
778 Mills Apr 81 DCNet Internet Clock Service
Specifies a format and procedure for the exchange of messages to
maintain synchronized clocks.
777 Postel Apr 81 Internet Control Message Protocol
An old version; see RFC 792.
776 Postel Jan 81 Assigned Numbers
This RFC has been replaced by RFCs 997 and 990.
775 Mankins Dec 80 Directory Oriented FTP Commands
The definition of additional FTP Commands related to directory
management.
774 Postel Oct 80 Internet Protocol Handbook Table of
Contents
An out-of-date table of contents for an Internet Protocol
Handbook.
773 Cerf Oct 80 Comments on NCP/TCP Mail Service
Transition Strategy
A discussion of issues in the transition from NCP to TCP,
particularly as related to MAIL Service.
772 Sluizer Sep 80 Mail Transfer Protocol
An old version of a Mail Protocol; see RFC 821.
771 Cerf Sep 80 Mail Transition Plan
A plan for supporting mail service in the transition from NCP to
TCP; see also RFC 801.
770 Postel Sep 80 Assigned Numbers
This RFC has been replaced by RFCs 997 and 990.
769 Postel Sep 80 Rapicom 450 Facsimile File Format
The definition of the exchange format of the encoded facsimile
data of the Rapicom 450; see also RFC 798.
768 Postel Aug 80 User Datagram Protocol
The specification of the UDP.
767 Postel Aug 80 A Structured Format for Transmission
of Multi-Media Documents
The definition of the format for the document of a multimedia
message.
766 Postel Jul 80 Internet Protocol Handbook
An out-of-date table of contents for the Internet Protocol
Handbook.
765 Postel Jun 80 File Transfer Protocol Specification
The specification of FTP.
764 Postel Jun 80 Telnet Protocol Specification
The specification of Telnet.
763 Abrams May 80 Role Mailboxes
A call for mailboxes with role names, such as "Management".
(next page on part 3)
