rfc83.txt

RFC 的详细文档！

      To insert a literal, separate the left-hand-side terms for its
      insertion on the right.

         a(A:10),b(A:70)->(a),(E'LIT':3),(b)

      The 80 ASCII characters are emitted in the output area with the
      EBCDIC literal LIT inserted after the first 10 ASCII characters.

   Deletion

      Terms on the left are separated so that the right side may omit
      unwanted terms.

         (B:7),a(A:10)->(Ev(a):L(a))

      Only the 10 ASCII characters are emitted (as EBCDIC) in the output
      area, the 7 binary digits are discarded.

   Spacing in the Output Buffer

      Where a pre-formatted output buffer exists (typically a display
      buffer) spacing can be realized by omitting the replication and
      value functions from a term on the right.




Anderson, et. al.                                               [Page 7]

RFC 83                 Language Machine For Data        18 December 1970


         a(A:74)->(E:6),(Ev(a):74)

      The (E:6) causes 48 bit positions to be skipped over in the output
      area, then the 74 ASCII characters are converted to EBCDIC and
      emitted at the current output position.

   Arbitrary Lengths

      Some devices/programs generate a variable number of characters per
      line and it is desirable to produce fixed-length records from
      them.

         a(A:#) -> (Ev(a):74)

      The ASCII characters are truncated or padded as required and
      converted to EBCDIC in a 74 character field.

   Transposition

      Fields to be transposed should be isolated as terms on the left.

         a(X:2),b(A:#)->(Ev(b):L(b)),(a)

   String Length Computation

      Some formats require the string length as part of the data stream.
      This can be accomplished by the length function.

         a(E:10),b(X'FF':2)->(BL(a)+L(b)+8:8),(Av(a):L(a)),(b)

      The length term is emitted first, in a 8 bit field.  In this case
      the length includes the length field as well as the ASCII
      character field.

   Expansion and Compression of repeated Symbols

      The following rule packs repeated symbols.

         a(E:1), b(E#*v(a):L(b)) -> (BL(b)+1:8),(a)

      Given the input string below, three successive applications of the
      rule will emit the output string shown.

         Input: XXXXYYZZZZZZZ

         Output: 4X2Y7Z





Anderson, et. al.                                               [Page 8]

RFC 83                 Language Machine For Data        18 December 1970


   APPLICATION OF THE FORM MACHINE TO PROGRAM PROTOCOLS

   The Protocol Manager mentioned in NWG/RFC #80 needs several
   interesting features that are properties of the above Form Machine.

   In certain instances during a protocol dialog it might be acceptable
   to get either an accept on connection A or an allocation on connect
   B, that is, the order is sometimes unimportant.  The defined
   procedure for applying rules allows for order independence.

   A logger might send us a socket number embedded in a regular message
   -- the socket number is intended to be the first of a contiguous set
   of sockets that we can use to establish connections with some
   program.  We wish to extract the socket number field from the regular
   message, perhaps convert it to another format, and add to it to get
   the additional socket names.  As a result of the regular message we
   wish to emit several INIT system calls that include the socket
   numbers that we have computed.  The value operator and the arithmetic
   operators of the Form Machine can do this.

   A third property of the Form Machine that is applicable to protocols
   is inter- and intra-rule binding to resolve context sensitive
   information.  In general we wish rules to be order independent but in
   certain cases we wish to impose an ordering.  Using the logger in
   NWG/RFC #66 as an example, the close that is sent by the logger can
   have two different meanings depending upon its context.  If the close
   is sent before the regular message containing the socket number then
   it means call refused.  If the regular message precedes the close
   then the call is accepted.  Since the close has contextual meaning,
   we must bind it to the regular message to avoid introducing IF and
   THEN into the Form Machine language.

   Assume for a moment that we can express system calls in Form Machine
   notation.  (The notation below is for _illustration only_ and is not
   part of the Form Machine language.)  We have two ways to bind the
   regular message to the close.  By intra-rule binding we insist that
   the close be preceded by a regular message.

      Reg. Msg , Close ->

   Now assume for a moment that the remote party must have an echo after
   each transmission.  Since we must emit an echo after receiving the
   regular message and before the close is sent, then we must use
   inter-rule binding.  This can be accomplished with the programming
   variable.  It is assigned a value when the regular message is
   received and the value is tested when the close is received.

      Reg. Msg -> Echo , ([lambda]+1)



Anderson, et. al.                                               [Page 9]

RFC 83                 Language Machine For Data        18 December 1970


      Close, ([lambda]=1) ->

   To illustrate inter-rule binding via the programming variable the
   connection protocol in NWG/RFC #66 could be represented by passing
   the following form to a protocol manager.  (The notation below is for
   _illustration only_ and is not part of the Form Machine language).

      1. ->INIT(parameters) , ([alpha]<-0)

      Send an INIT(RTS).

      2.  INIT(parameters) -> ALLOCATE(parameters)

      Send an allocate in response to the connection completion (an STR
      received).

      3.  Reg. Msg (parameters) -> ([alpha]<-1)

      When the messages bearing link numbers is received, set an
      internal indicator.  (The extraction of the link is not
      illustrated.)

      4.  CLOSE(parameters),([alpha]=1) ->
                             INIT(parameters),INIT(parameters)

      When the close is received following the regular message [2] is
      checked to see that the regular message was received before
      establishing the duplex connection.  If the close is received with
      no regular message preceding it (call refused) the form will fail
      (since no rules is satisfied).

   This protocol can be handled via a single form containing four
   replacement rules.  We have examined similar representations for more
   complex protocol sequences.  Such protocol sequences, stored by name,
   are an asset to the user; he can request a predefined sequence to be
   executed automatically.















Anderson, et. al.                                              [Page 10]

RFC 83                 Language Machine For Data        18 December 1970


Two System Forms to Handle Protocol Statements

   Assume that we have a Protocol Manager that manages protocol
   sequences between consoles and the Network.  The consoles generate
   and accept EBCDIC character strings and the Network transmits binary
   digits.  The console user has a language similar to system calls in
   which he can create and store protocol sequences via Protocol
   Manager, and at the same time he can indicate which commands are
   expected to be sent and which are to be received.  Upon command the
   Protocol Manager can execute this sequence with the Network,
   generating commands and validating those received.  Assume also that
   the Protocol Manager displays the dialog for the console user as it
   progresses.

   In order to translate between console and Network for generating,
   comparing, and displaying commands, the Protocol Manager can use the
   Form Machine.  Two system forms are needed, see Fig. 1.  One is a
   console-to-Network set of rules containing EBCDIC to binary for all
   legal commands; the other is a mirror image for Network-to-console.

REQUEST

   Since language design is not our forte, we would like comments from
   those with more experience than we.



























Anderson, et. al.                                              [Page 11]

RFC 83                 Language Machine For Data        18 December 1970


                           System form:
                             C -> N
                           +----------+
                           | one rule |
                           | for each |
                           | legal    |
                           | command  |
                   +-------|- - - - - |<----+
                   |       +----------+     |
            Binary |                        | EBCDIC
                   |                        |
   +----------+    |                        |      +----------+
   |          |<---+                        +------|          |
   | Network  |                                    | Consoles |
   |          |----+                        +----->|          |
   +----------+    |                        |      +----------+
                   | Binary          EBCDIC |
                   |                        |
                   |                        |
                   |       System form:     |
                   |          N -> C        |
                   |       +----------+     |
                   +------>|- - - - - |-----+
                           | one rule |
                           | for each |
                           | legal    |
                           | response |
                           +----------+

   Figure 1 -- Application of System Form for Protocol Management





















Anderson, et. al.                                              [Page 12]

RFC 83                 Language Machine For Data        18 December 1970


Distribution List
-----------------

   Alfred Cocanower - MERIT
   Gerry Cole - SDC
   Les Earnest - Stanford
   Bill English - SRI
   James Forgie - Lincoln Laboratory
   Jennings Computer Center - Case
   Nico Haberman - Carnegie-Melon
   Robert Kahn - BB&N
   Peggy Karp - MITRE
   Benita Kirstel - UCLA
   Tom Lawrence - RADC/ISIM
   James Madden - University of Illinois
   George Mealy - Harvard
   Thomas O'Sullivan - Raytheon
   Larry Roberts - ARPA
   Ron Stoughton - UCSB
   Albert Vezza- MIT
   Barry Wessler - Utah



   [The original document included non-ASCII characters.  The Greek
   letters Alpha and Lambda have been spelled out and enclosed in
   square brackets "[ ]".  A curly "l" character
   has been replaced by capital L.  Left and right arrows have been
   replaced by "<-" and "->" respectively.  RFC-Editor]


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


















Anderson, et. al.                                              [Page 13]