RFC 327

Data and File Transfer workshop notes

๐Ÿ“… published April 1972, from ietf

RFC 327: Data and File Transfer Workshop Notes ๐Ÿ’–

Okay bestie, here's the deal ๐ŸŽ€. This RFC is from A. Bhushan at MIT-MAC, dated April 27, 1972, with NIC number 9261. Its title is Data and File Transfer Workshop Notes. The header doesn't list a category or status, and it doesn't say what this document obsoletes or updates, so I'm not making anything up there ๐Ÿ™ˆ.

  • RFC number: 327 ๐Ÿฆ‹
  • Title: Data and File Transfer Workshop Notes โœจ
  • Author: A. Bhushan, MIT-MAC ๐Ÿ’…
  • NIC number: 9261
  • Date: April 27, 1972
  • Category, obsoletes, updates: not listed in the header

On April 14 and 15, 1972, a Data and File Transfer Workshop happened at M.I.T. in Cambridge, Mass. ๐ŸŒธ The attendee list for April 14 and 15 is at the end. The note tries to sum up most of the topics talked about and every decision the workshop made ๐Ÿซถ.

The April 14 Talks ๐ŸŒˆ

Steve Crooker talked about a general theory for Network protocols ๐Ÿง . Protocol transformations SHOULD have a unique inverse, and they SHOULD be transitive. Getting to a standard form takes only 2n transformations (n = number of different types of hosts), while having no standard form takes n(n-1) transformations. A standard approach is preferable for n >= 3 ๐Ÿ‘‘.

For file transfer, you could define a Network Virtual File Image ๐Ÿ“. People talked about whether it was possible to follow the rules above for file structure transformations. Nobody agreed, so the problem got shelved for now ๐Ÿ˜ญ.

More talking led to this formulation of the Workshop goals ๐ŸŽฏ:

To come up with a data and file transfer protocol/strategy that meets the needs of ARPANET users, including Maxi-HOSTs, Mini-HOSTs, TIPs, Datacomputer, RJE, and Mailbox users.

The goals for the protocols/strategy were set as:

  1. It SHOULD preserve the integrity of data. ๐Ÿ’–
  2. It SHOULD preserve the integrity of character representation and interpretation. ๐ŸŒธ
  3. It SHOULD preserve the integrity of structural information, to the extent conveniently possible. ๐Ÿงš
  4. It SHOULD lead to the development of a Network Virtual File System. ๐Ÿ‘‘

Richard Winter talked about the Datacomputer application ๐Ÿ’ป. Even though you can use it from terminals directly, it won't be engineered for direct terminal users. It's built for programs. In Datalanguage, a user can define data and file structure, and also how the file or data gets transferred. With the data language, you can transfer entire files or just the relevant parts of files โœจ. Here's an example of file transfer as currently envisioned for the Datacomputer:

LOGIN  <user> <password>
CREATE  <file name> <description>
CREATE  <port name> <description>
PORT  <port name> <external name>
<file name> = <port name> (for transfer to Datacomputer)
<port name> = <file name> (for transfer from Datacomputer)
LOGOUT

(CREATE statements are only needed when the description(s) required are not already on file at the Datacomputer ๐Ÿ“‚. A port description can specify a standard "external name", which makes a port statement optional too. "External name" is supposed to be a HOST-socket specification. The data transfer is to be in accordance with network data transfer standards. The File and Port descriptions are to be in Datalanguage.)

Alex McKenzie talked about what TIP users need ๐Ÿ“ฑ. He covered what TIPs and TIP terminals can do right now and where they fall short. TIP users' first choice is TELNET format, followed by DTP using the indefinite bit stream mode. Two TIPs with magnetic tape systems can move data between each other using the current DTP (RFC 264) in the descriptor count mode (utilizing sequence number option) ๐Ÿงฒ.

Bob Braden talked about the RJS protocol and shared some data on RJS use ๐Ÿ“Š. NETRJS is 1% of CCN job load, which works out to 2,000 jobs, 10,000 sessions, and 1,000 hours of connect time in the last 5 months ๐Ÿ˜ณ. The average job input is around 100,000 bits (400 cards), and the average job output is 700,000 bits (1,000 lines). Big files are about 10 million bits, which is roughly 8-10 minutes of transmission time โฑ๏ธ. The RJS protocol will be defined in a forthcoming document ๐Ÿ”ฎ.

Ray Tomlinson described the CPYNET system BBN uses to move files between TENEX systems ๐Ÿ›ฐ๏ธ. CPYNET commands are ASCII strings with a fixed syntax. The original connection closes once a command is accepted, and the data moves over a new connection that reuses the previous socket number, though possibly with a different byte size. CPYNET has reached a data transfer rate of about 10 Kb/s ๐Ÿš€.

Abhay Bhushan talked about evaluating network protocols and shared some early measurement results ๐Ÿ“. The evaluation criteria for protocols SHOULD include speed (real time delay and transmission rate), efficiency (CPU time or cost), reliability (error rate and failure rate), convenience (ease of use and implementation), and usage (suitability for various application and user classes) ๐Ÿ’….

