rfc189.txt

RFC 的详细文档！

   and a CLS will be returned; in this case, try again or call the
   Technical Liaison.

   When RJS has output to send to a particular (virtual) terminal and a
   corresponding open output channel, it will send the output as a
   series of logical records using the protocol in Appendix A.  The
   first record will consist of the job name (8 characters) followed by
   a comma and then the ID string from the JOB card (if any).  In the
   printer stream, the first column of each record will be an ASA car-
   riage control character (see Appendix C); the punch output stream
   will never contain carriage control characters.

   NETRJS will send an End-of-Data transaction and then close an output
   channel at the end of the output for each complete batch job; the
   remote site must then send a new RFC (and ALL) to start output for
   another job.  This gives the remote site a chance to allocate a new
   file for each job without breaking the output within a job.  If the
   user at the remote site wants to cancel (or backspace or defer) the
   output of a particular job, he enters appropriate RJS commands on the
   operator input channel (see Appendix D).

   A virtual printer in NETRJS has 254 columns, exclusive of carriage
   control; RJS will send up to 255 characters of a logical record it
   finds in a SYSOUT data set.  If the user wishes to reject or fold
   records longer than some smaller record size, he can do so in his
   VRBT process.

   If RJS encounters a permanent I/O error in reading the disk data set,
   it will notify the user via his console, skip forward to the next set
   of system messages or SYSOUT data set in the same job, and continue.
   In the future, RJS may be changed to send a Lost Data marker within
   the data stream as well as a console message to the user.  In any
   case, the user will receive notification of termination of output
   data transfer for each job via messages on his console.



Braden                                                          [Page 7]

RFC 189              Interim NETRJS Specifications             July 1971


   If the user detects an error in the stream, he can issue a Backspace
   (BSP) command from his console to repeat the last "page" of output,
   or a Restart (RST) command to repeat from last SYSOUT data set or the
   beginning of the job, or he can abort the channel by closing his
   socket.  If he aborts the channel, RJS will simulate a Backspace com-
   mand, and when the user re-opens the channel the job will begin
   transmission again from an earlier point in the same data set.  This
   is true even if the user terminates the current session first, and
   re-opens the channel in a later session; RJS saves the state of its
   output streams.  However, before re-opening the channel he can defer
   this job for later output, restart it at the beginning, or cancel its
   output (see Appendix D).  Note that aborting the channel is only
   effective if RJS has not yet sent the End-of-Data transaction.

   If the user's process, NCP, or host, or the Network itself fails dur-
   ing an output operation, RJS will act as if the channel had been
   aborted and the user signed off.  In no case should a user lose out-
   put from NETRJS.

































Braden                                                          [Page 8]

RFC 189              Interim NETRJS Specifications             July 1971


                                Appendix A

                     Data Transfer Protocol in NETRJS


1. Introduction

   The records in the data transfer channels (for virtual card reader,
   printer, and punch) are generally grouped into _transactions_ pre-
   ceded by headers.  The transaction header includes a sequence number
   and the length of the transaction.  Network byte size must be 8 bits
   in these data streams.

   A transaction is the unit of buffering within the Model 91 software.
   Internal buffers are 880 bytes.  Therefore, CCN cannot transmit or
   receive a single transaction larger than 880 bytes.  Transactions can
   be as short as one record; however, those sites which are concerned
   with efficiency should send transactions as close as possible to the
   880 byte limit.

   There is no necessary connection between physical message boundaries
   and transactions ("logical messages"); the NCP can break the "logical
   message" arbitrarily into physical messages.  At CCN we will choose
   to have each logical message start a new physical message, so the NCP
   can send the last part of each message without waiting for an expli-
   cit request, but a remote site is not required to follow this conven-
   tion.

   Each logical record within a transaction begins with an "op code"
   byte which contains the channel identification, so its value is
   unique to each channel but constant within a channel.  This choice
   provides a convenient way to verify bit synchronization at the
   receiver, and also allows an extension in the future to true "multi-
   leaving" (i.e., multiplexing all channels within one connection in
   each direction).

   The only provisions for transmission error detection in the current
   NETRJS protocol are (1) this "op code" byte to verify bit synchroni-
   zation and (2) the transaction sequence number.  At the urging of
   Crowther, we favor putting an optional 16 bit check sum in the unused
   bytes of the second-level header.  It is currently assumed that if an
   error is detected then the channel is to be aborted and the entire
   transmission repeated.  To provide automatic retransmission we would
   have to put in reverse channels for ACK/NAK messages.







Braden                                                          [Page 9]

RFC 189              Interim NETRJS Specifications             July 1971


2. Character Sets

   For an ASCII VRBT, NETRJS will map ASCII in the card reader stream
   into EBCDIC, and re-map the printer stream to ASCII, by the following
   rules:

        1.  One-to-one mapping between the three ASCII characters | ~ \
            which are not in EBCDIC, and the three EBCDIC characters
            [vertical bar, not-sign and cent-sign] (respectively) which
            are not in ASCII.

        2.  The other six ASCII graphics not in EBCDIC will be
            translated on input to an EBCDIC question mark (?).

        3.  The ASCII control DC3 (the only one not in EBCDIC) will be
            mapped into and from the EBCDIC control TM.

        4.  The EBCDIC characters not in ASCII will be mapped in the
            printer stream into the ASCII question mark.

