Movatterモバイル変換

Network Working Group                                          J. PostelRequest for Comments: 899                                     A. Westine                                                                     ISI                                                                May 1984Requests For Comments SummaryNotes: 800-899Status of this Memo   This RFC is a slightly annotated list of the 100 RFCs fromRFC 800   throughRFC 899.  This is a status report on these RFCs.RFC     Author       Date        Title---     ------       ----        -----899     Postel     Apr 84      Requests For Comments Summary   This memo.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 a 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 Internet.  This memo is a partial update   ofRFC 881.  The intent of this memo is to detail the schedule for   the implementation for 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.Postel & Westine                                                [page 1]

RFC 899                                                         May 1984896     Nagle      Jan 84      Congestion Control in IP/TCP                                 Internetworks   This memo discusses some aspects of congestion control in IP/TCP   Internetworks.  It is intended to stimulate thought and further   discussion of this topic.  While some specific suggestions are made   for improved congestion control implementation, this memo does not   specify any standards.895     Postel     Apr 84      A Standard for the Transmission of                                 IP Datagrams over Experimental Ethernet                                 Networks   This RFC specifies a standard method of encapsulating Internet   Protocol (IP) datagrams on an Experimental Ethernet.  This RFC   specifies a standard protocol for the ARPA Internet community.894     Hornig     Apr 84      A Standard for the Transmission of                                 IP Datagrams over Ethernet Networks   This RFC specifies a standard method of encapsulating Internet   Protocol (IP) datagrams on an Ethernet.  This RFC specifies a   standard protocol for the ARPA-Internet community.893     Leffler    Apr 84      Trailer Encapsulations   This RFC discusses the motivation for use of "trailer encapsulations"   on local-area networks and describes the implementation of such an   encapsulation on various media.  This document is for information   only.  This is NOT an official protocol for the ARPA Internet   community.892     ISO        Dec 83      ISO Transport Protocol Specification   This is a draft version of the transport protocol being standardized   by the ISO.  This version also appeared in the ACM SIGCOMM Computer   Communication Review (V.12, N.3-4) July-October 1982.  This version   is now out of date.891     Mills      Dec 83      DCN Local-Network Protocols   This RFC provides a description of the DCN protocols for maintaining   connectivity, routing, and clock information in a local network.   These procedures may be of interest to the designers and implementers   of other local networks.Postel & Westine                                                [page 2]

RFC 899                                                         May 1984890     Postel     Feb 84      Exterior Gateway Protocol                                 Implementation Schedule   This memo is a policy statement on the implementation of the Exterior   Gateway Protocol in the Internet.  This is an official policy   statement of ICCB and DARPA.  After 1-Aug-84 there shall be no dumb   gateways in the Internet. Every gateway must be a member of some   autonomous system.  Some gateway of each autonomous system must   exchange routing information with some gateway of the core autonomous   system using the Exterior Gateway Protocol.889     Mills      Dec 83      Internet Delay Experiments   This memo reports on some measurements of round-trip times in the   Internet and suggests some possible improvements to the TCP   retransmission timeout calculation.  This memo is both a status   report on the Internet and advice to TCP implementers.888     Seamonson  Jan 84      "Stub" Exterior Gateway Protocol   This RFC describes the Exterior Gateway Protocol used to connect Stub   Gateways to an Autonomous System of core Gateways.  This document   specifies the working protocol, and defines an ARPA official   protocol.  All implementers of Gateways should carefully review this   document.887     Accetta    Dec 83      Resource Location Protocol   This RFC specifies a draft standard for the ARPA Internet community.   It describes a resource location protocol for use in the ARPA   Internet.  It is most useful on networks employing technologies which   support some method of broadcast addressing, however it may also be   used on other types of networks.  For maximum benefit, all hosts   which provide significant resources or services to other hosts on the   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 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.Postel & Westine                                                [page 3]

