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).
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
A summary of the Request for Comments documents from RFC 800-898.
898 Hinden Apr 84 Gateway Special Interest Group Meeting Notes
This memo is a report on the Gateway Special Interest Group Meeting that was held at ISI on 28 and 29 February 1984. Robert Hinden of BBNCC chaired, and Jon Postel of ISI hosted the meeting. Approximately 35 gateway designers and implementors attended. These notes are based on the recollections of Jon Postel and Mike Muuss. Under each topic area are Jon Postel's brief notes, and additional details from Mike Muuss. This memo is a report on the meeting. No conclusions, decisions, or policy statements are documented in this note.
897 Postel Feb 84 Domain Name System Implementation Schedule
This memo is a policy statement on the implementation of the Domain Style Naming System in the ARPA-Internet. This memo is a partial update of RFC 881. The intent of this memo is to detail the schedule for the implementation of the Domain Style Naming System. The names of hosts will be changed to Domain style names. Hosts will begin to use Domain style names on 14-Mar-84, and the use of old style names will be completely phased out before 2-May-84. This applies to both the ARPA research hosts and the DDN operational hosts. This is an official policy statement of the ICCB and the DARPA.
896 Nagle Jan 84 Congestion Control in IP/TCP Internetworks
This memo discusses some aspects of congestion control in IP/TCP Internetworks. It is intended to stimulate thought and further discussion of this topic. While some specific suggestions are made for improved congestion control implementation, this memo does not specify any standards.
895 Postel Apr 84 A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks
This RFC specifies a standard method of encapsulating Internet
Reynolds & Postel [Page 49]
RFC 1000 - Request for Comments Reference Guide August 1987
Protocol (IP) datagrams on an Experimental Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community.
894 Hornig Apr 84 A Standard for the Transmission of IP Datagrams over Ethernet Networks
This RFC specifies a standard method of encapsulating Internet Protocol (IP) datagrams on an Ethernet. This RFC specifies a standard protocol for the ARPA-Internet community.
This RFC discusses the motivation for use of "trailer encapsulations" on local-area networks and describes the implementation of such an encapsulation on various media. This document is for information only. This is NOT an official protocol for the ARPA-Internet community.
892 ISO Dec 83 ISO Transport Protocol Specification
This is a draft version of the transport protocol being standardized by the ISO. This version also appeared in the ACM SIGCOMM Computer Communication Review (V.12, N.3-4) July-October 1982. This version is now out of date.
This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks.
890 Postel Feb 84 Exterior Gateway Protocol Implementation Schedule
This memo is a policy statement on the implementation of the Exterior Gateway Protocol (EGP) in the ARPA-Internet. This is an official policy statement of ICCB and DARPA. After 1-Aug-84 there shall be no dumb gateways in the Internet. Every gateway must be a member of some autonomous system. Some gateway of each autonomous system must exchange routing information with some gateway of the core autonomous system using the Exterior Gateway Protocol.
This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP
Reynolds & Postel [Page 50]
RFC 1000 - Request for Comments Reference Guide August 1987
retransmission timeout calculation. This memo is both a status report on the ARPA-Internet and advice to TCP implementers.
888 Seamonson Jan 84 "Stub" Exterior Gateway Protocol
This RFC describes the Exterior Gateway Protocol (EGP) used to connect Stub Gateways to an Autonomous System of core Gateways. This document specifies the working protocol, and defines an ARPA official protocol. All implementers of Gateways should carefully review this document.
This RFC specifies a draft standard for the ARPA-Internet community. It describes a resource location protocol for use in the ARPA-Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the ARPA-Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the ARPA-Internet.
886 Rose Dec 83 Proposed Standard for Message Header Munging
This RFC specifies a draft standard for the ARPA-Internet community. It describes the rules to be used when transforming mail from the conventions of one message system to those of another message system. In particular, the treatment of header fields, and recipient addresses is specified.
This RFC specifies a standard for the ARPA-Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.
This RFC specifies a standard for the ARPA-Internet community. It specifies a method for exchanging terminal type information in the Telnet protocol.
Reynolds & Postel [Page 51]
RFC 1000 - Request for Comments Reference Guide August 1987
883 Mockapetris Nov 83 Domain Names - Implementation and Specification
This RFC discusses the implementation of domain name servers and resolvers, specifies the format of transactions, and discusses the use of domain names in the context of existing mail systems and other network software.
882 Mockapetris Nov 83 Domain Names - Concepts and Facilities
This RFC introduces domain style names, their use for DDN/ARPA-Internet mail and host address support, and the protocol and servers used to implement domain name facilities.
881 Postel Nov 83 The Domain Names Plan and Schedule
This RFC outlines a plan and schedule for the implementation of domain style names throughout the DDN/ARPA-Internet community. The introduction of domain style names will impact all hosts on the DDN/ARPA-Internet.
879 Postel Nov 83 The TCP Maximum Segment Size and Related Topics
This RFC discusses the TCP Maximum Segment Size Option and related topics. The purpose is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers".
878 Malis Dec 83 The ARPANET 1822L Host Access Protocol
This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. The 1822L procedure allows ARPANET hosts to use logical identifiers as well as 1822 physical interface identifiers to address each other.
877 Korb Sep 83 A Standard for the Transmission of IP Datagrams Over Public Data Networks
This RFC specifies a standard adopted by CSNET, the VAN gateway,
Reynolds & Postel [Page 52]
RFC 1000 - Request for Comments Reference Guide August 1987
and other organizations for the transmission of IP datagrams over the X.25-based public data networks.
876 Smallberg Sep 83 Survey of SMTP Implementations
This RFC is a survey of implementation status. It does not specify an official protocol, but rather notes the status of implementation of aspects of a protocol. It is expected that the status of the hosts reported on will change. This information must be treated as a snapshot of the state of these implemetations.
875 Padlipsky Sep 82 Gateways, Architectures, and Heffalumps
This RFC is a discussion about the role of gateways in an internetwork, especially the problems of translating or mapping protocols between different protocol suites. The discussion notes possible functionality mis-matches, undesirable routing "singularity points", flow control issues, and high cost of translating gateways. Originally published as M82-51 by the MITRE Corporation, Bedford, Massachusetts.
This RFC is an analysis of X.25 pointing out some problems in the conceptual model, particularly the conflict between the interface aspects and the end-to-end aspects. The memo also touches on security, and implementation issues. Originally published as M82-50 by the MITRE Corporation, Bedford, Massachusetts.
873 Padlipsky Sep 82 The Illusion of Vendor Support
This memo takes issue with the claim that international standards in computer protocols presently provide a basis for low cost vendor supported protocol implementations. Originally published as M82-49 by the MITRE Corporation, Bedford, Massachusetts.
This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts.
871 Padlipsky Sep 82 A Perspective on the Arpanet Reference Model
This RFC is primarily intended as a perspective on the ARM and points out some of the differences between the ARM and the ISORM
Reynolds & Postel [Page 53]
RFC 1000 - Request for Comments Reference Guide August 1987
which were expressed by members in NWG general meetings, NWG protocol design committee meetings, the ARPA-Internet Working Group, and private conversations over the intervening years. Originally published as M82-47 by the MITRE Corporation, Bedford, Massachusetts.
This RFC specifies the Host Monitoring Protocol used to collect information from various types of hosts in the Internet. Designers of Internet communications software are encouraged to consider this protocol as a means of monitoring the behavior of their creations.
This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900.
This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet that choose to implement a Daytime Protocol are expected to adopt and implement this standard. The Daytime service simply sends the current date and time as a character string without regard to the input.
This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet that choose to implement an Active Users Protocol are expected to adopt and implement this standard. The Active Users service simply sends a list of the currently active users on the host without regard to the input.
This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet that choose to implement a Quote of the Day Protocol are expected to adopt and implement this standard.
Reynolds & Postel [Page 54]
RFC 1000 - Request for Comments Reference Guide August 1987
The Quote of the Day service simply sends a short message without regard to the input.
This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet that choose to implement a Character Generator Protocol are expected to adopt and implement this standard. The Character Generator service simply sends data without regard to the input.
This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet that choose to implement a Discard Protocol are expected to adopt and implement this standard. The Discard service simply throws away any data it receives.
This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet that choose to implement a Echo Protocol are expected to adopt and implement this standard. The Echo service simply sends back to the originating source any data it receives.
861 Postel May 83 Telnet Extended Options - List Option
This Telnet Option provides a mechanism for extending the set of possible options. This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes NIC 16239.
This Telnet Option provides a way to check the roundtrip path between two Telnet modules. This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes NIC 16238.
This Telnet Option provides a way to determine the other Telnet module's view of the status of options. This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes RFC 651 (NIC 31154).
Reynolds & Postel [Page 55]
RFC 1000 - Request for Comments Reference Guide August 1987
This Telnet Option disables the exchange of go-ahead signals between the Telnet modules. This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes NIC 15392.
This Telnet Option enables remote echoing by the other Telnet module. This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes NIC 15390.
This Telnet Option enables a binary data mode between the Telnet modules. This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes NIC 15389.
This memo specifies the general form for Telnet options and the directions for their specification. This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes RFC 651, NIC 18640.
This is the specification of the Telnet protocol used for remote terminal access in the ARPA-Internet. The purpose of the Telnet Protocol is to provide a fairly general, bi-directional, eight-bit byte oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other. It is envisioned that the protocol may also be used for terminal-terminal communication ("linking") and process-process communication (distributed computation). This RFC specifies a standard for the ARPA-Internet community. Hosts on the ARPA-Internet are expected to adopt and implement this standard. Obsoletes NIC 18639.
RFC 1000 - Request for Comments Reference Guide August 1987
852 Malis Apr 83 The ARPANET Short Blocking Feature
This RFC specifies the ARPANET Short Blocking Feature, which will allow ARPANET hosts to optionally shorten the IMP's host blocking timer. This Feature is a replacement of the ARPANET non-blocking host interface, which was never implemented, and will be available to hosts using either the 1822 or 1822L Host Access Protocol. This RFC is also being presented as a solicitation of comments on the Short Blocking Feature, especially from host network software implementers and maintainers.
851 Malis Apr 83 The ARPANET 1822L Host Access Protocol
This RFC specifies the ARPANET 1822L Host Access Protocol, which is a successor to the existing 1822 Host Access Protocol. 1822L allows ARPANET hosts to use logical names as well as 1822's physical port locations to address each other. This RFC is also being presented as a solicitation of comments on 1822L, especially from host network software implementers and maintainers. Obsoletes RFC 802.
850 Horton Jun 83 Standard for Interchange of USENET Messages
This memo is distributed as an RFC only to make this information easily accessible to researchers in the ARPA-Internet community. It does not specify an Internet standard. This RFC defines the standard format for interchange of Network News articles among USENET sites. It describes the format for articles themselves, and gives partial standards for transmission of news. The news transmission is not entirely standardized in order to give a good deal of flexibility to the individual hosts to choose transmission hardware and software, whether to batch news and so on.
849 Crispin May 83 Suggestions for Improved Host Table Distribution
This RFC actually is a request for comments. The issue dealt with is that of a naming registry update procedure, both as exists currently and what could exist in the future. None of the proposed solutions are intended as standards at this time; rather it is hoped that a general consensus will emerge as the appropriate solution, leaving eventually to the adoption of standards.
Reynolds & Postel [Page 57]
RFC 1000 - Request for Comments Reference Guide August 1987
848 Smallberg Mar 83 Who provides the "Little" TCP Services?
This RFC lists those hosts which provide any of these "little" TCP services: The list of hosts were taken from the NIC hostname table of 24-Feb-83. The tests were run on February 23 and 24, and March 3 and 5 from ISI-VAXA.ARPA.
This is a summary of the surveys of Telnet, FTP and Mail (SMTP) servers conducted by David Smallberg in December 1982, January and February 1983 as reported in RFC 832-843, 845-846. This memo extracts the number of hosts that accepted the connection to their server for each of Telnet, FTP, and SMTP, and compares it to the total host in the ARPA-Internet (not counting TACs or ECHOS).
846 Smallberg Feb 83 Who Talks TCP? -- Survey of 22 February 1983
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 18-Feb-83. The tests were run on 22-Feb-83 from ISI-VAXA.ARPA.
845 Smallberg Feb 83 Who Talks TCP? -- Survey of 15 February 1983
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 3-Feb-83. The tests were run on 15-Feb-83 from ISI-VAXA.ARPA.
844 Clements Feb 83 Who Talks ICMP, too? Survey of 18 February 1983
This survey determines how many hosts are able to respond to Telnet connections from a user at a class C site. This requires, in addition to IP and TCP, participation in gateway routing via ICMP and handling of Class C addresses. The list of hosts was taken from RFC 843, extracting only those hosts which are listed there as accepting Telnet connection. The tests were run on 18-Feb-83.
843 Smallberg Feb 83 Who Talks TCP? -- Survey of 8 February 1983
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was
Reynolds & Postel [Page 58]
RFC 1000 - Request for Comments Reference Guide August 1987
taken from the NIC hostname table of 3-Feb-83. The tests were run on 8-Feb-83 and on 9-Feb-83 from ISI-VAXA.ARPA.
842 Smallberg Feb 83 Who Talks TCP? -- Survey of 1 February 1983
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 28-Jan-83. The tests were run on 1-Feb-83 and on 2-Feb-83 ISI-VAXA.ARPA.
841 FIPS PUB 98 Jan 83 Specification for Message Format for Computer Based Message Systems
This RFC is FIPS 98. The purpose of distributing this document as an RFC is to make it easily accessible to the ARPA research community. This RFC does not specify a standard for the ARPA-Internet. Obsoletes RFC 806.
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 25-Jan-83.
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 18-Jan-83.
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 31-Dec-82. The tests were run on 11-Jan-83.
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 28-Dec-82 through 5-Jan-83.
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 22-Dec-82.
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 14-Dec-82.
This RFC is a survey of hosts to identify the implementation status of Telnet, FTP, and Mail on TCP. The list of hosts was taken from the NIC hostname table of 2-Dec-82. The tests were run on 7-Dec-82.
831 Braden Dec 82 Backup Access to the European Side of SATNET
The purpose of this RFC is to focus discussion on a particular Internet problem: a backup path for software maintenance of the European sector of the Internet, for use when SATNET is partitioned. We propose a mechanism, based upon the Source Routing option of IP, to reach European Internet sites via the VAN Gateway and UCL. This proposal is not intended as a standard at this time.
830 Zaw-Sing Su Oct 82 A Distributed System for Internet Name Service
This RFC proposes a distributed name service for ARPA-Internet. Its purpose is to focus discussion on the subject. It is hoped that a general consensus will emerge leading eventually to the adoption of standards.
Reynolds & Postel [Page 60]
RFC 1000 - Request for Comments Reference Guide August 1987
829 Cerf Oct 82 Packet Satellite Technology Reference Sources
This RFC describes briefly the packet satellite technology developed by the Defense Advanced Research Projects Agency and several other participating organizations in the U.K. and Norway and provides a bibliography of relevant papers for researchers interested in experimental and operational experience with this dynamic satellite-sharing technique.
828 Owen Aug 82 Data Communications: IFIP's International "Network" of Experts
This RFC is distributed to inform the ARPA-Internet community of the activities of the IFIP technical committee on Data Communications, and to encourage participation in those activities.
This RFC is proposed to establish a standard for Gateway to Gateway procedures that allow the Gateways to be mutually suspicious. This document is a DRAFT for that standard. Your comments are strongly encouraged.
826 Plummer Nov 82 An Ethernet Address Resolution Protocol
The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA-Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an ARPA-Internet Standard.
825 Postel Nov 82 Request for Comments on Requests for Comments
This RFC is intended to clarify the status of RFCs and to provide some guidance for the authors of RFCs in the future. It is in a sense a specification for RFCs.
824 MacGregor Aug 82 The Cronus Virtual Local Network
The purpose of this note is to describe the CRONUS Virtual Local Network, especially the addressing related features. These features include a method for mapping between Internet Addresses and Local Network addresses. This is a topic of current concern in the ARPA-Internet community. This note is intended to
Reynolds & Postel [Page 61]
RFC 1000 - Request for Comments Reference Guide August 1987
stimulate discussion. This is not a specification of an ARPA-Internet Standard.
This RFC is a status report on the Internet Gateway developed by BBN. It describes the Internet Gateway as of September 1982. This memo presents detailed descriptions of message formats and gateway procedures, however, this is not an implementation specification, and such details are subject to change.
822 Crocker Aug 82 Standard for the Format of ARPA Internet Text Messages
This document revises the specifications in RFC 733, in order to serve the needs of the larger and more complex ARPA-Internet. Some of RFC 733's features failed to gain adequate acceptance. In order to simplify the standard and the software that follows it, these features have been removed. A different addressing scheme is used, to handle the case of internetwork mail; and the concept of re-transmission has been introduced. Obsoletes RFC 733, NIC 41952.
The objective of Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. Obsoletes RFCs 788, 780, 772.
819 Zaw-Sing Su Aug 82 The Domain Naming Convention for Internet User Applications
This RFC is an attempt to clarify the generalization of the Domain Naming Convention, the Internet Naming Convention, and to explore the implications of its adoption for ARPA-Internet name service and user applications.
This RFC describes the portion of fault isolation and recovery which is the responsibility of the host.
815 Clark Jul 82 IP Datagram Reassembly Algorithms
This RFC describes an alternate approach of dealing with reassembly which reduces the bookkeeping problem to a minimum, and requires only one buffer for storage equal in size to the final datagram being reassembled, which can reassemble a datagram from any number of fragments arriving in any order with any possible pattern of overlap and duplication, and which is appropriate for almost any sort of operating system.
814 Clark Jul 82 Name, Addresses, Ports, and Routes
This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP.
813 Clark Jul 82 Window and Acknowledgement Strategy in TCP
This RFC describes implementation strategies to deal with two mechanisms in TCP, the window and the acknowledgement. It also presents a particular set of algorithms which have received testing in the field, and which appear to work properly with each other. With more experience, these algorithms may become part of the formal specification, until such time their use is recommended.
This RFC gives a description of what the NICNAME/WHOIS Server is and how to access it. This server together with the corresponding Identification Data Base provides online directory look-up equivalent to the ARPANET Directory.
Reynolds & Postel [Page 63]
RFC 1000 - Request for Comments Reference Guide August 1987
This RFC gives a description of what the Hostnames Server is and how to access it. The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the Internet environment.
810 Feinler Mar 82 DoD Internet Host Table Specification
This RFC specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This RFC obsoletes the host table described in RFC 608.
This RFC describes the features of the computerised facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work are reported. Then the disciplines for system design are discussed. Finally, the implementation of the system are described, while detailed description are given as appendices.
808 Postel Mar 82 Summary of Computer Mail Services Meeting Held at BBN on 10 January 1979
This RFC is a very belated attempt to document a meeting that was held three years earlier to discuss the state of computer mail in the ARPA community and to reach some conclusions to guide the further development of computer mail systems such that a coherent total mail service would continue to be provided.
This RFC consists of notes from a meeting held at USC/Information Sciences Institute on the 12th of January to discuss common interests in multimedia computer mail issues and to agree on some specific initial experiments.
806 NBS Sep 81 Specification for Message Format for Computer Based Message Systems
This RFC deals with Computer Based Message systems which provides a basis for interaction between different CBMS by defining the
Reynolds & Postel [Page 64]
RFC 1000 - Request for Comments Reference Guide August 1987
format of messages passed between them. This RFC is replaced by RFC 841.
This RFC consists of notes from a meeting that was held at USC/Information Sciences Institute on 11 January 1982, to discuss addressing issues in computer mail. The major conclusion reached at the meeting is to extend the "username@hostname" mailbox format to "username@host.domain", where the domain itself can be further structured.
This is the CCITT standard for group 3 facsimile encoding. This is useful for data compression of bit map data.
803 Agarwal Nov 81 Dacom 450/500 Facsimile Data Transcoding
The first part of this RFC describes in detail the Dacom 450 data compression algorithms and is an update and correction to an earlier memorandum. The second part of this RFC describes briefly the Dacom 500 data compression algorithm as used by the INTELPOST electronic-mail network under development by the US Postal Service and several foreign administrators.
802 Malis Nov 81 The ARPANET 1822L Host Access Protocol
This document proposed two major changes to the current ARPANET host access protocol. The first change will allow hosts to use logical addressing (i.e., host addresses that are independent of their physical location on the ARPANET) to communicate with each other, and the second will allow a host to shorten the amount of time that it may be blocked by its IMP after it presents a message to the network (currently, the IMP can block further input from a host for up to 15 seconds). See RFCs 852 and 851.
This RFC discusses the conversion of hosts from NCP to TCP. And making available the principle services: Telnet, File Transfer, and Mail. These protocols allow all hosts in the ARPA community to share a common interprocess communication environment.
Reynolds & Postel [Page 65]
RFC 1000 - Request for Comments Reference Guide August 1987
This document suggests that, as the Internet grows, the space of host names cannot remain a flat space of globally unique names, therefore a hierarchy of name domains must be introduced; see also RFC 822.
798 Katz Sep 81 Decoding Facsimile Data From the Rapicom 450
A description of the encoding/decoding procedure for Rapicom 450 facsimile machine.
757 Deutsch Sep 79 A Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPANET Message Systems
Discusses several proposals for handing the name to address to route processing for computer mail. Favors a solution based on unique-ids and a data base, see also RFCs 759, 821 and 822.
756 Pickens Jul 79 The NIC Name server--A Datagram-Based Information Utility
Describes the host table used at MIT and Stanford. This has several extensions and generalizations from the NIC standard and the table used by most Tenex and TOPS20 hosts.
A survey of hosts' responses to probes of their FTP servers to see if servers (a) accept mail for unknown users and (b) support the MAIL and MLFL commands.
Defines the Name or Finger Protocol which allows one to get "who is on" or "where is user x" information from another host.
741 Cohen Nov 77 Specifications for the Network Voice Protocol NVP
Defines the protocol used in the ARPANET packet speech experiments. Replaced by NVP-II and ST for Internet packet speech experiments. ST is documented in ISN 119; NVP-II is documented in an ISI Internal memo.
728 Day Apr 77 A Minor Pitfall in the Telnet Protocol
This RFC warns of the possibility of an unexpected occurence in Telnet resulting from the interaction between option subnegotiations and the Telnet SYNCH operation.
726 Postel Mar 77 Remote Controlled Transmission and Echoing Telnet Option
Defines a Telnet option for controlling the transmission and echoing of data to smooth the response to use in high transmission delay environments; see also RFCs 719 and 718.
Reynolds & Postel [Page 73]
RFC 1000 - Request for Comments Reference Guide August 1987
725 Day Mar 77 An RJE Protocol for a Resource Sharing Network
Describes a possible Remote Job Entry protocol.
724 Crocker May 77 Proposed Official Standard for the Format of ARPA Network Messages
714 McKenzie Apr 76 A Host/Host Protocol for an ARPANET-type Network
A specification of a NCP-like protocol for an ARPA-like network. Interesting to compare to the NCP specification to see what the author would do differently.
675 Cerf Dec 74 Specification of Internet Transmission Control Program (TCP)
The first detailed specification of TCP; see RFC 793.
674 Postel Dec 74 Procedure Call Documents--Version 2
A host level protocol used in the NSW--a slightly constrained version of ARPANET Host-to-Host protocol, affecting allocation, RFNM wait, and retransmission; see also RFC 684.
660 Walden Oct 74 Some Changes to the IMP and the IMP/Host Interface
Decoupling of message number sequences of hosts; host-host access control; message number window; messages outside normal mechanism; see also BBN 1822.
659 Postel Oct 74 Announcing Additional Telnet Options
Options defined in RFCs 651-658.
658 Crocker Oct 74 Telnet Output Line Feed Disposition
Defines a Telnet option for specific control of Line Feed.
657 Crocker Oct 74 Telnet Output Vertical Tab Disposition Option
Defines a Telnet option for specific control of Vertical Tab.
656 Crocker Oct 74 Telnet Output Vertical Tab Stops Option
Defines a Telnet option for setting the stops for Vertical Tab.
655 Crocker Oct 74 Telnet Output Form Feed Disposition Option
Defines a Telnet option for specific control of Form Feed.
Reynolds & Postel [Page 80]
RFC 1000 - Request for Comments Reference Guide August 1987
654 Crocker Oct 74 Telnet Output Horizontal Tab Disposition Option
Defines a Telnet option for specific control of Horizontal Tab.
653 Crocker Oct 74 Telnet Output Horizontal Tab Stops Option
Defines a Telnet option for setting the stops for Horizontal Tab.
652 Crocker Oct 74 Telnet Output Carriage Return Disposition Option
Defines a Telnet option for specific control of Carriage Return.
645 Crocker Jun 74 Network Standard Data Specification Syntax
Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615.
644 Thomas Jul 74 On The Problem of Signature Authentication for Network Mail
Proposes that the mail sender be an authorized system process and that the mail sender and mail receiver processes exchange a password. The sender process takes responsibility for authentication of the signature on the mail.
Reynolds & Postel [Page 81]
RFC 1000 - Request for Comments Reference Guide August 1987
582 Clements Nov 73 Comments on RFC 580 - Machine Readable Protocols
Cites objections to the phrase "preferably NLS files".
581 Crocker Nov 73 Corrections to RFC 560 - Remote Controlled Transmission and Echoing Telnet Option
This RFC contains corrections to RFC 560, which described the Remote Controlled Transmission and Echoing Telnet Option.
580 Postel Oct 73 Note to Protocol Designers and Implementers
An announcement that future proposed protocols shall be submitted in the form of on-line documents, preferably in NLS files, to the Network Information Center.
A report on the Host traffic statistics for the month of September 1973. Updates RFC 566.
578 Bhushan Oct 73 Using MIT-MATHLAB MACSYMA From MIT-DMS Muddle - An Experiment in Automated Resource Sharing
This paper describes an experiment in non-trivial automated resource sharing between dissimilar systems. The goal of this experiment was to interface the Muddle system at MIT-DMS to the MACSYMA system at MIT-Mathlab.
553 Thomas Jul 73 Draft Design for a Text/Graphics Protocol
This document was proposed as a synthesis of existing ideas rather than an attempt to put forth new ones. It draws upon the concerns about the lack of text-handling capabilities of the protoocl suggested in RFC 493.
552 Owen Jul 73 Single Access to Standard Protocols
Queries and statements regarding a socket number assignment for a single access protocol before the proposed mail protocol becomes official.
551 Feinroth Aug 73 NYU, ANL, and LBL Joining the Net
Announcement of the intent of several Atomic Energy Commission installations to enter the network.
This RFC states that there are considerable changes from the last "official" version of FTP, but the gross structure still remains the same. References RFCs 354, 454, and 495.
539 Crocker Jul 73 Thoughts on the Mail Protocol Proposed in RFC 524
This memo is in response to RFC 524. In general, the authors of this RFC feel that the protocol is extremely rich. They also feel that there are some minor and some major problems.
Reynolds & Postel [Page 92]
RFC 1000 - Request for Comments Reference Guide August 1987
The purpose of this paper is 1) to report on the status of the SURVEY project and current data, 2) to inform the ARPANET community of the services offered related to this project, 3) to report on future plans, and 4) to ask for suggestions and improvements.
529 McKenzie Jun 73 A Note on Protocol Synch Sequences
Proposal of restricted use of IMP DDT due to opinions from representatives of several sites feeling that uncontrolled use of IMP DDT made access control mechanisms too vulnerable to interception or tampering.
520 Day Jun 73 Memo to FTP Group (Proposal for File Access Protocol)
This document discusses the File Access Protocol as an extension to FTP.
Reynolds & Postel [Page 94]
RFC 1000 - Request for Comments Reference Guide August 1987
UCSB announces a new test group based upon RFC 369, which attempts to take a detailed look at specific network resources and develop initial site dependent and function dependent MINIMAN's.
515 Winter Jun 73 Specifications for Datalanguage, Version 0/9
This specification for Datalanguage is extremely primitive. Version 0/9 is currently running at CCA and offers an opportunity for experience with the Datacomputer and with fundamental Datalanguage concepts.
This RFC states how the NIC outlined its requirements for implementing FTP Journal delivery and submission.
478 Bressler Mar 73 FTP Server-Server Interaction - II
Discusses server-server interaction where, in a typical situation, a user conversing with two servers is interested in retrieving a file from one site and sending it to another.
Reynolds & Postel [Page 98]
RFC 1000 - Request for Comments Reference Guide August 1987
This RFC is the follow-on document to RFC 436. This document restates the essence of the official RJE Protocol and documents in detail UCSB's implementation of it. Obsoletes RFC 436.
476 McKenzie Mar 73 IMP/TIP Memory Retrofit Schedules (Revision 2)
Describes plans and schedule for upgrading IMPs and TIPs.
475 Bhushan Mar 73 FTP and the Network Mail System
This paper describes the author's understanding of the results of the Network Mail System meeting and the implications for FTP.
474 Bunch Mar 73 Announcement of Forthcoming Meeting of the Network Graphics Working Group and Call for RFC's.
Plans for a graphics meeting to be held in May 1973.
Report on the Host traffic statistics for the month of December 1972. Updates RFC 422.
442 Cerf Jan 73 The Current Flow-Control Scheme for IMPSYS
This RFC discusses the current flow-control scheme for IMPSYS.
441 Bressler Jan 73 Inter-Entity Communication - An Experiment
A status report concerning an experiment based on the desire of users, at their consoles, to converse with one another, and to receive some debugging assistance.
440 Walden Jan 73 Scheduled Network Software Maintenance
Explains plans and schedule for IMP software maintenance, expands the normal time slot.
This document suggests a simple extension to FTP which would allow a FTP user process at one site to arrange for FTP server processes at other sites to act cooperatively on its behalf.
Reynolds & Postel [Page 102]
RFC 1000 - Request for Comments Reference Guide August 1987
437 Faeh Jun 73 Data Reconfiguration Service at UCSB
Announcement of the availability of the Data Reconfiguration Service (DRS) at UCSB.
436 Krilanovich Jan 73 Announcement of RJS at UCSB
Attachment of the network logical map as of December 30, 1972.
431 Krilanovich Dec 72 Update on SMFS Login and Logout
This document obsoletes RFC 399, which introduced the Login and Logout commands for UCSB's SMFS, but was incomplete. RFC 399 is restated more fully in this RFC.
430 Braden Feb 73 Comments on File Transfer Protocol
This document describes several situations in which the ability to reconnect is useful, presents a mechanism to achieve reconnections, sketches how the mechanism could be added to Host-Host or Telnet protocol, and recommends a place for the mechanism in the protocol hierarchy.
425 Bressler Dec 72 "But my NCP costs $500 a day..."
Discussion on the cost of network software and network use.
401 Hansen Oct 72 Conversion of NGP-0 Coordinates to Device Specific Coordinates
A means is described to convert NGP coordinates to interger coordinates in the range zero to M, where M is the maximum address of the device screen on a machine using 2's complement arithmetic.
Announcement that users with Tektronix or IMLAC terminals, or with systems that support the proposed Level 0 graphics protocol can access UCSB graphics.
Suggests how to get arbitrary characters sets stored in computers and to be able to display them on any CRT screen, edit them using any keyboard, and print them on any printer.
372 Watson Jul 72 Notes on a Conversation with Bob Kahn on the ICCC
Discussion on some aspects of the ICCC meeting demonstration.
371 Kahn Jul 72 Demonstration at International Computer Communications Conference
Observation and notes on the ICCC meeting demonstration.
Report on the status of Network Hosts from June 5 to June 16. Updates RFC 353.
361 Bressler Jul 72 In Response to RFCs 347 and 348
Deamon Processes on Host 106.
Reynolds & Postel [Page 110]
RFC 1000 - Request for Comments Reference Guide August 1987
360 Holland Jun 72 Proposed Remote Job Entry Protocol
This protocol specifies the Network standard procedures for remote job entry as a mechanism whereby a user at one location causes a batch-processing job to be run at some other location.
359 Walden Jun 72 The Status of the Release of the New IMP System (2600)
357 Davidson Jun 72 An Echoing Strategy for Satellite Links
This document describes a strategy which will eliminate the delay associated with simple echoing and allow the transmission delay to be hidden in the cost of computation only. This scheme is proposed as an optional addition to existing User Telnets; its use requires the explicit support of a cooperating server process.
This RFC obsoletes RFCs 264,265. The File Transfer Protocol (FTP) is a protocol for file transfer between HOSTs on the ARPANET. The primary function of FTP is to transfer files efficiently and reliably among hosts and to allow the convenient use of remote file storage capabilities.
A proposed change to the Telnet protocol calling for one standard protocol and dropping the idea of minimum implementation.
339 Thomas May 72 MLTNET - A "Multi-Telnet" Subsystem for TENEX
This RFC describes MLTNET as a Telnet-like facility for Tenex which enables a user to control a number of jobs, running on different ARPANET hosts. MLTNET is currently a subsystem on the BBN-Tenex host.
338 Braden May 72 EBCDIC/ASCII Mapping for Network RJE
This RFC proposes: to make all users of NETRJS aware of the changed ASCII mapping; to call this problem to the attention of the Network RJE Protocol committee; and to knowledge and support Joel Winett's pioneering work in this area.
333 Bressler May 72 A Proposed Experiment with a Message Switching Protocol
This document attempts to sketch how one would organize the lowest level host-host protocol in the ARPANET around Message Switching Protocols (MSPs) and how this organization would affect the implementation of the host software.
Reynolds & Postel [Page 113]
RFC 1000 - Request for Comments Reference Guide August 1987
This paper has two purposes: to solicit comments from the NWG and others on how selected classes of resources of a General Purpose Network might be applied to the field of Computer Based Instructions; and initiate a dialog between interested parties on the problem of Computer Base Instruction.
312 McKenzie Mar 72 Proposed Change in IMP-to-Host Protocol
This RFC proposes a redefinition of the IMP-to-Host error message types and the creation of additional IMP-to-Host error message types. These changes should assist the Hosts in determining
Reynolds & Postel [Page 115]
RFC 1000 - Request for Comments Reference Guide August 1987
appropriate recovery action without causing any serious reprogramming problems.
311 Bryan Feb 72 New Console Attachments to the UCSB Host
Describes types of terminals used at UCSB.
310 Bhushan Apr 72 Another Look at Data and File Transfer Protocols
This paper suggests some specific changes in DTP and FTP that should make them more useful and/or simplify implementation.
309 Bhushan Mar 72 Data and File Tranfer Workshop Announcement
Describes plans for a meeting on FTP to be held April 1972.
Discusses testing of IMPs and notes that this may cause some hosts to receive messages from unregistered addresses.
304 McKay Feb 72 A Data Management System Proposal for the ARPA Network
A proposal to provide a framework that will allow the ARPA community to recognize and develop the necessary tools in a unified manner enabling the network to manage its resources to the best advantage of the user.
Reynolds & Postel [Page 116]
RFC 1000 - Request for Comments Reference Guide August 1987
This RFC describes a proposed modular graphic/alphanumeric display system containing a 512 by 512 line, 60 line per inch plasma display/memory panel and a minprocessor. It is intended to combine the advantages of display memory and local processing power in three general modes.
292 Michener Jan 72 Graphics Protocol - Level 0 only
A description of part of the proposed Network Standard Graphics Protocol for transmitting graphics data within the ARPA network. The particular aspects covered are related to the form and content of graphics information sent from a source of graphical information to a display package for output to a graphics console.
291 McKay Jan 72 Data Management Meeting Announcement
A meeting about datamanagement will be held February 1972.
290 Mullery Jan 72 Computer Network and Data Sharing: A Bibliography
Reports on tests of host availability for 6 Dec to 18 Dec 1971.
286 Forman Dec 71 Network Library Information System
This RFC solicites interested parties in the ARPA community to form a working group whose interests include developing a new system that would enable computer query of Library holdings. Georgetown University is currently designing a Learning Resource Center which could be the prototype of the proposed working group.
This paper is aimed at bringing together the present state of graphics on the NET for the newcomer and attempting to add a little more documentation to the current ground covered in graphics research by ARPA.
Reynolds & Postel [Page 118]
RFC 1000 - Request for Comments Reference Guide August 1987
283 Braden Dec 71 NETRJT - Remote Job Service Protocol for TIPS
Discusses how it may be feasible in the future to use TIPS for remote job entry in one or more of three ways: attach local card readers, line printer, and card punches directly to TIP ports, connect a remote batch terminal to a full-duplex TIP port via a communication line, and/or use the tape drive, and do card-to-tape and/or tape-to-print on another computer.
254 Bhushan Oct 71 Scenarios for Using ARPANET Computers
This document is provided to facilitate the use of ARPANET host computer systems via the ARPANET. The objective of these scenarios is to aid a user in sampling host computers on the ARPANET, thereby stimulating his interest in using the ARPANET.
253 Moorer Oct 71 Second Network Graphics Meeting Details
Plans for a graphics meeting to be held November 1971. See RFC 282.
Further clarification and proposed revision on several aspects of the proposed Data Transfer Protocol and the File Transfer Protocol.
Reynolds & Postel [Page 121]
RFC 1000 - Request for Comments Reference Guide August 1987
249 Borelli Oct 71 Coordination of Equipment and Supplies Purchase
Announcement of an agreement reached regarding the study of the feasibility of a coordinating point for purchases of equipment and supplies to be used on the network.
242 Haibt Jul 71 Data Descriptive Language for Shared Data
Discussion of representation differences. Three categories are defined: very local representation, representation of collections of data, and other more complex structures that data collections may have.
241 McKenzie Sep 71 Connecting Computers to MLC Ports
Discussion on the pros and cons of computers being connected through serial communication lines to ports on the Terminal IMP's Multi-Line Controller (MLC).
RFC 1000 - Request for Comments Reference Guide August 1987
238 Braden Sep 71 Comments on DTP and FTP Protocols
This RFC updates RFCs 171,172.
237 Watson Sep 71 The NIC's View of Standard Host Names
The NIC strongly favors standardization of host names. In this RFC, the NIC proposes that any standard naming scheme should take into account certain considerations.
Starting with this RFC, BBN will report on the status of most Network Hosts.
234 Vezza Oct 71 Network Working Group Meeting Schedule
Plans for a Network Working Group meeting in October 1971.
233 Bhushan Sep 71 Standardization of Host Call Letters
A currently recommended list of call letters.
232 Vezza Sep 71 Announcement of the next Network Graphics Meeting
Schedule conflict and postponement of the graphics meeting.
231 Heafner Sep 71 Service Center Standards for Remote Usage - A User's View
A statement of views on service center standards. An input to the service center panel discussion of the October Network meeting.
230 Pyke Sep 71 Toward Reliable Operation of Minicomputer-based Terminals on a TIP
Points out inadequate error detection and initiation of corrective measures in the present protocol for communication between a TIP and attached terminals. References RFC 203.
Reynolds & Postel [Page 123]
RFC 1000 - Request for Comments Reference Guide August 1987
207 Vezza Aug 71 A September Network Working Group Meeting
Next meeting announcement.
206 White Aug 71 A User Telnet Description of an Initial Implementation
This document describes a program whose function is to make an Online System terminal appear to any teletype-compatible, time-sharing system in the Network as if it were directly connected to that system.
205 Braden Aug 71 NETCRT - A Character Display Protocol
A significant revision of the character-display protocol (NETCRT), based on CCN's proposed NETCRT from the May NWG Meeting.
This is a non-standard protocol, suitable for either second or third level use and is proposed with the intent of providing error resistant and highly reliable communication channels.
RFC 1000 - Request for Comments Reference Guide August 1987
199 Williams Jul 71 Suggestions for a Network Data-Tablet Graphics Protocol
SDC's comments to the discussion of a protocol for network graphics within the ARPA Network community. Concern is focused on the development of the graphics protocol in two areas: non-interactive graphics and data-tablet graphics, as opposed to fully interactive graphics.
198 Heafner Jul 71 Site Certification - Lincoln Labs 360/67
A report from RAND that Lincoln Labs protocol implementations are correct.
The purpose of this protocol is to provide at each site a standard mechanism to receive sequential files for immediate or deferred printing or other uses.
195 Mealy Jul 71 Data Computers - Data Descriptions and Access Language
This document discusses some of the problems involved in the unified approach to Network data management, and to suggest possible avenues of approach toward their resolution.
194 Cerf Jul 71 The Data Reconfiguration Service - Compiler/Interpreter Implementation Notes
This document describes the new features of the language, the new syntax, the form interpreter, and the instruction set.
RFC 1000 - Request for Comments Reference Guide August 1987
192 Watson Jul 71 Some Factors Which a Network Graphics Protocol Must Consider
Discussion on what any network graphics protocol should come to grips with.
191 Irby Jul 71 Graphics Implementation and Conceptualization at ARC
A brief description of the way in which graphics terminals are conceptualized and used at the Augmentation Research Center.
190 Deutsch Jul 71 DEC PDP-10 - IMLAC Communication System
This document describes an operational system for communicating textual display information between a main-site computer and a remote display processor.
A description of the operation and protocol of the remote job entry service to CCN's 360 Model 91. This interim protocol will be implemented as a production service before the end of July.
188 Karp Jan 71 Data Management Meeting Announcement
Plans for a data management meeting to be held Auguest 1971.
An information Request for Comments that is intended to convey some of the thinking and philosophy that went into IBM's network protocol and overall network design.
The Network Graphics Loader described in this document proposes to permit remote users on the ARPA network to obtain graphics output from programs they write for the Evans and Sutherland Line Drawing System.
185 North Jul 71 NIC Distribution of Manuals and Handbooks
The NIC request that sites send copies of manuals and handbooks to them.
Reynolds & Postel [Page 128]
RFC 1000 - Request for Comments Reference Guide August 1987
The ARPA Network node at the University of Illinois' Center for Advanced Computation is different from other nodes. It is not just a simple attachment to the net. Establishment of the computer system specifically for use of the ILLIAC IV and the network is in process. This paper describes the operating systems, network interface and utility routines, and ILLIAC IV routines to be used over the network.
183 Winett Jul 71 The EBCDIC Codes and Their Mapping to ASCII
This document defines and describes the IBM Standard Extended BCD Interchange Code. This is done in order to uniquely map the ASCII codes into corresponding EBCDIC codes in a consistent manner throughout the ARPA Network.
182 North Jun 71 Compilation of List of Relevant Site Reports
A Network Information Center compilation list of all site-produced reports which are of interest to Network participants.
This document is intended to modify the proposal for a device independent graphical display description discussed in RFC 177. The main changes are in the definition of coordinate areas to avoid one problem encountered with the old definition and to provide more flexibility.
178 Cotton Jun 71 Network Graphic Attention Handling
The process of attention handling is briefly described, various graphic configurations are discussed, input devices are surveyed to identify the types of data which they produce, and an attention protocol is proposed.
Reynolds & Postel [Page 129]
RFC 1000 - Request for Comments Reference Guide August 1987
177 McConnell Jun 71 A Device Independent Graphical Display Description
As more nodes are connected to the ARPA network, the types of graphical display processors available to users is quite varied. To attempt to facilitate the transmission of graphical information over the network, a device independent description of a display is described.
176 Bhushan Jun 71 Comments on Byte Size for Connections
This document points out three views on the use of byte size for network connections: 1) Byte size should not be used at all. 2) Byte size is solely for the convenience of NCP's. 3) Byte size choice is a user-level prerogative.
175 Harslem Jun 71 Comments on "Socket Conventions Reconsidered"
This protocol is a user-level protocol for file transfer between host computers (including terminal IMPs), on the ARPA computer network. The File Transfer Protocol (FTP) uses the data transfer protocol described in RFC 171. This paper assumes knowledge of RFC 171.
Definition of a low-level Data Transfer Protocol (DTP) to be used for transfer of data in file transfer, remote job entry, and other applications oriented protocols. A companion paper (RFC 172) describes file transfer protocol.
Reynolds & Postel [Page 130]
RFC 1000 - Request for Comments Reference Guide August 1987
167 Bhushan May 71 Socket Conventions Reconsidered
The recent NCP Protocol said nothing about how hosts should assign socket numbers to process ports, except that the low-order bit is to specify socket gender. This document discusses two recent proposals that call for additional network-wide conventions on the 32-bit socket number.
166 Anderson May 71 Data Reconfiguration Service - An Implementation Specification
This DRS experiment involved a software mechanism to reformat Network data streams. The mechanism can be adapted to numerous Network application programs.
165 Postel May 71 A Proferred Official Initial Connection Protocol
This document specifies the third level protocol used to connect a user process at one site with a server process at another site.
164 Heafner May 71 Minutes of Network Working Group Meeting
A 38 page reference on the discussions held at the Network Working Group Meeting.
Discussion of NETBUGGER3 as a third level program for the debugging of second and third level programs, experimentation with and simulation of third level protocols.
Reynolds & Postel [Page 131]
RFC 1000 - Request for Comments Reference Guide August 1987
161 Shoshani May 71 A Solution to the Race Condition in the ICP
A proposed solution to a problem that arose out of RFC 143.
A working paper discussing the exposition of the types of usage to which an IPC facility would be subjected. This document hopes to clarify the goals being pursued and should provide a benchmark for gauging various implementation strategies.
149 Crocker May 71 The Best Laid Plans...
Changes to the topics and attendees of the upcoming NWG meeting.
Description of a family of ICPs (Initial Connection Protocol) suitable for establishing one pair of connections (one in each direction) between any user process and any server process, and proposes a particular subset of this family as the standard ICP for connecting user processes to loggers on systems which accept teletype-like devices.
122 White Apr 71 Network Specifications for UCSB's Simple-Minded File System
UCSB's Simple Minded File System (SMFS) which will provide file storage for network users. This document provides programmers with the information necessary to communicate with SMFS.
This paper discusses the problems and solutions that are simple to implement in the current protocol specifications that contain serious logical errors in the interrupt functions.
102 Crocker Feb 71 Output of the HOST/HOST Protocol Glitch Cleaning Committee
Numerous topics were discussed.
101 Watson Feb 71 Notes on the Network Working Group Meeting
Transcript of the Network Working Group Meeting, February 1970.
100 Karp Feb 71 Categorization and Guide to NWG/RFCs
Categorizes, identifies, and summarizes RFCS 1-100.
This "network logger protocol" is intended to specify how the existing logger of a network host is to interface to the network so as to permit a login from a console attached to another host.
097 Melvin Feb 71 A First Cut at a Proposed Telnet Protocol
This document was motivated by the need to set specifications for a protocol which would allow on-line access to the Network Information Center (NIC).
096 Watson Feb 71 An Interactive Network Experiment to Study Modes of Access to the Network Information Center
Outlines the framework for a simple interactive experiment to study modes of access to the Network Information Center (NIC).
095 Crocker Feb 71 Distribution of NWG/RFC's Through the NIC
Standards for establishing lines of communication of all of the sites with the Network Information Center, in regards to distribution of RFC's.
094 Harslem Feb 71 Some Thoughts on Network Graphics
Discussion of the initial reaction to RFC 86, whose purpose was to provide a basis for discussion and development of Network graphics.
Discussion of UCLA's Campus Computing Network of services and implementation priorities.
089 Metcalfe Jan 71 Some Historic Moments in Networking
Noteworthy achievements for the MIT-Project MAC Dynamic Modeling/Computer Graphics PDP-6/10 System, while awaiting the completion of an interim network control program.
088 Braden Jan 71 NETRJS - A Third Level Protocol for Remote Job Entry
Description of NETRJS, which is the name for a message protocol and a set of control conventions which will allow users at remote Hosts to access the RJS remote batch subsystem of UCLA/CCN.
087 Vezza Jan 71 Topic for Discussion at the Next Network Working Group Meeting
Suggests Network Working Group discussion on topics germane to network graphics.
086 Crocker Jan 71 Proposal for a Network Standard Format for a Data Stream to Control Graphics Display
Proposes specifying the form of an output stream for the case that the output portion of the console (which is attached to a computer at the user's site) is a typical refresh display with point, vector, and character drawing capability.
Report on three Network Working Group meetings held during November 16, 17, and 18.
076 Bouknight Oct 70 Connection-by-Name: User-Oriented Protocol
Suggests a user level interface to network protocol where all user protocol is handled symbolically with system procedures making the translation into host-to-host protocol. Proposes general solutions.
072 Bressler Sep 70 Proposed Moratorium on Changes to Network Protocol
Cites critical changes that could occur in hardware/software development efforts and advanced debugging if changes in the Network Protocol aren't kept in check.
071 Schipper Sep 70 Reallocation in Case of Input Error
Discussion of how to resynchronize flow control using a proposed protocol for the CCN-Host at UCLA.
Definition of a new NCP Protocol that is simple enough to be implemented on a very small computer, yet can be extended for efficient operation on large timesharing machines.
059 Meyer Jun 70 Flow Control-Fixed Versus Demand Allocation
Discussion of the advantages and disadvantages of the method of flow control as described in RFC 54.
058 Skinner Jun 70 Logical Message Synchronization
A discussion on a question raised at the last network meeting regarding the question of logical and physical message distinctions.
057 Kraley Jun 70 Thoughts and Reflections on RFC 54
Announcement that MIT is now to receive all Network Working Group memos.
015 Carr Sep 69 Network Subsystem for Time Sharing Hosts
Proposes a subsystem called "Telnet", which would be a shell program around the network system primitives, allowing a teletype or similar terminal at a remote host to function as a teletype at the serving host.