1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955
|
Network Working Group A. Bhushan
Request for Comments: 114 MIT Project MAC
NIC: 5823 16 April 1971
A FILE TRANSFER PROTOCOL
I. Introduction
Computer network usage may be divided into two broad categories --
direct and indirect. Direct usage implies that you, the network
user, are "logged" into a remote host and use it as a local user.
You interact with the remote system via a terminal (teletypewriter,
graphics console) or a computer. Differences in terminal
characteristics are handled by host system programs, in accordance
with standard protocols (such as TELNET (RFC 97) for teletypewriter
communications, NETRJS (RFC 88) for remote job entry). You, however,
have to know the different conventions of remote systems, in order to
use them.
Indirect usage, by contrast, does not require that you explicitly log
into a remote system or even know how to "use" the remote system. An
intermediate process makes most of the differences in commands and
conventions invisible to you. For example, you need only know a
standard set of network file transfer commands for your local system
in order to utilize remote file system. This assumes the existence
of a network file transfer process at each host cooperating via a
common protocol.
Indirect use is not limited to file transfers. It may include
execution of programs in remote hosts and the transfer of core
images. The extended file transfer protocol would facilitate the
exchange of programs and data between computers, the use of storage
and file handling capabilities of other computers (possibly including
the trillion-bit store data computer), and have programs in remote
hosts operate on your input and return an output.
The protocol described herein has been developed for immediate
implementation on two hosts at MIT, the GE645/Multics and the PDP-
10/DM/CG-ITS (and possibly Harvard's PDP-10). An interim version
with limited capabilities is currently in the debugging stage. [1]
Since our implementation involves two dissimilar systems (Multics is
a "service" system, ITS is not) with different file systems (Multics
provides elaborate access controls, ITS provides none), we feel that
the file transfer mechanisms proposed are generalizable. In
addition, our specification reflects a consideration of other file
systems on the network. We conducted a survey [2] of network host
Bhushan [Page 1]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
systems to determine the requirements and capabilities. This paper
is a "first cut" at a protocol that will allow users at any host on
the network to use the file system of every cooperating host.
II. Discussion
A few definitions are in order before the discussion of the protocol.
A file is an ordered set consisting of computer instructions and/or
data. A file can be of arbitrary length [3]. A named file is
uniquely identified in a system by its file name and directory name.
The directory name may be the name of a physical directory or it may
be the name of a physical device. An example of physical directory
name is owner's project-programmer number and an example of physical
device name is tape number.
A file may or may not have access controls associated with it. The
access controls designate the users' access privileges. In the
absence of access controls, the files cannot be protected from
accidental or unauthorized usage.
A principal objective of the protocol is to promote the indirect use
of computers on the network. Therefore, the user or his program
should have a simple and uniform interface to the file systems on the
network and be shielded from the variations in file and storage
systems of different host computers. This is achieved by the
existence of a standard protocol in each host.
Criteria by which a user-level protocol may be judged were described
by Mealy in RFC 91, as involving the notion of logical records,
ability to access files without program modifications, and
implementability. I would add to these efficiency, extendibility,
adaptability, and provision of error-recovery mechanisms.
The attempt in this specification has been to enable the reliable
transfer of network ASCII (7-bit ASCII in 8-bit field with leftmost
bit zero) as well as "binary" data files with relative ease. The use
of other character codes, such as EBCDIC, and variously formatted
data (decimal, octal, ASCII characters packed differently) is
facilitated by inclusion of data type in descriptor headings. An
alternative mechanism for defining data is also available in the form
of attributes in file headings. The format control characters
reserved for the syntax of this protocol have identical code
representation in ASCII and EBCDIC. (These character are SOH, STX,
ETX, DC1, DC2, DC3, US, RS, GS, and FS.)
Bhushan [Page 2]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
The notion of messages (the physical blocks of data communicated
between NCP's) is suppressed herein and that of "logical" records and
transactions is emphasized. The data passed by the NCP is parsed
into logical blocks by use of simple descriptors (code and count
mechanisms) as described in Section III. The alternative to count is
fixed length blocks or standard end-of-file characters (scan data
stream). Both seem less desirable than count.
The cooperating processes may be "daemon" processes which "listen" to
agreed-upon sockets, and follow the initial connection protocol much
in the same way as a "logger" does. We recommend using a single
full-duplex connection for the exchange of both data and control
information [4], and using CLS to achieve synchronization when
necessary (a CLS is not transmitted until a RFNM is received).
The user may be identified by having the using process send at the
start of the connection the user's name information (either passed on
by user or known to the using system) [5]. This user name
information (a sequence of standard ASCII characters), along with the
host number (known to the NCP), positively identifies the user to the
serving process.
At present, more elaborate access control mechanisms, such as
passwords, are not suggested. The user, however, will have the
security and protection provided by the serving system. The serving
host, if it has access controls, can prevent unprivileged access by
users from other host sites. It is up to the using host to prevent
its own users from violating access rules.
The files in a file system are identified by a pathname, similar to
the labels described in RFC 76 (Bouknight, Madden, and Grossman).
The pathname contains the essential information regarding the storage
and retrieval of data.
In order to facilitate use, default options should be provided. For
example, the main file directory on disk would be the default on the
PDP-10/ITS, and a pool directory would be the default on Multics.
The file to be transferred may be a complete file or may consist of
smaller records. It may or may not have a heading. A heading should
contain ASCII or EBCDIC characters defining file attributes. The
file attributes could be some simple agreed-upon types or they could
be described in a data reconfiguration or interpretation language
similar to that described in RFC 83 (Anderson, Haslern, and Heffner),
or a combination.
Bhushan [Page 3]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
The protocol does not restrict the nature of data in the file. For
example, a file could contain ASCII text, binary core image, graphics
data or any other type of data. The protocol includes an "execute"
request for files that are programs. This is intended to facilitate
the execution of programs and subroutines in remote host computers
[6].
III. SPECIFICATIONS
1. Transactions
1A. The protocol is transaction-oriented. A transaction is defined
to be an entity of information communicated between cooperating
processes.
1B. Syntax
A transaction has three fields, a 72-bit descriptor field and
variable length (including zero) data and filler fields, as
shown below. The total length of a transaction is (72 + data +
filler) bits.
| <code><filler count><NUL><data count><NUL> | <data><filler> |
| |____||____________||___||__________||___| | |____________| |
| | | | | | | | |
| 24-bits 8-bits 8-bits 24-bits 8-bits| variable length |
| <-------descriptor field 72-bits---------> |<--data and filler-->|
| | |
1C. Semantics
The code field has three 8-bit bytes. The first byte is
interpreted as transaction type, the second byte as data type
and the third byte as extension of data type.
The filler count is a binary count of bits used as "filler"
(i.e., not information) at the end of a transaction [7]. As
the length of the filler count field is 8-bits, the number of
bits of filler shall not exceed 255 bits.
The data count is a binary count of the number of data (i.e.,
information) bits in the data field, not including filler bits.
The number of data bits is limited to (2^24-1), as there are 24
bits in the data count field.
Bhushan [Page 4]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
The NUL bytes are inserted primarily as fillers in the
descriptor field and allow the count information to appear at
convenient word boundaries for different word length machines
[8].
2. Transaction Types
2A. A transaction may be of the following four basic types:
request, response, transfer and terminate. Although large
number of request and transfer types are defined,
implementation of a subset is specifically permitted. Host
computers, on which a particular transaction type is not
implemented, may refuse to accept that transaction by
responding with an unsuccessful terminate.
The following transaction type codes are tentatively defined:
Transaction Type Transaction Type Code
ASCII Octal Hexidecimal
Request
Identify I 111 49
Retrieve R 122 52
Store S 123 53
Append A 101 41
Delete D 104 44
Rename N 116 4E
addname (Plus) P 120 50
deletename (Minus) M 115 4D
Lookup L 114 4C
Open O 117 4F
Close C 103 43
Execute [9] E 105 45
Response
ready-to-receive (rr) < 074 3C
ready-to-send (rs) > 076 3E
Transfer
complete_file * 052
heading # 043 23
part_of_file ' 054 2C
last_part . 056 2E
Terminate
successful (pos.) + 053 2B
unsuccessful (neg.) - 055 2D
Bhushan [Page 5]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
2B. Syntax
In the following discussion US, RS, GS, FS, DC1, DC2, and DC3
are the ASCII characters, unit separator (octal 037), record
separator (octal 036), group separator (octal 035), file
separator (octal 034), device control 1 (octal 021), device
control 2 (octal 022), and device control 3 (octal 023),
respectively. These have an identical interpretation in
EBCDIC.
2B.1 Requests
Identify, retrieve, store, append, delete, open, lookup and
execute requests have the following data field:
<path name>
Rename request has the data field:
<path name> GS <name>
Addname and deletename requests have the data field:
<path name> GS <filenames>
where pathname [10], name and filenames have the following
syntax (expressed in BNF, the metalanguage of the ALGOL 60
report):
<pathname> ::= <device name>|<name>|<pathname>US<name>
<device name> ::= DC1<name>
<name> ::= <char> | <name> <char>
<char> ::= All 8-bit ASCII or EBCDIC characters except
US, RS, GS, FS, DC1, DC2, AND DC3.
<filenames> ::= <name>|<filenames> RS <name>
The data type for the request transaction shall be either A
(octal 101 for ASCII, or E (octal 105) for EBCDIC [11].
Some examples of pathname are:
DC1 MT08
DC1 DSK 1.2 US Net<3> US J.Doe US Foo
udd US proj. US h,n/x US user US file
filename 1 filename 2
Bhushan [Page 6]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
2B.2 Responses
The response transactions shall normally have an empty data
field.
2B.3 Transfers
The data types defined in section 4 will govern the syntax of
the data field in transfer transactions. No other syntactical
restrictions exist.
2B.4 Terminates
The successful terminate shall normally have an empty data
field. The unsuccessful terminate may have a data field
defined by the data types A (octal 101) for ASCII, E (octal
105) for EBCDIC, or S (octal 123) for status.
A data type code of 'S' would imply byte oriented error return
status codes in the data field. The following error return
status codes are defined tentatively:
Error Code Meaning Error Code
ASCII Octal Hexadecimal
Undefined error U 125 55
Transaction type error T 124 54
Syntax error S 123 53
File search failed F 106 46
Data type error D 104 44
Access denied A 101 41
Improper transaction sequence I 111 49
Time-out error O 117 4F
Error condition by system E 105 45
2C. Semantics
2C.1 Requests
Requests are always sent by using host. In absence of a device
name or complete pathname, default options should be provided
for all types of requests.
_Identify_ request identifies the user as indicated by
<pathname> from serving to using host.
_Retrieve_ request achieves the transfer of file specified in
<pathname> from serving to using host.
Bhushan [Page 7]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
_Store_ request achieves the transfer of file specified in
<pathname> from using to serving host.
_Append_ request causes data to be added to file specified in
pathname.
_Rename_ request causes name of file specified in <pathname> to
be replaced by name specified in <name>.
_Delete_ request causes file specified in <pathname> to be
deleted. If an extra level of protection for delete is desired
(such as the query 'Do you wish to delete file x?'), it is to
be a local implementation option.
_Addname_ and _deletename_ requests cause names in <filenames>
to be added or deleted to existing names of file specified in
<pathname>. These requests are useful in systems such as
Multics which allow multiple names to be associated with a
file.
_Lookup_ request achieves the transfer of attributes (such as
date last modified, access list, etc) of file specified in
<pathname>, instead of the file itself.
_Open_ request does not cause a data transfer, instead file
specified in <pathname> is "opened" for retrieve (read) or
store (write). Subsequent requests are then treated as
requests pertaining to the file that is opened till such a time
that a close request is received.
_Execute_ request achieves the execution of file specified in
<pathname>, which must be an executable program. Upon receipt
of rr response, using host will transmit the necessary input
data (parameters, arguments, etc). Upon completion of
execution serving host will send the results to using host and
terminate [12].
2C.2 Response
Responses are always sent by serving host. The rr response
indicates that serving host is ready to receive the file
indicated in the preceding request. The rs response indicates
that the next transaction from serving host will be the
transfer of file indicated in the preceding request.
Bhushan [Page 8]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
2C.3 Transfers
Transfers may be sent by either host. Transfer transactions
indicate the transfer of file indicated by a request. Files
can be transferred either as complete_file transactions or as
part_of_file transactions followed by last_part transactions.
The file may also have a heading transaction in the beginning.
The syntax of a file, therefore, may be defined as:
<file> ::= <text> | <heading> <text>
<text> ::= <complete_file> | <parts> <last_part>
<parts> ::= <part_of_file> | <parts> <part_of_file>
Headings may be used to communicate the attributes of files.
The form of headings is not formally specified but is discussed
in Section IV as possible extension to this protocol.
2C.4 Terminates
The successful terminate is always sent by serving host. It
indicates to using host that serving host has been successful
in serving the request and has gone to an initial state. Using
host will then inform user that his request is successfully
served, and go to an initial state.
The unsuccessful terminate may be sent by either host. It
indicates that sender of the terminate is unable to (or does
not not wish to) go through with the request. Both hosts will
then go to their initial states. The using host will inform
the user that his request was aborted. If any reasons for the
unsuccessful terminate (either as text or as error return
status codes) are received, these shall be communicated to the
user.
3. Transaction Sequence
3A. The transaction sequence may be defined as an instance of file
transfer, initiated by a request and ended by a terminate [13].
The exact sequence in which transactions occur depends on the
type of request. A transaction sequence may be aborted anytime
by either host, as explained in Section 3C.
3B. Examples
The identify request doesn't require a response or terminate
and constitutes a transaction sequence by itself.
Bhushan [Page 9]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
Rename, delete, addname, deletename and open requests involve
no data transfer but require terminates. The user sends the
request and the server sends a successful or an unsuccessful
terminate depending on whether or not he is successful in
complying with the request.
Retrieve and Lookup requests involve data transfer from the
server to the user. The user sends the request, the server
responds with a rs, and transfers the data specified by the
request. Upon completion of the data transfer, the server
terminates the transaction sequence with a successful terminate
if all goes well, or with an unsuccessful terminate is errors
were detected.
Store and Append requests involve data transfer from the user
to server. The user sends the request and the server responds
with a rr. The user then transfers the data. Upon receiving
the data, the server terminates the sequence.
Execute request involves transfer of inputs from user to
server, and transfer of outputs from server to user. The user
sends the request to which the server responds with rr. The
user then transfers the necessary inputs. The server
"executes" the program or subroutine and transfers the outputs
to the user. Upon completion of the output transfer, the
server terminates the transaction sequence.
3C. Aborts
Either host may abort the transaction sequence at any time by
sending an unsuccessful terminate, or by closing the connection
(NCP to transmit a CLS for the connection). The CLS is a more
drastic type of abort and shall be used when there is a
catastrophic failure or when an abort is desired in the middle
of a long file transfer. The abort indicates to the receiving
host that the other host wishes to terminate the transaction
sequence and is now in the initial state. When CLS is used to
abort, the using host will reopen the connection.
4. Data Types
4A. The data type code together with the extension code defines the
manner in which the data field is to be parsed and interpreted
[14]. Although a large number of data types are defined,
specific implementations may handle only a limited subset of
data types. It is recommended that all host sites accept the
Bhushan [Page 10]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
"network ASCII" and "binary" data types. Host computers which
do not "recognize" particular data types may abort the
transaction sequence and return a data type error status code.
4B. The following data types are tentatively defined. The code in
the type and extension field is represented by its ASCII
equivalent with 8th bit as zero.
Bhushan [Page 11]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
Data Type Code
Byte Size Type Extension
ASCII character, bit8=0 (network) 8 A NUL
ASCII characters, bit8=1 8 A 1
ASCII characters, bit8=even parity 8 A E
ASCII characters, bit8=odd parity 8 A O
ASCII characters, 8th bit info. 8 A 8
ASCII characters, 7 bits 7 A 7
ASCII characters, in 9-bit field 9 A 9
ASCII formatted files (with SOH,
STX, ETX, etc.) 8 A F
DEC-packed ASCII (5 7-bit char.,
36th bit 1 or 0) 36 A D
EBCDIC characters 8 E NUL
SIXBIT characters 6 S NUL
Binary data 1 B NUL
Binary bytes (size is binary ext.) 1-255 B (any)
Decimal numbers, net ASCII 8 D A
Decimal numbers, EBCDIC 8 D E
Decimal numbers, sixbit 6 D S
Decimal numbers, BCD (binary coded) 4 D B
Octal numbers, net. ASCII 8 O A
Octal numbers, EBCDIC 8 O E
Octal numbers, SIXBIT 6 O S
Hexadecimal numbers, net. ASCII 8 H A
Hexadecimal numbers, EBCDIC 8 H E
Hexadecimal numbers, SIXBIT 6 H S
Unsigned integers, binary (ext.
field is byte size) 1-225 U (any)
Sign magnitude integers (field is
binary size) 1-255 I (any)
2's complement integers (ext.
field is byte size) 1-255 2 (any)
1's complement integers (ext.
field is byte size) 1-255 1 (any)
Floating point (IBM360) 32 F I
Floating point (PDP-10) 36 F D
Status codes 8 S NUL
Bhushan [Page 12]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
4C. The data type information is intended to be interpretive. If a
host accepts a data type, it can interpret it to a form suited
to its internal representation of characters or numbers [15].
Specifically when no conversion is to be performed, the data
type used will be binary. The implicit or explicit byte size
is useful as it facilitates storing of data. For example, if a
PDP-10 receives data types A, A1, AE, or A7, it can store the
ASCII characters five to a word (DEC-packed ASCII). If the
datatype is A8 or A9, it would store the characters four to a
word. Sixbit characters would be stored six to a word. If
conversion routines are available on a system, the use of
system program could convert the data from one form to another
(such as EBCDIC to ASCII, IBM floating point to DEC floating
point, Decimal ASCII to integers, etc.).
5. Initial Connection, CLS, and Identifying Users
5A. There will be a prearranged socket number [16] for the
cooperating process on the serving host. The connection
establishment will be in accordance with the initial connection
protocol of RFC 66 as modified by RFC 80. The NCP dialog would
be:
user to server: RTS<us><3><p>
if accepted, server to user: STR<3><us><CLS><3><us>
server to user on link p: <ss>
server to user: STR<ss+1><us>RTS<ss><us+1><q>
user to server: STR<us><ss+1>RTS<us+1><ss><r>
This sets up a full-duplex connection between user and server
processes, with server receiving through local socket ss from
remote socket us+1 via link q, and sending to remote socket us
through local socket ss+1 via link r.
5B. The connection will be broken by trading a CLS between the
NCP'S for each of the two connections. Normally the user will
initiate the CLS.
CLS may also be used by either the user or the server to abort
a data transmission in the middle. If a CLS is received in the
middle of a transaction sequence, the whole transaction
sequence will be aborted. The using host will then reopen the
connection.
5C. The first transaction from the user to server will be the
identify transaction. The users will be identified by the
pathname in data field of the transaction which should be a
Bhushan [Page 13]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
form acceptable to the server. The server is at liberty to
truncate pathnames for its own use. Since the identify
transaction does not require a response or terminate, the user
can proceed directly with other requests.
IV. Extensions to Protocol
The protocol specified above has been designed to be extendable. The
obvious extensions would be in the area of transaction types (new
types of requests), error return status words, and data types. Some
of the non-obvious extensions, that I can visualize are provisions of
access control mechanisms, developing a uniform way of specifying
file attributes in headings of files, increasing the scope of the
execute command to include subroutine mediation, and the provision of
transaction sequence identification numbers to facilitate handling of
multiple requests over the same connection pair.
Users of protected file systems should be able to have a reasonable
degree of confidence in the ability of the serving process to
identify remote users correctly. In the absence of such confidence,
some users would not be willing to give access to the serving process
(especially write access). Inclusion of access control mechanisms
such as passwords, is likely to enhance the indirect use of network
by users who are concerned about privacy and security. A simple
extension to the protocol would be to have the serving host sent a
transaction type "password?" after it receives user name. Upon
receipt of "password?" the using host will transmit the password,
which when successfully acknowledged, would indicate to the user that
requests may proceed.
There are a number of file attributes which properly belong in the
heading of a file rather than the file itself or the data type in
descriptors of transactions. Such attributes include access control
lists, date file was last modified, information about the nature of
file, and description of its contents in a data description or data
reconfiguration language. Some uniformity in the way file attributes
are specified would be useful. Until then, the interpretation of the
heading would be up to the user or the using process. For example,
the heading of files which are input to a data reconfiguration (form)
machine may be the desired transformations expressed in the
reconfiguration language.
The "execute" command which achieves the execution of programs
resident in remote hosts is a vital part of indirect use of remote
hosts. The present scope of the execute command, as outlined in the
specifications, is somewhat limited. It assumes that the user or
Bhushan [Page 14]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
using process is aware of the manner in which the arguments and
results should be exchanged. One could broaden the scope of the
execute command by introducing a program mediation protocol [17].
The present specification of the protocol does not allow the
simultaneous transfer and processing of multiple requests over the
same pair of connections. If such a capability is desired, there is
an easy way to implement it which only involves a minor change. A
transaction sequence identification number (TSid) could replace a NUL
field in the descriptor of transactions. The TSid would facilitate
the coordination of transactions, related to a particular transaction
sequence. The 256 code combinations permitted by the TSid would be
used in a round-robin manner (I can't see more than 256 outstanding
requests between two user-processes in any practical implementation).
An alternate way of simultaneous processing of requests is to open
new pairs of connection. I am not sure as to how useful simultaneous
processing of requests is, and which of the two is a more reasonable
approach.
V. Conclusions
I tried to present a user-level protocol that will permit users and
using programs to make indirect use of remote host computers. The
protocol facilitates not only file system operations but also program
execution in remote hosts. This is achieved by defining requests
which are handled by cooperating processes. The transaction sequence
orientation provides greater assurance and would facilitate error
control. The notion of data types is introduced to facilitate the
interpretation, reconfiguration and storage of simple and limited
forms of data at individual host sites. The protocol is readily
extendible.
Endnotes
[1] The interim version of the protocol, limited to transfer of ASCII
files, was developed by Chander Ramchandani and Howard Brodie of
Project MAC. The ideas of transactions, descriptors, error recovery,
aborts, file headings and attributes, execution of programs, and use
of data types, pathnames, and default mechanisms are new here.
Howard Brodie and Neal Ryan have coded the interim protocol in the
PDP-10 and the 645, respectively.
[2] The network system survey was conducted last fall by Howard
Brodie of Project MAC, primarily by telephone.
[3] PDP-10 Reference Handbook, page 306.
Bhushan [Page 15]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
[4] We considered using two full-duplex links, one for control
information, the other for data. The use of a separate control link
between the cooperating processes would simplify aborts, error
recoveries and synchronization. The synchronization function may
alternatively be performed by closing the connection (in the middle
of a transaction sequence) and reopening it with an abort message.
(The use of INR and INS transmitted via the NCP control link has
problems as mentioned by Kalin in RFC 103.) We prefer the latter
approach.
[5] Identifying users through use of socket numbers is not practical,
as unique user identification numbers have not been implemented, and
file systems identify users by name, not number.
[6] This subject is considered in detail by Bob Metcalfe in a
forthcoming paper.
[7] Filler bits may be necessary as particular implementations of
NCP's may not allow the free communication of bits. Instead the
NCP's may only accept bytes, as suggested in RFC 102. The filler
count is needed to determine the boundary between transactions.
[8] 72-bits in descriptor field are convenient as 72 is the least
common multiple of 6, 8, 9, 18, 24 and 30, the commonly encountered
byte sizes on the ARPA network host computers.
[9] The execute request is intended to facilitate the indirect
execution of programs and subroutines. However, this request in its
present form may have only limited use. A subroutine or program
mediation protocol would be required for broader use of the execute
feature. Metcalfe considers this problem in a forthcoming paper.
[10] The pathname idea used in Multics is similar to that of labels
in RFC 76 by Bouknight, Madden and Grossman.
[11] We, however, urge the use of standard network ASCII.
[12] The exact manner in which the input and output are transmitted
would depend on specific mediation conventions. Names of input and
output files may be transmitted instead of data itself.
[13] The transactions (including terminate) are not "echoed", as
echoing does not solve any "hung" conditions. Instead time-out
mechanisms are recommended for avoiding hang-ups.
[14] The data type mechanism suggested here does not replace data
reconfiguration service suggested by Harslem and Heafner in RFC 83
and NIC5772. In fact, it complements the reconfiguration. For
Bhushan [Page 16]
RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
example, data reconfiguration language can be expressed in EBCDIC,
Network ASCII or any other code that form machine may "recognize".
Subsequent data may be transmitted binary, and the form machine would
reconfigure it to the required form. I have included in data types,
a large number suggested by Harslem and Heafner, as I do not wish to
preclude interpretation, reconfiguration and storage of simple forms
of data at individual host sites.
[15] The internal character representation in the hosts may be
different even in ASCII. For example PDP-10 stores 7-bit characters,
five per word with 36th bit as don't care, while Multics stores them
four per word, right-justified in 9-bit fields.
[16] It seems that socket 1 has been assigned to logger and socket 5
to NETRJS. Socket 3 seems a reasonable choice for the file transfer
process.
[17] The term program mediation was suggested by Bob Metcalfe who is
intending to write a paper on this subject.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Ryan Kato 6/01]
Bhushan [Page 17]
|