RFC 899                                                         May 1984885     Postel     Dec 83      Telnet End of Record Option   This RFC specifies a standard for the ARPA Internet community.  It   specifies a method for marking the end of records in data transmitted   on Telnet connections.884     Solomon    Dec 83      Telnet Terminal Type Option   This RFC specifies a standard for the ARPA Internet community.  It   specifies a method for exchanging terminal type information in the   Telnet protocol.883     MockapetrisNov 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     MockapetrisNov 83      Domain Names - Concepts and Facilities   This RFC introduces domain style names, their use for ARPA Internet   mail and host address support, and the protocol and servers used to   implement domain name facilities.881     Postel     Nov 83      The Domain Names Plan and Schedule   This RFC outlines a plan and schedule for the implementation of   domain style names throughout the DDN/ARPA Internet community.  The   introduction of domain style names will impact all hosts on the   DDN/ARPA Internet.880     Reynolds   Oct 83      Official Protocols   This RFC identifies the documents specifying the official protocols   used in the ARPA Internet.  Annotations identify any revisions or   changes planned.  ObsoletesRFC 840.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 purposes 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".Postel & Westine                                                [page 4]

RFC 899                                                         May 1984878     Malis      Dec 83      The ARPANET 1822L Host Access Protocol   This RFC specifies the ARPANET 1822L Host Access Protocol, which is a   successor to the existing 1822 Host Access Protocol.  The 1822L   procedure allows ARPANET hosts to use logical identifiers as well as   1822 physical interface identifiers to address each other.877     Korb       Sep 83      A Standard for the Transmission of IP                                 Datagrams Over Public Data Networks   This RFC specifies a standard adopted by CSNET, the VAN gateway, and   other organizations for the transmission of IP datagrams over the   X.25-based public data networks.876     Smallberg  Sep 83      Survey of SMTP Implementations   This RFC is a survey of implementation status.  It does not specify   an official protocol, but rather notes the status of implementation   of aspects of a protocol.  It is expected that the status of the   hosts reported on will change.  This information must be treated as a   snapshot of the state of these implemetations.875     Padlipsky  Sep 82      Gateways, Architectures, and Heffalumps   This RFC is a discussion about the role of gateways in an   internetwork, especially the problems of translating or mapping   protocols between different protocol suites.  The discussion notes   possible functionality mis-matches, undesirable routing "singularity   points", flow control issues, and high cost of translating gateways.   Originally published as M82-51 by the MITRE Corporation, Bedford,   Massachusetts.874     Padlipsky  Sep 82      A Critique of X.25   This RFC is an analysis of X.25 pointing out some problems in the   conceptual model, particularly the conflict between the interface   aspects and the end-to-end aspects.  The memo also touches on   security, and implementation issues.  Originally published as M82-50   by the MITRE Corporation, Bedford, Massachusetts.873     Padlipsky  Sep 82      The Illusion of Vendor Support   This memo takes issue with the claim that international standards in   computer protocols presently provide a basis for low cost vendor   supported protocol implementations.  Originally published as M82-49   by the MITRE Corporation, Bedford, Massachusetts.Postel & Westine                                                [page 5]

RFC 899                                                         May 1984872     Padlipsky  Sep 82      TCP-ON-A-LAN   This memo attacks the notion that TCP cannot be appropriate for use   on a Local Area Network.  Originally published as M82-48 by the MITRE   Corporation, Bedford Massachusetts.871     Padlipsky  Sep 82      A Perspective on the Arpanet Reference                                 Model   This RFC is primarily intended as a perspective on the ARM and points   out some of the differences between the ARM and the ISORM  which were   expressed by members in NWG general meetings, NWG protocol design   committee meetings, the ARPA Internet Working Group, and private   conversations over the intervening years.  Originally published as   M82-47 by the MITRE Corporation, Bedford, Massachusetts.870     Reynolds   Oct 83      Assigned Numbers   This RFC documents the list of numbers assigned for networks,   protocols, etc.  Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755,   750, 739, 604.869     Hinden     Dec 83      A Host Monitoring Protocol   This RFC specifies the Host Monitoring Protocol used to collect   information from various types of hosts in the Internet.  Designers   of Internet communications software are encouraged to consider this   protocol as a means of monitoring the behavior of their creations.868     Postel     May 83      Time Protocol   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet that choose to implement a Time Protocol are   expected to adopt and implement this standard.  This protocol   provides a site-independent, machine readable date and time.  The   Time service sends back to the originating source the time in seconds   since midnight on January first 1900.867     Postel     May 83      Daytime Protocol   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet that choose to implement a Daytime Protocol are   expected to adopt and implement this standard.  The Daytime service   simply sends the current date and time as a character string without   regard to the input.Postel & Westine                                                [page 6]

