RFC114 日本語訳
0114 File Transfer Protocol. A.K. Bhushan. April 1971. (Format: TXT=38981 bytes) (Updated by RFC0133, RFC0141, RFC0171, RFC0172) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Bhushan Request for Comments: 114 MIT Project MAC NIC: 5823 16 April 1971
Network Working Group A. Bhushan Request for Comments: 114 MIT Project MAC NIC: 5823 16 April 1971
A FILE TRANSFER PROTOCOL
A FILE TRANSFER PROTOCOL
I. Introduction
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.
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 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.
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
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
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.
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
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 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 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.
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.
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.)
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
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 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 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.
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.
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.
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.
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.
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
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].
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
III. SPECIFICATIONS
1. Transactions
1. Transactions
1A. The protocol is transaction-oriented. A transaction is defined
to be an entity of information communicated between cooperating
processes.
1A. The protocol is transaction-oriented. A transaction is defined to be an entity of information communicated between cooperating processes.
1B. Syntax
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.
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-->| | | |
| <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
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 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 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.
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
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].
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
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.
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:
The following transaction type codes are tentatively defined:
Transaction Type Transaction Type Code
Transaction Type Transaction Type Code
ASCII Octal Hexidecimal
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
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
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
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
Terminate successful (pos.) + 053 2B unsuccessful (neg.) - 055 2D
Bhushan [Page 5] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
Bhushan [Page 5] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
2B. Syntax
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.
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
2B.1 Requests
Identify, retrieve, store, append, delete, open, lookup and
execute requests have the following data field:
Identify, retrieve, store, append, delete, open, lookup and execute requests have the following data field:
<path name>
<path name>
Rename request has the data field:
Rename request has the data field:
<path name> GS <name>
<path name> GS <name>
Addname and deletename requests have the data field:
Addname and deletename requests have the data field:
<path name> GS <filenames>
<path name> GS <filenames>
where pathname [10], name and filenames have the following
syntax (expressed in BNF, the metalanguage of the ALGOL 60
report):
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>
<pathname> ::= <device name>|<name>|<pathname>US<name> <device name> ::= DC1<name>
<name> ::= <char> | <name> <char>
<char> ::= All 8-bit ASCII or EBCDIC characters except
<name> ::= <char> | <name> <char> <char> ::= All 8-bit ASCII or EBCDIC characters except
US, RS, GS, FS, DC1, DC2, AND DC3.
US, RS, GS, FS, DC1, DC2, AND DC3.
<filenames> ::= <name>|<filenames> RS <name>
<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].
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:
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
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
Bhushan [Page 6] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
2B.2 Responses
2B.2 Responses
The response transactions shall normally have an empty data
field.
The response transactions shall normally have an empty data field.
2B.3 Transfers
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.
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
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.
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:
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
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
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. Semantics
2C.1 Requests
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.
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.
_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.
_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
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.
_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.
_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>.
_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.
_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.
_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.
_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.
_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].
_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
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.
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
Bhushan [Page 8] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
2C.3 Transfers
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:
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>
<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.
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
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 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.
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
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.
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
3B. Examples
The identify request doesn't require a response or terminate
and constitutes a transaction sequence by itself.
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
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.
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.
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.
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.
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
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.
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
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
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
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.
"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.
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
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
データType Code Byte Size Type Extension ASCII文字、bit8=0(ネットワーク)8A NUL
ASCII characters, bit8=1 8 A 1
ASCII文字、bit8=1 8A1
ASCII characters, bit8=even parity 8 A E
8偶数パリティA bit8=EのASCII文字
ASCII characters, bit8=odd parity 8 A O
奇数パリティ8ASCII文字、bit8=A O
ASCII characters, 8th bit info. 8 A 8
ASCII文字、8番目のビットインフォメーション。 8 8
ASCII characters, 7 bits 7 A 7
ASCII文字、7ビット7A7
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
ASCII文字、9ビットの分野9A9では、ASCIIはファイル(SOH、STX、ETXなどと)をフォーマットしました。 8A FがASCIIを12月梱包しました。(5 7ビットが焦げる、36番目に、1か0つの)36人のA D EBCDlC文字8E NUL SIXBITキャラクタ6秒間NUL Binaryデータに1B NUL Binaryバイト(サイズはextに2進です。)噛み付きます。 1-255B (いずれ)の10進数、ネットのASCII8D A Decimal番号、EBCDIC8D E Decimal番号、sixbit6D S Decimal番号、4つのBCD(コード化されたバイナリー)D B Octal番号(ネット)。 ASCII8O A Octal番号、EBCDIC8O E Octal番号、SIXBIT6O S Hexadecimal番号、ネット。 ASCII8H A Hexadecimal番号、EBCDIC8H E Hexadecimal番号、SIXBIT6H S Unsigned整数、2進(ext分野はバイトサイズである)の1-225U(いくらか)サイン2つの大きさ整数(分野は2進のサイズである)1-255I(いくらか)補数整数(ext分野はバイトサイズである)1-255 2(いくらか)1の補数整数(ext分野はバイトサイズである)1-255 1つ(いくらか)の浮動小数点(IBM360)32F I Floatingポイント(PDP-10)36F D Statusは8秒間、NULをコード化します。
Bhushan [Page 12] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
ファイル転送プロトコル1971年4月16日あたりBhushan[12ページ]RFC114
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.).
4C。 データ型情報が解釈的であることを意図します。 ホストがデータ型を受け入れるなら、それはキャラクタか数[15]の内部の表現に合ったフォームにそれを解釈できます。 特にどんな変換も実行されないことであるときに、使用されるデータ型は2進になるでしょう。 データが保存されるのを容易にするとき、暗黙の、または、明白なバイトサイズは役に立ちます。 例えば、PDP-10がデータ型A、A1、AE、またはA7を受けるなら、それはASCII文字5対a単語(12月が詰まっているASCII)を保存できます。 データ型式がA8かA9であるなら、それはキャラクタ4対a単語を保存するでしょう。 Sixbitキャラクタは保存された6対1単語でしょう。 変換ルーチンがシステムの上で利用可能であるなら、システムプログラムの使用が1つのフォームから別のフォームまでデータを変換するかもしれない、(ASCII、IBMにEBCDICとしてそのような浮動小数点、12月、浮動小数点、整数へのDecimal ASCIIなど)
5. Initial Connection, CLS, and Identifying Users
5. 初期の接続と、CLSと、ユーザを特定すること。
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:
5A。 給仕のホストの協調処理の根回しされたソケット番号[16]があるでしょう。 変更されるとしてのRFC66ごとの初期の接続プロトコルによると、コネクション確立があるでしょう。 NCP対話は以下の通りでしょう。
user to server: RTS<us><3><p>
サーバへのユーザ: RTS<、私たち、><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>
受け入れるならユーザへのサーバ: STR<3><、私たち、><CLS><3><、私たち、リンクpの上のユーザへの>サーバ: ユーザへの<ss>サーバ: STR<ss+1><、私たち、>RTS<ss><、私たち、+1 サーバへの><q>ユーザ: STR<、私たち、><ss+1>RTS<、私たち、+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.
これは、サーバが地方のソケットssを通してリモートソケットから受信されている状態でリンクqを通して+1に私たちを処理して、リンクrを通して地方のソケットss+1を通してリモートソケットに私たちを送りながら、ユーザとサーバとの全二重関係をセットアップします。
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.
5B。 接続はそうでしょう。NCPの間でCLSを取り引きすることによって、壊れるのは、接続2人の各人のためのそうです。 通常、ユーザは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.
また、CLSはユーザかサーバのどちらかによって使用されて、中央でデータ伝送を中止するかもしれません。 トランザクション系列の中央にCLSを受け取ると、全体のトランザクション系列を中止するでしょう。 そして、使用しているホストは接続を再開させるでしょう。
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
5C。 最初のユーザからサーバまでのトランザクションがそうになる、トランザクションを特定してください。 ユーザはaであるべきであるトランザクションのデータ・フィールドでパス名によって特定されるでしょう。
Bhushan [Page 13] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
ファイル転送プロトコル1971年4月16日あたりBhushan[13ページ]RFC114
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
IV。 議定書の中で述べる拡大
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
ファイル転送プロトコル1971年4月16日あたりBhushan[14ページ]RFC114
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].
プロセスを使用するのは議論と結果が交換されるべきである方法を意識しています。 1つは、プログラム仲介プロトコル[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.
プロトコルの現在の仕様は接続の同じ組の上の複数の要求の同時の転送と処理を許しません。 そのような能力が望まれているなら、マイナーチェンジを伴うだけであるものをそれに実装する簡単な方法があります。 トランザクション系列識別番号(TSid)はトランザクションに関する記述子のNUL野原を取り替えるかもしれません。 TSidは特定の取引系列に関連するトランザクションのコーディネートを容易にするでしょう。 TSidによって可能にされた256のコード組み合わせが連続方法で使用されるでしょう(私はどんな実用的な実装でも2つのユーザ・プロセスの間の256以上の傑出している要求を見ることができません)。 要求の同時処理の代替の道は接続の新しいペアを開くことです。 私は要求の同時処理がどれくらい役に立つか、そして、2つのもののどれが、より合理的なアプローチであるかに関して確信していません。
V. Conclusions
V。 結論
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.
[1] プロトコルの当座のASCIIファイルの転送に限られたバージョンはProject MACのChander Ramchandaniとハワードブローディによって開発されました。 トランザクション、記述子、エラー回復、アボート、ファイル見出し、および属性のアイデア、プログラムの実行、およびデータ型、パス名、およびデフォルトメカニズムの使用はここで新しいです。 ハワードブローディとニール・ライアンはそれぞれPDP-10と645における当座のプロトコルをコード化しました。
[2] The network system survey was conducted last fall by Howard Brodie of Project MAC, primarily by telephone.
[2] ネットワーク・システム調査は去年の秋にProject MACのハワードブローディと、主として電話によって指導されました。
[3] PDP-10 Reference Handbook, page 306.
[3] PDP-10参照ハンドブック、306ページ。
Bhushan [Page 15] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
ファイル転送プロトコル1971年4月16日あたりBhushan[15ページ]RFC114
[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.
[4] 私たちは、制御情報、データのためのもう片方に2個の全二重リンク、1を使用すると考えました。 協調処理の間の別々のコントロールリンクの使用はアボート、誤り回復、および同期を簡素化するでしょう。 あるいはまた、同期機能は、接続(トランザクション系列の中央の)を終えて、アボートメッセージでそれを再開させることによって、実行されるかもしれません。 (NCPコントロールリンクを通して伝えられたINRとINSの使用には、RFC103でKalinによって言及されるように問題があります。) 私たちは後者のアプローチを好みます。
[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.
[5] ソケット番号の使用でユーザを特定するのは実用的ではありません、ユニークユーザー識別番号が実装されていなくて、ファイルシステムが数ではなく、名前のユーザを特定するとき。
[6] This subject is considered in detail by Bob Metcalfe in a forthcoming paper.
[6] この対象は今度の紙のボブメトカルフェによって詳細に考えられます。
[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.
[7] NCPのものの特定の実装がビットの無料のコミュニケーションを許容しないかもしれないので、フィラービットが必要であるかもしれません。 代わりに、NCPのものはRFC102に示されるようにバイトを受け入れるだけであるかもしれません。 フィラーカウントが、トランザクションの間の境界を決定するのに必要です。
[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.
[8] 記述子分野における72ビットが72が6、8、9、18、24、および30の最小公倍数であるので便利である、一般的に遭遇したバイトはARPAネットワークでホストコンピュータを大きさで分けます。
[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.
要求を実行してください。[9]、プログラムとサブルーチンの間接的な実行は容易にされるつもりです。 しかしながら、現行様式におけるこの要求は使用を制限するだけであったかもしれません。 サブルーチンかプログラム仲介プロトコルが、より広い使用に必要であるだろう、特徴を実行してください。 メトカルフェは今度の紙でこの問題を考えます。
[10] The pathname idea used in Multics is similar to that of labels in RFC 76 by Bouknight, Madden and Grossman.
[10] Multicsで使用されるパス名考えはRFC76でBouknight、Madden、およびグロースマンでラベルのものと同様です。
[11] We, however, urge the use of standard network ASCII.
[11] しかしながら、私たちは標準のネットワーク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.
[12] 入出力が伝えられる正確な方法は特定の仲介コンベンションに頼っているでしょう。 入出力ファイルの名前はデータ自体の代わりに伝えられるかもしれません。
[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.
[13] 反響がどんな「掛かっている」状態も解決しないとき、トランザクション(終わって、包含する)は「反響されません」。 代わりに、タイムアウトメカニズムは、ハングアップを避けるために推薦されます。
[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
[14] ここに示されたデータ型メカニズムはRFC83とNIC5772でHarslemとHeafnerによって勧められたデータ再構成サービスを取り替えません。 事実上、それは再構成の補足となります。 for
Bhushan [Page 16] RFC 114 A FILE TRANSFER PROTOCOL 16 April 1971
ファイル転送プロトコル1971年4月16日あたりBhushan[16ページ]RFC114
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.
EBCDICに例、データ再構成言語を表すことができて、Networkはフォームマシンが「認識するかもしれない」ASCIIかコードですいかなる他のも。 順次データは2進で伝えられるかもしれません、そして、フォームマシンは必要なフォームにそれを再構成するでしょう。 個々のホストサイトで単純形に関するデータの解釈、再構成、およびストレージを排除したいと思わないとき、私はデータ型、Harslemによって勧められた多く、およびHeafnerで入れました。
[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.
[15] ホストの内部の文字表示はASCIIにおいてさえ異なっているかもしれません。 例えば、PDP-10は7ビットのキャラクタを保存します、気にかけないように噛み付かれた36番目がある単語あたり5、Multicsが1単語あたり4に彼らを保存しますが、9ビットの分野でまさしく正当です。
[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.
[16] ソケット1がNETRJSへのきこりとソケット5に割り当てられたように思えます。 ソケット3はファイル転送プロセスのための正当な選択に見えます。
[17] The term program mediation was suggested by Bob Metcalfe who is intending to write a paper on this subject.
[17] 用語プログラム仲介はこの問題に関してレポートを書くつもりであるボブメトカルフェによって示されました。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Ryan Kato 6/01]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ライアン・加藤6/01によるオンラインRFCアーカイブへの]
Bhushan [Page 17]
Bhushan[17ページ]
一覧
スポンサーリンク
