home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc0899.txt < prev    next >
Text File  |  1996-05-07  |  41KB  |  624 lines

  1.  
  2.  
  3. Network Working Group                                          J. Postel Request for Comments: 899                                     A. Westine                                                                      ISI                                                                 May 1984 
  4.  
  5.                       Requests For Comments Summary                              Notes: 800-899 
  6.  
  7. Status of this Memo 
  8.  
  9.    This RFC is a slightly annotated list of the 100 RFCs from RFC 800    through RFC 899.  This is a status report on these RFCs. 
  10.  
  11. RFC     Author       Date        Title ---     ------       ----        ----- 
  12.  
  13. 899     Postel       Apr 84      Requests For Comments Summary 
  14.  
  15.    This memo. 
  16.  
  17. 898     Hinden       Apr 84      Gateway Special Interest Group Meeting                                  Notes 
  18.  
  19.    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. 
  20.  
  21. 897     Postel       Feb 84      Domain Name System Implementation                                  Schedule 
  22.  
  23.    This memo is a policy statement on the implementation of the Domain    Style Naming System in the Internet.  This memo is a partial update    of RFC 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. 
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33. Postel & Westine                                                [page 1] 
  34.  
  35.  
  36.  RFC 899                                                         May 1984 
  37.  
  38.  896     Nagle        Jan 84      Congestion Control in IP/TCP                                  Internetworks 
  39.  
  40.    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. 
  41.  
  42. 895     Postel       Apr 84      A Standard for the Transmission of                                  IP Datagrams over Experimental Ethernet                                  Networks 
  43.  
  44.    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. 
  45.  
  46. 894     Hornig       Apr 84      A Standard for the Transmission of                                  IP Datagrams over Ethernet Networks 
  47.  
  48.    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. 
  49.  
  50. 893     Leffler      Apr 84      Trailer Encapsulations 
  51.  
  52.    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. 
  53.  
  54. 892     ISO          Dec 83      ISO Transport Protocol Specification 
  55.  
  56.    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. 
  57.  
  58. 891     Mills        Dec 83      DCN Local-Network Protocols 
  59.  
  60.    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. 
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68. Postel & Westine                                                [page 2] 
  69.  
  70.  
  71.  RFC 899                                                         May 1984 
  72.  
  73.  890     Postel       Feb 84      Exterior Gateway Protocol                                  Implementation Schedule 
  74.  
  75.    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. 
  76.  
  77. 889     Mills        Dec 83      Internet Delay Experiments 
  78.  
  79.    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. 
  80.  
  81. 888     Seamonson    Jan 84      "Stub" Exterior Gateway Protocol 
  82.  
  83.    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. 
  84.  
  85. 887     Accetta      Dec 83      Resource Location Protocol 
  86.  
  87.    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. 
  88.  
  89. 886     Rose         Dec 83      Proposed Standard for Message Header                                  Munging 
  90.  
  91.    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. 
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  Postel & Westine                                                [page 3] 
  98.  
  99.  
  100.  RFC 899                                                         May 1984 
  101.  
  102.  885     Postel       Dec 83      Telnet End of Record Option 
  103.  
  104.    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. 
  105.  
  106. 884     Solomon      Dec 83      Telnet Terminal Type Option 
  107.  
  108.    This RFC specifies a standard for the ARPA Internet community.  It    specifies a method for exchanging terminal type information in the    Telnet protocol. 
  109.  
  110. 883     Mockapetris  Nov 83      Domain Names - Implementation and                                  Specification 
  111.  
  112.    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. 
  113.  
  114. 882     Mockapetris  Nov 83      Domain Names - Concepts and Facilities 
  115.  
  116.    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. 
  117.  
  118. 881     Postel       Nov 83      The Domain Names Plan and Schedule 
  119.  
  120.    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. 
  121.  
  122. 880     Reynolds     Oct 83      Official Protocols 
  123.  
  124.    This RFC identifies the documents specifying the official protocols    used in the ARPA Internet.  Annotations identify any revisions or    changes planned.  Obsoletes RFC 840. 
  125.  
  126. 879     Postel       Nov 83      The TCP Maximum Segment Size and                                  Related Topics 
  127.  
  128.    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". 
  129.  
  130.  
  131.  
  132.  
  133.  
  134. Postel & Westine                                                [page 4] 
  135.  
  136.  
  137.  RFC 899                                                         May 1984 
  138.  
  139.  878     Malis        Dec 83      The ARPANET 1822L Host Access Protocol 
  140.  
  141.    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. 
  142.  
  143. 877     Korb         Sep 83      A Standard for the Transmission of IP                                  Datagrams Over Public Data Networks 
  144.  
  145.    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. 
  146.  
  147. 876     Smallberg    Sep 83      Survey of SMTP Implementations 
  148.  
  149.    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. 
  150.  
  151. 875     Padlipsky    Sep 82      Gateways, Architectures, and Heffalumps 
  152.  
  153.    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. 
  154.  
  155. 874     Padlipsky    Sep 82      A Critique of X.25 
  156.  
  157.    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. 
  158.  
  159. 873     Padlipsky    Sep 82      The Illusion of Vendor Support 
  160.  
  161.    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. 
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  Postel & Westine                                                [page 5] 
  168.  
  169.  
  170.  RFC 899                                                         May 1984 
  171.  
  172.  872     Padlipsky    Sep 82      TCP-ON-A-LAN 
  173.  
  174.    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. 
  175.  
  176. 871     Padlipsky    Sep 82      A Perspective on the Arpanet Reference                                  Model 
  177.  
  178.    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. 
  179.  
  180. 870     Reynolds     Oct 83      Assigned Numbers 
  181.  
  182.    This RFC documents the list of numbers assigned for networks,    protocols, etc.  Obsoletes RFCs 820, 790, 776, 770, 762, 758, 755,    750, 739, 604. 
  183.  
  184. 869     Hinden       Dec 83      A Host Monitoring Protocol 
  185.  
  186.    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. 
  187.  
  188. 868     Postel       May 83      Time Protocol 
  189.  
  190.    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. 
  191.  
  192. 867     Postel       May 83      Daytime Protocol 
  193.  
  194.    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. 
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. Postel & Westine                                                [page 6] 
  203.  
  204.  
  205.  RFC 899                                                         May 1984 
  206.  
  207.  866     Postel       May 83      Active Users 
  208.  
  209.    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. 
  210.  
  211. 865     Postel       May 83      Quote of the Day Protocol 
  212.  
  213.    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. 
  214.  
  215. 864     Postel       May 83      Character Generator Protocol 
  216.  
  217.    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. 
  218.  
  219. 863     Postel       May 83      Discard Protocol 
  220.  
  221.    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. 
  222.  
  223. 862     Postel       May 83      Echo Protocol 
  224.  
  225.    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. 
  226.  
  227. 861     Postel       May 83      Telnet Extended Options - List Option 
  228.  
  229.    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. 
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  Postel & Westine                                                [page 7] 
  238.  
  239.  
  240.  RFC 899                                                         May 1984 
  241.  
  242.  860     Postel       May 83      Telnet Timing Mark Option 
  243.  
  244.    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. 
  245.  
  246. 859     Postel       May 83      Telnet Status Option 
  247.  
  248.    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). 
  249.  
  250. 858     Postel       May 83      Telnet Suppress Go Ahead Option 
  251.  
  252.    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. 
  253.  
  254. 857     Postel       May 83      Telnet Echo Option 
  255.  
  256.    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. 
  257.  
  258. 856     Postel       May 83      Telnet Binary Transmission 
  259.  
  260.    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. 
  261.  
  262. 855     Postel       May 83      Telnet Option Specifications 
  263.  
  264.    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. 
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274. Postel & Westine                                                [page 8] 
  275.  
  276.  
  277.  RFC 899                                                         May 1984 
  278.  
  279.  854     Postel       May 83      Telnet Protocol Specifications 
  280.  
  281.    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. 
  282.  
  283. 853     Not issued yet. 
  284.  
  285. 852     Malis        Apr 83      The ARPANET Short Blocking Feature 
  286.  
  287.    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. 
  288.  
  289. 851     Malis        Apr 83      The ARPANET 1822L Host Access Protocol 
  290.  
  291.    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. 
  292.  
  293. 850     Horton       Jun 83      Standard for Interchange of USENET                                  Messages 
  294.  
  295.    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. 
  296.  
  297.  
  298.  
  299.  Postel & Westine                                                [page 9] 
  300.  
  301.  
  302.  RFC 899                                                         May 1984 
  303.  
  304.  849     Crispin      May 83      Suggestions for Improved Host Table                                  Distribution 
  305.  
  306.    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. 
  307.  
  308. 848     Smallberg    Mar 83      Who provides the "Little" TCP Services? 
  309.  
  310.    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. 
  311.  
  312. 847     Westine      Feb 83      Summary of Smallberg Surveys 
  313.  
  314.    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 Internet (not counting TACs or ECHOS). 
  315.  
  316. 846     Smallberg    Feb 83      Who Talks TCP? -- Survey of 22 February                                  1983 
  317.  
  318.    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. 
  319.  
  320. 845     Smallberg    Feb 83      Who Talks TCP? -- Survey of 15 February                                  1983 
  321.  
  322.    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. 
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334. Postel & Westine                                               [page 10] 
  335.  
  336.  
  337.  RFC 899                                                         May 1984 
  338.  
  339.  844     Clements    Feb 83      Who Talks ICMP, too?  Survey of 18                                  February 1983 
  340.  
  341.    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 from RFC    843, extracting only those hosts which are listed there as accepting    TELNET connection.  The tests were run on 18-Feb-83. 
  342.  
  343. 843     Smallberg    Feb 83      Who Talks TCP? -- Survey of 8 February                                  1983 
  344.  
  345.    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. 
  346.  
  347. 842     Smallberg    Feb 83      Who Talks TCP? -- Survey of 1 February                                  1983 
  348.  
  349.    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. 
  350.  
  351. 841     FIPS PUB 98  Jan 83      Specification for Message Format for                                  Computer Based Message Systems 
  352.  
  353.    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. 
  354.  
  355. 840     Postel       Apr 83      Official Protocols 
  356.  
  357.    This RFC has been revised, see RFC 880. 
  358.  
  359. 839     Smallberg    Jan 83      Who Talks TCP? 
  360.  
  361.    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. 
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  Postel & Westine                                               [page 11] 
  370.  
  371.  
  372.  RFC 899                                                         May 1984 
  373.  
  374.  838     Smallberg    Jan 83      Who Talks TCP? 
  375.  
  376.    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. 
  377.  
  378. 837     Smallberg    Jan 83      Who Talks TCP? 
  379.  
  380.    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. 
  381.  
  382. 836     Smallberg    Jan 83      Who Talks TCP? 
  383.  
  384.    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. 
  385.  
  386. 835     Smallberg    Dec 82      Who Talks TCP? 
  387.  
  388.    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. 
  389.  
  390. 834     Smallberg    Dec 82      Who Talks TCP? 
  391.  
  392.    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. 
  393.  
  394. 833     Smallberg    Dec 82      Who Talks TCP? 
  395.  
  396.    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. 
  397.  
  398. 832     Smallberg    Dec 82      Who Talks TCP? 
  399.  
  400.    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. 
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408. Postel & Westine                                               [page 12] 
  409.  
  410.  
  411.  RFC 899                                                         May 1984 
  412.  
  413.  831     Braden       Dec 82      Backup Access to the European Side of                                  SATNET 
  414.  
  415.    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. 
  416.  
  417. 830     Zaw-Sing Su  Oct 82      A Distributed System for Internet Name                                  Service 
  418.  
  419.    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. 
  420.  
  421. 829     Cerf         Oct 82      Packet Satellite Technology Reference                                  Sources 
  422.  
  423.    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. 
  424.  
  425. 828     Owen         Aug 82      Data Communications:  IFIP's                                  International "Network" of Experts 
  426.  
  427.    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. 
  428.  
  429. 827     Rosen        Oct 82      Exterior Gateway Protocol (EGP) 
  430.  
  431.    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. 
  432.  
  433. 826     Plummer      Nov 82      An Ethernet Address Resolution Protocol 
  434.  
  435.    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. 
  436.  
  437.  Postel & Westine                                               [page 13] 
  438.  
  439.  
  440.  RFC 899                                                         May 1984 
  441.  
  442.  825     Postel       Nov 82      Request for Comments on Requests for                                  Comments 
  443.  
  444.    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. 
  445.  
  446. 824     MacGregor    Aug 82      The Cronus Virtual Local Network 
  447.  
  448.    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. 
  449.  
  450. 823     Hinden       Sep 82      The DARPA Internet Gateway 
  451.  
  452.    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. 
  453.  
  454. 822     Crocker      Aug 82      Standard for the Format of ARPA                                  Internet Text Messages 
  455.  
  456.    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. 
  457.  
  458. 821     Postel       Aug 82      Simple Mail Transfer Protocol 
  459.  
  460.    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 RFC 788, 780, and 772. 
  461.  
  462. 820     Postel       Jan 82      Assigned Numbers 
  463.  
  464.    This RFC is an old version, see RFC 870. 
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472. Postel & Westine                                               [page 14] 
  473.  
  474.  
  475.  RFC 899                                                         May 1984 
  476.  
  477.  819     Zaw-Sing Su  Aug 82      The Domain Naming Convention for                                  Internet User Applications 
  478.  
  479.    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. 
  480.  
  481. 818     Postel       Nov 82      The Remote User Telnet Service 
  482.  
  483.    This RFC is the specification of an application protocol.  Any host    that implements this application level service must follow this    protocol. 
  484.  
  485. 817     Clark        Jul 82      Modularity and Efficiency in Protocol                                  Implementation 
  486.  
  487.    This RFC will discuss some of the commonly encountered reasons why    protocol implementations seem to run slowly. 
  488.  
  489. 816     Clark        Jul 82      Fault Isolation and Recovery 
  490.  
  491.    This RFC describes the portion of fault isolation and recovery which    is the responsibility of the host. 
  492.  
  493. 815     Clark        Jul 82      IP Datagram Reassembly Algorithms 
  494.  
  495.    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. 
  496.  
  497. 814     Clark        Jul 82      Name, Addresses, Ports, and Routes 
  498.  
  499.    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. 
  500.  
  501. 813     Clark        Jul 82      Window and Acknowledgement Strategy in                                  TCP 
  502.  
  503.    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. 
  504.  
  505.  Postel & Westine                                               [page 15] 
  506.  
  507.  
  508.  RFC 899                                                         May 1984 
  509.  
  510.  812     Harrenstien   Mar 82     NICNAME/WHOIS 
  511.  
  512.    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. 
  513.  
  514. 811     Harrenstien   Mar 82      Hostnames Server 
  515.  
  516.    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. 
  517.  
  518. 810     Feinler      Mar 82      DoD Internet Host Table Specification 
  519.  
  520.    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. 
  521.  
  522. 809     Chang        Feb 82      UCL Facsimile System 
  523.  
  524.    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. 
  525.  
  526. 808     Postel       Mar 82      Summary of Computer Mail Services                                  Meeting Held at BBN on 10 January 1979 
  527.  
  528.    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. 
  529.  
  530. 807     Postel       Feb 82      Multimedia Mail Meeting Notes 
  531.  
  532.    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. 
  533.  
  534.  
  535.  
  536.  Postel & Westine                                               [page 16] 
  537.  
  538.  
  539.  RFC 899                                                         May 1984 
  540.  
  541.  806     NBS          Sep 81      Specification for Message Format for                                  Computer Based Message Systems 
  542.  
  543.    This RFC deals with Computer Based Message systems which provides a    basis for interaction between different CBMS by defining the format    of messages passed between them.  This RFC is replaced by RFC 841. 
  544.  
  545. 805     Postel       Feb 82      Computer Mail Meeting Notes 
  546.  
  547.    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. 
  548.  
  549. 804     CCITT        Jan 82      CCITT Draft Recommendation T.4 
  550.  
  551.    This is the CCITT standard for group 3 facsimile encoding.  This is    useful for data compression of bit map data. 
  552.  
  553. 803     Agarwal      Nov 81      Dacom 450/500 Facsimile Data                                  Transcoding 
  554.  
  555.    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. 
  556.  
  557. 802     Malis        Nov 81      The ARPANET 1822L Host Access Protocol 
  558.  
  559.    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. 
  560.  
  561. 801     Postel       Nov 81      NCP/TCP Transition Plan 
  562.  
  563.    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. 
  564.  
  565.  
  566.  
  567.  Postel & Westine                                               [page 17] 
  568.  
  569.  
  570.  RFC 899                                                         May 1984 
  571.  
  572.  800     Postel       Nov 82      Requests for Comments Summary 
  573.  
  574.    This RFC is a slightly annotated list of the 100 RFCs from RFC 700    through RFC 799.  This is a status report on these RFCs. 
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  Postel & Westine                                               [page 18] 
  623.  
  624.