RFC 899                                                         May 1984866     Postel     May 83      Active Users   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet that choose to implement an Active Users   Protocol are expected to adopt and implement this standard.  The   Active Users service simply sends a list of the currently active   users on the host without regard to the input.865     Postel     May 83      Quote of the Day Protocol   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet that choose to implement a Quote of the Day   Protocol are expected to adopt and implement this standard.   The   Quote of the Day service simply sends a short message without regard   to the input.864     Postel     May 83      Character Generator Protocol   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet that choose to implement a Character Generator   Protocol are expected to adopt and implement this standard.  The   Character Generator service simply sends data without regard to the   input.863     Postel     May 83      Discard Protocol   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet that choose to implement a Discard Protocol are   expected to adopt and implement this standard.  The Discard service   simply throws away any data it receives.862     Postel     May 83      Echo Protocol   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet that choose to implement a Echo Protocol are   expected to adopt and implement this standard.  The Echo service   simply sends back to the originating source any data it receives.861     Postel     May 83      Telnet Extended Options - List Option   This Telnet Option provides a mechanism for extending the set of   possible options.  This RFC specifies a standard for the ARPA   Internet community.  Hosts on the ARPA Internet are expected to adopt   and implement this standard.  Obsoletes NIC 16239.Postel & Westine                                                [page 7]

RFC 899                                                         May 1984860     Postel     May 83      Telnet Timing Mark Option   This Telnet Option provides a way to check the roundtrip path between   two Telnet modules.  This RFC specifies a standard for the ARPA   Internet community.  Hosts on the ARPA Internet are expected to adopt   and implement this standard.  Obsoletes NIC 16238.859     Postel     May 83      Telnet Status Option   This Telnet Option provides a way to determine the other Telnet   module's view of the status of options.  This RFC specifies a   standard for the ARPA Internet community.  Hosts on the ARPA Internet   are expected to adopt and implement this standard.  ObsoletesRFC 651   (NIC 31154).858     Postel     May 83      Telnet Suppress Go Ahead Option   This Telnet Option disables the exchange of go-ahead signals between   the Telnet modules.  This RFC specifies a standard for the ARPA   Internet community.  Hosts on the ARPA Internet are expected to adopt   and implement this standard.  Obsoletes NIC 15392.857     Postel     May 83      Telnet Echo Option   This Telnet Option enables remote echoing by the other Telnet module.   This RFC specifies a standard for the ARPA Internet community.  Hosts   on the ARPA Internet are expected to adopt and implement this   standard.  Obsoletes NIC 15390.856     Postel     May 83      Telnet Binary Transmission   This Telnet Option enables a binary data mode between the Telnet   modules.  This RFC specifies a standard for the ARPA Internet   community.  Hosts on the ARPA Internet are expected to adopt and   implement this standard.  Obsoletes NIC 15389.855     Postel     May 83      Telnet Option Specifications   This memo specifies the general form for Telnet options and the   directions for their specification.  This RFC specifies a standard   for the ARPA Internet community.  Hosts on the ARPA Internet are   expected to adopt and implement this standard.  ObsoletesRFC 651,   NIC 18640.Postel & Westine                                                [page 8]

RFC 899                                                         May 1984854     Postel     May 83      Telnet Protocol Specifications   This is the specification of the Telnet protocol used for remote   terminal access in the ARPA Internet.  The purpose of the TELNET   Protocol is to provide a fairly general, bi-directional, eight-bit   byte oriented communications facility.  Its primary goal is to allow   a standard method of interfacing terminal devices and   terminal-oriented processes to each other.  It is envisioned that the   protocol may also be used for terminal-terminal communication   ("linking") and process-process communication (distributed   computation).   This RFC specifies a standard for the ARPA Internet   community.  Hosts on the ARPA Internet are expected to adopt and   implement this standard.  Obsoletes NIC 18639.853     Not issued yet.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.  ObsoletesRFC 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 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.Postel & Westine                                                [page 9]

