💾 Archived View for gemini.bortzmeyer.org › rfc-mirror › rfc327.txt captured on 2024-07-09 at 01:08:28.
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Network Working Group A. Bhushan
Request for Comments: 327 MIT-MAC
NIC: 9261 April 27, 1972
DATA AND FILE TRANSFER WORKSHOP NOTES
On April 14 and 15, 1972, a Data and File Transfer Workshop was held
at M.I.T., Cambridge, Mass. A list of attendees of the meeting for
April 14 and 15 is appended to the notes. This note attempts to
summarize most of the topics discussed and all of the decisions
reached at the workshop meeting.
The following is a summary of the talks and discussions on April 14,
1972.
Steve Crooker discussed a general theory for Network protocols.
Protocols transformations should have a unique inverse, and should be
transitive. Transformation to a standard form requires only 2n
transformations (n = number of different types of hosts), as compared
with n(n-1) transformations with no standard form. A standard
approach is preferable for n >= 3.
For file transfer, one could define a Network Virtual File Image.
There was some discussion on whether it was possible to satisfy the
above rules for file structure transformations. No agreement was
reached and the problem was abandoned for the present.
Further discussion lead to the following formulation of the Workshop
goals:
To come up with data and file transfer protocol/strategy that
satisfies the needs of ARPANET users including Maxi-HOSTs, Mini-
HOSTs, TIPs, Datacomputer, RJE, and Mailbox users.
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.
Bhushan [Page 1]
RFC 327 Data and File Transfer Workshop Notes April 1972
Richard Winter discussed the Datacomputer application. The
Datacomputer though usable from terminals directly will not be
engineered for direct terminal users, but for use by programs. In
Datalanguage a user can define data and file structure, and also how
the file/data is to be transferred. Using the data language it is
possible to transfer entire files, or only the relevant parts of
files. The following is an example of file transfer as currently
envisioned in 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 needed only when the description(s) required
are not already on file at the Datacomputer. A port description can
specify a standard "external name", thus making a port statement
optional also. "External name" is 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 discussed the TIP user needs, describing the current
capabilities and limitations of TIPs and TIP terminals. TELNET
format is the first choice of TIP users, followed by DTP using the
indefinite bit stream mode. There are two TIPs with magnetic tape
systems which are capable of transferring data between them using the
current DTP (RFC 264) in the descriptor count mode (utilizing
sequence number option).
Bob Braden discussed the RJS protocol and presented some data on RJS
use. NETRJS is 1% of CCN job load representing 2,000 jobs, 10,000
sessions and 1,000 hours connect time in the last 5 months. Average
job input is of the order of 100,000 bits (400 cards), average job
output is 700,000 bits (1,000 lines). Large files have about 10
million bits representing about 8-10 minutes of transmission time.
The RJS protocol will be defined in a forthcoming document.
Ray Tomlinson described the CPYNET system BBN is using to transfer
files among TENEX systems. CPYNET commands are ASCII strings with a
fixed syntax. The original connection is closed after a command is
accepted, and data is transferred on a new connection using previous
socket number, but with possibly a different byte size. The data
transfer rate achieved in CPYNET has been about 10 Kb/s.
Bhushan [Page 2]
RFC 327 Data and File Transfer Workshop Notes April 1972
Abhay Bhushan discussed the evaluation of network protocols and
presented some preliminary 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 given 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.).
There was some discussion as to how data and file transfer protocols
may be altered to make transfer faster and more efficient by using
optimum byte size and minimizing some of the constraints that impose
a large overhead.
The follow up discussions on DTP and FTP lead to a list of discussion
and decision items for the next day. The following is a summary of
decisions reached on Saturday, April 15, 1972.
1. Separate connections are to be used for data and control
information.
2. 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 are 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 data connection, data
representation, and transfer mode to be used in file transfer
may be chosen by a user via one or more commands requiring a
positive or negative acknowledgment.
Bhushan [Page 3]
RFC 327 Data and File Transfer Workshop Notes April 1972
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 his file should be able to store or
retrieve his 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 indicated by closing connection.
No record structure.
2) Block - File is series of blocks preceded by a count
field. Appropriate means 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 8th bit set to "one".
4) File is network-ASCII with an end-of-record defined by CR
LF, and end-of-file by closing connection.
5) Hasp compressed file with end-of-record and end-of-file
information.
Bhushan [Page 4]
RFC 327 Data and File Transfer Workshop Notes April 1972
8. A restart procedure will be provided to protect user from
system failures (either host or 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 has
meaning only to the sender. It could be bit-count, record
count, or page count, etc.). The receiver of data would mark
the corresponding position of this marker in its own system,
and return this information to the user. In the event of a
system failure, the user can restart the transfer by supplying
this information with a restart command.
9. DTP is no longer a separate protocol but a set of transfer
modes or format procedures whose use is defined by the file
transfer protocol.
10. 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]
Bhushan [Page 5]