The parameters that affect speed and efficiency for a given set of system conditions (fixed load, etc.) are:

  1. Byte size used for NCP connection.
  2. Average message size used for transmission.
  3. Data format conversion (e.g., into Network ASCII, DTP Blocks, etc.).
  4. Buffer size and I/O mode used (unit or block mode, etc.).
  5. Other protocol constraints (acknowledge, error checking, connection procedure, etc.).

People talked about how data and file transfer protocols MAY be altered to make transfers faster and more efficient, by using an optimum byte size and cutting down on constraints that add a lot of overhead ๐ŸŽ๏ธ. Kinda iconic.

The April 15 Decisions ๐Ÿ‘‘

The DTP and FTP follow-up talks produced a list of discussion and decision items for the next day ๐Ÿ“. Here's the summary of decisions reached on Saturday, April 15, 1972 ๐ŸŽ€.

  1. Separate connections are to be used for data and control information. ๐Ÿ”€
  2. The control connection is to be a "TELNET" full-duplex connection (NVT-ASCII), established via the ICP. Data connections are to be simplex connections established directly ๐Ÿ”Œ.
  3. The File Transfer and File System commands and their arguments SHALL be printable ASCII strings, instead of numeric codes, so that they're directly usable by a user at a terminal ๐Ÿ’ป. The interaction, however, will be optimized for usage by programs (indirect use) ๐Ÿค–.
  4. The byte size and user socket for the data connection, data representation, and transfer mode used in file transfer MAY be chosen by a user via one or more commands that require a positive or negative acknowledgment โœ….
  5. The following data representations are to be accepted by all servers ๐Ÿ“š:
    1. Network ASCII (7-bit ASCII in 8-bit field with 8th bit zero).
    2. Local Byte (a server option to store data in an efficient manner; the storage scheme SHOULD be well publicized).
    3. Image (a sequence of bits which SHOULD be stored contiguously, independent of the byte size chosen for transfer).
    4. ASCII Print file (convert ASCII file to a form suitable for printing).
    5. EBCDIC Print file (convert EBCDIC file to a form suitable for printing).
  6. Record structures are allowed but not mandatory ๐Ÿ—‚๏ธ. A user with no record structure in their file SHOULD be able to store or retrieve their file at any host. If a serving host cannot accept record structure, it MUST inform the user of the fact. Any record structure information in the data stream MAY subsequently be discarded ๐Ÿ—‘๏ธ.
  7. The following data transfer modes are defined ๐Ÿšš:
    1. Byte-Stream: End of File is indicated by closing the connection. No record structure.
    2. Block: The file is a series of blocks preceded by a count field. Appropriate means are provided to indicate end-of-file, end-of-record, and restart markers.
    3. ASCII: The file is network-ASCII. End-of-record and end-of-file are indicated by a special "TELNET-control" character with the 8th bit set to "one".
    4. The file is network-ASCII with an end-of-record defined by CR LF, and end-of-file by closing the connection.
    5. Hasp compressed file with end-of-record and end-of-file information.
  8. A restart procedure will be provided to protect the user from system failures (either a host or a process dying) ๐Ÿ›Ÿ. The issue of bits lost or scrambled is handled best at the NCP level. Standard error codes and responses will be provided for storage and I/O channel errors, at the FTP level.

The restart procedure would require that the sender of data insert a special marker in the data stream. The marker only has meaning to the sender, and it could be a bit count, a record count, a page count, etc. The receiver of the data marks the corresponding position of this marker in its own system and returns this information to the user. If a system failure happens, the user can restart the transfer by supplying this information with a restart command ๐Ÿ”.

  1. DTP is no longer a separate protocol. It's a set of transfer modes or format procedures whose use is defined by the file transfer protocol ๐Ÿช„.
  2. Abhay Bhushan will write the workshop notes and the draft specifications for the new file transfer protocol โœ๏ธ.

List of Attendees, Data and File Transfer Workshop ๐Ÿซถ

Abhay Bhushan            MIT-MAC        April 14,15
Bob Braden               UCLA-CCN       April 14,15
Arvola Chan              MIT-MAC        April 14,15
Steve Crocker            ARPA           April 14
Eric Harslem             RAND           April 14
John Heafner             RAND           April 14
Chuck Holland            UCSD           April 14,15
Alex McKenzie            BBN (NET)      April 14
Bob Metcalfe             MIT-MAC        April 14
Hal Murray               CCA            April 14
Bill Plummer             BBN            April 14
Jon Postel               UCLA           April 14
Neal Ryan                MIT-MAC        April 14,15
Marc Seriff              MIT-MAC        April 14,15
Bob Thomas               BBN            April 14
Ray Tomlinson            BBN            April 14
Dick Watson              SRI-ARC        April 14,15
Doug Wells               MIT-MAC        April 14
Jim White                SRI-ARC        April 14,15
Richard Winter           CCA            April 14,15

[This RFC was put into machine readable form for entry] [into the online RFC archives by H๏ฟฝl๏ฟฝne Morin, Viag๏ฟฝnie 10/99]

That's the whole RFC, bestie! ๐ŸŒˆ๐Ÿฆ‹๐Ÿ’– Workshop, decisions, and attendees all covered.

๐Ÿ“ฆ where this page comes from