RFC 899                                                         May 1984849     Crispin    May 83      Suggestions for Improved Host Table                                 Distribution   This RFC actually is a request for comments.  The issue dealt with is   that of a naming registry update procedure, both as exists currently   and what could exist in the future.  None of the proposed solutions   are intended as standards at this time; rather it is hoped that a   general consensus will emerge as the appropriate solution, leaving   eventually to the adoption of standards.848     Smallberg  Mar 83      Who provides the "Little" TCP Services?   This RFC lists those hosts which provide any of these "little" TCP   services:  The list of hosts were taken from the NIC hostname table   of 24-Feb-83.  The tests were run on February 23 and 24, and March 3   and 5 from ISI-VAXA.ARPA.847     Westine    Feb 83      Summary of Smallberg Surveys   This is a summary of the surveys of Telnet, FTP and Mail (SMTP)   servers conducted by David Smallberg in December 1982, January and   February 1983 as reported inRFC 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 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.Postel & Westine                                               [page 10]

RFC 899                                                         May 1984844     Clements  Feb 83      Who Talks ICMP, too?  Survey of 18                                 February 1983   This survey determines how many hosts are able to respond to TELENET   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 fromRFC843, extracting only those hosts which are listed there as accepting   TELNET connection.  The tests were run on 18-Feb-83.843     Smallberg  Feb 83      Who Talks TCP? -- Survey of 8 February                                 1983   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 3-Feb-83.  The tests were run on 8-Feb-83   and on 9-Feb-83 from ISI-VAXA.ARPA.842     Smallberg  Feb 83      Who Talks TCP? -- Survey of 1 February                                 1983   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 28-Jan-83.  The tests were run on 1-Feb-83   and on 2-Feb-83 ISI-VAXA.ARPA.841     FIPS PUB 98Jan 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.   ObsoletesRFC 806.840     Postel     Apr 83      Official Protocols   This RFC has been revised, seeRFC 880.839     Smallberg  Jan 83      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 31-Dec-82.  The tests were run on   25-Jan-83.Postel & Westine                                               [page 11]

RFC 899                                                         May 1984838     Smallberg  Jan 83      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 31-Dec-82.  The tests were run on   18-Jan-83.837     Smallberg  Jan 83      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 31-Dec-82.  The tests were run on   11-Jan-83.836     Smallberg  Jan 83      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 20-Dec-82.  The tests were run on 4-Jan-83   through 5-Jan-83.835     Smallberg  Dec 82      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 2-Dec-82.  The tests were run on 28-Dec-82   through 5-Jan-83.834     Smallberg  Dec 82      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 2-Dec-82.  The tests were run on 22-Dec-82.833     Smallberg  Dec 82      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 2-Dec-82.  The tests were run on 14-Dec-82.832     Smallberg  Dec 82      Who Talks TCP?   This RFC is a survey of hosts to identify the implementation status   of Telnet, FTP, and Mail on TCP.  The list of hosts was taken from   the NIC hostname table of 2-Dec-82.  The tests were run on 7-Dec-82.Postel & Westine                                               [page 12]

