As per Relevance of the word standard, we have this rfc below:
Network Working Group A.
Request for Comments: 999 J.
April 1987
Requests For Comments
Notes: 900-999
Status of this
This RFC is a slightly annotated list of the 100 RFCs from RFC-900
through RFC-999. This is a status report on these RFCs.
of this memo is unlimited
RFC Author Date
--- ------ ---- -----
999 Westine Apr 87 Requests For Comments
This memo
998 Lambert Mar 87 NETBLT: A Bulk Data
This document is a description of, and a specification for, the
protocol. It is a revision of the specification published in RFC-969.
NETBLT (NETwork BLock Transfer) is a transport level protocol
for the rapid transfer of a large quantity of data between computers
It provides a transfer that is reliable and flow controlled, and
designed to provide maximum throughput over a wide variety of networks
Although NETBLT currently runs on top of the Internet Protocol (IP),
should be able to operate on top of any datagram protocol similar
function to IP. This document is published for discussion and comment
and does not constitute a standard. The proposal may change and
parts of the protocol have not yet been specified; implementation of
document is therefore not advised. Obsoletes RFC-969.
997 Reynolds Mar 87 Internet
This memo is an official status report on the network numbers used
the Internet community. As of 1-Mar-87 the Network Information
(NIC) at SRI International has assumed responsibility for assignment
Network Numbers and Autonomous System Numbers. This RFC documents
current assignments of these numbers at the time of this transfer
responsibility. Obsoletes RFC-990, 960, 943, 923 and 900.
Westine & Postel [Page 1]
RFC 999 March 1987
996 Mills Feb 87 Statistics
This RFC specifies a standard for the ARPA Internet community. Hosts
gateways on the DARPA Internet that choose to implement a
statistics monitoring facility may use this protocol to send
data upon request to a monitoring center or debugging host
995 ANSI Apr 86 End System to Intermediate
Routing Exchange Protocol for use
conjunction with ISO 8473.
This Protocol is one of a set of International Standards produced
facilitate the interconnection of open systems. The set of
covers the services and protocols required to achieve such interconnection
This Protocol is positioned with respect to other related standards
the layers defined in the Reference Model for Open Systems
(ISO 7498) and by the structure defined in the Internal Organization of
Network Layer (DIS 8648). In particular, it is a protocol of the
Layer. This Protocol permits End Systems and Intermediate Systems
exchange configuration and routing information to facilitate the
of the routing and relaying functions of the Network Layer
994 ANSI Mar 86 Final Text of DIS 8473, Protocol
Providing the Connectionless
Network
This Protocol Standard is one of a set of International
produced to facilitate the interconnection of open systems. The set
standards covers the services and protocols required to achieve
interconnection. This Protocol Standard is positioned with respect
other related standards by the layers defined in the Reference
for Open Systems Interconnection (ISO 7498). In particular, it is
protocol of the Network Layer. This Protocol may be used
network-entities in end systems or in Network Layer relay systems (
both). It provides the Connectionless-mode Network Service as
in Addendum 1 to the Network Service Definition Covering Connectionless-
Transmission (ISO 8348/AD1).
993 Clark Dec 86 PCMAIL: A Distributed Mail System
Personal
This document is a discussion of the Pcmail workstation-
distributed mail system. It is a revision of the design published
NIC RFC-984. The revision is based on discussion and comment fromm
variety of sources, as well as further research into the design
interactive Pcmail clients and the use of client code on machines
than IBM PCs. As this design may change, implementation of
document is not advised. Obsoletes RFC-984.
Westine & Postel [Page 2]
RFC 999 March 1987
992 Birman Nov 86 On Communication Support
Fault-Tolerant Process
This memo describes a collection of multicast communication
integrated with a mechanism for handling process failure and recovery
These primitives facilitate the implementation of fault-tolerant
groups, which can be used to provide distributed services in
environment subject to non-malicious crash failures
991 Reynolds Nov 86 Official ARPA-Internet
This RFC identifies the documents specifying the official protocols
in the Internet. Comments indicate any revisions or changes planned
This memo is an official status report on the numbers used in
in the ARPA-Internet community. Obsoletes RFC-961, 944 and 924.
990 Reynolds Nov 86 Assigned
This Network Working Group Request for Comments documents the
assigned values from several series of numbers used in network
implementations. This memo is an official status report on the
used in protocols in the ARPA-Internet community. See RFC-997.
RFC-960, 943, 923 and 900.
989 Linn Feb 87 Privacy Enhancement for
Electronic Mail: Part I:
Encipherment and
This RFC suggests a proposed protocol for the Internet community
requests discussion and suggestions for improvements. This RFC is
outgrowth of a series of IAB Privacy Task Force meetings and of
working papers distributed for those meetings. This RFC defines
encipherment and authentication procedures, as the initial phase of
effort to provide privacy enhancement services for electronic
transfer in the Internet. It is intended that the procedures
here be compatible with a wide range of key management approaches
including both conventional (symmetric) and public-key (asymmetric
approaches for encryption of data encrypting keys. Use of
cryptography for message text encryption and/or authentication
anticipated
988 Deering Jul 86 Host Extensions for IP
This memo specifies the extensions required of a host implementation
the Internet Protocol (IP) to support internetwork multicasting.
specification supersedes that given in RFC-966, and constitutes
proposed protocol standard for IP multicasting in the ARPA-Internet
The reader is directed to RFC-966 for a discussion of the motivation
rationale behind the multicasting extension specified here
Westine & Postel [Page 3]
RFC 999 March 1987
987 Kille Jun 86 Mapping between X.400 and RFC-822
The X.400 series protocols have been defined by CCITT to provide
Interpersonal Messaging Service (IPMS), making use of a store
forward Message Transfer Service. It is expected that this
will be implemented very widely. This document describes a set
mappings which will enable interworking between systems operating
X.400 protocols and systems using RFC-822 mail protocol or
derived from RFC-822. This RFC suggests a proposed protocol for
ARPA-Internet community, and requests discussion and suggestions
improvements
986 Callon Jun 86 Working Draft -- Guidelines for the
of Internet-IP addressing in the
Connectionless-Mode Network
This RFC suggests a method to allow the existing IP addressing
including the IP protocol field, to be used for the ISO
Network Protocol (CLNP). This is a draft solution to one of
problems inherent in the use of "ISO-grams" in the DOD Internet
Related issues will be discussed in subsequent RFCs. This RFC
a proposed protocol for the ARPA-Internet community, and
discussion and suggestions for improvements
985 Mills May 86 Requirements for Internet
This RFC summarizes the requirements for gateways to be used on
supporting the DARPA Internet protocols. While it applies
to National Science Foundation research programs, the requirements
stated in a general context and are believed applicable throughout
Internet community. The purpose of this document is to present
for vendors offering products that might be used or adapted for use
an Internet application. It enumerates the protocols required and
references to RFCs and other documents describing the
specification
984 Clark May 86 PCMAIL: A Distributed Mail System
Personal
This document is a preliminary discussion of the design of
personal-computer-based distributed mail system. Pcmail is
distributed mail system that provides mail service to an
number of users, each of which owns one or more personal
(PCs). The system is divided into two halves. The first consists of
single entity called the "repository". The repository is a
center for incoming mail. Mail for a Pcmail user can arrive
from the Internet or internally from other repository users.
repository also maintains a stable copy of each user's mail state.
repository is therefore typically a computer with a large amount of
storage. It is published for discussion and comment, and does
constitute a standard. As the proposal may change, implementation
this document is not advised. See RFC-993.
9Westine & Postel [Page 4]
RFC 999 March 1987
983 Cass Apr 86 ISO Transport Services on Top of
This memo describes a proposed protocol standard for the ARPA
community. The CCITT and the ISO have defined various session
presentation, and application recommendations which have been adopted
the international community and numerous vendors. To the largest
possible, it is desirable to offer these higher level services
in the ARPA Internet, without disrupting existing facilities.
permits users to develop expertise with ISO and CCITT applications
previously were not available in the ARPA Internet. The intention
that hosts in the ARPA-Internet that choose to implement ISO
services on top of the TCP be expected to adopt and implement
standard. Suggestions for improvement are encouraged
982 ANSI Apr 86 Guidelines for the Specification of
Structure of the Domain Specific
(DSP) of the ISO Standard NSAP
This RFC is a draft working document of the ANSI "Guidelines for
Specification of the Structure of the Domain Specific Part (DSP) of
ISO Standard NSAP Address". It provides guidance to private
administration authorities on preferred formats and semantics for
Domain Specific Part (DSP) of an NSAP address. This RFC specifies
way in which the DSP may be constructed so as to facilitate
address assignment. This RFC is for informational purposes only and
distribution is unlimited and does not specify a standard of
ARPA-Internet
981 Mills Mar 86 An Experimental Multiple-Path
This document introduces wiretap algorithms, a class of experimental
multiple routing algorithms that compute quasi-optimum routes
stations sharing a packet-radio broadcast channel. The primary route (
minimum-distance path), and additional paths ordered by distance,
serve as alternate routes should the primary route fail, are computed
This prototype is presented as an example of a class of
algorithms and data-base management techniques that may find
application in the Internet community. Discussions and suggestions
improvements are welcomed
980 Jacobsen Mar 86 Protocol Document Order
This RFC indicates how to obtain various protocol documents used in
DARPA research community. Included is an overview of the new 1985
Protocol Handbook and available sources for obtaining related
(such as DOD, ISO, and CCITT).
9
9Westine & Postel [Page 5]
RFC 999 March 1987
979 Malis Mar 86 PSN End-to-End Functional
This memo is an updated version of BBN Report 5775, "End-to-
Functional Specification and describes important changes to
functionality of the interface between a Host and the PSN, and should
carefully reviewed by anyone involved in supporting a host on either
ARPANET or MILNET". The new End-to-End protocol (EE) is being
in order to correct a number of deficiencies in the old EE, to
its performance and overall throughput, and to better equip the
Switch Node (PSN, also known as the IMP) to support its current
anticipated host population
978 Reynolds Feb 86 Voice File Interchange Protocol (VFIP
The purpose of the Voice File Interchange Protocol (VFIP) is to
the interchange of various types of speech files between
systems in the ARPA-Internet community. Suggestions for improvement
encouraged
977 Kantor Feb 86 Network News Transfer
NNTP specifies a protocol for the distribution, inquiry, retrieval,
posting of news articles using a reliable stream-based transmission
news among the ARPA-Internet community. NNTP is designed so that
articles are stored in a central database allowing a subscriber
select only those items he wishes to read. Indexing, cross-referencing
and expiration of aged messages are also provided. This RFC suggests
proposed protocol for the ARPA-Internet community, and
discussion and suggestions for improvements
976 Horton Feb 86 UUCP Mail Interchange Format
This document defines the standard format for the transmission of
messages between computers in the UUCP Project. It does not however
address the format for storage of messages on one machine, nor the
level transport mechanisms used to get the date from one machine to
next. It represents a standard for conformance by hosts in the
zone
975 Mills Feb 86 Autonomous
This RFC proposes enhancements to the Exterior Gateway Protocol (EGP)
support a simple, multiple-level routing capability while preserving
robustness features of the current EGP model. The
generalize the concept of core system to include multiple communities
autonomous systems, called autonomous confederations. Discussion
suggestions for improvement are requested
Westine & Postel [Page 6]
RFC 999 March 1987
974 Partridge Jan 86 Mail Routing and the Domain
This RFC presents a description of how mail systems on the Internet
expected to route messages based on information from the domain system
This involves a discussion of how mailers interpret MX RRs, which
used for message routing
973 Mockapetris Jan 86 Domain System Changes and
This RFC documents updates to Domain Name System specifications RFC-882
and RFC-883, suggests some operational guidelines, and discusses
experiences and problem areas in the present system
972 Wancho Jan 86 Password Generator
This RFC specifies a standard for the ARPA Internet community.
Password Generator Service (PWDGEN) provides a set of six
generated eight-character "words" with a reasonable level
pronounceability, using a multi-level algorithm. Hosts on the
Internet that choose to implement a password generator service
expected to adopt and implement this standard
971 DeSchon Dec 85 A Survey of Data
This RFC is a comparison of several data representation standards
are currently in use. The standards discussed are the CCITT X.409
recommendation, the NBS Computer Based Message System (CBMS) standard
DARPA Multimedia Mail system, the Courier remote procedure
protocol, and the SUN Remote Procedure Call package. No proposals
this document are intended as standards for the ARPA-Internet at
time. Rather, it is hoped that a general consensus will emerge as
the appropriate approach to a data representation standard,
eventually to the adoption of an ARPA-Internet standard
970 Nagle Dec 85 On Packet Switches With
The purpose of this RFC is to focus discussion on a particular
in the ARPA-Internet and possible methods of solution. Most prior
on congestion in datagram systems focuses on buffer management. In
memo the case of a packet switch with infinite storage is considered
Such a packet switch can never run out of buffers. It can, however
still become congested. The meaning of congestion in
infinite-storage system is explored. An unexpected result is found
shows a datagram network with infinite storage, first-in-first-
queuing, at least two packet switches, and a finite packet
will, under overload, drop all packets. By attacking the problem
congestion for the infinite-storage case, new solutions applicable
switches with finite storage may be found. No proposed solutions
document are intended as standards for the ARPA-Internet at this time
Westine & Postel [Page 7]
RFC 999 March 1987
969 Clark Dec 85 NETBLT: A Bulk Data Transfer
This RFC suggests a proposed protocol for the ARPA-Internet community
and requests discussion and suggestions for improvements. This is
preliminary discussion of the Network Block Transfer (NETBLT) protocol
NETBLT is intended for the rapid transfer of a large quantity of
between computers. It provides a transfer that is reliable and
controlled, and is structured to provide maximum throughput over a
variety of networks. This description is published for discussion
comment, and does not constitute a standard. As the proposal
change, implementation of this document is not advised. See RFC-998.
968 Cerf Dec 85 'Twas the Night Before Start-up
This memo discusses problems that arise and debugging techniques used
bringing a new network into operation
967 Padlipsky Dec 85 All Victims
This RFC proposes a new set of RFCs on how the networking code
integrated with various operating systems. It appears that this
has not received enough exposure in the literature. Comments
suggestions are encouraged
966 Deering Dec 85 A Multicast Extension to the
This RFC defines a model of service for Internet multicasting
proposes an extension to the Internet Protocol (IP) to support such
multicast service. Discussion and suggestions for improvements
requested. See RFC-988.
965 Aguilar Dec 85 A Format for a Graphical
This RFC describes the requirements for a graphical format on which
base a graphical on-line communication protocol, and proposes
Interactive Graphical Communication Format using the GKSM
metafile. We hope this contribution will encourage the discussion
multimedia data exchange and the proposal of solutions
964 Sidhu Nov 85 Some Problems with the Specification
the Military Standard
Control
The purpose of this RFC is to provide helpful information on
Military Standard Transmission Control Protocol (MIL-STD-1778) so
one can obtain a reliable implementation of this protocol standard
This note points out three errors with this specification. This
also proposes solutions to these problems
Westine & Postel [Page 8]
RFC 999 March 1987
963 Sidhu Nov 85 Some Problems with the Specification
the Military Standard Internet
The purpose of this RFC is to provide helpful information on
Military Standard Internet Protocol (MIL-STD-1777) so that one
obtain a reliable implementation of this protocol. This paper
out several problems in this specification. This note also
solutions to these problems
962 Padlipsky Nov 85 TCP-4
This memo is in response to Bob Braden's call for a transaction
protocol (RFC-955), and continues the discussion of a
transaction oriented transport protocol. This memo does not propose
standard
961 Reynolds Dec 85 Official ARPA-Internet
This memo identifies the documents specifying the official
used in the Internet, and comments on any revisions or changes planned
This edition of the Official Protocols updates and obsoletes RFC-944.
This memo is an official status report on the protocols used in
ARPA-Internet community. See RFC-991.
960 Reynolds Dec 85 Assigned
This memo documents the currently assigned values from several series
numbers used in network protocol implementations. This edition
Assigned Numbers updates and obsoletes RFC-943. This memo is
official status report on the numbers used in protocols in
ARPA-Internet community. See RFC-990 and 997.
959 Postel Oct 85 File Transfer Protocol (FTP
This memo is the official specification of the File Transfer
(FTP) for the DARPA Internet community. The primary intent is
clarify and correct the documentation of the FTP specification, not
change the protocol. The following new optional commands are
in this edition of the specification: Change to Parent
(CDUP), Structure Mount (SMNT), Store Unique (STOU), Remove
(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
synchronizing a set of network clocks using a set of distributed
and servers. NTP is built on the User Datagram Protocol (UDP),
provides a connectionless transport mechanism. It is evolved from
Time Protocol and the ICMP Timestamp message and is a
replacement for both. This RFC suggests a proposed protocol for
Westine & Postel [Page 9]
RFC 999 March 1987
ARPA-Internet community, and requests discussion and suggestions
improvements
957 Mills Sep 85 Experiments in Network
This RFC discusses some experiments in clock synchronization in
ARPA-Internet community, and requests discussion and suggestions
improvements. One of the services frequently neglected in
network design is a high-quality, time-of-day clock capable
generating accurate timestamps with small errors compared to one-
network delays. Such a service would be useful for tracing the
of complex transactions, synchronizing cached data bases,
network performance and isolating problems. In this memo one such
service design will be described and its performance assessed.
design has been incorporated as an integral part of the network
and control protocols of the Distributed Computer Network (DCnet
architecture
956 Mills Sep 85 Algorithms for Synchronizing
This RFC discussed clock synchronization algorithms for
ARPA-Internet community, and requests discussion and suggestions
improvements. The recent interest within the Internet community
determining accurate time from a set of mutually suspicious
clocks has been prompted by several occasions in which errors were
in usually reliable, accurate clock servers after thunderstorms
disrupted their power supply. To these sources of error should be
those due to malfunctioning hardware, defective software and
mistakes, as well as random errors in the mechanism used to set
synchronize clocks. This report suggests a stochastic model
algorithms for computing a good estimator from time-offset
measured between clocks connected via network links. Included in
report are descriptions of certain experiments which give an
of the effectiveness of the algorithms
955 Braden Sep 85 Towards a Transport Service
Transaction Processing
The DoD Internet protocol suite includes two alternative
service protocols, TCP and UDP, which provide virtual circuit
datagram service, respectively. These two protocols represent points
the space of possible transport service attributes which are quite "
apart". We want to examine an important class of applications,
which perform what is often called "transaction processing". We
see that the communication needs for these applications fall into
gap "between" TCP and UDP -- neither protocol is very appropriate
This RFC is concerned with the possible design of one or more
protocols for the ARPA-Internet, to support kinds of applications
are not well supported at present. The RFC is intended to
Westine & Postel [Page 10]
RFC 999 March 1987
discussion in the Internet research community towards the development
new protocols and/or concepts, in order to meet these unmet
requirements. It does not represent a standard, nor even a
protocol proposal
954 Harrenstien Oct 85 NICNAME/
This RFC is the official specification of the NICNAME/WHOIS protocol
This memo describes the protocol and the service. This is an update
RFC-812.
953 Harrenstien Oct 85 Hostname
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
952 Harrenstien Oct 85 DoD Internet Host Table
This RFC is the official specification of the format of the
Host Table. This edition of the specification includes minor
to RFC-810 which brings it up to date
951 Croft Sep 85 Bootstrap Protocol (BOOTP
This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows
diskless client machine to discover its own IP address, the address of
server host, and the name of a file to be loaded into memory
executed. The bootstrap operation can be thought of as consisting
TWO PHASES. This RFC describes the first phase, which could be
`address determination and bootfile selection'. After this address
filename information is obtained, control passes to the second phase
the bootstrap where a file transfer occurs. The file transfer
typically use the TFTP protocol, since it is intended that both
reside in PROM on the client. However BOOTP could also work with
protocols such as SFTP or FTP. This RFC suggests a proposed
for the ARPA-Internet community, and requests discussion and
for improvements
950 Mogul Aug 85 Internet Standard Subnetting
This memo discusses the utility of "subnets" of Internet networks,
are logically visible sub-sections of a single Internet network.
administrative or technical reasons, many organizations have chosen
divide one Internet network into several subnets, instead of acquiring
set of Internet network numbers. This memo specifies procedures for
use of subnets. These procedures are for hosts (e.g., workstations).
The procedures used in and between subnet gateways are not
described. Important motivation and background information for
subnetting standard is provided in RFC-940. This RFC specifies
protocol for the ARPA-Internet community. If subnetting is
it is strongly recommended that these procedures be followed
9Westine & Postel [Page 11]
RFC 999 March 1987
949 Padlipsky Jul 85 FTP Unique-Named Store
There are various contexts in which it would be desirable to have an
command that had the effect of the present STOR but rather
requiring the sender to specify a file name istead caused the
file to have a unique name relative to the current directory.
RFC proposes an extension to the File Transfer Protocol for
ARPA-Internet community, and requests discussion and suggestions
improvements. See RFC-959.
948 Winston Jun 85 Two Methods for the Transmission of
Datagrams Over IEEE 802.3
This RFC describes two methods of encapsulating Internet Protocol (IP
datagrams on an IEEE 802.3 network. This RFC suggests a proposed
for the ARPA-Internet community, and requests discussion and
for improvements
947 Lebowitz Jun 85 Multi-Network Broadcasting Within
This RFC describes the extension of a network's broadcast domain
include more than one physical network through the use of a
packet repeater
946 Nedved May 85 Telnet Terminal Location Number
Many systems provide a mechanism for finding out where a user is
in from usually including information about telephone extension
office occupants names. The information is useful for
locating people and/or calling them on the phone. In 1982 CMU
and implemented a terminal location database and modified
network software to handle a 64-bit number called the Terminal
Number (or TTYLOC). It now seems appropriate to incorporate
mechanism into the TCP-based network protocol family. The mechanism
not viewed as a replacement for the Terminal Location Telnet
(SEND-LOCATION) but as a shorthand mechansim for communicating
location information between hosts in a localized community. This
proposes a new option for Telnet for the ARPA-Internet community,
requests discussion and suggestions for improvements
945 Postel May 85 A DoD Statement on the NRC
In May 1983 the National Research Council (NRC) was asked jointly by
and NBS to study the issues and recommend a course of action. The
report of the NRC committee was published in February 1985 (
RFC-942). The enclosed letter is from Donald C. Latham (ASDC3I) to
transmitting the NRC report and requesting specific actions relative
the recommendations of the report. This RFC reproduces a letter from
Assistant Secretary of Defense for Command, Control, Communications,
Intelligence (ASDC3I) to the Director of the Defense Communications
(DCA). This letter is distributed for information only
9Westine & Postel [Page 12]
RFC 999 March 1987
944 Reynolds Apr 85 Official ARPA-Internet
This RFC identifies the documents specifying the official protocols
in the Internet. This edition of Official ARPA-Internet
obsoletes RFC-924 and earlier editions. This RFC will be
periodically, and current information can be obtained from Joyce Reynolds
This memo is an official status report on the protocols used in
ARPA-Internet community. See RFC-991.
943 Reynolds Apr 85 Assigned Network
This Network Working Group Request for Comments documents the
assigned values from several series of numbers used in network
implementations. This RFC will be updated periodically, and in any
current information can be obtained from Joyce Reynolds. The
of numbers is also handled by Joyce. If you are developing a
or application that will require the use of a link, socket, port
protocol, network number, etc., please contact Joyce to receive a
assignment. This memo is an official status report on the numbers
in protocols in the ARPA-Internet community. See RFC-990 and 997.
942 NRC Feb 85 Transport Protocols for Department
Defense Data
This RFC reproduces the National Research Council report resulting
a study of the DoD Internet Protocol (IP) and Transmission
Protocol (TCP) in comparison with the ISO Internet Protocol (ISO-IP)
Transport Protocol level 4 (TP-4).
941 ISO Apr 85 Addendum to the Network
Definition Covering Network
This Addendum to the Network Service Definition Standard, ISO 8348,
defines the abstract syntax and semantics of the Network
(Network Service Access Point Address). The Network Address defined
this Addendum is the address that appears in the primitives of
connection-mode Network Service as the calling address, called address
and responding address parameters, and in the primitives of
connectionless-mode Network Service as the source address
destination address parameters. This document is distributed as an
for information only. It does not specify a standard for the ARPA-Internet
9
9Westine & Postel [Page 13]
RFC 999 March 1987
940 GADS Apr 85 Toward an Internet Standard Scheme
Several sites now contain a complex of local links connected to
Internet via a gateway. The details of the internal connectivity are
little interest to the rest of the Internet. One way of
these local complexes of links is to use the same strategy as
Internet uses to organize networks, that is, to declare each link to
an entity (like a network) and to interconnect the links with
that perform routing functions (like gateways). This general scheme
called subnetting, the individual links are called subnets, and
connecting devices are called subgateways (or bridges, or gateways).
This RFC discusses standardizing the protocol used in
environments in the ARPA-Internet
939 NRC Feb 85 Executive Summary of the NRC Report
Transport Protocols for Department
Defense Data
This RFC reproduces the material from the "front pages" of the
Research Council report resulting from a study of the DOD
Protocol (IP) and Transmission Control Protocol (TCP) in comparison
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
Summary widely available in a timely way. The order of presentation
been altered, and the pagination changed. This RFC is distributed
information only. This RFC does not establish any policy for the
research community or the DDN operational community
938 Miller Feb 85 Internet Reliable Transaction
Functional and Interface
This RFC is being distributed to members of the DARPA research
in order to solicit their reactions to the proposals contained in it
While the issues discussed may not be directly relevant to the
problems of the DARPA community, they may be interesting to a number
researchers and implementors. This RFC suggests a proposed protocol
the ARPA-Internet community, and requests discussion and suggestions
improvements
937 Reynolds Feb 85 Post Office Protocol - Version 2
This RFC suggests a simple method for workstations to dynamically
mail from a mailbox server. This RFC specifies a proposed protocol
the ARPA-Internet community, and requests discussion and suggestions
improvement. This memo is a revision of RFC-918.
Westine & Postel [Page 14]
RFC 999 March 1987
936 Karels Feb 85 Another Internet Subnet
There have been several proposals for schemes to allow the use of
single Internet network number to refer to a collection of
networks under common administration which are reachable from the
of the Internet by a common route. Such schemes allow a simplified
of an otherwise complicated topology from hosts and gateways outside
this collection. They allow the complexity of the number and type
these networks, and routing to them, to be localized. Additions
changes in configuration thus cause no detectable change, and
interruption of service, due to slow propagation of routing and
information outside of the local environment. These schemes
simplify the administration of the network, as changes do not
allocation of new network numbers for each new cable installed.
proposal discusses an alternative scheme, one that has been in use
the University of California, Berkeley since April 1984. This
suggests a proposed protocol for the ARPA-Internet community,
requests discussion and suggestions for improvements
935 Robinson Jan 85 Reliable Link Layer
This RFC discusses protocols proposed recently in RFCs 914 and 916,
suggests a proposed protocol that could meet the same needs addressed
those memos. The stated need is reliable communication between
programs over a full-duplex, point-to-point communication link, and
particular the RFCs address the need for such communication over
asynchronous link at relatively low speeds. The suggested protocol
the methods of existing national and international data link
standards. This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
934 Rose Jan 85 Proposed Standard for
This memo concerns itself with message forwarding. Forwarding can
thought of as encapsulating one or more messages inside another
Although this is useful for transfer of past correspondence to
recipients, without a decapsulation process (which this memo
"bursting"), the forwarded messages are of little use to the
because they can not be distributed, forwarded, replied-to, or
processed as separate individual messages. In order to burst a
it is necessary to know how the component messages were encapsulated
the draft. At present there is no unambiguous standard for
group digests. This RFC proposes a proposed protocol for
ARPA-Internet community, and requests discussion and suggestions
improvements
Westine & Postel [Page 15]
RFC 999 March 1987
933 Silverman Jan 85 Output Marking Telnet
This proposed option would allow a Server-Telnet to send a banner to
User-Telnet so that this banner would be displayed on the
screen independently of the application software running in
Server-Telnet
932 Clark Jan 85 A Subnetwork Addressing
This RFC proposes an alternative addressing scheme for subnets which,
most cases, requires no modification to host software whatsoever.
drawbacks of this scheme are that the total number of subnets in any
network are limited, and that modification is required to all gateways
931 StJohns Jan 85 Authentication
This RFC suggests a proposed protocol for the ARPA-Internet community
and requests discussion and suggestions for improvements. This is
second draft of this proposal (superseding RFC-912) and incorporates
more formal description of the syntax for the request and
dialog, as well as a change to specify the type of user
returned
930 Solomon Jan 85 Telnet Terminal Type
This RFC specifies a standard for the ARPA Internet community. Hosts
the ARPA Internet that exchange terminal type information within
Telnet protocol are expected to adopt and implement this standard.
standard supersedes RFC-884. The only change is to specify that
TERMINAL-TYPE IS sub-negotiation should be sent only in response to
TERMINAL-TYPE SEND sub-negotiation
929 Lilienkamp Dec 84 Proposed Host-Front End
The Host-Front End Protocol introduced in RFC-928 is described in
in this memo. The first order of business is to declare that THIS IS
PROPOSAL, NOT A FINAL STANDARD, and the second order of business is
request that any readers of these documents who are able to do
implementations (a) do so and (b) coordinate their efforts with the author
This RFC suggests a proposed protocol for the ARPA-Internet community,
requests discussion and suggestions for improvements
928 Padlipsky Dec 84 Introduction to Proposed DOD
H-
The broad outline of the Host-Front End Protocol introduced here
described in RFC-929 is the result of the deliberations of a number
experienced H-FP designers, who sat as a committee of the DoD
Standards Technical Panel. It is the intent of the designers that
protocol be subjected to multiple test implementations and
iteration before being agreed upon as any sort of "standard".
Westine & Postel [Page 16]
RFC 999 March 1987
Therefore, the first order of business is to declare that THIS IS
PROPOSAL, NOT A FINAL STANDARD, and the second order of business is
request that any readers of these documents who are able to do
implementations (a) do so and (b) coordinate their efforts with
author. This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
927 Anderson Dec 84 TACACS User Identification
The following is the description of a TELNET option designed
facilitate double login avoidance. It is intended primarily for
connections to target hosts on behalf of TAC users, but it can be
between any two consenting hosts. For example, all hosts at one
(e.g., BBN) can use this option to avoid double login when TELNETing
one another. This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
926 ISO Dec 84 Protocol for Providing
Connectionless-Mode Network
This note is the draft ISO protocol roughly similar to the DOD
Protocol. This document has been prepared by retyping the text of
DIS 8473 of May 1984, which is currently undergoing voting within ISO
a Draft International Standard (DIS). This document is distributred
an RFC for information only. It does not specify a standard for
ARPA-Internet
925 Postel Oct 84 Multi-LAN Address
The problem of treating a set of local area networks (LANs) as
Internet network has generated some interest and concern. It
inappropriate to give each LAN within an site a distinct
network number. It is desirable to hide the details of
interconnections between the LANs within an 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
the use of "explicit subnets" in a multi-LAN environment. The
subnet scheme is a call to recursively apply the mechanisms the
uses to manage networks to the problem of managing LANs within
network. In this note I urge another approach: the use of "
subnets" supported by a multi-LAN extension of the Address
Protocol. This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
924 Reynolds Oct 84 Official ARPA-Internet
This RFC identifies the documents specifying the official protocols
in the Internet. This edition of Official ARPA-Internet
obsoletes RFC-900 and earlier editions. This memo is an official
report on the protocols used in the ARPA-Internet community. See RFC-991.
Westine & Postel [Page 17]
RFC 999 March 1987
923 Reynolds Oct 84 Assigned
This RFC documents the currently assigned values from several series
numbers used in network protocol implementations. This edition
Assigned Numbers obsoletes RFC-900 and earlier editions. This memo
an official status report on the numbers used in protocols in
ARPA-Internet community. See RFC-990, and 997.
922 Mogul Oct 84 Broadcasting Internet Datagrams in
Presence of
We propose simple rules for broadcasting Internet datagrams on
networks that support broadcast, for addressing broadcasts, and for
gateways should handle them. This RFC suggests a proposed protocol
the ARPA-Internet community, and requests discussion and suggestions
improvements
921 Postel Oct 84 Domain Name System
Schedule -
This memo is a policy statement on the implementation of the
Style Naming System in the Internet. This memo is an update of RFC-881,
and RFC-897. This is an official policy statement of the IAB and
DARPA. The intent of this memo is to detail the schedule for
implementation for the Domain Style Naming System. The explanation
how this system works is to be found in the references
920 Postel Oct 84 Domain
This memo states the requirements on establishing a Domain,
introduces the limited set of top level domains. This memo is a
statement on the requirements of establishing a new domain in
ARPA-Internet and the DARPA research community. This is an
policy statement of the IAB and the DARPA
919 Mogul Oct 84 Broadcasting Internet
This RFC proposes simple rules for broadcasting Internet datagrams
local networks that support broadcast, for addressing broadcasts,
for how gateways should handle them. This RFC suggests a
protocol for the ARPA-Internet community, and requests discussion
suggestions for improvements
918 Reynolds Oct 84 Post Office Protocol (POP
This RFC suggests a simple method for workstations to dynamically
mail from a mailbox server. The intent of the Post Office
(POP) is to allow a user's workstation to access mail from a
server. It is expected that mail will be posted from the workstation
the mailbox server via the Simple Mail Transfer Protocol (SMTP).
RFC specifies a proposed protocol for the ARPA-Internet community,
Westine & Postel [Page 18]
RFC 999 March 1987
requests discussion and suggestions for improvement. The status of
protocol is experimental, and this protocol is dependent upon TCP
917 Mogul Oct 84 Internet
This memo discusses subnets and proposes procedures for the use
subnets, including approaches to solving the problems that arise
particularly that of routing. A subnet of an Internet network is
logically visible sub-section of a single Internet network.
administrative or technical reasons, many organizations have chosen
divide one Internet network into several subnets, instead of acquiring
set of Internet network numbers. This RFC suggests a proposed
for the ARPA-Internet community, and requests discussion and
for improvements
916 Finn Oct 84 Reliable Asynchronous Transfer
(RATP
This RFC suggests a proposed protocol for the ARPA-Internet community
and requests discussion and suggestions for improvements. This
proposes and specifies a protocol which allows two programs to
communicate over a communication link. It ensures that the data
one end of the link if received arrives at the other end intact
unaltered. The protocol, named RATP, is designed to operate over a
duplex point-to-point connection. It contains some features which
it to the RS-232 links now in common use
915 Elvy Dec 84 Network Mail Path
This RFC proposed a new service for the ARPA-Internet community
requests discussion and suggestions for improvements. The network
path service fills the current need of people to determine
addresses for hosts that are not part of the ARPA-Internet but can
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
service if they have TCP/TELENET to one of the hosts with a mail path server
914 Farber Sep 84 A Thinwire
This RFC focuses discussion on the particular problems in
ARPA-Internet of low speed network interconnection with
computers, and possible methods of solution. None of the
solutions in this document are intended as standards for
ARPA-Internet. Rather, it is hoped that a general consensus will
as to the appropriate solution to the problems, leading eventually
the adoption of standards
Westine & Postel [Page 19]
RFC 999 March 1987
913 Lottor Sep 84 Simple File Transfer
This memo describes a proposed Simple File Transfer Protocol (SFTP).
fills the need of people wanting a protocol that is more useful
TFTP but easier to implement (and less powerful) than FTP.
supports user access control, file transfers, directory listing
directory changing, file renaming and deleting. Discussion of
proposal is encouraged, and suggestions for improvements may be sent
the author
912 StJohns Sep 84 Authentication
This memo describes a proposed authentication protocol for verifying
identity of a user of a TCP connection. Given a TCP port number pair
it returns a character string which identifies the owner of
connection on the server's system. Suggested uses include
identification and verification of a user during an FTP session
additional verification of a TAC dial up user, and access
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
(EGP) (in that sense it is a status report). The memo also
some possible extentions and some design issues (in that sense it is
invitation for further discussion).
910 Forsdick Aug 84 Multimedia Mail Meeting
This memo is a report on a meeting about the experimental
mail system (and in a sense a status report on that experiment).
meeting was held at Bolt Beranek and Newman on 23-24 July 1984
discuss recent progress by groups who are building multimedia
systems and to discuss a variety of issues related to the
development of 