rfc283.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 489 行 · 第 1/2 页

NETWORK WORKING GROUP                                         R. T. BRADEN
REQUEST FOR COMMENTS #283                                     UCLA/CCN
NIC #8165                                                     DECEMBER 20, 1971
CATEGORIES: D
OBSOLETES: NONE
UPDATES: RFC #189

             NETRJT -- Remote Job Service Protocol for TIPS
             ----------------------------------------------

A.  INTRODUCTION
    ------------

 TIP's have very limited processing capability; their function is
mainly limited to interfacing printer-keyboard devices to the Network
using TELNET protocol. It will also be possible to have a tape drive
on a TIP, using a subset of the count form of DTP (see RFC #264).
However, TIP's cannot and will not support either DTP or FTP (see RFC
#265) in general. Therefore, TIP users are excluded from using any
existing remote job entry protocol (e.g. CCN's NETRJS - see RFC #189).

 It appears, however, that it may be feasible in the future to use
TIP's for remote job entry in one or more of the following three ways:

 (a)  Attach local card readers, line printers, and card punches
      directly to TIP ports. These devices would use a TELNET-like*
      format and frame their characters with Start/Stop bits.  BBN
      can now supply a suitable 200 LPM printer, and is searching for
      suitable readers and punches.

 (b)  Connect a remote batch terminal to a full-duplex TIP port via
      a communication line. BBN is looking into this.

 (c)  Use the tape drive, and do card-to-tape and/or tape-to-print
      on another computer.

 BBN hopes to make case (b) look exactly like (a) to the server host.
That is, the remote batch terminal will send to and receive from the
server in a TELNET-like format*; the printer, card reader, punch, and
operator console connections will all use different sockets but one
hardware port at the TIP, which will map multiple sockets into the one
port.

NOTE:  By "TELNET-like format", we mean: (a) _CR_LF_ used to delimit
       logical records (lines or cards), and (b) the ASCII or EBCDIC
       format effector control characters used for carriage control
       in the printer stream. It does _not_ necessarily imply ASCII
       character codes.



                                                                [Page 1]

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                   12/96   ]

 This document describes NETRJT, a modification of CCN's NETRJS
protocol specifically to provide remote job entry service to TIP's
using one of the methods (a), (b), or (c). NETRJT follows the general
model of NETRJS: use TELNET protocol over a primary or "operator"
connection pair, and open simplex secondary connections for data
transfer of job stream input and output. (We also considered the
possibility of using the Divert Output mechanism of the TIP for
sending remote job output over the operator connection, and an
analogous mechanism for input.  However, in discussion with Alex
McKenzie, it was agreed that sharing the operator connections has
little merit and causes lots of problems).

  NETRJT differs in two principal ways from NETRJS:

   1.  The NETRJT server process initiates the data transfer
       connections, under control of commands from the remote
       operator console. On the other hand, under NETRJS the
       remote user process has responsibility for initiating
       the opening of secondary data transfer connections; the
       NETRJS server simply listens on these sockets.

   2.  NETRJT provides the TELNET-like format defined above for
       data transfer, as well as the TIP-tape DTP format. NETRJS,
       on the other hand, is restricted to counts to delimit logical
       records within DTP-like transactions, and ASA carriage control.

 There are some other minor differences. For example, (1) the NETRJT
server takes responsibility for folding output records when they
exceed a size specified by a user command; under NETRJS, this was the
user process' responsibility. (2) There are NETRJT operator commands
to set the record format, record size, and code for each data transfer
connection. NETRJS made the first two fixed properties of a particular
terminal id, and deter- mined the last by the choice of ICP socket.
These differences imply remote operator commands in NETRJT in addition
to those of NETRJS. The operator must be able to (1) cause NETRJT to
open a secondary connection to a TIP socket, and (2) specify the data
transfer protocol, maximum logical record length, and/or transmission
code. These NETRJT commands are discussed in the following section.

 CCN plans to proceed with implementation of a NETRJT server with the
goal of completing an initial version by March 15, 1972. This initial
version may support only DTP=BS or TT, and RECFM=TELNET or RECORDS;
other options will be added as the need arises. We welcome comments
and suggestions.



                                                                [Page 2]

In the longer term, we believe that the NETRJT protocol described
here should be considered as the first draft of a Network standard for
remote job entry via TIP's. In its present form, NETRJT owes much to
the ideas and comments of Alex McKenzie (BBN), Jon Postel (NMC), Jim
White (UCSB), and Steve Wolfe (CCN).

B.  NETRJT COMMANDS
    ---------------

 NETRJT provides the following commands over the remote operator
connection, in addition to the NETRJS operator commands (see Appendix
D of RFC #189). The symbol "#" denotes one or more spaces.  We will
use the IBM meta-language to describe the command syntax. The literal
text shown here in upper case may, in fact, be entered in either upper
or lower case.

   1. Opening a Stream
      ----------------

               /            \           
               | PR [INTER] |  _         _
               |            | |           |
    O [PEN] # <  PU [NCH]    >| (jobname) | [ =socket-number[ /host-name ]]
               |            | |           |
               | R  [EADER] | |   (*)     |
               \            / |_         _|


 If the specified device does not already have an open connection, the
NETRJT server will request connection to the specified socket. The
optional "(jobname)" para- meter is used to specify a particular job
by name; for more information on the semantics of this parameter, see
the discussion of input and output operations below. The "/host-name"
parameter, to be implemented later, is intended to allow the file to
be at a host different from both user and server hosts. We include it
here only to suggest a syntax.

 The socket number may have a one-letter suffix D, H, or O to mean
decimal, hex, or octal. Octal is the default, so the O suffix may be
omitted.  If BBN establishes standardized TIP sockets for specific
unit record devices, the socket number parameter could be omitted when
the standard socket number is intended.










                                                                [Page 3]

   2. Closing a Stream
      ----------------

                _            _
               | # PR [INTER] |
               |              |
      CL [OSE] | # PU [NCH]   | [,A [CCEPT]]
               |              |
               | # R  [EADER] |
               |_            _|


 This command closes the specified data transfer connection.  The
ACCEPT option is used to signal the server that it may discard output
it has transmitted, or that it has received a complete stack of job
input. See discussion in next section.  The device specification (PR,
PU, or R) may be omitted if only one device stream is currently open.


   3. Setting Format and Device Characteristics
      -----------------------------------------

 In each of the following variants of the RJT commands, the parameter
"device" is one of "PR [INTER]", "PU [NCH]", or "R [EADER]".
                               /        \
      RJT # D [TP] (device) = <  B [S]   >
                               | T [T]  |
                               | D [TP] |
                               \        /

   BS:  an unstructured byte stream.

   TT:  the TIP-tape transfer protocol (essentially
        the count form of Network DTP).

  DTP:  the Network standard DTP, complete with a modes-
        available handshake. This form is not useful
        for TIP's but is included here in anticipation
        of the general Network standard RJE protocol.

                                 /               \
      RJT # R [ECFM] (device) = <  T [ELNET]      >
                                 | A [SA]        |
                                 | R [ECORDS]    |
                                 | C [OMPRESSED] |
                                 \               /








                                                                [Page 4]

The following choice of options is tentative, as it is presently
unclear just what record formats will be useful for TIP tapes or
remote batch terminals connected to TIP's.

      TELNET:   the "TELNET-like format": _CR_LF_ used to delimit
                logical records in all streams, and format effector
                control characters (_CR_, _LF_, _FF_) for printer
                carriage control.

         ASA:   CRLF used to delimit logical records, but an ASA
                carriage control character is sent as the first
                character of each printer record. (This option
                may be useful for remote batch terminals which
                expect ASA carriage control).

     RECORDS:   the "truncated" format of NETRJS: an id byte, a
                count byte, and then the string, with ASA carriage
                control in each printer record.

  COMPRESSED:   the "compressed" format of NETRJS (see RFC #189 for
                details). (Compression will be useful for batch
                terminals connected remotely to Tip's) .