RFC 899                                                         May 1984831     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 SuOct 82      A Distributed System for Internet Name                                 Service   This RFC proposes a distributed name service for DARPA Internet.  Its   purpose is to focus discussion on the subject.  It is hoped that a   general consensus will emerge leading eventually to the adoption of   standards.829     Cerf       Oct 82      Packet Satellite Technology Reference                                 Sources   This RFC describes briefly the packet satellite technology developed   by the Defense Advanced Research Projects Agency and several other   participating organizations in the U.K. and Norway and provides a   bibliography of relevant papers for researchers interested in   experimental and operational experience with this dynamic   satellite-sharing technique.828     Owen       Aug 82      Data Communications:  IFIP's                                 International "Network" of Experts   This RFC is distributed to inform the ARPA Internet community of the   activities of the IFIP technical committee on Data Communications,   and to encourage participation in those activities.827     Rosen      Oct 82      Exterior Gateway Protocol (EGP)   This RFC is proposed to establish a standard for Gateway to Gateway   procedures that allow the Gateways to be mutually suspicious.  This   document is a DRAFT for that standard.  Your comments are strongly   encouraged.826     Plummer    Nov 82      An Ethernet Address Resolution Protocol   The purpose of this RFC is to present a method of Converting Protocol   Addresses (e.g., IP addresses) to Local Network Addresses (e.g.,   Ethernet addresses).  This is an issue of general concern in the ARPA   Internet Community at this time.  The method proposed here is   presented for your consideration and comment.  This is not the   specification of an Internet Standard.Postel & Westine                                               [page 13]

RFC 899                                                         May 1984825     Postel     Nov 82      Request for Comments on Requests for                                 Comments   This RFC is intended to clarify the status of RFCs and to provide   some guidance for the authors of RFCs in the future.  It is in a   sense a specification for RFCs.824     MacGregor  Aug 82      The Cronus Virtual Local Network   The purpose of this note is to describe the CRONUS Virtual Local   Network, especially the addressing related features.  These features   include a method for mapping between Internet Addresses and Local   Network addresses.  This is a topic of current concern in the ARPA   Internet community.  This note is intended to stimulate discussion.   This is not a specification of an Internet Standard.823     Hinden     Sep 82      The DARPA Internet Gateway   This RFC is a status report on the Internet Gateway developed by BBN.   It describes the Internet Gateway as of September 1982.  This memo   presents detailed descriptions of message formats and gateway   procedures, however, this is not an implementation specification, and   such details are subject to change.822     Crocker    Aug 82      Standard for the Format of ARPA                                 Internet Text Messages   This document revises the specifications inRFC 733, in order to   serve the needs of the larger and more complex ARPA Internet.  Some   ofRFC 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.  ObsoletesRFC 733, NIC 41952.821     Postel     Aug 82      Simple Mail Transfer Protocol   The objective of Simple Mail Transfer Protocol (SMTP) is to transfer   mail reliably and efficiently.  SMTP is independent of the particular   transmission subsystem and requires only a reliable ordered data   stream channel.  ObsoletesRFC 788, 780, and 772.820     Postel     Jan 82      Assigned Numbers   This RFC is an old version, seeRFC 870.Postel & Westine                                               [page 14]

RFC 899                                                         May 1984819     Zaw-Sing SuAug 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 Internet name service and user   applications.818     Postel     Nov 82      The Remote User Telnet Service   This RFC is the specification of an application protocol.  Any host   that implements this application level service must follow this   protocol.817     Clark      Jul 82      Modularity and Efficiency in Protocol                                 Implementation   This RFC will discuss some of the commonly encountered reasons why   protocol implementations seem to run slowly.816     Clark      Jul 82      Fault Isolation and Recovery   This RFC describes the portion of fault isolation and recovery which   is the responsibility of the host.815     Clark      Jul 82      IP Datagram Reassembly Algorithms   This RFC describes an alternate approach of dealing with reassembly   which reduces the bookkeeping problem to a minimum, and requires only   one buffer for storage equal in size to the final datagram being   reassembled, which can reassemble a datagram from any number of   fragments arriving in any order with any possible pattern of overlap   and duplication, and which is appropriate for almost any sort of   operating system.814     Clark      Jul 82      Name, Addresses, Ports, and Routes   This RFC gives suggestions and guidance for the design of the tables   and algorithms necessary to keep track of these various sorts of   identifiers inside a host implementation of TCP/IP.813     Clark      Jul 82      Window and Acknowledgement Strategy in                                 TCP   This RFC describes implementation strategies to deal with two   mechanisms in TCP, the window and the acknowledgement.  It also   presents a particular set of algorithms which have received testing   in the field, and which appear to work properly with each other.   With more experience, these algorithms may become part of the formal   specification, until such time their use is recommended.Postel & Westine                                               [page 15]

