rfc80.txt

RFC 的详细文档！

      to communicate but do not speak the same language.

      One approach to the protocol and data format problems is to
      provide an adaptable mechanism that programs and terminals can use
      to easily access Network resources.  ARPA is sponsoring the
      Adaptive Communicator Project at Rand which is a research effort
      to investigate a teachable front-end process to interface man to
      program.  The variety of terminal devices being explored include
      voice, tablets, sophisticated graphics terminals, etc.

      The Adaptive Communicator looks very encouraging but it will not
      be ready for some time.  The Network Project at Rand chose to take
      the adaptable approach (_not_ adaptive, i.e., no heuristics, no
      self-learning).  Our problem is to get Rand researchers onto the
      Network easily, assuming that they have different simultaneous
      applications calling for different program protocols and data
      configurations.

      Protocols and data formats will be described separately to
      illustrate what we mean by adaptation.  Protocols are sequences of
      "system calls" that correspond to (and result in NCP's issuance
      of) NCP commands.  Data formats are the descriptions of regular
      message contents and are not meaningful to an NCP.




Harslem, et. al.                                                [Page 5]

RFC 80                 Protocols and Data Formats        1 December 1970


   The Form Machine (adapting to data formats)

      To put the reader in context, the Form Machine is of the class of
      finite state machines that recognize a form of _regular_
      expressions_ which, in our case, describe data formats.  The
      notation, however, is aimed at particular descriptions and
      therefore can be more succinct, for our purposes, than the
      language of regular expressions.

      The Form Machine is an experimental software package that couples
      a variety of programs and terminals whose data format requirements
      are different.  We envision Form Machines located (to reduce
      Network traffic) at various service providing Hosts.

      To test the Form Machine idea, we are implementing two IBM OS-
      callable subroutines; a compiler that compiles statements which
      describe forms of data formats; and an executor that executes a
      compiled form on a data stream.

      To describe the Form Machine test, it is necessary to mention
      another program at Rand--the Network Services Program (NSP), which
      is a multi-access program that interfaces the Network Control
      Program both to arbitrary programs and to Video Graphics Consoles.
      (We view a terminal as just another program with a different
      interface, i.e., # characters/line, # lines/page, unique hardware
      features, the application to which it is put, etc.)  The Form
      Machine subroutines are callable from NSP upon consoles or program
      direction.

      Operationally, a console user names and specifies the data forms
      that he will use.  The forms are compiled and stored for later
      use.  At some future time when the user wishes to establish
      Network connections and transmit data, he dynamically associates
      named forms with each side of a port--a symbolically named Network
      full duplex connection.  Data streams incoming or outgoing are
      executed according to the compiled form and the transformed data
      stream is then passed along to the console/program or to the
      Network, respectively.

      The details of the syntax of our Form Machine notation are
      unimportant to the collective Network community.  However, the
      provisions of the notation are of interest.  It will eventually
      encompass the description of high performance CRT displays, TTY,
      and arbitrary file structures.  To test its viability, a subset of
      such features is being implemented.






Harslem, et. al.                                                [Page 6]

RFC 80                 Protocols and Data Formats        1 December 1970


      The current version is characterized by the following features:

         1)    Character code translation (viz., decimal, octal,
               hexidecimal, 8 bit ASCII, 7 bit ASCII, EBCDIC, and
               binary).

         2)    Multiple break strings (many terminals have multiple
               termination signals).

         3)    Insertion of literals (used primarily for display
               information presentation).

         4)    Skip or delete arbitrary strings (used to remove record
               sequence numbers, etc., that are not to be displayed).

         5)    Record sequence number generation.

         6)    String-length computation and insertion.

         7)    _Arbitrary_ data string length specifications, e.g., "a
               hex literal string followed by an _arbitrary_ number of
               EBCDIC characters, followed by a break string, .....".

         8)    Concatenation of Network messages, i.e., the execution of
               compiled forms on incomplete data strings.

         9)    Data field transposition.

         10)   Both explicit and indefinite multiplicative factors for
               both single and multi-line messages.

      Features that are not being implemented but will be added, if
      successful, include:

         1)    Graphics oriented descriptions.

         2)    General number translations.

         3)    Conditional statements.

         4)    A pointer capability.

   The Protocol Manager (adapting to NCP command sequences)

      The NSP allows terminal users and programs to work at the NCP
      protocol level; i.e., LISTEN, INIT, et al.  It also allows them to
      transmit and massage information meaningful only to themselves.
      This "hands-on" approach is desirable from the systems



Harslem, et. al.                                                [Page 7]

RFC 80                 Protocols and Data Formats        1 December 1970


      programmer's, or exploratory point of view.  However, it is
      desirable to eliminate the laborious "handshaking" for the
      researcher who repeatedly uses a given remote program by allowing
      him to define, store, retrieve, and execute "canned" protocol
      sequences.

      We are currently specifying a Protocol Manager as a module of NSP
      that will allow the above operations on NCP command sequences.
      Features of the module are:

         1) The sequences may contain "break points" to permit the
            console user to dynamically inject any contextually needed
            information.

         2) The parameters of a command may contain tokens whose values
            are supplied by the remote party during the protocol dialog.
            For example, in Note #66 the socket number provided by the
            server is to be used by the user in subsequent RTS, STR
            commands.

   REQUEST

      We would like to hear from anyone concerning the notion of
      adaptation to data formats and protocol.  Is this a reasonable
      approach?  What should it encompass?

      JFH:EFH:hs
























Harslem, et. al.                                                [Page 8]

RFC 80                 Protocols and Data Formats        1 December 1970


   Distribution

      Albert Vezza, MIT
      Alfred Cocanower, MERIT
      Gerry Cole, SDC
      Bill English, SRI
      Bob Flegel, Utah
      James Forgie, LL
      Peggy Karp, MITRE
      Nico Haberman, Carnegie-Mellon
      John Heafner, RAND
      Bob Kahn, BB&N
      Margie Lannon, Harvard
      James Madden, Univ. of Ill.
      Thomas O'Sullivan, Raytheon
      Larry Roberts, ARPA
      Robert Sproull, Stanford
      Ron Stoughton, UCSB
      Chuck Rose, Case University
      Benita Kirstel, UCLA


           [This RFC was put into machine readable form for entry]
            [into the online RFC archives by Lorrie Shiota, 10/01]



























Harslem, et. al.                                                [Page 9]