home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2555.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  42.9 KB  |  1,012 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                 RFC Editor, et al.
  8. Request for Comments: 2555                                       USC/ISI
  9. Category: Informational                                     7 April 1999
  10.  
  11.  
  12.                             30 Years of RFCs
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard of any kind.  Distribution of this
  18.    memo is unlimited.
  19.  
  20. Copyright Notice
  21.  
  22.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  23.  
  24. Table of Contents
  25.  
  26.    1.  Introduction.................................................. 2
  27.    2.  Reflections................................................... 2
  28.    3.  The First Pebble: Publication of RFC 1........................ 3
  29.    4.  RFCs - The Great Conversation................................. 5
  30.    5.  Reflecting on 30 years of RFCs................................ 9
  31.    6.  Favorite RFCs -- The First 30 Years...........................14
  32.    7.  Security Considerations.......................................15
  33.    8.  Acknowledgments...............................................15
  34.    9.  Authors' Addresses............................................15
  35.    10. APPENDIX - RFC 1..............................................17
  36.    11. Full Copyright Statement......................................18
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. RFC Editor, et al.           Informational                      [Page 1]
  59.  
  60. RFC 2555                    30 Years of RFCs                7 April 1999
  61.  
  62.  
  63. 1. Introduction - Robert Braden
  64.  
  65.    Thirty years ago today, the first Request for Comments document,
  66.    RFC 1, was published at UCLA (ftp://ftp.isi.edu/in-notes/rfc1.txt).
  67.    This was the first of a series that currently contains more than 2500
  68.    documents on computer networking, collected, archived, and edited by
  69.    Jon Postel for 28 years.  Jon has left us, but this 30th anniversary
  70.    tribute to the RFC series is assembled in grateful admiration for his
  71.    massive contribution.
  72.  
  73.    The rest of this document contains a brief recollection from the
  74.    present RFC Editor Joyce K. Reynolds, followed by recollections from
  75.    three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-
  76.    range vision continues to guide us, and Jake Feinler who played a key
  77.    role in the middle years of the RFC series.
  78.  
  79. 2. Reflections - Joyce K. Reynolds
  80.  
  81.    A very long time ago when I was dabbling in IP network number and
  82.    protocol parameter assignments with Jon Postel, gateways were still
  83.    "dumb", the Exterior Gateway Protocol (EGP) was in its infancy and
  84.    TOPS-20 was in its heyday.  I was aware of the Request for Comments
  85.    (RFCs) document series, with Jon as the RFC Editor.  I really didn't
  86.    know much of the innerworkings of what the task entailed.  It was
  87.    Jon's job and he quietly went about publishing documents for the
  88.    ARPANET community.
  89.  
  90.    Meanwhile, Jon and I would have meetings in his office to go over our
  91.    specific tasks of the day.  One day, I began to notice that a pile of
  92.    folders sitting to one side of his desk seemed to be growing.  A few
  93.    weeks later the pile had turned into two stacks of folders.  I asked
  94.    him what they were.  Apparently, they contained documents for RFC
  95.    publication.  Jon was trying to keep up with the increasing quantity
  96.    of submissions for RFC publication.
  97.  
  98.    I mentioned to him one day that he should learn to let go of some of
  99.    his work load and task it on to other people.  He listened intently,
  100.    but didn't comment.  The very next day, Jon wheeled a computer stand
  101.    into my office which was stacked with those documents from his desk
  102.    intended for RFC publication.  He had a big Cheshire cat grin on his
  103.    face and stated, "I'm letting go!", and walked away.
  104.  
  105.    At the top of the stack was a big red three ring notebook.  Inside
  106.    contained the "NLS Textbook", which was prepared at ISI by Jon, Lynne
  107.    Sims and Linda Sato for use on ISI's TENEX and TOPS-20 systems.  Upon
  108.    reading its contents, I learned that the NLS system was designed to
  109.    help people work with information on a computer.  It included a wide
  110.    range of tools, from a simple set of commands for writing, reading
  111.  
  112.  
  113.  
  114. RFC Editor, et al.           Informational                      [Page 2]
  115.  
  116. RFC 2555                    30 Years of RFCs                7 April 1999
  117.  
  118.  
  119.    and printing documents to sophisticated methods for retrieving and
  120.    communication information.  NLS was the system Jon used to write,
  121.    edit and create the RFCs.  Thus began my indoctrination to the RFC
  122.    publication series.
  123.  
  124.    Operating systems and computers have changed over the years, but
  125.    Jon's perseverance about the consistency of the RFC style and quality
  126.    of the documents remained true.  Unfortunately, Jon did not live to
  127.    see the 30th Anniversary of this series that he unfailingly nurtured.
  128.    Yet, the spirit of the RFC publication series continues as we
  129.    approach the new millennium.  Jon would be proud.
  130.  
  131. 3. The First Pebble: Publication of RFC 1 - Steve Crocker
  132.  
  133.    RFC 1, "Host Software", issued thirty years ago on April 7, 1969
  134.    outlined some thoughts and initial experiments.  It was a modest and
  135.    entirely forgettable memo, but it has significance because it was
  136.    part of a broad initiative whose impact is still with us today.
  137.  
  138.    At the time RFC 1 was written, the ARPANET was still under design.
  139.    Bolt, Beranek and Newman had won the all-important contract to build
  140.    and operate the Interface Message Processors or "IMPs", the
  141.    forerunners of the modern routers.  They were each the size of a
  142.    refrigerator and cost about $100,000 in 1969 dollars.
  143.  
  144.    The network was scheduled to be deployed among the research sites
  145.    supported by ARPA's Information Processing Techniques Office (IPTO).
  146.    The first four nodes were to be at UCLA, SRI, University of
  147.    California, Santa Barbara and University of Utah.  The first
  148.    installation, at UCLA, was set for September 1, 1969.
  149.  
  150.    Although there had been considerable planning of the topology, leased
  151.    lines, modems and IMPs, there was little organization or planning
  152.    regarding network applications.  It was assumed the research sites
  153.    would figure it out.  This turned out to be a brilliant management
  154.    decision at ARPA.
  155.  
  156.    Previously, in the summer of 1968, a handful of graduate students and
  157.    staff members from the four sites were called together to discuss the
  158.    forthcoming network.  There was only a basic outline.  BBN had not
  159.    yet won the contract, and there was no technical specification for
  160.    the network's operation.  At the first meeting, we scheduled future
  161.    meetings at each of the other laboratories, thus setting the stage
  162.    for today's thrice yearly movable feast.  Over the next couple of
  163.    years, the group grew substantially and we found ourselves with
  164.    overflow crowds of fifty to a hundred people at Network Working Group
  165.    meetings.  Compared to modern IETF meetings all over the world with
  166.    attendance in excess of 1,000 people and several dozen active working
  167.  
  168.  
  169.  
  170. RFC Editor, et al.           Informational                      [Page 3]
  171.  
  172. RFC 2555                    30 Years of RFCs                7 April 1999
  173.  
  174.  
  175.    groups, the early Network Working Groups were small and tame, but
  176.    they seemed large and only barely manageable at the time.  One
  177.    tradition that doesn't seem to have changed at all is the spirit of
  178.    unrestrained participation in working group meetings.
  179.  
  180.    Our initial group met a handful of times in the summer and fall of
  181.    1968 and winter 1969.  Our earliest meetings were unhampered by
  182.    knowledge of what the network would look like or how it would
  183.    interact with the hosts.  Depending on your point of view, this
  184.    either allowed us or forced us to think about broader and grander
  185.    topics.  We recognized we would eventually have to get around to
  186.    dealing with message formats and other specific details of low-level
  187.    protocols, but our first thoughts focused on what applications the
  188.    network might support.  In our view, the 50 kilobit per second
  189.    communication lines being used for the ARPANET seemed slow, and we
  190.    worried that it might be hard to provide high-quality interactive
  191.    service across the network.  I wish we had not been so accurate!
  192.  
  193.    When BBN issued its Host-IMP specification in spring 1969, our
  194.    freedom to wander over broad and grand topics ended.  Before then,
  195.    however, we tried to consider the most general designs and the most
  196.    exciting applications.  One thought that captured our imagination was
  197.    the idea of downloading a small interpretative program at the
  198.    beginning of a session.  The downloaded program could then control
  199.    the interactions and make efficient use of the narrow bandwidth
  200.    between the user's local machine and the back-end system the user was
  201.    interacting with. Jeff Rulifson at SRI was the prime mover of this
  202.    line of thinking, and he took a crack at designing a Decode-Encode
  203.    Language (DEL) [RFC 5].  Michel Elie, visiting at UCLA from France,
  204.    worked on this idea further and published Proposal for a Network
  205.    Interchange Language (NIL) [RFC 51].  The emergence of Java and
  206.    ActiveX in the last few years finally brings those early ideas to
  207.    fruition, and we're not done yet.  I think we will continue to see
  208.    striking advances in combining communication and computing.
  209.  
  210.    I have already suggested that the early RFCs and the associated
  211.    Network Working Group laid the foundation for the Internet
  212.    Engineering Task Force.  Two all-important aspects of the early work
  213.    deserve mention, although they're completely evident to anyone who
  214.    participates in the process today.  First, the technical direction we
  215.    chose from the beginning was an open architecture based on multiple
  216.    layers of protocol.  We were frankly too scared to imagine that we
  217.    could define an all-inclusive set of protocols that would serve
  218.    indefinitely.  We envisioned a continual process of evolution and
  219.    addition, and obviously this is what's happened.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. RFC Editor, et al.           Informational                      [Page 4]
  227.  
  228. RFC 2555                    30 Years of RFCs                7 April 1999
  229.  
  230.  
  231.    The RFCs themselves also represented a certain sense of fear.  After
  232.    several months of meetings, we felt obliged to write down our
  233.    thoughts.  We parceled out the work and wrote the initial batch of
  234.    memos.  In addition to participating in the technical design, I took
  235.    on the administrative function of setting up a simple scheme for
  236.    numbering and distributing the notes.  Mindful that our group was
  237.    informal, junior and unchartered, I wanted to emphasize these notes
  238.    were the beginning of a dialog and not an assertion of control.
  239.  
  240.    It's now been thirty years since the first RFCs were issued.  At the
  241.    time, I believed the notes were temporary and the entire series would
  242.    die off in a year or so once the network was running.  Thanks to the
  243.    spectacular efforts of the entire community and the perseverance and
  244.    dedication of Jon Postel, Joyce Reynolds and their crew, the humble
  245.    series of Requests for Comments evolved and thrived.  It became the
  246.    mainstay for sharing technical designs in the Internet community and
  247.    the archetype for other communities as well.  Like the Sorcerer's
  248.    Apprentice, we succeeded beyond our wildest dreams and our worst
  249.    fears.
  250.  
  251. 4. RFCs - The Great Conversation - Vint Cerf
  252.  
  253.    A long time ago, in a network far, far away...
  254.  
  255.    Considering the movement of planet Earth around the Sun and the Sun
  256.    around the Milky Way galaxy, that first network IS far away in the
  257.    relativistic sense. It takes 200 million years for the Sun to make
  258.    its way around the galaxy, so thirty years is only an eyeblink on the
  259.    galactic clock. But what a marvelous thirty years it has been! The
  260.    RFCs document the odyssey of the ARPANET and, later, the Internet, as
  261.    its creators and netizens explore, discover, build, re-build, argue
  262.    and resolve questions of design, concepts and applications of
  263.    computer networking.
  264.  
  265.    It has been ultimately fascinating to watch the transformation of the
  266.    RFCs themselves from their earliest, tentative dialog form to today's
  267.    much more structured character. The growth of applications such as
  268.    email, bulletin boards and the world wide web have had much to do
  269.    with that transformation, but so has the scale and impact of the
  270.    Internet on our social and economic fabric. As the Internet has taken
  271.    on greater economic importance, the standards documented in the RFCs
  272.    have become more important and the RFCs more formal. The dialog has
  273.    moved to other venues as technology has changed and the working
  274.    styles have adapted.
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. RFC Editor, et al.           Informational                      [Page 5]
  283.  
  284. RFC 2555                    30 Years of RFCs                7 April 1999
  285.  
  286.  
  287.    Hiding in the history of the RFCs is the history of human
  288.    institutions for achieving cooperative work. And also hiding in that
  289.    history are some heroes that haven't been acknowledged.  On this
  290.    thirtieth anniversary, I am grateful for the opportunity to
  291.    acknowledge some of them. It would be possible to fill a book with
  292.    such names - mostly of the authors of the RFCs, but as this must be a
  293.    brief contribution, I want to mention four of them in particular:
  294.    Steve Crocker, Jon Postel, Joyce K. Reynolds and Bob Braden.
  295.  
  296.    Steve Crocker is a modest man and would likely never make the
  297.    observation that while the contents of RFC 1 might have been entirely
  298.    forgettable, the act of writing RFC 1 was indicative of the brave and
  299.    ultimately clear-visioned leadership that he brought to a journey
  300.    into the unknown. There were no guides in those days - computer
  301.    networking was new and few historical milestones prepared us for what
  302.    lay ahead. Steve's ability to accommodate a diversity of views, to
  303.    synthesize them into coherence and, like Tom Sawyer, to persuade
  304.    others that they wanted to devote their time to working on the
  305.    problems that lay in the path of progress can be found in the early
  306.    RFCs and in the Network Working Group meetings that Steve led.
  307.  
  308.    In the later work on Internet, I did my best to emulate the framework
  309.    that Steve invented: the International Network Working Group (INWG)
  310.    and its INWG Notes, the Internet Working Group and its Internet
  311.    Experiment Notes (IENs) were brazen knock-offs of Steve's
  312.    organizational vision and style.
  313.  
  314.    It is doubtful that the RFCs would be the quality body of material
  315.    they are today were it not for Jonathan Postel's devotion to them
  316.    from the start. Somehow, Jon knew, even thirty years ago that it
  317.    might be important to document what was done and why, to say nothing
  318.    of trying to capture the debate for the benefit of future networkers
  319.    wondering how we'd reached some of the conclusions we did (and
  320.    probably shake their heads...).
  321.  
  322.    Jon was the network's Boswell, but it was his devotion to quality and
  323.    his remarkable mix of technical and editing skills that permeate many
  324.    of the more monumental RFCs that dealt with what we now consider the
  325.    TCP/IP standards. Many bad design decisions were re-worked thanks to
  326.    Jon's stubborn determination that we all get it "right" - as the
  327.    editor, he simply would not let something go out that didn't meet his
  328.    personal quality filter. There were times when we moaned and
  329.    complained, hollered and harangued, but in the end, most of the time,
  330.    Jon was right and we knew it.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. RFC Editor, et al.           Informational                      [Page 6]
  339.  
  340. RFC 2555                    30 Years of RFCs                7 April 1999
  341.  
  342.  
  343.    Joyce K. Reynolds was at Jon's side for much of the time that Jon was
  344.    the RFC editor and as has been observed, they functioned in unison
  345.    like a matched pair of superconducting electrons - and
  346.    superconductors they were of the RFC series. For all practical
  347.    purposes, it was impossible to tell which of the two had edited any
  348.    particular RFC. Joyce's passion for quality has matched Jon's and
  349.    continues to this day. And she has the same subtle, puckish sense of
  350.    humor that emerged at unexpected moments in Jon's stewardship. One
  351.    example that affected me personally was Joyce's assignment of number
  352.    2468 to the RFC written to remember Jon.  I never would have thought
  353.    of that, and it was done so subtly that it didn't even ring a bell
  354.    until someone sent me an email asking whether this was a coincidence.
  355.    In analog to classical mystery stories, the editor did it.
  356.  
  357.    Another unsung hero in the RFC saga is Bob Braden - another man whose
  358.    modesty belies contributions of long-standing and monumental
  359.    proportions. It is my speculation that much of the quality of the
  360.    RFCs can be traced to consultations among the USC/ISI team, including
  361.    Jon, Joyce and Bob among others. Of course, RFC 1122 and 1123 stand
  362.    as two enormous contributions to the clarity of the Internet
  363.    standards. For that task alone, Bob deserves tremendous appreciation,
  364.    but he has led the End-to-End Research Group for many years out of
  365.    which has come some of the most important RFCs that refine our
  366.    understanding of optimal implementation of the protocols, especially
  367.    TCP.
  368.  
  369.    When the RFCs were first produced, they had an almost 19th century
  370.    character to them - letters exchanged in public debating the merits
  371.    of various design choices for protocols in the ARPANET. As email and
  372.    bulletin boards emerged from the fertile fabric of the network, the
  373.    far-flung participants in this historic dialog began to make
  374.    increasing use of the online medium to carry out the discussion -
  375.    reducing the need for documenting the debate in the RFCs and, in some
  376.    respects, leaving historians somewhat impoverished in the process.
  377.    RFCs slowly became conclusions rather than debates.
  378.  
  379.    Jon permitted publication of items other than purely technical
  380.    documents in this series. Hence one finds poetry, humor (especially
  381.    the April 1 RFCs which are as funny today as they were when they were
  382.    published), and reprints of valuable reference material mixed into
  383.    the documents prepared by the network working groups.
  384.  
  385.    In the early 1970s, the Advanced Research Projects Agency was
  386.    conducting several parallel research programs into packet switching
  387.    technology, after the stunning success of this idea in the ARPANET.
  388.    Among these were the Packet Radio Network, the Atlantic Packet
  389.    Satellite Network and the Internet projects. These each spawned note
  390.    series akin to but parallel to the RFCs. PRNET Notes, ARPA Satellite
  391.  
  392.  
  393.  
  394. RFC Editor, et al.           Informational                      [Page 7]
  395.  
  396. RFC 2555                    30 Years of RFCs                7 April 1999
  397.  
  398.  
  399.    System Notes (bearing the obvious and unfortunate acronym...),
  400.    Internet Experiment Notes (IENs), and so on. After the Internet
  401.    protocols were mandated to be used on the ARPANET and other DARPA-
  402.    sponsored networks in January 1983 (SATNET actually converted before
  403.    that), Internet- related notes were merged into the RFC series. For a
  404.    time, after the Internet project seemed destined to bear fruit, IENs
  405.    were published in parallel with RFCs. A few voices, Danny Cohen's in
  406.    particular (who was then at USC/ISI with Jon Postel) suggested that
  407.    separate series were a mistake and that it would be a lot easier to
  408.    maintain and to search a single series. Hindsight seems to have
  409.    proven Danny right as the RFC series, with its dedicated editors,
  410.    seems to have borne the test of time far better than its more
  411.    ephemeral counterparts.
  412.  
  413.    As the organizations associated with Internet continued to evolve,
  414.    one sees the RFCs adapting to changed circumstances. Perhaps the most
  415.    powerful influence can be seen from the evolution of the Internet
  416.    Engineering Task Force from just one of several task forces whose
  417.    chairpersons formed the Internet Activities Board to the dominant,
  418.    global Internet Standards development organization, managed by its
  419.    Internet Engineering Steering Group and operating under the auspices
  420.    of the Internet Society. The process of producing "standards-track"
  421.    RFCs is now far more rigorous than it once was, carries far more
  422.    impact on a burgeoning industry, and has spawned its own, relatively
  423.    informal "Internet Drafts" series of short-lived documents forming
  424.    the working set of the IETF working groups.
  425.  
  426.    The dialogue that once characterized the early RFCs has given way to
  427.    thrice-annual face-to-face meetings of the IETF and enormous
  428.    quantities of email, as well as a growing amount of group-interactive
  429.    work through chat rooms, shared white boards and even more elaborate
  430.    multicast conferences. The parallelism and the increasing quantity of
  431.    transient dialogue surrounding the evolution of the Internet has made
  432.    the task of technology historians considerably more difficult,
  433.    although one can sense a counter-balancing through the phenomenal
  434.    amount of information accumulating in the World Wide Web. Even casual
  435.    searches often turn up some surprising and sometimes embarrassing old
  436.    memoranda - a number of which were once paper but which have been
  437.    rendered into bits by some enterprising volunteer.
  438.  
  439.    The RFCs, begun so tentatively thirty years ago, and persistently
  440.    edited and maintained by Jon Postel and his colleagues at USC/ISI,
  441.    tell a remarkable story of exploration, achievement, and dedication
  442.    by a growing mass of internauts who will not sleep until the Internet
  443.    truly is for everyone. It is in that spirit that this remembrance is
  444.    offered, and in particular, in memory of our much loved colleague,
  445.    Jon Postel, without whose personal commitment to this archive, the
  446.    story might have been vastly different and not nearly as remarkable.
  447.  
  448.  
  449.  
  450. RFC Editor, et al.           Informational                      [Page 8]
  451.  
  452. RFC 2555                    30 Years of RFCs                7 April 1999
  453.  
  454.  
  455. 5. Reflecting on 30 years of RFCs - Jake Feinler
  456.  
  457.    By now we know that the first RFC was published on April 7, 1969 by
  458.    Steve Crocker.  It was entitled "Host Software".  The second RFC was
  459.    published on April 9, 1969 by Bill Duvall of SRI International (then
  460.    called Stanford Research Institute or SRI), and it too was entitled
  461.    "Host Software".  RFC 2 was a response to suggestions made in RFC 1-
  462.    -and so the dialog began.
  463.  
  464.    Steve proposed 2 experiments in RFC 1:
  465.  
  466.    "1)  SRI is currently modifying their on-line retrieval system which
  467.    will be the major software component of the Network Documentation
  468.    Center [or The SRI NIC as it soon came to be known] so that it can be
  469.    modified with Model 35 teletypes.  The control of the teletypes will
  470.    be written in DEL [Decode-Encode Language].  All sites will write DEL
  471.    compilers and use NLS [SRI Doug Engelbart's oNLine System] through
  472.    the DEL program".
  473.  
  474.    "2)  SRI will write a DEL front end for full NLS, graphics included.
  475.    UCLA and UTAH will use NLS with graphics".
  476.  
  477.    RFC 2, issued 2 days later, proposed detailed procedures for
  478.    connecting to the NLS documentation system across the network.  Steve
  479.    may think RFC 1 was an "entirely forgettable" document; however, as
  480.    an information person, I beg to differ with him.  The concepts
  481.    presented in this first dialog were mind boggling, and eventually led
  482.    to the kind of network interchange we are all using on the web today.
  483.    (Fortunately, we have graduated beyond DEL and Model 35 teletypes!)
  484.  
  485.    RFC 1 was, I believe, a paper document.  RFC 2 was produced online
  486.    via the SRI NLS system and was entered into the online SRI NLS
  487.    Journal.  However, it was probably mailed to each recipient via snail
  488.    mail by the NIC, as email and the File Transfer Protocol (FTP) had
  489.    not yet been invented.
  490.  
  491.    RFC 3, again by Steve Crocker, was entitled, "Documentation
  492.    Conventions;" and we see that already the need for a few ground rules
  493.    was surfacing. More ground-breaking concepts were introduced in this
  494.    RFC.  It stated that:
  495.  
  496.    "The Network Working Group (NWG) is concerned with the HOST software,
  497.    the strategies for using the network, and the initial experiments
  498.    with the network.  Documentation of the NWG's effort is through notes
  499.    such as this.  Notes may be produced at any site by anybody and
  500.    included in this series".
  501.  
  502.  
  503.  
  504.  
  505.  
  506. RFC Editor, et al.           Informational                      [Page 9]
  507.  
  508. RFC 2555                    30 Years of RFCs                7 April 1999
  509.  
  510.  
  511.    It goes on to say:
  512.  
  513.    "The content of a NWG note may be any thought, suggestion,
  514.    etc.related to the Host software or other aspect of the network.
  515.    Notes are encouraged to be timely rather than polished.
  516.    Philosophical positions without examples or other specifics, specific
  517.    suggestions or implementation techniques without introductory or
  518.    background explanation, and explicit questions without any attempted
  519.    answers are all acceptable.  The minimum length for a NWG note is one
  520.    sentence".
  521.  
  522.    "These standards (or lack of them) are stated explicitly for two
  523.    reasons.  First, there is a tendency to view a written statement as
  524.    discussion of considerably less than authoritative ideas.  Second,
  525.    there is a natural hesitancy to publish something unpolished, and we
  526.    hope to ease this inhibition".
  527.  
  528.    Steve asked that this RFC be sent to a distribution list consisting
  529.    of:
  530.  
  531.         Bob Kahn, BBN
  532.         Larry Roberts, ARPA
  533.         Steve Carr, UCLA
  534.         Jeff Rulifson, UTAH
  535.         Ron Stoughton, UCSB
  536.         Steve Crocker, UCLA
  537.  
  538.    Thus by the time the third RFC was published, many of the concepts of
  539.    how to do business in this new networking environment had been
  540.    established--there would be a working group of implementers (NWG)
  541.    actually discussing and trying things out; ideas were to be free-
  542.    wheeling; communications would be informal; documents would be
  543.    deposited (online when possible) at the NIC and distributed freely to
  544.    members of the working group; and anyone with something to contribute
  545.    could come to the party.  With this one document a swath was
  546.    instantly cut through miles of red tape and pedantic process.  Was
  547.    this radical for the times or what!  And we were only up to RFC 3!
  548.  
  549.    Many more RFCs followed and the SRI NLS Journal became the
  550.    bibliographic search service of the ARPANET.  It differed from other
  551.    search services of the time in one important respect:  when you got a
  552.    "hit" searching the journal online, not only did you get a citation
  553.    telling you such things as the author and title; you got an
  554.    associated little string of text called a "link".  If you used a
  555.    command called "jump to link",  voila!  you got the full text of the
  556.    document.  You did not have to go to the library, or send an order
  557.    off to an issuing agency to get a copy of the document, as was the
  558.    custom with other search services of the time.  The whole document
  559.  
  560.  
  561.  
  562. RFC Editor, et al.           Informational                     [Page 10]
  563.  
  564. RFC 2555                    30 Years of RFCs                7 April 1999
  565.  
  566.  
  567.    itself was right there immediately!
  568.  
  569.    Also, any document submitted to the journal could not be changed.
  570.    New versions could be submitted, and these superceded old versions,
  571.    but again the new versions could not be changed.  Each document was
  572.    given a unique identifying number, so it was easy to track.  These
  573.    features were useful in a fast-moving environment.  Documents often
  574.    went through several drafts before they were finally issued as an RFC
  575.    or other official document, and being able to track versions was very
  576.    useful.
  577.  
  578.    The SRI NLS Journal was revolutionary for the time; however, access
  579.    to it online presented several operational problems.  Host computers
  580.    were small and crowded, and the network was growing by leaps and
  581.    bounds; so connections had to be timed out and broken to give
  582.    everyone a chance at access.  Also, the rest of the world was still a
  583.    paper world (and there were no scanners or laser printers, folks!),
  584.    so the NIC still did a brisk business sending out paper documents to
  585.    requestors.
  586.  
  587.    By 1972 when I became Principal Investigator for the NIC project, the
  588.    ARPANET was growing rapidly, and more and more hosts were being
  589.    attached to it.  Each host was required to have a technical contact
  590.    known as the Technical Liaison, and most of the Liaison were also
  591.    members of the NWG.  Each Liaison was sent a set of documents by the
  592.    NIC called "functional documents" which included the Protocol
  593.    Handbook (first issued by BBN and later published by the NIC.)  The
  594.    content of the Protocol Handbook was made up of key RFCs and a
  595.    document called "BBN 1822" which specified the Host-to-Imp protocol.
  596.  
  597.    The NWG informed the NIC as to which documents should be included in
  598.    the handbook; and the NIC assembled, published, and distributed the
  599.    book. Alex McKenzie of BBN helped the NIC with the first version of
  600.    the handbook, but soon a young fellow, newly out of grad school,
  601.    named Jon Postel joined the NWG and became the NIC's contact and
  602.    ARPA's spokesperson for what should be issued in the Protocol
  603.    Handbook.
  604.  
  605.    No one who is familiar with the RFCs can think of them without
  606.    thinking of Dr. Jonathan Postel.  He was "Mister RFC" to most of us.
  607.    Jon worked at SRI in the seventies and had the office next to mine.
  608.    We were both members of Doug Engelbart's Augmentation Research
  609.    Center.  Not only was Jon a brilliant computer scientist, he also
  610.    cared deeply about the process of disseminating information and
  611.    establishing a methodology for working in a networking environment.
  612.    We often had conversations way into the wee hours talking about ways
  613.    to do this "right".  The network owes Jon a debt of gratitude for his
  614.    dedication to the perpetuation of the RFCs.  His work, along with
  615.  
  616.  
  617.  
  618. RFC Editor, et al.           Informational                     [Page 11]
  619.  
  620. RFC 2555                    30 Years of RFCs                7 April 1999
  621.  
  622.  
  623.    that of his staff, the NWG, the IETF, the various NICs, and CNRI to
  624.    keep this set of documents viable over the years was, and continues
  625.    to be, a labor of love.
  626.  
  627.    Jon left SRI in 1976 to join USC-ISI, but by that time the die was
  628.    cast, and the RFCs, NWG, Liaison, and the NIC were part of the
  629.    network's way of doing business. However, the SRI NLS Journal system
  630.    was becoming too big for its host computer and could not handle the
  631.    number of users trying to access it.  Email and FTP had been
  632.    implemented by now, so the NIC developed methodology for delivering
  633.    information to users via distributed information servers across the
  634.    network.  A user could request an RFC by email from his host computer
  635.    and have it automatically delivered to his mailbox.  Users could also
  636.    purchase hardcopy subscriptions to the RFCs and copies of the
  637.    Protocol Handbook, if they did not have network access.
  638.  
  639.    The NIC worked with Jon, ARPA, DCA, NSF, other NICs, and other
  640.    agencies to have secondary reference sets of RFCs easily accessible
  641.    to implementers throughout the world.  The RFCs were also shared
  642.    freely with official standards bodies, manufacturers and vendors,
  643.    other working groups, and universities.  None of the RFCs were ever
  644.    restricted or classified.  This was no mean feat when you consider
  645.    that they were being funded by DoD during the height of the Cold War.
  646.  
  647.    Many of us worked very hard in the early days to establish the RFCs
  648.    as the official set of technical notes for the development of the
  649.    Internet.  This was not an easy job.  There were suggestions for many
  650.    parallel efforts and splinter groups.  There were naysayers all along
  651.    the way because this was a new way of doing things, and the ARPANET
  652.    was "coloring outside the lines" so to speak.  Jon, as Editor-in-
  653.    Chief was criticized because the RFCs were not issued by an
  654.    "official" standards body, and the NIC was criticized because it was
  655.    not an "official" document issuing agency.  We both strived to marry
  656.    the new way of doing business with the old, and fortunately were
  657.    usually supported by our government sponsors, who themselves were
  658.    breaking new ground.
  659.  
  660.    Many RFCs were the end result of months of heated discussion and
  661.    implementation.  Authoring one of them was not for the faint of
  662.    heart.  Feelings often ran high as to what was the "right" way to go.
  663.    Heated arguments sometimes ensued.  Usually they were confined to
  664.    substance, but sometimes they got personal.  Jon would often step in
  665.    and arbitrate.  Eventually the NWG or the Sponsors had to say, "It's
  666.    a wrap.  Issue a final RFC".  Jon, as Editor-in-Chief of the RFCs,
  667.    often took merciless flak from those who wanted to continue
  668.    discussing and implementing, or those whose ideas were left on the
  669.    cutting room floor.  Somehow he always managed to get past these
  670.    controversies with style and grace and move on.  We owe him and
  671.  
  672.  
  673.  
  674. RFC Editor, et al.           Informational                     [Page 12]
  675.  
  676. RFC 2555                    30 Years of RFCs                7 April 1999
  677.  
  678.  
  679.    others, who served on the NWG or authored RFCs, an extreme debt of
  680.    gratitude for their contributions and dedication.
  681.  
  682.    At no time was the controversy worse than it was when DoD adopted
  683.    TCP/IP as its official host-to-host protocols for communications
  684.    networks.  In March 1982, a military directive was issued by the
  685.    Under Secretary of Defense, Richard DeLauer.  It simply stated that
  686.    the use of TCP and IP was mandatory for DoD communications networks.
  687.    Bear in mind that a military directive is not something you discuss -
  688.    the time for discussion is long over when one is issued.  Rather a
  689.    military directive is something you DO.  The ARPANET and its
  690.    successor, the Defense Data Network, were military networks, so the
  691.    gauntlet was down and the race was on to prove whether the new
  692.    technology could do the job on a real operational network.  You have
  693.    no idea what chaos and controversy that little 2-page directive
  694.    caused on the network.  (But that's a story for another time.)
  695.    However, that directive, along with RFCs 791 and 793 (IP and TCP)
  696.    gave the RFCs as a group of technical documents stature and
  697.    recognition throughout the world.  (And yes, TCP/IP certainly did do
  698.    the job!)
  699.  
  700.    Jon and I were both government contractors, so of course followed the
  701.    directions of our contracting officers.  He was mainly under contract
  702.    to ARPA, whereas the NIC was mainly under contract to DCA.  BBN was
  703.    another key contractor.  For the most part we all worked as a team.
  704.    However, there was frequent turnover in military personnel assigned
  705.    to both the ARPANET and the DDN, and we all collaborated to try to
  706.    get all the new participants informed as to what was available to
  707.    them when they joined the network.  We also tried to foster
  708.    collaboration rather than duplication of effort, when it was
  709.    appropriate.  The NWG (or IETF as it is now known) and the RFCs
  710.    became the main vehicles for interagency collaboration as the DoD
  711.    protocols began to be used on other government, academic, and
  712.    commercial networks.
  713.  
  714.    I left SRI and the NIC project in 1989.  At that time there were
  715.    about 30,000 hosts on what was becoming known as the Internet, and
  716.    just over a 1000 RFCs had been issued.  Today there are millions of
  717.    hosts on the Internet, and we are well past the 3000 mark for RFCs.
  718.    It was great fun to be a part of what turned out to be a
  719.    technological revolution.   It is heartwarming to see that the RFCs
  720.    are still being issued by the IETF, and that they are still largely
  721.    based on ideas that have been discussed and implemented; that the
  722.    concepts of online working groups and distributed information servers
  723.    are a way of life; that those little "links" (officially known as
  724.    hypertext) have revolutionized the delivery of documents; and that
  725.    the government, academia, and business are now all playing the same
  726.    game for fun and profit.  (Oh yes, I'm happy to see that Steve's idea
  727.  
  728.  
  729.  
  730. RFC Editor, et al.           Informational                     [Page 13]
  731.  
  732. RFC 2555                    30 Years of RFCs                7 April 1999
  733.  
  734.  
  735.    for integrated text and graphics has finally come to fruition,
  736.    although that work took a little longer than 2 days.)
  737.  
  738. 6. Favorite RFCs -- The First 30 Years - Celeste Anderson
  739.  
  740.    Five years ago, Jon Postel and I had wanted to publish a 25th RFC
  741.    anniversary book, but, alas, we were both too busy working on other
  742.    projects.  We determined then that we should commemorate the
  743.    thirtieth anniversary by collecting together thirty "RFC Editors'
  744.    Choice" RFCs based on original ideas expressed throughout the first
  745.    30 years of their existence.
  746.  
  747.    Jon's untimely death in October 1998 prevented us from completing
  748.    this goal.  We did, however, start to put online some of the early
  749.    RFCs, including RFC 1.  We weren't sure whether we were going to try
  750.    to make them look as close to the typewritten originals as possible,
  751.    or to make a few adjustments and format them according to the latest
  752.    RFC style.  Those of you who still have your copies of RFC 1 will
  753.    note the concessions we made to NROFF the online version.  The hand-
  754.    drawn diagrams of the early RFCs also present interesting challenges
  755.    for conversion into ASCII format.
  756.  
  757.    There are still opportunities to assist the RFC Editor to put many of
  758.    the early RFCs online.  Check the URL:
  759.    http://www.rfc-editor.org/rfc-online.html for more information on this
  760.    project.
  761.  
  762.    In memory of Jon, we are compiling a book for publication next year
  763.    of "Favorite RFCs -- The First 30 Years".
  764.  
  765.    We have set up a web interface at
  766.  
  767.            http://www.rfc-editor.org/voterfc.html
  768.  
  769.    for tabulating votes and recording the responses.  We will accept
  770.    email as well.  Please send your email responses to: voterfc@isi.edu.
  771.    We prefer votes accompanied by explanations for the vote choice.
  772.  
  773.    We reserve the right to add to the list several RFCs that Jon Postel
  774.    had already selected for the collection.  Voting closes December 31,
  775.    1999.
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. RFC Editor, et al.           Informational                     [Page 14]
  787.  
  788. RFC 2555                    30 Years of RFCs                7 April 1999
  789.  
  790.  
  791. 7. Security Considerations
  792.  
  793.    Security issues are not discussed in this commemorative RFC.
  794.  
  795. 8. Acknowledgments
  796.  
  797.    Thank you to all the authors who contributed to this RFC on short
  798.    notice.  Thanks also to Fred Baker and Eve Schooler who goaded us
  799.    into action.  A special acknowledgment to Eitetsu Baumgardner, a
  800.    student at USC, who NROFFed this document and who assisted in the
  801.    formatting of RFCs 1, 54, and 62, converting hand-drawn diagrams into
  802.    ASCII format.
  803.  
  804. 9. Authors' Addresses
  805.  
  806.    Robert Braden
  807.    USC/Information Sciences Institute
  808.    4676 Admiralty Way #1001
  809.    Marina del Rey, CA 90292
  810.  
  811.    Phone:  +1 310-822-1511
  812.    Fax:    +1 310 823 6714
  813.    EMail:  braden@isi.edu
  814.  
  815.  
  816.    Joyce K. Reynolds
  817.    USC/Information Sciences Institute
  818.    4676 Admiralty Way #1001
  819.    Marina del Rey, CA 90292
  820.  
  821.    Phone:  +1 310-822-1511
  822.    Fax:    +1 310-823-6714
  823.    EMail:  jkrey@isi.edu
  824.  
  825.  
  826.    Steve Crocker
  827.    Steve Crocker Associates, LLC
  828.    5110 Edgemoor Lane
  829.    Bethesda, MD 20814
  830.  
  831.    Phone:   +1 301-654-4569
  832.    Fax:     +1 202-478-0458
  833.    EMail:   crocker@mbl.edu
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. RFC Editor, et al.           Informational                     [Page 15]
  843.  
  844. RFC 2555                    30 Years of RFCs                7 April 1999
  845.  
  846.  
  847.    Vint Cerf
  848.    MCI
  849.  
  850.    EMail: vcerf@mci.net
  851.  
  852.  
  853.    Jake Feinler
  854.    SRI Network Information Center
  855.    1972-1989
  856.  
  857.    EMail: feinler@juno.com
  858.  
  859.  
  860.    Celeste Anderson
  861.    USC/Information Sciences Institute
  862.    4676 Admiralty Way #1001
  863.    Marina del Rey, CA 90292
  864.  
  865.    Phone:  +1 310-822-1511
  866.    Fax:    +1 310-823-6714
  867.    EMail:  celeste@isi.edu
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. RFC Editor, et al.           Informational                     [Page 16]
  899.  
  900. RFC 2555                    30 Years of RFCs                7 April 1999
  901.  
  902.  
  903. 10. APPENDIX - RFC 1
  904.  
  905.    The cover page said at the top:
  906.  
  907.      "Network Working Group
  908.       Request for Comments"
  909.  
  910.    and then came an internal UCLA distribution list:
  911.  
  912.      V. Cerf, S. Crocker, M. Elie, G. Estrin, G. Fultz, A. Gomez,
  913.      D. Karas, L. Kleinrock, J. Postel, M. Wingfield, R. Braden,
  914.      and W. Kehl.
  915.  
  916.    followed by an "Off Campus" distribution list:
  917.  
  918.      A. Bhushan (MIT), S. Carr (Utah), G. Cole (SDC), W. English (SRI),
  919.      K. Fry (Mitre), J. Heafner (Rand), R. Kahn (BBN), L. Roberts (ARPA),
  920.      P. Rovner (MIT), and R. Stoughton (UCSB).
  921.  
  922.    The following title page had
  923.  
  924.      "Network Working Group
  925.       Request for Comments: 1"
  926.  
  927.    at the top, and then:
  928.  
  929.                HOST SOFTWARE
  930.  
  931.                STEVE CROCKER
  932.                7 APRIL 1969
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. RFC Editor, et al.           Informational                     [Page 17]
  955.  
  956. RFC 2555                    30 Years of RFCs                7 April 1999
  957.  
  958.  
  959. 11. Full Copyright Statement
  960.  
  961.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  962.  
  963.    This document and translations of it may be copied and furnished
  964.    to others, and derivative works that comment on or otherwise
  965.    explain it or assist in its implementation may be prepared, copied,
  966.    published and distributed, in whole or in part, without
  967.    restriction of any kind, provided that the above copyright notice
  968.    and this paragraph are included on all such copies and derivative
  969.    works.  However, this document itself may not be modified in any
  970.    way, such as by removing the copyright notice or references to the
  971.    Internet Society or other Internet organizations, except as needed
  972.    for the purpose of developing Internet standards in which case the
  973.    procedures for copyrights defined in the Internet Standards
  974.    process must be followed, or as required to translate it into
  975.    languages other than English.
  976.  
  977.    The limited permissions granted above are perpetual and will not
  978.    be revoked by the Internet Society or its successors or assigns.
  979.  
  980.    This document and the information contained herein is provided on
  981.    an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
  982.    ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
  983.    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
  984.    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  985.    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  986.  
  987.  
  988.  
  989.  
  990.  
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. RFC Editor, et al.           Informational                     [Page 18]
  1011.  
  1012.