Network Working Group J. Reynolds
Request for Comments: 1000 J. Postel
ISI
August 1987
Obsoletes: RFCs 084, 100, 160, 170, 200, 598, 699, 800, 899, 999
THE REQUEST FOR COMMENTS REFERENCE GUIDE
STATUS OF THIS MEMO
This RFC is a reference guide for the Internet community which
summarizes of all the Request for Comments issued between April 1969
and March 1987. This guide also categorizes the RFCs by topic.
INTRODUCTION
This RFC Reference Guide is intended to provide a historical account
by categorizing and summarizing of the Request for Comments numbers 1
through 999 issued between the years 1969-1987. These documents have
been crossed referenced to indicate which RFCs are current, obsolete,
or revised. Distribution of this memo is unlimited.
THE ORIGINS OF RFCS - by Stephen D. Crocker
The DDN community now includes hundreds of nodes and thousands of
users, but once it was all a gleam in Larry Roberts' eye. While much
of the development proceeded according to a grand plan, the design of
the protocols and the creation of the RFCs was largely accidental.
The procurement of the ARPANET was initiated in the summer of 1968 --
Remember Vietnam, flower children, etc? There had been prior
experiments at various ARPA sites to link together computer systems,
but this was the first version to explore packet-switching on a grand
scale. ("ARPA" didn't become "DARPA" until 1972.) Unlike most of
the ARPA/IPTO procurements of the day, this was a competitive
procurement. The contract called for four IMPs to be delivered to
UCLA, SRI, UCSB and The University of Utah. These sites were running
a Sigma 7 with the SEX operating system, an SDS 940 with the Genie
operating system, an IBM 360/75 with OS/MVT (or perhaps OS/MFT), and
a DEC PDP-10 with the Tenex operating system. Options existed for
additional nodes if the first experiments were successful. BBN won
the procurement in December 1968, but that gets ahead of this story.
Part of the reason for selecting these four sites was these were
existing ARPA computer science research contractors. The precise
usage of the ARPANET was not spelled out in advance, and the research
community could be counted on to take some initiative. To stimulate
this process, a meeting was called during the summer with
representatives from the selected sites, chaired by Elmer Shapiro
Reynolds & Postel [Page 1]RFC 1000 - Request for Comments Reference Guide August 1987
from SRI. If memory serves me correctly, Jeff Rulifson came from
SRI, Ron Stoughton from UCSB, Steve Carr from Utah and I came from
UCLA. (Apologies to anyone I've left out; records are inaccessible or
lost at this point.) At this point we knew only that the network was
coming, but the precise details weren't known.
That first meeting was seminal. We had lots of questions -- how IMPs
and hosts would be connected, what hosts would say to each other, and
what applications would be supported. No one had any answers, but
the prospects seemed exciting. We found ourselves imagining all
kinds of possibilities -- interactive graphics, cooperating
processes, automatic data base query, electronic mail -- but no one
knew where to begin. We weren't sure whether there was really room
to think hard about these problems; surely someone from the east
would be along by and by to bring the word. But we did come to one
conclusion: We ought to meet again. Over the next several months, we
managed to parlay that idea into a series of exchange meetings at
each of our sites, thereby setting the most important precedent in
protocol design.
The first few meetings were quite tenuous. We had no official
charter. Most of us were graduate students and we expected that a
professional crew would show up eventually to take over the problems
we were dealing with. Without clear definition of what the host-IMP
interface would look like, or even what functions the IMP would
provide, we focused on exotic ideas. We envisioned the possibility
of application specific protocols, with code downloaded to user
sites, and we took a crack at designing a language to support this.
The first version was known as DEL, for "Decode-Encode Language" and
a later version was called NIL, for "Network Interchange Language."
When the IMP contract was finally let and BBN provided some definite
information on the host-IMP interface, all attention shifted to
low-level matters and the ambitious ideas for automatic downloading
of code evaporated. It was several years before ideas like remote
procedure calls and typed objects reappeared.
In February of 1969 we met for the first time with BBN. I don't
think any of us were prepared for that meeting. The BBN folks, led
by Frank Heart, Bob Kahn, Severo Ornstein and Will Crowther, found
themselves talking to a crew of graduate students they hadn't
anticipated. And we found ourselves talking to people whose first
concern was how to get bits to flow quickly and reliably but hadn't
-- of course -- spent any time considering the thirty or forty layers
of protocol above the link level. And while BBN didn't take over the
protocol design process, we kept expecting that an official protocol
design team would announce itself.
A month later, after a particularly delightful meeting in Utah, it
became clear to us that we had better start writing down our
Reynolds & Postel [Page 2]
RFC 1000 - Request for Comments Reference Guide August 1987
discussions. We had accumulated a few notes on the design of DEL and
other matters, and we decided to put them together in a set of notes.
I remember having great fear that we would offend whomever the
official protocol designers were, and I spent a sleepless night
composing humble words for our notes. The basic ground rules were
that anyone could say anything and that nothing was official. And to
emphasize the point, I labeled the notes "Request for Comments." I
never dreamed these notes would distributed through the very medium
we were discussing in these notes. Talk about Sorcerer's Apprentice!
Over the spring and summer of 1969 we grappled with the detailed
problems of protocol design. Although we had a vision of the vast
potential for intercomputer communication, designing usable protocols
was another matter. A custom hardware interface and custom intrusion
into the operating system was going to be required for anything we
designed, and we anticipated serious difficulty at each of the sites.
We looked for existing abstractions to use. It would have been
convenient if we could have made the network simply look like a tape
drive to each host, but we knew that wouldn't do.
It was clear we needed to support remote login for interactive use --
later known as Telnet -- and we needed to move files from machine to
machine. We also knew that we needed a more fundamental point of
view for building a larger array of protocols. Unfortunately,
operating systems of that era tended to view themselves as the center
of the universe; symmetric cooperation did not fit into the concepts
currently available within these operating systems. And time was
pressing: The first IMP was due to be delivered to UCLA September 1,
1969, and the rest were scheduled at monthly intervals.
At UCLA we scrambled to build a host-IMP interface. SDS, the builder
of the Sigma 7, wanted many months and many dollars to do the job.
Mike Wingfield, another grad student at UCLA, stepped in and offered
to get interface built in six weeks for a few thousand dollars. He
had a gorgeous, fully instrumented interface working in five and one
half weeks. I was in charge of the software, and we were naturally
running a bit late. September 1 was Labor Day, so I knew I had a
couple of extra days to debug the software. Moreover, I had heard
BBN was having some timing troubles with the software, so I had some
hope they'd miss the ship date. And I figured that first some
Honeywell people would install the hardware -- IMPs were built out of
Honeywell 516s in those days -- and then BBN people would come in a
few days later to shake down the software. An easy couple of weeks
of grace.
BBN fixed their timing trouble, air shipped the IMP, and it arrived
on our loading dock on Saturday, August 30. They arrived with the
IMP, wheeled it into our computer room, plugged it in and the
Reynolds & Postel [Page 3]
RFC 1000 - Request for Comments Reference Guide August 1987
software restarted from where it had been when the plug was pulled in
Cambridge. Still Saturday, August 30. Panic time at UCLA.
The second IMP was delivered to SRI at the beginning of October, and
ARPA's interest was intense. Larry Roberts and Barry Wessler came by
for a visit on November 21, and we actually managed to demonstrate a
Telnet-like connection to SRI.
With the pressure to get something working and the general confusion
as to how to achieve the high generality we all aspired to, we punted
and defined the first set of protocols to include only Telnet and FTP
functions. In particular, only asymmetric, user-server relationships
were supported. In December 1969, we met with Larry Roberts in Utah,
and suffered our first direct experience with "redirection". Larry
made it abundantly clear that our first step was not big enough, and
we went back to the drawing board. Over the next few months we
designed a symmetric host-host protocol, and we defined an abstract
implementation of the protocol known as the Network Control Program.
("NCP" later came to be used as the name for the protocol, but it
originally meant the program within the operating system that managed
connections. The protocol itself was known blandly only as the
host-host protocol.) Along with the basic host-host protocol, we
also envisioned a hierarchy of protocols, with Telnet, FTP and some
splinter protocols as the first examples. If we had only consulted
the ancient mystics, we would have seen immediately that seven layers
were required.
The initial experiment had been declared an immediate success and the
network continued to grow. More and more people started coming to
meetings, and the Network Working Group began to take shape. Working
Group meetings started to have 50 and 100 people in attendance
instead of the half dozen we had had in 1968 and early 1969. We held
one meeting in conjunction with the Spring Joint Computer Conference
in Atlantic City in 1971. In October 1971 we all convened at MIT for
a major protocol "fly-off". Representatives from each site were on
hand, and everyone tried to log in to everyone else's site. With the
exception of one site that was completely down, the matrix was almost
completely filled in, and we had reached a major milestone in
connectivity.
The rapid growth of the network and the working group also led to a
large pile of RFCs. When the 100th RFC was in sight, Peggy Karp took
on the task of indexing them. That seemed like a large task then,
and we could have hardly anticipated seeing more than a 1000 RFCs
several years later.
Where will it end? The network has the exceeded all estimates of its
growth. It has been transformed, extended, cloned, renamed and
reimplemented. I doubt if there is a single computer still on the
Reynolds & Postel [Page 4]RFC 1000 - Request for Comments Reference Guide August 1987
network that was on it in 1971. But the RFCs march on. Maybe I'll
write a few words for RFC 10,000.
REQUEST FOR COMMENTS BY CATEGORIES
The RFCs are categorized into several broad groups and within these
groups are subdivided by topic. For example, the RFCs relating to
file transfer are in 5 (Applications) c (File Transfer).
1. Administrative
1a. Assigned Numbers RFCs
997, 990, 960, 943, 923, 900, 870, 820, 790, 776, 770, 762,
758, 755, 750, 739, 717, 604, 503, 433, 349, 322, 317, 204,
179, 175, 167.
1b. Official Protocols RFCs
991, 961, 944, 924, 901, 880, 840, 694, 661, 617, 582, 580,
552.
774 - Internet Protocol Handbook Table of Contents
1c. Meeting Notes and Minutes
898 - Gateway Special Interest Group Meeting Notes
808, 805, 469 - Computer Mail Meeting Notes
910, 807 - Multimedia Mail Meeting Notes
585 - ARPANET Users Interest Working Group Meeting
549, 396, 282, 253 - Graphics Meeting Notes
371 - International Computer Communications Conference
327 - Data and File Transfer Workshop Notes
316 - Data Management Working Group Meeting Report
164, 131, 116, 108, 101, 082, 077, 066, 063, 037, 021 - Network
Working Group Meeting
1d. Meeting Announcements and Group Overviews
828 - Data Communications: IFIP's International "Network" of
Experts
631 - Call for Papers: International Meeting on Minicomputers
and Data Communication
584 - Charter for ARPANET Users Interest Working Group
537 - Announcement of NGG Meeting
526 - Technical Meeting - Digital Image Processing Software
Systems
504 - Workshop Announcement
483 - Cancellation of the Resource Notebook Framework Meeting
474, 314, 246, 232, 134 - Network Graphics Working Group
Reynolds & Postel [Page 5]RFC 1000 - Request for Comments Reference Guide August 1987
471 - Announcement of a (Tentative) Workshop on Multi-Site
Executive Programs
461 - Telnet Meeting Announcement
457 - TIPUG
456 - Memorandum
454 - File Transfer Protocol Meeting Announcement
453 - Meeting Announcement to Discuss a Network Mail System
374 - IMP System Announcement
359 - The Status of the Release of the New IMP System (2600)
343, 331 - IMP System Change Notification
324 - RJE Protocol Meeting
323 - Formation of Network Measurement Group (NMG)
320 - Workshop on Hard Copy Line Graphics
309 - Data and File Transfer Workshop Announcement
299 - Information Management System
295 - Report of the Protocol Workshop
291, 188, 173 - Data Management Meetings
245, 234, 207, 188, 173, 140, 116, 099, 087, 085, 075, 043, 035
- Network Working Group Meetings
222 - System Programmer's Workshop
212 - NWG Meeting on Network Usage
157 - Invitation to the Second Symposium on Problems in the
Optimization of Data Communication Systems
149 - The Best Laid Plans...
147 - The Definition of a Socket
111 - Pressure from the Chairman
048 - A Possible Protocol Plateau
046 - ARPA Network Protocol Notes
1e. Distribution List
402, 363, 329, 303, 300, 211, 168, 155 - ARPA Network Mailing
Lists
069 - Distribution List Change for MIT
052 - Updated Distribution List
1f. Policies
980 - Protocol Document Order Form
952, 810, 608 - Host Table Specification
945 - A DoD Statement on the NRC Report
902 - ARPA-Internet Protocol Policy
849 - Suggestions for Improved Host Table Distribution
678 - Document Formats
602 - The Stockings Were Hung by the Chimney With Care
115 - Some Network Information Center Policies on Handling
Documents
053 - An Official Protocol Mechanism
Reynolds & Postel [Page 6]RFC 1000 - Request for Comments Reference Guide August 1987
1g. Request for Comments Administrative
999, 899, 800, 699 - Requests for Comments Summary
825 - Request for Comments on Requests for Comments
629 - Scenario for Using the Network Journal
628 - Status of RFC Numbers and a Note on Pre-assigned Journal
Numbers
598, 200, 170, 160, 100, 084 - RFC Index
1h. Bibliographies
829 - Packet Satellite Technology Reference Sources
290 - Computer Network and Data Sharing: A Bibliography
243 - Network and Data Sharing Bibliography
1i. Other
637 - Change of Network Address for SU-DSL
634 - Change in Network Address for Haskins Lab
616 - Latest Network Maps
609 - Statement of Upcoming Move of NIC/NLS Service
590 - MULTICS Address Change
588 - London Node is Now Up
551 - NYU, ANL, and LBL Joining the Net
544 - Locating On-Line Documentation at SRI-ARC
543 - Network Journal Submission and Delivery
518 - ARPANET Accounts
511 - Enterprise Phone Service to NIC From ARPANET Sites
510 - Request for Network Mailbox Addresses
432 - Network Logical Map
423, 389 - UCLA Campus Computing Network Liaison Staff for APRA
Network
421 - A Software Consulting Service for Network Users
419 - MIT-DMS on Vacation
416 - The ARC System will be Unavailable for Use During
Thanksgiving Week
405 - Correction to RFC 404
404 - Host Address Changes Involving Rand and ISI
403 - Desirability of a Network 1108 Service
386 - Letter to TIP Users - 2
384 - Official Site IDENTS for Organizations in the ARPA
Networks
381 - Three Aids to Improved Network Operation
356 - ARPA Network Control Center
334 - Network Use on May 8
305 - Unknown Host Numbers
301 - BBN IMP No. 5 and NCC Schedule for March 4, 1972
276 - NIC Course
249 - Coordination of Equipment and Supplies Purchase
Reynolds & Postel [Page 7]RFC 1000 - Request for Comments Reference Guide August 1987
223 - Network Information Center Schedule for Network Users
185 - NIC Distribution of Manuals and Handbooks
154 - Exposition Style
136 - Host Accounting and Administrative Procedures
118 - Information Required for Each Service Available to the
Network
095 - Distribution of NWG/RFC's Through the NIC
016 - MIT
2. ARPANET Host to Host Protocol
2a. Network Control Protocol
801 - NCP/TCP Transition Plan
773 - Comments on NCP/TCP Mail Service Transition Strategy
714 - A Host/Host Protocol for an ARPANET-type Network
689 - Tenex NCP Finite State Machine for Connections
663 - A Lost Message Detection and Recovery Protocol
636 - TIP/TENEX Reliability Improvements
635 - An Assessment of ARPANET Protocols
534, 516, 512 - Lost Message Detection
492, 467 - Proposed Change to Host-Host Protocol
Resynchronization of Connection Status
489 - Comment on Resynchronization of Connection Status
Proposal
425 - "But my NCP Costs $500 a day..."
210 - Improvement of Flow Control
197 - Initial Connection Protocol - Revised
176 - Comments on Byte Size for Connections
165 - A Proferred Official Initial Connection Protocol
147 - The Definition of a Socket
142 - Time-out Mechanism in the Host-Host Protocol
132, 124, 107, 102 - Output of the Host-Host Protocol Glitch
Cleaning Committee
129 - A Request for Comments on Socket Name Structure
128 - Bytes
117 - Some Comments on the Official Protocol
072 - Proposed Moratorium on Changes to Network Protocol
068 - Comments on Memory Allocation Control Commands (CEASE,
ALL, GVB, RET) and RFNM
065 - Comments on Host-Host Protocol Document Number 1
060 - A Simplified NCP Protocol
059 - Flow Control-Fixed Versus Demand Allocation
058 - Logical Message Synchronization
057, 054 - An Official Protocol Proffering
056 - Third Level Protocol
055 - A Prototypical Implementation of the NCP
050, 049, 048, 047, 046, 045, 044, 040, 039, 038, 036, 033 -
New Host-Host Protocol
Reynolds & Postel [Page 8]RFC 1000 - Request for Comments Reference Guide August 1987
042 - Message Data Types
023 - Transmission of Multiple Control Messages
022 - Host-Host Control Message Formats
018 - Comments Re: Host-Host control link
015 - Network Subsystem for Time Sharing Hosts
011 - Implementation of the Host-Host Software Procedures in
GORDO
009, 001 - Host Software
008 - ARPA Network Functional Specifications
005 - DEL
002 - Links
2b. Initial Connection Protocol
202 - Possible Deadlock in ICP
197 - Initial Connection Protocol - Revised
161 - A Solution to the Race Condition in the ICP
151, 148, 143, 127, 123 - A Proferred Official ICP
150 - The Use of IPC Facilities
145 - Initial Connection Protocol Control Commands
093 - Initial Connection Protocol
080 - Protocol and Data Formats
066 - 3rd Level Ideas and Other Noise
3. Internet Level
3a. Internet Protocol
815 - IP Datagram Reassembly Algorithms
791, 760 - Internet Protocol (IP)
781 - A Specification of the Internet Protocol IP Timestamp
Option
3b. Internet Control Message Protocol
792, 777 - Internet Control Message Protocol (ICMP)
3c. Gateway Protocols
985 - Requirements for Internet Gateways
975 - Autonomous Confederations
970 - On Packet Switches With Infinite Storage
911 - EGP Gateway under Berkeley Unix
904, 890, 888, 827 - Exterior Gateway Protocol
875 - Gateways, Architectures, and Heffalumps
823 - Gateway Gateway Protocol
Reynolds & Postel [Page 9]RFC 1000 - Request for Comments Reference Guide August 1987
3d. Other
986 - Working Draft - Guidelines for the Use of Internet-IP
Addressing in the ISO Connectionless-Mode Network
981 - An Experimental Multiple-Path Routing Algorithm
963 - Some Problems with the Specification of the Military
Standard Internet Protocol
950 - Internet Standard Subnetting Procedure
947 - Multi-Network Broadcasting Within the Internet
940, 917, 925, 932, 936, 922 - Internet Subnets Protocol
925, 917, 826 - Multi-LAN Address Resolution Protocol
919, 922 - Broadcasting Internet Datagrams
891 - DCN Local-Network Protocols
871 - A Perspective on the ARPANET Reference Model
831 - Backup Access to the European Side of SATNET
817 - Modularity and Efficiency in Protocol Implementation
816 - Fault Isolation and Recovery
814 - Name, Addresses, Ports, and Routes
796 - Address Mapping
795 - Service Mappings
730 - Extensible Field Addressing
4. Host Level
4a. User Datagram Protocol
768 - User Datagram Protocol
4b. Transmission Control Protocol
983 - ISO Transport Services on Top of the TCP
964 - Some Problems with the Specification of the Military
Standard Transmission Control Protocol
896 - Congestion Control in IP/TCP Internetworks
889 - Internet Delay Experiments
879 - The TCP Maximum Segment Size and Related Topics
872 - TCP-ON-A-LAN
817 - Modularity and Efficiency in Protocol Implementation
816 - Fault Isolation and Recovery
814 - Name, Addresses, Ports, and Routes
794 - Pre-Emption
793, 761, 675 - Transmission Control Protocol
721 - Out of Band Control Signals in a Host to Host Protocol
700 - A Protocol Experiment
4c. Transaction Protocols and Distributed Operating Systems
955 - Towards a Transport Service for Transaction Processing
Applications
Reynolds & Postel [Page 10]RFC 1000 - Request for Comments Reference Guide August 1987
938 - Internet Reliable Transaction Protocol Functional and
Interface Specification
908 - Reliable Data Protocol
722 - Thoughts on Interactions in Distributed Services
713 - MSDTP -- Message Services Data Transmission Protocol
712 - A Distributed Capability Computing System DCCS
708 - Elements of a Distributed Programming System
707 - A High-Level Framework for Network-Based Resource Sharing
684 - A Commentary on Procedure Calling as A Network Protocol
677 - The Maintenance of Duplicate Databases
674 - Procedure Call Documents--Version 2
672 - A Multi-Site Data Collection Facility
671 - A Note on Reconnection Protocol
645 - Network Standard Data Specification Syntax
615 - Proposed Network Standard Data Pathname Syntax
610 - Further Datalanguage Design Concepts
592 - Some Thoughts on System Design to Facilitate Resource
Sharing
578 - Using MIT-MATHLAB MACSYMA From MIT-DMS Muddle - An
Experiment in Automated Resource Sharing
515 - Specifications for Datalanguage, Version 0/9
500 - The Integration of Data Management Systems on a Computer
Network
441 - Inter-Entity Communication - An Experiment
437 - Data Reconfiguration Service at UCSB
203 - Achieving Reliable Communication
076 - Connection-by-Name: User-Oriented Protocol
062 - A System for Interprocess Communication in a Resource
Sharing Computer Network
061 - A Note on Interprocess Communication in a Resource
Sharing Computer Network
051 - Proposal for a Network Interchange Language
031 - Binary Message Forms in Computer Networks
005 - DEL
001 - Host Software
4d. Other
998, 969 - NETBLT: A Bulk Data Transfer Protocol
988 - Host Extensions for IP Multicasting
979 - PSN End-to-End Functional Specification
966 - A Multicast Extension to the Internet Protocol
869 - Host Monitoring Protocol
741 - Specifications for the Network Voice Protocol NVP
643 - Cross Net Debugger
162 - NETBUGGER3
Reynolds & Postel [Page 11]RFC 1000 - Request for Comments Reference Guide August 1987
5. Application Level
5a. Telnet Protocol
854, 764 - Telnet Protocol Specification
818 - The Remote User Telnet Service
801 - NCP/TCP Transition Plan
782 - A Virtual Terminal Management Model
764 - Telnet Protocol Specification
728 - A Minor Pitfall in the Telnet Protocol
688 - Tentative Schedule for the New Telnet Implementation for
the TIP
681 - Network Unix
600 - Interfacing an Illinois Plasma Terminal to the ARPANET
596 - Second Thoughts on Telnet Go-Ahead
595 - Some Thoughts in Defense of the Telnet Go-Ahead
593 - Telnet and FTP Implementation Schedule Change
576 - Proposal for Modifying Linking
570 - Experimental Input Mapping Between NVT ASCII and UCSB
Online System
562 - Modifications to the Telnet Specification
559 - Comments on the New Telnet Protocol and Its
Implementation
529 - A Note on Protocol Synch Sequences
513 - Comments on the New Telnet Specifications
495 - Telnet Protocol Specification
466 - Telnet Logger/Server for Host LL-67
461 - Telnet Meeting Announcement
452 - Telnet Command at Host LL
435 - Telnet Issues
426 - Reconnection Protocol
393 - Comments on Telnet Protocol Changes
377 - Using TSO Via ARPA Network Virtual Terminal
357 - An Echoing Strategy for Satellite Links
355, 346 - Satellite Considerations
340 - Proposed Telnet Changes
339 - MLTNET - A "Multi-Telnet" Subsystem for TENEX
328 - Suggested Telnet Protocol Changes
318 - Ad Hoc Telnet Protocol
216 - Telnet Access to UCSB's On-Line System
215 - NCP, ICP, and Telnet: The Terminal IMP Implementation
206 - A User Telnet Description of an Initial Implementation
205 - NETCRT - A Character Display Protocol
190 - DEC PDP-10 - IMLAC Communication System
158 - Proposed Telnet Protocol
139 - Discussion of Telnet Protocol
137 - Telnet Protocol - A Proposed Document
135, 110 - Conventions for Using an IBM 2741 Terminal as a User
Console for Access to Network Server Hosts
Reynolds & Postel [Page 12]RFC 1000 - Request for Comments Reference Guide August 1987
103 - Implementation of Interrupt Keys
097 - A First Cut at a Proposed Telnet Protocol
091 - A Proposed User-User Protocol
015 - Network Subsystem for Time Sharing Hosts
5b. Telnet Options
946 - Telnet Terminal Location Number Option
933 - Output Marking Telnet Option
930 - Telnet Terminal Type Option
927 - TACACS User Identification Telnet Option
885 - Telnet End of Record Option
884 - Telnet Terminal Type Option
861 - Telnet Extended Options - List Option
860 - Telnet Timing Mark Option
859 - Telnet Status Option
858 - Telnet Suppress Go Ahead Option
857 - Telnet Echo Option
856 - Telnet Binary Transmission
855 - Telnet Option Specifications
854 - Telnet Protocol Specifications
779 - Telnet Send-Location Option
749 - Telnet SUPDUP-OUTPUT Option
748 - Telnet Randomly-Lose Option
736 - Telnet SUPDUP Option
735 - Revised Telnet Byte Macro Option
734 - SUPDUP Protocol
747 - Recent Extensions to the SUPDUP Protocol
746 - The SUPDUP Graphics Extension
732 - Telnet Data Entry Terminal Option
731 - Telnet Data Entry Terminal Option
729 - Telnet Byte Macro Option
727 - Telnet Logout Option
726 - Remote Controlled Transmission and Echoing Telnet Option
719 - Discussion on RCTE
718 - Comments on RCTE from the Tenex Implementation Experience
703, 702, 701 - Survey of New-Protocol Telnet Servers
698 - Telnet Extended ASCII Option
679 - February, 1975, Survey of New-Protocol Telnet Servers
669 - November 1974, Survey of New-Protocol Telnet Servers
659 - Announcing Additional Telnet Options
658 - Telnet Output Line Feed Disposition
657 - Telnet Output Vertical Tab Disposition Option
656 - Telnet Output Vertical Tab Stops Option
655 - Telnet Output Form Feed Disposition Option
654 - Telnet Output Horizontal Tab Disposition Option
653 - Telnet Output Horizontal Tab Stops Option
652 - Telnet Output Carriage Return Disposition Option
651 - Revised Telnet Status Option
Reynolds & Postel [Page 13]RFC 1000 - Request for Comments Reference Guide August 1987
587 - Announcing New Telnet Options
581 - Corrections to RFC 560 - Remote Controlled Transmission
and Echoing Telnet Option
563 - Comments on the RCTE Telnet Option
560 - Remote Controlled Transmission and Echoing Telnet Option
5c. File Transfer Protocol
987 - Mapping Between X.400 and RFC 822
959, 542, 354, 265, 172, 114 - The File Transfer Protocol
949 - FTP Unique-Named Store Command
913 - Simple File Transfer Protocol
906 - Bootstrap Loading Using TFTP
822 - Standard for the Format of ARPA Internet Text Messages
821, 788 - Simple Mail Transfer Protocol
783, 768, 764 - The TFTP Protocol Revision 2
775 - Directory Oriented FTP Commands
743 - FTP Extension: XRSQ/XRCP
737 - FTP Extension: XSEN
697 - CWD Command of FTP
691 - One More Try on the FTP
686 - Leaving Well Enough Alone
683 - FTPSRV -- Tenex Extension for Paged Files
678 - Document File Format Standards
662 - Performance Improvement in ARPANET File Transfers from
Multics
640 - Revised FTP Reply Codes
630 - FTP Error Code Usage for More Reliable Mail Service
624 - Comments on the File Transfer Protocol
614 - Response to RFC 607 - Comments on the FTP
607 - NIC-21255 Comments on the File Transfer Protocol
573 - Data and File Transfer - Some Measurement Results
571 - Tenex FTP Problem
535 - Comments on File Access Protocol
532 - The UCSD-CC Server-FTP Facility
520 - Memo to FTP Group (Proposal for File Access Protocol)
506 - An FTP Command Naming Problem
505 - Two Solutions to a File Transfer Access Problem
501 - Un-Muddling "Free File Transfer"
487 - Host-Dependent FTP Parameters
486 - Data Transfer Revisited
480 - Host-Dependent FTP Parameters
479 - Use of FTP by the NIC Journal
478 - FTP Server-Server Interaction - II
475 - FTP and the Network Mail System
468 - FTP Data Compression
463 - FTP Comments and Response to RFC 430
458 - Mail Retrieval via FTP
Reynolds & Postel [Page 14]RFC 1000 - Request for Comments Reference Guide August 1987
454 - File Transfer Protocol - Meeting Announcement and a New
Proposed Document
448 - Print Files in FTP
438 - FTP Server-Server Interaction
430 - Comments on File Transfer Protocol
418 - Server File Transfer Under TSS/360 at NASA/Ames Research
Center
414 - File Transfer Protocols (FTP): Status and Further
Comments
412 - User FTP Documentation
385 - Comments on the File Transfer Protocol (RFC 354)
310 - Another Look at Data and File Transfer Protocols
294 - The Use of "Set Data Type" Transaction in the File
Transfer Protocol
281 - A Suggested Addition to File Transfer Protocol
269 - Some Experience with File Transfer
264, 171 - The Data Transfer Protocol
250 - Some Thoughts on File Transfer
242 - Data Descriptive Language for Shared Data
238 - Comments on DTP and FTP Protocols
163 - Data Transfer Protocols
141 - Comments on RFC 114 (A File Transfer Protocol)
133 - File Transfer and Error Recovery
5d. Domain Name System
974 - Mail Routing and the Domain System
973 - Domain System Changes and Observations
953, 811, 810 - HOSTNAME Protocol
921, 897 - Domain Name System Implementation Schedule
920 - Domain Requirements
883 - Domain Names - Implementation and Specification
882 - Domain Names - Concepts and Facilities
881 - The Domain Names Plan and Schedule
830 - A Distributed System for Internet Name Service
819 - The Domain Naming Convention for Internet User
Applications
799 - Internet Name Domains
756 - The NIC Name Server -- A Datagram-Based Information
Utility
752 - A Universal Host Table
5e. Mail and Message Systems
994, 983 - PCMAIL: A Distributed Mail System
977 - Network News Transfer Protocol
976 - UUCP Mail Interchange Format Standard
974 - Mail Routing and the Domain System
934 - Proposed Standard for Message Encapsulation
Reynolds & Postel [Page 15]RFC 1000 - Request for Comments Reference Guide August 1987
915 - Network Mail Path Service
886 - Proposed Standard for Message Header Munging
850 - Standard for Interchange of USENET Messages
841 - Specification for Message Format for Computer Based
Message Systems
822 - Standard for the Format of ARPA Internet Text Messages
821 - Simple Mail Transfer Protocol
806 - Specification for Message Format for Computer Based
Message Systems
780, 772 - Mail Transfer Protocol
786 - Mail Transfer Protocol - ISI TOPS-20 MTP-NIMAIL Interface
785 - Mail Transfer Protocol - ISI TOPS-20 File Definitions
784 - Mail Transfer Protocol - ISI TOPS-20 Implementation
771 - Mail Transition Plan
763 - Role Mailboxes
757 - A Suggested Solution to the Naming, Addressing, and
Delivery Problem for ARPANET Message Systems
754 - Out-of-Net Host Addresses for Mail
753 - Internet Message Protocol
751 - Survey of FTP Mail and MLFL
733 - Standard for the Format of ARPA Network Text Messages
724 - Proposed Official Standard for the Format of ARPA Network
Messages
720 - Address Specification Syntax for Network Mail
706 - On the Junk Mail Problem
680 - Message Transmission Protocol
644 - On the Problem of Signature Authentication for Network
Mail
577 - Mail Priority
574 - Announcement of a Mail Facility at UCSB
561 - Standardizing Network Mail Headers
555 - Responses to Critiques of the Proposed Mail Protocol
539, 524 - A Proposed Mail Protocol
498 - On Mail Service to CCN
491 - What is "Free"?
475 - On FTP and the Network Mail System
458 - Mail Retrieval via FTP
333 - A Proposed Experiment with a Message Switching Protocol
278, 224, 221, 196 - A Mail Box Protocol
5f. Facsimile and Bitmaps
809 - UCL Facsimile System
804 - Facsimile Formats
803 - Dacom 450/500 Facsimile Date Transcoding
798 - Decoding Facsimile Data From the Rapicom 450
797 - Bitmap Formats
769 - Rapicom 450 Facimile File Format
Reynolds & Postel [Page 16]RFC 1000 - Request for Comments Reference Guide August 1987
5g. Graphics
965 - A Format for a Graphical Communication Protocol
553 - Draft Design for a Text/Graphics Protocol
493 - Graphics Protocol
401 - Conversion of NGP-0 Coordinates to Device Specific
Coordinates
398 - UCSB Online Graphics
387 - Some Experiences in Implementing Network Graphics
Protocol Level 0
351 - Information Form for the ARPANET Graphics Resources
Notebook
336 - Level 0 Graphics Input Protocol
296 - DS-1 Display System
292 - Graphics Protocol - Level 0 only
285 - Network Graphics
268 - Graphics Facilities Information
199 - Suggestions for a Network Data-Telnet Graphics Protocol
192 - Some Factors Which a Network Graphics Protocol Must
Consider
191 - Graphics Implementation and Conceptualization at ARC
186 - A Network Graphics Loader
184 - Proposed Graphic Display Modes
181, 177 - A Device Independent Graphical Display Description
178 - Network Graphics Attention Handling
125, 086 - Proposal for a Network Standard Format for a Data
Stream to Control Graphics Display
094 - Some Thoughts on Network Graphics
5h. Data Management
304 - A Data Management System Proposal for the ARPA Network
195 - Data Computers - Data Descriptions and Access Language
194 - The Data Reconfiguration Service - Compiler/Interpreter
Implementation Notes
166 - Data Reconfiguration Service - An Implementation
Specification
144 - Data Sharing on Computer Networks
138 - Status Report on Proposed Data Reconfiguration Service
083 - Language-Machine for Data Reconfiguration
5i. Remote Job Entry
740, 599, 589, 325, 189, 088 - CCN Network Remote Job Entry
Program - NETRJS
725 - An RJE Protocol for a Resource Sharing Network
499 - Harvard's Network RJE
490 - Surrogate RJS for UCLA-CCN
477, 436 - Remote Job Service at UCSB
Reynolds & Postel [Page 17]RFC 1000 - Request for Comments Reference Guide August 1987
407 - Remote Job Entry
368 - Comments on "Proposed Remote Job Entry Protocol"
360 - Proposed Remote Job Entry Protocol
338 - EBCDIC/ASCII Mapping for Network RJE
307 - Using Network Remote Job Entry
283 - NETRJT - Remote Job Service Protocol for TIPS
105 - Network Specification for Remote Job Entry and Remote Job
Output Retrieval at UCSB
5j. Time
958, 957, 956 - Network Time Protocol
868 - Time Server Protocol
867 - Daytime Protocol
778 - DCNET Time Server Protocol
738 - Time Server
685 - Response Time in Cross-network Debugging
034 - Some Brief Preliminary Notes on the ARC Clock
032 - Some Thoughts on SRI's Proposed Real Time Clock
028 - Time Standards
5k. Other
978 - Voice File Interchange Protocol (VFIP)
972 - Password Generator Protocol
954, 812 - Whois Protocol
951 - Bootstrap Protocol
937, 918 - Post Office Protocol
931, 912 - Authentication Service
913 - Simple File Transfer Protocol
909 - Loader Debugger Protocol
891 - DCN Local Net Protocol
887 - Resource Location Protocol
866 - Active Users Protocol
865 - Quote of the Day Protocol
864 - Character Generator Protocol
863, 361, 348 - Discard Protocol
862, 361, 347 - Echo Protocol
821, 822 - Simple Mail Transfer Protocol
783 - Trivial File Transfer Protocol
767 - Document Formats
759 - Internet Message Protocol
742 - Finger Protocol
734 - SUPDUP Protocol
726 - Remote Controlled Transmission and Echoing Telnet Option
666 - Specification of the Unified User-Level Protocol
621 - NIC User Directories at SRI-ARC
569 - Network Standard Text Editor
470 - Change in Socket for TIP News Facility
Reynolds & Postel [Page 18]RFC 1000 - Request for Comments Reference Guide August 1987
451 - Tentative Proposal for a Unified User Level Protocol
098, 079 - Logger Protocol
029 - Note in Response to Bill English's Request for Comments
6. Program Documentation
6a. General
496 - A TNLS Quick Reference Card is Available
494 - Availability of MIX and MIXAL in the Network
488 - NLS Classes at Network Sites
485 - MIS and MIXAL at UCSB
431 - Update on SMFS Login and Logout
411 - New Multics Network Software Features
409 - TENEX Interface to UCSB's Simple-Minded File System
399 - SMFS Login and Logout
390 - TSO Scenario Batch Compilation and Foreground Execution
382 - Mathematical Software on the ARPA Network
379 - Using TSO at CCN
373 - Arbitrary Character Sets
350 - User Accounts for UCSB On-Line System
345 - Interest Mixed Integer Programming (MPSX on 360/91 at
CCN)
321 - CBI Networking Activity at MITRE
317 - Official Host-Host Protocol Modification: Assigned Link
Numbers
311 - New Console Attachments to the UCSB Host
251 - Weather Data
223 - Network Information Center Schedule for Network Users
217 - Specification Changes for OLS, RJE/RJOR, and SMFS
174 - UCLA-Computer Science Graphics Overview
122 - Network Specifications for UCSB's Simple-Minded File
System
121 - Network On-Line Operators
120 - Network PL1 Subprograms
119 - Network FORTRAN Subprograms
074 - Specifications for Network Use of the UCSB On-Line System
7. Network Specific
7a. ARPANET
878, 851, 802 - The ARPANET 1822L Host Access Protocol
852 - The ARPANET Short Blocking Feature
789 - Vulnerabilities of Network Control Protocols: An Example
716 - Interim Revision to Appendix F of BBN 1822
704 - IMP/Host and Host/IMP Protocol Change
696 - Comments on the IMP/HOST and HOST/IMP Protocol Changes
695 - Official Change in Host-Host Protocol
Reynolds & Postel [Page 19]RFC 1000 - Request for Comments Reference Guide August 1987
692 - Comments on IMP/Host Protocol Changes
690 - Comments on the Proposed Host/IMP Protocol Changes
687 - IMP/Host and Host/IMP Protocol
667 - BBN Host Ports
660 - Some Changes to the IMP and the IMP/Host Interface
642 - Ready Line Philosophy and Implementation
638, 633 - IMP/TIP Preventive Maintenance Schedule
632 - Throughput Degradation for Single Packet Message
627 - ASCII Text File of Hostnames
626 - On a possible Lockup Condition in IMP Subnet due to
Message Sequencing
625 - On Line Hostnames Service
623 - Comments on On-line Host Name Service
622 - Scheduling IMP/TIP Down Time
620 - Request for Monitor Host Table Updates
619 - Mean Round-Trip Times in the ARPANET
613 - Network Connectivity: A Response to RFC 603
611 - Two Changes to the IMP/Host Protocol
606 - Host Names On-Line
594 - Speedup of Host-IMP Interface
591 - Addition to the Very Distant Host Specification
568, 567 - Cross-Country Network Bandwidth
548 - Hosts Using the IMP Going Down Message Specification
547 - Change to the Very Distant Host Specification
533 - Message-ID Numbers
534 - Lost Message Detection
528 - Software Checksumming in the IMP and Network Reliability
521 - Restricted Use of IMP DDT
508 - Real-Time Data Transmission on the ARPANET
476, 434 - IMP/TIP Memory Retrofit Schedules
449, 442 - The Current Flow-Control Scheme for IMPSYS
447, 445 - IMP/TIP Preventive Maintenance Schedule
417 - LINK Usage Violation
410 - Removal of the 30-second Delay When Hosts Come Up
406 - Scheduled IMP Software Releases
395 - Switch Settings on IMPs and TIPs
394 - Two Proposed Changes to the IMP-HOST Protocol
369 - Evaluation of ARPANET Services (January through March,
1972)
335 - New Interface-IMP/360
312 - Proposed Change in IMP-to-Host Protocol
297 - TIP Message Buffers
280 - A Draft Set of Host Names
274 - Establishing a Local Guide for Network Usage
271 - IMP System Change Notification
270 - Correction to the BBN Report No. 1822
263 - "Very Distant" Host Interface
254 - Scenarios for Using ARPANET Computers
247 - Proffered Set of Standard Host Names
Reynolds & Postel [Page 20]RFC 1000 - Request for Comments Reference Guide August 1987
241 - Connecting Computers to NLC Ports
239 - Host Mnemonics Proposed in RFC 226
237 - The NIC's View of Standard Host Names
236 - Standard Host Names
233 - Standardization of Host Call Letters
230 - Toward Reliable Operation of Minicomputer-based Terminals
on a TIP
229 - Standard Host Names
228 - Clarification
226 - Standardization of Host Mnemonics
218 - Changing the IMP Status Reporting
213 - IMP System Change Notification
209 - Host/IMP Interface Documentation
208 - Address Tables
073, 067 - Proposed Change to Host/IMP Spec to Eliminate
Marking
071 - Reallocation in Case of Input Error
070 - A Note On Padding
064 - Getting Rid of Marking
041 - IMP/IMP Teletype Communication
025 - No High Link Numbers
019 - Two Protocol Suggestions to Reduce Congestion at
Swap-Bound Nodes
017a, 017 - Some Questions Re: HOST-IMP Protocol
012 - IMP-HOST Interface Flow Diagrams
007 - HOST-IMP Interface
006 - Conversation with Bob Kahn
7b. Internet Protocol On Networks
948 - Two Methods for the Transmission of IP Datagrams Over
IEEE 802.3 Networks
907 - Host Access Protocol
903 - A Reverse Address Resolution Protocol
895 - A Standard for the Transmission of IP Datagrams over
Experimental Ethernet Networks
894 - A Standard for the Transmission of IP Datagrams over
Ethernet Networks
893 - Trailer Encapsulations
891 - Internet Protocol on DC Networks
877 - A Standard for the Transmission of IP Datagrams Over
Public Data Networks
826 - Address Resolution Protocol
796 - Address Mappings
795 - Service Mappings
7c. Host Front End Protocols
929, 928, 705, 647 - Host-Front End Protocol
Reynolds & Postel [Page 21]RFC 1000 - Request for Comments Reference Guide August 1987
7d. Other
935 - Reliable Link Layer Protocols
916 - Reliable Asynchronous Transfer Protocol
914 - Thinwire Protocol
824 - The Cronus Virtual Local Network
8. Measurement
8a. General
573 - Data and File Transfer - Some Measurement Results
557 - Revelations in Network Host Measurements
546 - Tenex Load Averages for July 1973
462 - Responding to User Needs
415 - TENEX Bandwidth
392 - Measurement of Host Costs for Transmitting Network Data
352 - TIP Site Information Form
308 - ARPANET Host Availability Data
286 - Network Library Information System
274 - Establishing a Local Guide for Network Usage
214, 193 - Network Checkout
198 - Site Certification - Lincoln Labs
182 - Compilation of List of Revelant Site Reports
180 - File System Questionnaire
156 - Status of the Illinois Site (Response to RFC 116)
153 - SRI ARC-NIC Status
152 - SRI Artificial Intelligence Status Report
126 - Ames Graphics Facilities at Ames Research Center
112 - User/Server Site Protocol Network HOST Questionnaire
104 - Link 191
106 - USER/SERVER Site Protocol Network Host Questionnaire
8b. Surveys
971 - A Survey of Data Representation Standards
876 - Survey of SMTP Implementations
848 - Who Provides the "Little" TCP Services?
847 - Summary of Smallberg Surveys
844 - Who Talks ICMP, too? Survey of 18 February 1983
846, 845, 843, 842, 839, 838, 837, 836, 835, 834, 833, 832 -
Who Talks TCP?
787 - Connectionless Data Transmission Survey/Tutorial
703, 702, 701, 679, 669 - Survey of New-Protocol Telnet Servers
565 - Storing Network Survey Data at the Datacomputer
545 - Of What Quality be the UCSB Resource Evaluators?
530 - A Report on the SURVEY Project
523 - SURVEY is in Operation Again
519 - Resource Evaluation
Reynolds & Postel [Page 22]RFC 1000 - Request for Comments Reference Guide August 1987
514 - Network Make-Work
464 - Resource Notebook Framework
460 - NCP Survey
459 - Network Questionnaire
450 - Multics Sampling Timeout Change
446 - Proposal to Consider a Network Program Resource Notebook
096 - An Interactive Network Experiment to Study Modes of
Access to the Network Information Center
090 - CCN as a Network Service Center
081 - Request for Reference Information
078 - NCP Status Report: UCSB/Rand
8c. Statistics
996 - Statistics Server
618 - A Few Observations on NCP Statistics
612, 601, 586, 579, 566, 556, 538, 522, 509, 497, 482, 455,
443, 422, 413, 400, 391, 378 - Traffic Statistics
603, 597, 376, 370, 367, 366, 362, 352, 344, 342, 332, 330,
326, 319, 315, 306, 298, 293, 288, 287, 267, 266 -
Network Host Status
550 - NIC NCP Experiment
388 - NCP Statistics
255, 252, 240, 235 - Site Status
9. Network Experience and Demonstrations
9a. General
968 - 'Twas the Night Before Start-up
967 - All Victims Together
573 - Data and File Transfer - Some Measurement Results
527 - ARPAWOCKY
525 - MIT-Mathlab Meets UCSB-OLS
439 - PARRY Encounters the Doctor
420 - CCA ICC Weather Demo
372 - Notes on a Conversation with Bob Kahn on the ICCC
364 - Serving Remote Users on the ARPANET
302 - Excercising the ARPANET
231 - Service Center Standards for Remote Usage - A User's View
227 - Data Transfer Rates (RAND/UCLA)
113 - Network Activity Report: UCSB and Rand
089 - Some Historic Moments in Networking
004 - Network Timetable
Reynolds & Postel [Page 23]RFC 1000 - Request for Comments Reference Guide August 1987
10. Site Documentation
10a. General
30, 27, 24, 16, 10, 3 - Documentation Conventions
11. Other Standards
11a. ANSI
570 - Experimental Input Mapping Between NVT ASCII and UCSB
Online System
183 - The EBCDIC Codes and Their Mapping to ASCII
020 - ASCII Format for Network Interchange
11b. CCITT
987 - Mapping Between X.400 and RFC 822
874 - A Critique of X.25
11c. NRC
942 - Transport Protocols for Department of Defense Data
Networks
939 - Executive Summary of the NRC Report on Transport
Protocols for Department of Defense Data Networks
11d. ISO
995 - End System to Intermediate System Routing Exchange
Protocol for Use in Conjunction with ISO 8473
994 - Final Text of DIS 8473, Protocol for Providing the
Connectionless Mode Network Service
982 - Guidelines for the Specification of the Structure of the
Domain Specific Part (DSP) of the ISO Standard NSAP
Address
941 - Addendum to the Network Service Definition Covering
Network Layer Addressing
926 - Protocol for Providing the Connectionless-Mode Network
Services
905 - ISO Transport Protocol Specification (ISO DP 8073)
892 - ISO Transport Protocol
873 - The Illusion of Vendor Support
Reynolds & Postel [Page 24]RFC 1000 - Request for Comments Reference Guide August 1987
12. Never Issued
12a. Never Issued
014, 026, 092, 159, 201, 220, 244, 248, 257, 258, 259, 260,
261, 262, 272, 275, 277, 279, 284, 337, 341, 358, 375, 380,
383, 397, 424, 427, 428, 444, 465, 481, 484, 502, 507, 517,
536, 540, 541, 554, 558, 564, 572, 575, 583, 605, 639, 641,
646, 648, 649, 650, 664, 665, 668, 670, 673, 676, 682, 693,
709, 710, 711, 715, 723, 853.
Reynolds & Postel [Page 25]RFC 1000 - Request for Comments Reference Guide August 1987
REQUEST FOR COMMENTS LIST WITH ABSTRACTS
RFC Author Date Title
--- ------ ---- -----
999 Westine Mar 87 Requests For Comments Summary
A summary of the Request for Comments Documents from RFC 900-999.
998 Lambert Mar 87 NETBLT: A Bulk Data Transfer
Protocol
This document is a description of and a specification for the
NETBLT protocol. It is a revision of the specification published
in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level
protocol intended for the rapid transfer of a large quantity of
data between computers. It provides a transfer that is reliable
and flow controlled, and is designed to provide maximum throughput
over a wide variety of networks. Although NETBLT currently runs
on top of the Internet Protocol (IP), it should be able to operate
on top of any datagram protocol similar in function to IP.
This document is published for discussion and comment, and does
not constitute a standard. The proposal may change and certain
parts of the protocol have not yet been specified; implementation
of this document is therefore not advised.
997 Reynolds Mar 87 Internet Numbers
This memo is an official status report on the network numbers used
in the Internet community. As of 1-Mar-87 the Network Information
Center (NIC) at SRI International has assumed responsibility for
assignment of Network Numbers and Autonomous System Numbers. This
RFC documents the current assignments of these numbers at the time
of this transfer of responsibility.
996 Mills Feb 87 Statistics Server
This RFC specifies a standard for the ARPA Internet community.
Hosts and gateways on the DARPA Internet that choose to implement
a remote statistics monitoring facility may use this protocol to
send statistics data upon request to a monitoring center or
debugging host.
995 ANSI Apr 86 End System to Intermediate System
Routing Exchange Protocol for use in
conjunction with ISO 8473.
This Protocol is one of a set of International Standards produced
Reynolds & Postel [Page 26]RFC 1000 - Request for Comments Reference Guide August 1987
to facilitate the interconnection of open systems. The set of
standards covers the services and protocols required to achieve
such interconnection.
This Protocol is positioned with respect to other related
standards by the layers defined in the Reference Model for Open
Systems Interconnection (ISO 7498) and by the structure defined in
the Internal Organization of the Network Layer (DIS 8648). In
particular, it is a protocol of the Network Layer. This Protocol
permits End Systems and Intermediate Systems to exchange
configuration and routing information to facilitate the operation
of the routing and relaying functions of the Network Layer.
994 ANSI Mar 86 Final Text of DIS 8473, Protocol for
Providing the Connectionless Mode
Network Service
This Protocol Standard is one of a set of International Standards
produced to facilitate the interconnection of open systems. The
set of standards covers the services and protocols required to
achieve such interconnection.
This Protocol Standard is positioned with respect to other related
standards by the layers defined in the Reference Model for Open
Systems Interconnection (ISO 7498). In particular, it is a
protocol of the Network Layer. This Protocol may be used between
network-entities in end systems or in Network Layer relay systems
(or both). It provides the Connectionless-mode Network Service as
defined in Addendum 1 to the Network Service Definition Covering
Connectionless-mode Transmission (ISO 8348/AD1).
993 Clark Dec 86 PCMAIL: A Distributed Mail System
for Personal Computers
This document is a discussion of the PCMAIL workstation-based
distributed mail system. It is a revision of the design published
in NIC RFC 984. The revision is based on discussion and comments
from a variety of sources, as well as further research into the
design of interactive PCMAIL clients and the use of client code on
machines other than IBM PCs. As this design may change,
implementation of this document is not advised.
992 Birman Nov 86 On Communication Support for
Fault-Tolerant Process Groups
This memo describes a collection of multicast communication
primitives integrated with a mechanism for handling process
failure and recovery. These primitives facilitate the
implementation of fault-tolerant process groups, which can be used
Reynolds & Postel [Page 27]RFC 1000 - Request for Comments Reference Guide August 1987
to provide distributed services in an environment subject to
non-malicious crash failures.
Here, we argue that the form of "best effort" reliability provided
by host groups may not address the requirements of those
researchers who are building fault tolerant software. Our basic
premise is that reliable handling of failures, recoveries, and
dynamic process migration are important aspects of programming in
distributed environments, and that communication support that
provides unpredictable behavior in the presence of such events
places an unacceptable burden of complexity on higher level
application software. This complexity does not arise when using
the fault-tolerant process group alternative.
991 Reynolds Nov 86 Official ARPA-Internet Protocols
This RFC identifies the documents specifying the official
protocols used in the Internet. Comments indicate any revisions
or changes planned. This memo is an official status report on the
numbers used in protocols in the ARPA-Internet community. This
memo obsoletes RFCs 961, 944, 924, 901, 880, 840, 694, 661, 617,
582, 580, 552.
990 Reynolds Nov 86 Assigned Numbers
This Network Working Group Request for Comments documents the
currently assigned values from several series of numbers used in
network protocol implementations. This memo is an official status
report on the numbers used in protocols in the ARPA-Internet
community. This memo obsoletes RFCs 960, 943, 923, 900, 870, 820,
790, 776, 770, 762, 758, 755, 750, 739, 717, 604, 503, 433, 349,
322, 317, 204, 179, 175, 167.
989 Linn Feb 87 Privacy Enhancement for Internet
Electronic Mail: Part I: Message
Encipherment and Authentication
Procedures
This RFC suggests a proposed protocol for the Internet community
and requests discussion and suggestions for improvements. This
RFC is the outgrowth of a series of IAB Privacy Task Force
meetings and of internal working papers distributed for those
meetings. This RFC defines message encipherment and
authentication procedures, as the initial phase of an effort to
provide privacy enhancement services for electronic mail transfer
in the Internet. It is intended that the procedures defined 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.
Reynolds & Postel [Page 28]RFC 1000 - Request for Comments Reference Guide August 1987
Use of conventional cryptography for message text encryption
and/or authentication is anticipated.
Privacy enhancement services (confidentiality, authentication, and
message integrity assurance) are offered through the use of
end-to- end cryptography between originator and recipient User
Agent processes, with no special processing requirements imposed
on the Message Transfer System at endpoints or at intermediate
relay sites. This approach allows privacy enhancement facilities
to be incorporated on a site-by-site or user-by-user basis without
impact on other Internet entities. Interoperability among
heterogeneous components and mail transport facilities is
supported.
988 Deering Jul 86 Host Extensions for IP Multicasting
This memo specifies the extensions required of a host
implementation of the Internet Protocol (IP) to support
internetwork multicasting. This specification supersedes that
given in RFC 966, and constitutes a proposed protocol standard for
IP multicasting in the ARPA-Internet. The reader is directed to
RFC 966 for a discussion of the motivation and rationale behind
the multicasting extension specified here.
987 Kille Jun 86 Mapping Between X.400 and RFC 822
The X.400 series of protocols have been defined by CCITT to
provide an Interpersonal Messaging Service (IPMS), making use of a
store and forward Message Transfer Service. It is expected that
this standard will be implemented very widely. This document
describes a set of mappings which will enable interworking between
systems operating the X.400 protocols and systems using RFC 822
mail protocol or protocols derived from RFC 822. This RFC
suggests a proposed protocol for the ARPA-Internet community, and
requests discussion and suggestions for improvements.
986 Callon Jun 86 Working Draft -- Guidelines for the
Use of Internet-IP addressing in the
ISO Connectionless-Mode Network
Protocol
This RFC suggests a method to allow the existing IP addressing,
including the IP protocol field, to be used for the ISO
Connectionless Network Protocol (CLNP). This is a draft solution
to one of the problems inherent in the use of "ISO-grams" in the
DoD Internet. Related issues will be discussed in subsequent
RFCs. This RFC suggests a proposed protocol for the ARPA-Internet
community, and requests discussion and suggestions for
improvements.
Reynolds & Postel [Page 29]RFC 1000 - Request for Comments Reference Guide August 1987
985 Mills May 86 Requirements for Internet Gateways
This RFC summarizes the requirements for gateways to be used on
networks supporting the DARPA Internet protocols. While it
applies specifically to the National Science Foundation research
programs, the requirements are stated in a general context and are
believed applicable throughout the Internet community. The
purpose of this document is to present guidance for vendors
offering products that might be used or adapted for use in an
Internet application. It enumerates the protocols required and
gives references to RFCs and other documents describing the
current specification. Suggestions and comments on this document
are welcomed and can be sent to Dave Mills (Mills@D.ISI.EDU) or
Dave Farber (Farber@HUEY.UDEL.EDU).
984 Clark May 86 PCMAIL: A Distributed Mail System
for Personal Computers
This document is a preliminary discussion of the design of a
personal-computer-based distributed mail system. Pcmail is a
distributed mail system that provides mail service to an arbitrary
number of users, each of which owns one or more personal computers
(PCs). The system is divided into two halves. The first consists
of a single entity called the "repository". The repository is a
storage center for incoming mail. Mail for a Pcmail user can
arrive externally from the Internet or internally from other
repository users. The repository also maintains a stable copy of
each user's mail state. The repository is therefore typically a
computer with a large amount of disk storage. It is published for
discussion and comment, and does not constitute a standard. As
the proposal may change, implementation of this document is not
advised.
983 Cass Apr 86 ISO Transport Services on Top of the
TCP
This memo describes a proposed protocol standard for the
ARPA-Internet community. The CCITT and the ISO have defined
various session, presentation, and application recommendations
which have been adopted by the international community and
numerous vendors. To the largest extent possible, it is desirable
to offer these higher level services directly to the
ARPA-Internet, without disrupting existing facilities. This
permits users to develop expertise with ISO and CCITT applications
which previously were not available in the ARPA-Internet. The
intention is that hosts within the ARPA-Internet that choose to
implement ISO TSAP services on top of the TCP be expected to adopt
and implement this standard. Suggestions for improvement are
encouraged.
Reynolds & Postel [Page 30]RFC 1000 - Request for Comments Reference Guide August 1987
982 ANSI Apr 86 Guidelines for the Specification of
the Structure of the Domain Specific
Part (DSP) of the ISO Standard NSAP
Address
This RFC is a draft working document of the ANSI "Guidelines for
the Specification of the Structure of the Domain Specific Part
(DSP) of the ISO Standard NSAP Address". It provides guidance to
private address administration authorities on preferred formats
and semantics for the Domain Specific Part (DSP) of an NSAP
address. This RFC specifies the way in which the DSP may be
constructed so as to facilitate efficient address assignment.
This RFC is for informational purposes only and its distribution
is unlimited and does not specify a standard of the ARPA-Internet.
981 Mills Mar 86 An Experimental Multiple-Path
Routing Algorithm
This document introduces wiretap algorithms, a class of
experimental, multiple routing algorithms that compute
quasi-optimum routes for stations sharing a packet-radio broadcast
channel. The primary route (a minimum-distance path), and
additional paths ordered by distance, which serve as alternate
routes should the primary route fail, are computed. This
prototype is presented as an example of a class of routing
algorithms and data-base management techniques that may find wider
application in the Internet community. Discussions and
suggestions for improvements are welcomed.
980 Jacobsen Mar 86 Protocol Document Order Information
This RFC indicates how to obtain various protocol documents used
in the DARPA research community. Included is an overview of the
new 1985 DDN Protocol Handbook and available sources for obtaining
related documents (such as DOD, ISO, and CCITT).
979 Malis Mar 86 PSN End-to-End Functional
Specification
This memo is an updated version of BBN Report 5775, "End-to-End
Functional Specification". It describes important changes to the
functionality of the interface between a host and the PSN (Packet
Switch Node), and should be carefully reviewed by anyone involved
in supporting a host on either the ARPANET or MILNET. The new
End-to-End Protocol (EE) is being developed in order to correct a
number of deficiencies in the old End-to-End Protocol, to improve
its performance and overall throughput, and to better equip the
Packet Switch Node (also known as the IMP) to support its current
and anticipated host population.
Reynolds & Postel [Page 31]RFC 1000 - Request for Comments Reference Guide August 1987
978 Reynolds Feb 86 Voice File Interchange Protocol
(VFIP)
The purpose of the Voice File Interchange Protocol (VFIP) is to
permit the interchange of various types of speech files between
different systems in the ARPA-Internet community. Suggestions for
improvement are encouraged.
977 Kantor Feb 86 Network News Transfer Protocol
NNTP specifies a protocol for the distribution, inquiry,
retrieval, and posting of news articles using a reliable
stream-based transmission of news among the ARPA-Internet
community. NNTP is designed so that news articles are stored in a
central database allowing a subscriber to select only those items
he wishes to read. Indexing, cross-referencing, and expiration of
aged messages are also provided. This RFC suggests a proposed
protocol for the ARPA-Internet community, and requests discussion
and suggestions for improvements.
976 Horton Feb 86 UUCP Mail Interchange Format
Standard
This document defines the standard format for the transmission of
mail messages between computers in the UUCP Project. It does not
however, address the format for storage of messages on one
machine, nor the lower level transport mechanisms used to get the
date from one machine to the next. It represents a standard for
conformance by hosts in the UUCP zone.
975 Mills Feb 86 Autonomous Confederations
This RFC proposes enhancements to the Exterior Gateway Protocol
(EGP) to support a simple, multiple-level routing capability while
preserving the robustness features of the current EGP model. The
enhancements generalize the concept of core system to include
multiple communities of autonomous systems, called autonomous
confederations. Discussion and suggestions for improvement are
requested.
974 Partridge Jan 86 Mail Routing and the Domain System
This RFC presents a description of how mail systems on the
Internet are expected to route messages based on information from
the domain system. This involves a discussion of how mailers
interpret MX RRs, which are used for message routing.
Reynolds & Postel [Page 32]RFC 1000 - Request for Comments Reference Guide August 1987
973 Mockapetris Jan 86 Domain System Changes and
Observations
This RFC documents updates to Domain Name System specifications
RFC-882 and RFC-883, suggests some operational guidelines, and
discusses some experiences and problem areas in the present
system.
972 Wancho Jan 86 Password Generator Protocol
This RFC specifies a standard for the ARPA-Internet community.
The Password Generator Service (PWDGEN) provides a set of six
randomly generated eight-character "words" with a reasonable level
of pronounceability, using a multi-level algorithm. Hosts on the
ARPA-Internet that choose to implement a password generator
service are expected to adopt and implement this standard.
971 DeSchon Dec 85 A Survey of Data Representation
Standards
This RFC is a comparison of several data representation standards
that 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 call protocol, and the SUN Remote Procedure Call
package. No proposals in this document are intended as standards
for the ARPA-Internet at this time. Rather, it is hoped that a
general consensus will emerge as to the appropriate approach to a
data representation standard, leading eventually to the adoption
of an ARPA-Internet standard.
970 Nagle Dec 85 On Packet Switches With Infinite
Storage
The purpose of this RFC is to focus discussion on a particular
problem in the ARPA-Internet and possible methods of solution.
Most prior work on congestion in datagram systems focuses on
buffer management. In this 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 an infinite-storage system is explored.
An unexpected result is found that shows a datagram network with
infinite storage, first-in-first-out queuing, at least two packet
switches, and a finite packet lifetime will, under overload, drop
all packets. By attacking the problem of congestion for the
infinite-storage case, new solutions applicable to switches with
finite storage may be found. No proposed solutions this document
are intended as standards for the ARPA-Internet at this time.
Reynolds & Postel [Page 33]RFC 1000 - Request for Comments Reference Guide August 1987
969 Clark Dec 85 NETBLT: A Bulk Data Transfer
Protocol
This RFC has been replaced by RFC 998. This is a preliminary
discussion of the Network Block Transfer (NETBLT) protocol.
NETBLT is intended for the rapid transfer of a large quantity of
data between computers. It provides a transfer that is reliable
and flow controlled, and is structured to provide maximum
throughput over a wide variety of networks. This description is
published for discussion and comment, and does not constitute a
standard. As the proposal may change, implementation of this
document is not advised.
968 Cerf Dec 85 'Twas the Night Before Start-up'
This memo discusses problems that arise and debugging techniques
used in bringing a new network into operation.
967 Padlipsky Dec 85 All Victims Together
This RFC proposes a new set of RFCs on how the networking code is
integrated with various operating systems. It appears that this
topic has not received enough exposure in the literature. Comments
and suggestions are encouraged.
966 Deering Dec 85 A Multicast Extension to the
Internet Protocol
This RFC defines a model of service for Internet multicasting and
proposes an extension to the Internet Protocol (IP) to support
such a multicast service. Discussion and suggestions for
improvements are requested.
965 Aguilar Dec 85 A Format for a Graphical
Communication Protocol
This RFC describes the requirements for a graphical format on
which to base a graphical on-line communication protocol, and
proposes an Interactive Graphical Communication Format using the
GKSM session metafile. We hope this contribution will encourage
the discussion of multimedia data exchange and the proposal of
solutions.
964 Sidhu Nov 85 Some Problems with the Specification
of the Military Standard
Transmission Control Protocol
The purpose of this RFC is to provide helpful information on the
Military Standard Transmission Control Protocol (MIL-STD-1778) so
Reynolds & Postel [Page 34]RFC 1000 - Request for Comments Reference Guide August 1987
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
Reynolds & Postel [Page 35]RFC 1000 - Request for Comments Reference Guide August 1987
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
Reynolds & Postel [Page 36]RFC 1000 - Request for Comments Reference Guide August 1987
"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
Reynolds & Postel [Page 37]RFC 1000 - Request for Comments Reference Guide August 1987
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
Reynolds & Postel [Page 38]RFC 1000 - Request for Comments Reference Guide August 1987
(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.
Reynolds & Postel [Page 39]RFC 1000 - Request for Comments Reference Guide August 1987
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.
Reynolds & Postel [Page 40]RFC 1000 - Request for Comments Reference Guide August 1987
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
Reynolds & Postel [Page 41]RFC 1000 - Request for Comments Reference Guide August 1987
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.
Reynolds & Postel [Page 42]RFC 1000 - Request for Comments Reference Guide August 1987
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
Reynolds & Postel [Page 43]RFC 1000 - Request for Comments Reference Guide August 1987
(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
Reynolds & Postel [Page 44]RFC 1000 - Request for Comments Reference Guide August 1987
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.
Reynolds & Postel [Page 45]RFC 1000 - Request for Comments Reference Guide August 1987
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).
Reynolds & Postel [Page 46]RFC 1000 - Request for Comments Reference Guide August 1987
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.
Reynolds & Postel [Page 47]RFC 1000 - Request for Comments Reference Guide August 1987
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.
Reynolds & Postel [Page 48]RFC 100