3. Meta-Notation

   The following description of the NETRJS data transfer protocol uses a
   formal notation derived from that proposed in RFC #31 by Bobrow and
   Sutherland.  (The NETRJS format is also shown diagramatically in
   Figure 2.)

   The derived notation is both concise and easily readable, and we
   recommend its use for Network documentation.  The notation consists
   of a series of productions for bit string variables whose names are
   capitalized.  Each variable name which represents a fixed length
   field is followed by the length in bits (e.g., SEQNUMB(16)).  Numbers
   enclosed in quotes are decimal, unless qualified by a leading X
   meaning hex.  Since each hex digit is 4 bits, the length is not shown
   explicitly in hex numbers.  For example, '1'(8) and X'FF' both
   represent a string of 8 one bits.  The meta-syntactic operators are:

           |       :alternative string
           [ ]     :optional string
           ( )     :grouping
           +       :catenation of bit strings

   The numerical value of a bit string (interpreted as an integer) is
   symbolized by a lower case identifier preceding the string expression
   and separated by a colon.  For example, in "i:FIELD(8)", i symbolizes
   the numeric value of the 8 bit string FIELD.





Braden                                                         [Page 10]

RFC 189              Interim NETRJS Specifications             July 1971


   Finally, we use Bobrow and Sutherland's symbolism for iteration of a
   sub-string:  (STRING-EXPRESSION = n); denotes n occurrences of STRING
   EXPRESSION, implicitly catenated together.  Here any n >= 0 is
   assumed unless n is explicitly restricted.


4. Protocol Definition

       STREAM <-- (TRANSACTION = n) + [END-OF-DATA]

   That is, STREAM, the entire sequence of data on a particular open
   channel, is a sequence of n TRANSACTIONS followed by an END-OF-DATA
   marker (omitted if the sender aborts the channel).

       TRANSACTION <-- THEAD(72) + (RECORD = r) + ('0'(1) = f)

   That is, a transaction consists of a 72 bit header, r records, and f
   filler bits.

       THEAD <-- X'FF' + f:FILLER(8) + SEQNUMB(16) + LENGTH(32) + X'00'

   Transactions are to be consecutively numbered in the SEQNUMB field,
   starting with 0 in the first transaction after the channel is (re-)
   opened.  The 32 bit LENGTH field gives the total length in bits of
   the r RECORD's which follow.  For convenience, the using site may add
   f additional filler bits at the end of the transaction to reach a
   convenient word boundary on his machine; the value f is also
   transmitted in the FILLER field of THEAD.

       RECORD <-- COMPRESSED | TRUNCATED

   RJS will accept intermixed RECORD's which are COMPRESSED or TRUNCATED
   in an input stream.  RJS will send one or the other format in the
   printer and punch streams to a given VRBT; the choice is determined
   when CCN establishes a terminal id.

       COMPRESSED  <--   '2'(2) + DEVID(6) + (STRING = p) + '0'(8)

       STRING      <--   ('6'(3) + i:DUPCOUNT(5))
                         This form represents a string of i
                         consecutive blanks

                         ('7'(3) + i:DUPCOUNT(5) + TEXTBYTE(8))
                         This form represents string of i consecutive
                         duplicated of TEXTBYTE.






Braden                                                         [Page 11]

RFC 189              Interim NETRJS Specifications             July 1971


                         ('2'(2) + j:LENGTH(6) + (TEXTBYTE(8) = j))
                         This form represents a string of j
                         characters.

   The first two alternatives above in the STRING production begin with
   count bytes chosen to be distinguishable from the (currently defined)
   Telnet control characters.  In a Telnet stream, the third count byte
   would not be needed.  This is irrelevant to the current NETRJS, but
   it would allow the use of compression within a Telnet data stream.

      TRUNCATED <-- '3'(2) + DEVID(6) + n:COUNT(8) + (TEXTBYTE(8) = n)

      DEVID(6)  <-- DEVNO(3) + t:DEVTYPE(3)

                    DEVID identifies a particular virtual device, i.e.,
                    it identifies a channel.  DEVTYPE specifies the type
                    of device, as follows:

                    t = 1:  Output to remote operator console
                        2:  Input from remote operator console
                        3:  Input from card reader
                        4:  Output to printer
                        5:  Output to card punch
                      6,7:  Unused

                    DEVNO(3) identifies the particular device of type t
                    at this remote site; at present only DEVNO = 0 is
                    possible.

      END-OF-DATA <-- X'FE'
                    Signals end of job (output) or job stack (input).




















Braden                                                         [Page 12]

RFC 189              Interim NETRJS Specifications             July 1971


                                APPENDIX B

                     Telnet for VRBT Operator Console

   The remote operator console connections use the ASCII Telnet
   protocol as in RFC #158.  Specifically:

    1)  The following one-to-one character mappings are used for the
        three EBCDIC graphics not in ASCII:

               ASCII
              in Telnet                NETRJS

                  |                  [vertical bar]
                  ~                  [not-sign]
                  \                  [cent-sign]

    2)  Initially all Telnet control characters will be ignored.  In the
        future we will implement the Telnet Break facility to allow a
        remote user to terminate extensive console output from a
        command.

    3)  An operator console input line which exceeds 133 characters
        (exclusive of CR LF) will be truncated by NETRJS.

    4)  NETRJS will accept BS to delete a character, and CAN to delete
        the current line.  The sequence CR LF terminates each input and
        output line.  HT will be translated to a single space in RJS.
        All other ASCII control characters will be ignored.  NETRJS will
        translate the six ASCII graphics with no equivalent in EBCDIC
        into the character question mark ("?") on input.