RFC 899                                                         May 1984812     Harrenstien Mar 82     NICNAME/WHOIS   This RFC gives a description of what the NICNAME/WHOIS Server is and   how to access it.  This server together with the corresponding   Identification Data Base provides online directory look-up equivalent   to the ARPANET Directory.811     Harrenstien Mar 82      Hostnames Server   This RFC gives a description of what the Hostnames Server is and how   to access it.  The function of this particular server is to deliver   machine-readable name/address information describing networks,   gateways, hosts, and eventually domains, within the internet   environment.810     Feinler    Mar 82      DoD Internet Host Table Specification   This RFC specifies a new host table format applicable to both ARPANET   and Internet needs.  In addition to host name to host address   translation and selected protocol information, we have also included   network and gateway name to address correspondence, and host   operating system information.  This RFC obsoletes the host table   described inRFC 608.809     Chang      Feb 82      UCL Facsimile System   This RFC describes the features of the computerised facsimile system   developed in the Department of Computer Science at UCL.  First its   functions are considered and the related experimental work are   reported.  Then the disciplines for system design are discussed.   Finally, the implementation of the system are described, while   detailed description are given as appendices.808     Postel     Mar 82      Summary of Computer Mail Services                                 Meeting Held at BBN on 10 January 1979   This RFC is a very belated attempt to document a meeting that was   held three years earlier to discuss the state of computer mail in the   ARPA community and to reach some conclusions to guide the further   development of computer mail systems such that a coherent total mail   service would continue to be provided.807     Postel     Feb 82      Multimedia Mail Meeting Notes   This RFC consists of notes from a meeting held at USC Information   Sciences Institute on the 12th of January to discuss common interests   in multimedia computer mail issues and to agree on some specific   initial experiments.Postel & Westine                                               [page 16]

RFC 899                                                         May 1984806     NBS        Sep 81      Specification for Message Format for                                 Computer Based Message Systems   This RFC deals with Computer Based Message systems which provides a   basis for interaction between different CBMS by defining the format   of messages passed between them.  This RFC is replaced byRFC 841.805     Postel     Feb 82      Computer Mail Meeting Notes   This RFC consists of notes from a meeting that was held at USC   Information Sciences Institute on 11 January 1982, to discuss   addressing issues in computer mail. The major conclusion reached at   the meeting is to extend the "username@hostname" mailbox format to   "username@host.domain", where the domain itself can be further   strutured.804     CCITT      Jan 82      CCITT Draft Recommendation T.4   This is the CCITT standard for group 3 facsimile encoding.  This is   useful for data compression of bit map data.803     Agarwal    Nov 81      Dacom 450/500 Facsimile Data                                 Transcoding   The first part of this RFC describes in detail the Dacom 450 data   compression algorithms and is an update and correction to an earlier   memorandum.  The second part of this RFC describes briefly the Dacom   500 data compression algorithm as used by the INTELPOST   electronic-mail network under development by the US Postal Service   and several foreign administrators.802     Malis      Nov 81      The ARPANET 1822L Host Access Protocol   This document proposed two major changes to the current ARPANET host   access protocol.  The first change will allow hosts to use logical   addressing (i.e., host addresses that are independent of their   physical location on the ARPANET) to communicate with each other, and   the second will allow a host to shorten the amount of time that it   may be blocked by its IMP after it presents a message to the network   (currently, the IMP can block further input from a host for up to 15   seconds).  See RFCs 852 and 851.801     Postel     Nov 81      NCP/TCP Transition Plan   This RFC discusses the conversion of hosts from NCP to TCP.  And   making available the principle services:  Telnet, File Transfer, and   Mail.  These protocols allow all hosts in the ARPA community to share   a common interprocess communication environment.Postel & Westine                                               [page 17]

RFC 899                                                         May 1984800     Postel     Nov 82      Requests for Comments Summary   This RFC is a slightly annotated list of the 100 RFCs fromRFC 700   throughRFC 799.  This is a status report on these RFCs.Postel & Westine                                               [page 18]