RFC913 日本語訳
0913 Simple File Transfer Protocol. M. Lottor. September 1984. (Format: TXT=20929 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Mark K. Lottor
Request for Comments: 913 MIT
September 1984
Lottorがコメントのために要求するワーキンググループマークK.をネットワークでつないでください: 913 MIT1984年9月
Simple File Transfer Protocol
簡単なファイル転送プロトコル
STATUS OF THIS MEMO
このメモの状態
This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。
INTRODUCTION
序論
SFTP is a simple file transfer protocol. It fills the need of people wanting a protocol that is more useful than TFTP but easier to implement (and less powerful) than FTP. SFTP supports user access control, file transfers, directory listing, directory changing, file renaming and deleting.
SFTPは簡単なファイル転送プロトコルです。 それはTFTPより役に立ちますが、FTPより実装しやすくて(それほど強力でない)であるプロトコルが欲しい人々の必要性をいっぱいにしています。 SFTPはコントロール、ファイル転送、ディレクトリリスト、ディレクトリ変化、ファイル改名、および削除をユーザアクセスに支えます。
SFTP can be implemented with any reliable 8-bit byte stream oriented protocol, this document describes its TCP specification. SFTP uses only one TCP connection; whereas TFTP implements a connection over UDP, and FTP uses two TCP connections (one using the TELNET protocol).
バイト・ストリームが適応させたどんな信頼できる8ビットプロトコルでもSFTPを実装することができて、このドキュメントはTCP仕様を説明します。 SFTPは1つのTCP接続だけを使用します。 TFTPは2つのTCP接続(TELNETプロトコルを使用する1つ)をUDP、およびFTP用途の上の関係に実装しますが。
THE PROTOCOL
プロトコル
SFTP is used by opening a TCP connection to the remote hosts' SFTP port (115 decimal). You then send SFTP commands and wait for replies. SFTP commands sent to the remote server are always 4 ASCII letters (of any case) followed by a space, the argument(s), and a <NULL>. The argument can sometimes be null in which case the command is just 4 characters followed by <NULL>. Replies from the server are always a response character followed immediately by an ASCII message string terminated by a <NULL>. A reply can also be just a response character and a <NULL>.
SFTPは、リモートホストのSFTPポート(115小数)にTCP接続を開くことによって、使用されます。 あなたは、次に、コマンドをSFTPに送って、回答を待ちます。 いつもリモートサーバに送られたSFTPコマンドはスペース、議論、および<NULL>によっていうことになられた4個のASCII手紙(どんなケースのも)です。 議論は時々ヌルである場合があります、その場合、コマンドが<NULL>によっていうことになられたちょうど4つのキャラクタです。 いつもサーバからの回答はすぐ<NULL>によって終えられたASCIIメッセージストリングがいうことになった応答キャラクタです。 また、回答は、ただ応答キャラクタと<NULL>であるかもしれません。
<command> : = <cmd> [<SPACE> <args>] <NULL>
<コマンド>: = <cmd>[<スペース><args>]の<のヌル>。
<cmd> : = USER ! ACCT ! PASS ! TYPE ! LIST ! CDIR
KILL ! NAME ! DONE ! RETR ! STOR
<cmd>: = ユーザ!ACCT!パス!タイプ!リスト!CDIRはRETR!STORが行われた名前!を殺します。
<response> : = <response-code> [<message>] <NULL>
<応答>: = <応答コードの>[<メッセージ>]の<のヌル>。
<response-code> : = + | - | | !
<応答コード>: = + | - | | !
<message> can contain <CRLF>
<メッセージ>は<CRLF>を含むことができます。
Commands that can be sent to the server are listed below. The server
サーバに送ることができるコマンドは以下に記載されています。 サーバ
Lottor [Page 1]
Lottor[1ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
replies to each command with one of the possible response codes listed under each message. Along with the response, the server should optionally return a message explaining the error in more detail. Example message texts are listed but do not have to be followed. All characters used in messages are ASCII 7-bit with the high-order bit zero, in an 8 bit field.
可能な応答コードの1つによる各コマンドに関する回答は各メッセージの下で記載しました。 応答と共に、サーバはさらに詳細に誤りがわかるメッセージを任意に返すべきです。 例のメッセージ・テキストは、記載されていますが、従われる必要はありません。 メッセージで使用されるすべてのキャラクタが高位のビットゼロが8ビットの分野にある7ビットのASCIIです。
The response codes and their meanings:
応答コードとそれらの意味:
+ Success.
+ 成功。
- Error.
- 誤り。
An error occurred while processing your command.
誤りはあなたのコマンドを処理している間、発生しました。
Number.
数。
The number-sign is followed immediately by ASCII digits
representing a decimal number.
すぐ10進数を表すASCIIケタがナンバー記号のあとに続いています。
! Logged in.
中のLogged。
You have sent enough information to be able to log yourself in.
This is also used to mean you have sent enough information to
connect to a directory.
あなたは、自分にログインできるように情報を十分に送りました。 また、これは、あなたがディレクトリに接続できるくらいの情報を送ったことを意味するのに使用されます。
To use SFTP you first open a connection to the remote SFTP server. The server replies by sending either a positive or negative greeting, such as:
SFTPを使用するために、あなたは最初に、リモートSFTPサーバに接続を開きます。サーバは、以下などの肯定しているか否定している挨拶を送ることによって、返答します。
+MIT-XX SFTP Service
+ MIT-XX SFTP、サービス
(the first word should be the host name)
(最初の単語はホスト名であるべきです)
-MIT-XX Out to Lunch
-昼食へのMIT-XX
Lottor [Page 2]
Lottor[2ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
If the server send back a '-' response it will also close the connection, otherwise you must now send a USER command.
また、サーバが'--'応答を返送すると、それは接続を終えるでしょう。さもなければ、あなたは現在、USERコマンドを送らなければなりません。
USER user-id
USERユーザID
Your userid on the remote system.
リモートシステムの上のあなたのユーザID。
The reply to this command will be one of:
このコマンドに関する回答は1であるために望んでいます:
!<user-id> logged in
ログインされた<ユーザID>。
Meaning you don't need an account or password or you
specified a user-id not needing them.
あなたがアカウント、パスワードまたはあなたを必要としないことを意味するのがそれらを必要としないユーザIDを指定しました。
+User-id valid, send account and password
+ユーザID有効であることで、アカウントとパスワードを送ってください。
-Invalid user-id, try again
-無効のユーザID、トライ、再び。
If the remote system does not have user-id's then you should
send an identification such as your personal name or host name
as the argument, and the remote system would reply with '+'.
リモートシステムにユーザIDのものがないなら、あなたは議論としてのあなたの個人名かホスト名などの識別を送るべきです、そして、リモートシステムは'+'で返答するでしょう。
ACCT account
ACCTアカウント
The account you want to use (usually used for billing) on the
remote system.
あなたがリモートシステムの上で使用したい(通常、支払いに使用されます)アカウント。
Valid replies are:
有効な回答は以下の通りです。
! Account valid, logged-in
Account有効、そして、ログインします。
Account was ok or not needed. Skip the password.
アカウントは、間違いないか必要ではありませんでした。 パスワードをスキップしてください。
+Account valid, send password
+アカウント有効であることで、パスワードを送ってください。
Account ok or not needed. Send your password next.
OKに必要な状態で説明してください。 次に、パスワードを送ってください。
-Invalid account, try again
-病人は説明して、再試行してください。
Lottor [Page 3]
Lottor[3ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
PASS password
PASSパスワード
Your password on the remote system.
リモートシステムに関するあなたのパスワード。
Valid replies are:
有効な回答は以下の通りです。
! Logged in
ログインされました。
Password is ok and you can begin file transfers.
パスワードは間違いありません、そして、あなたはファイル転送を始めることができます。
+Send account
+はアカウントを送ります。
Password ok but you haven't specified the account.
パスワードの間違いないあなただけがアカウントを指定していません。
-Wrong password, try again
-パスワードを虐待してください、そして、再試行してください。
Lottor [Page 4]
Lottor[4ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
You cannot specify any of the following commands until you receive a '!' response from the remote system.
あなたはリモートシステムから'!'応答を受けるまで以下のコマンドのいずれも指定できません。
TYPE { A | B | C }
タイプA|B|C
The mapping of the stored file to the transmission byte stream
is controlled by the type. The default is binary if the type
is not specified.
トランスミッションバイト・ストリームへの保存されたファイルに関するマッピングはタイプによって制御されます。 タイプが指定されないなら、デフォルトは2進です。
A - ASCII
A--ASCII
The ASCII bytes are taken from the file in the source
system, transmitted over the connection, and stored in the
file in the destination system.
ASCIIバイトは、接続の上に送られたソースシステムのファイルから取られて、目的地システムのファイルに保存されます。
The data is the 7-bit ASCII codes, transmitted in the
low-order 7 bits of 8-bit bytes. The high-order bit of the
transmission byte must be zero, and need not be stored in
the file.
データは8ビットのバイトの下位の7ビットで伝えられた7ビットのASCIIコードです。 トランスミッションバイトの高位のビットは、ゼロでなければならなく、ファイルに保存される必要はありません。
The data is "NETASCII" and is to follow the same rules as
data sent on Telnet connections. The key requirement here
is that the local end of line is to be converted to the pair
of ASCII characters CR and LF when transmitted on the
connection.
データは、"NETASCII"であり、telnet接続に送られたデータと同じ規則に従うことです。 接続のときに伝えられると地方の行末がASCII文字のCRとLFの組に変えられることになっているという主要な要件がここにあります。
For example, TOPS-20 machines have 36-bit words. On TOPS-20
machines, The standard way of labeling the bits is 0 through
35 from high-order to low-order. On TOPS-20 the normal way
of storing ASCII data is to use 5 7-bit bytes per word. In
ASCII mode, the bytes transmitted would be [0-6], [7-13],
[14-20], [21-27], [28-34], (bit 35 would not be
transmitted), each of these 7-bit quantities would be
transmitted as the low-order 7 bits of an 8-bit byte (with
the high-order bit zero).
例えば、TOPS-20マシンには、36ビットの単語があります。 TOPS-20マシンの上では、高位から下位まで、ビットをラベルする標準の方法は、0〜35です。 TOPS-20では、ASCIIデータを保存する正常な方法は1単語あたり7ビットの5バイトを使用することです。 ASCIIモードで、伝えられたバイトは[0-6] [7-13] [14-20] [21-27]、[28-34](ビット35は伝えられない)、これらの7ビットの量のそれぞれが8ビットのバイト(高位のビットゼロがある)の下位の7ビットとして伝えられるだろうということでしょう。
For example, one disk page of a TOPS-20 file is 512 36-bit
words. But using only 35 bits per word for 7-bit bytes, a
page is 17920 bits or 2560 bytes.
例えば、TOPS-20ファイルの1ディスクのページは512の36ビットの単語です。 しかし、7ビットのバイトに1単語あたり35ビットだけを使用して、1ページは、17920ビットか2560バイトです。
Lottor [Page 5]
Lottor[5ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
B - BINARY
B--バイナリー
The 8-bit bytes are taken from the file in the source
system, transmitted over the connection, and stored in the
file in the destination system.
8ビットのバイトは、接続の上に送られたソースシステムのファイルから取られて、目的地システムのファイルに保存されます。
The data is in 8-bit units. In systems with word sizes
which are not a multiple of 8, some bits of the word will
not be transmitted.
データが8ビットのユニットにあります。 8の倍数でない語長があるシステムで、単語の数ビットは伝えられないでしょう。
For example, TOPS-20 machines have 36-bit words. In binary
mode, the bytes transmitted would be [0-7], [8-15], [16-23],
[24-31], (bits 32-35 would not be transmitted).
例えば、TOPS-20マシンには、36ビットの単語があります。 バイナリ・モードで、伝えられたバイトは[0-7]、[8-15]、[16-23]、[24-31](ビット32-35は伝えられない)でしょう。
For example, one disk page of a TOPS-20 file is 512 36-bit
words. But using only 32 bits per word for 8-bit bytes, a
page is 16384 bits or 2048 bytes.
例えば、TOPS-20ファイルの1ディスクのページは512の36ビットの単語です。 しかし、8ビットのバイトに1単語あたり32ビットだけを使用して、1ページは、16384ビットか2048バイトです。
C - CONTINUOUS
C--、連続
The bits are taken from the file in the source system
continuously, ignoring word boundaries, and sent over the
connection packed into 8-bit bytes. The destination system
stores the bits received into the file continuously,
ignoring word boundaries.
ビットを語境界を無視して、ソースシステムでファイルから絶え間なく取って、8ビットのバイトに詰め込まれた接続の上に送ります。 目的地システムは語境界を無視して、絶え間なくファイルの中に受け取られたビットを保存します。
For systems on machines with a word size that is a multiple
of 8 bits, the implementation of binary and continuous modes
should be identical.
8ビットの倍数である語長があるマシンの上のシステムにおいて、2進の、そして、連続したモードの実装は同じであるべきです。
For example, TOPS-20 machines have 36-bit words. In
continuous mode, the bytes transmitted would be [first word,
bits 0-7], [first word, bits 8-15], [first word, bits
16-23], [first word, bits 24-31], [first word, bits 32-35 +
second word, bits 0-3], [second word, bits 4-11], [second
word, bits 12-19], [second word, bits 20-27], [second word,
bits 28-35], then the pattern repeats.
例えば、TOPS-20マシンには、36ビットの単語があります。 連続モードで、伝えられたバイトはそうでしょう。[最初の単語、ビット0-7] [最初の単語、ビット8-15] [最初の単語、ビット16-23] [最初の単語、ビット24-31] [最初の単語、ビット32-35+は単語を後援します、ビット0-3]、[2番目の単語、ビット4-11]、[2番目の単語、ビット12-19]、[2番目の単語、ビット20-27]、[2番目の単語、ビット28-35]、そして、パターンは繰り返されます。
For example, one disk page of a TOPS-20 file is 512 36-bit
words. This is 18432 bits or 2304 8-bit bytes.
例えば、TOPS-20ファイルの1ディスクのページは512の36ビットの単語です。 これは、18432ビットか8ビットの2304バイトです。
Replies are:
回答は以下の通りです。
+Using { Ascii | Binary | Continuous } mode
+ 使用、アスキー| バイナリー|、連続、モード
-Type not valid
-有効でなく、タイプしてください。
Lottor [Page 6]
Lottor[6ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
LIST { F | V } directory-path
LIST、F| V、ディレクトリパス
A null directory-path will return the current connected
directory listing.
ヌルディレクトリパスは現在の接続ディレクトリリストを返すでしょう。
F specifies a standard formatted directory listing.
Fは標準のフォーマットされたディレクトリリストを指定します。
An error reply should be a '-' followed by the error message
from the remote systems directory command. A directory
listing is a '+' followed immediately by the current
directory path specification and a <CRLF>. Following the
directory path is a single line for each file in the
directory. Each line is just the file name followed by
<CRLF>. The listing is terminated with a <NULL> after the
last <CRLF>.
エラー応答はエラーメッセージがリモートシステムディレクトリコマンドからいうことになった'--'であるべきです。 ディレクトリリストはカレントディレクトリ経路仕様と<CRLF>によるすぐにいうことになられた'+'です。 ディレクトリパスに続くのは、ディレクトリの各ファイルのための単線です。 各系列はただ<CRLF>によっていうことになられたファイル名です。 リストは最後の<CRLF>の後の<NULL>で終えられます。
V specifies a verbose directory listing.
Vは冗長なディレクトリリストを指定します。
An error returns '-' as above. A verbose directory listing
is a '+' followed immediately by the current directory path
specification and a <CRLF>. It is then followed by one line
per file in the directory (a line ending in <CRLF>). The
line returned for each file can be of any format. Possible
information to return would be the file name, size,
protection, last write date, and name of last writer.
誤りは上の'--'を返します。 冗長なディレクトリリストはカレントディレクトリ経路仕様と<CRLF>によるすぐにいうことになられた'+'です。 そして、1ファイルあたり1つの系列がディレクトリ(<CRLF>の系列結末)でそれのあとに続いています。 各ファイルのために返された系列はどんな形式のものであることができます。 サイズ、保護は、最後に返す可能な情報がファイル名であると日付、および最後の作家の名前を書きます。
Lottor [Page 7]
Lottor[7ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
CDIR new-directory
CDIRの新しいディレクトリ
This will change the current working directory on the remote
host to the argument passed.
これは通過された議論へのリモートホストの上の現在の働くディレクトリを変えるでしょう。
Replies are:
回答は以下の通りです。
!Changed working dir to <new-directory>
<の新しいディレクトリの>へのChangedの働くdir
-Can't connect to directory because: (reason)
-ディレクトリに接続できない、: (理由)
+directory ok, send account/password
+ ディレクトリ、OK、アカウント/パスワードを送ってください。
If the server replies with '+' you should then send an ACCT or
PASS command. The server will wait for ACCT or PASS commands
until it returns a '-' or '!' response.
次に、サーバ回答がACCTかPASSを送るなら、命令してください。 '--'か'!'応答を返すまで、サーバはACCTかPASSコマンドを待っています。
Replies to ACCT could be:
ACCTへの回答は以下の通りであるかもしれません。
!Changed working dir to <new-directory>
<の新しいディレクトリの>へのChangedの働くdir
+account ok, send password
+はOKに説明して、パスワードを送ってください。
-invalid account
-無効のアカウント
Replies to PASS could be:
PASSへの回答は以下の通りであるかもしれません。
!Changed working dir to <new-directory>
<の新しいディレクトリの>へのChangedの働くdir
+password ok, send account
+ パスワード、OK、アカウントを送ってください。
-invalid password
-無効のパスワード
KILL file-spec
KILLファイル仕様
This will delete the file from the remote system.
これはリモートシステムからファイルを削除するでしょう。
Replies are:
回答は以下の通りです。
+<file-spec> deleted
+ >が削除した<ファイル仕様
-Not deleted because (reason)
-削除されません。(理由)
Lottor [Page 8]
Lottor[8ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
NAME old-file-spec
NAMEの古いファイル仕様
Renames the old-file-spec to be new-file-spec on the remote
system.
リモートシステムに関する新しいファイル仕様になるように古いファイル仕様を改名します。
Replies:
回答:
+File exists
+ ファイルは存在しています。
-Can't find <old-file-spec>
-<が古いファイルの仕様の>であることを見つけることができません。
NAME command is aborted, don't send TOBE.
NAMEコマンドは中止されて、戸部を送らないでください。
If you receive a '+' you then send:
'+'を受けるなら、あなたは発信します:
TOBE new-file-spec
戸部の新しいファイル仕様
The server replies with:
サーバは以下で返答します。
+<old-file-spec> renamed to <new-file-spec>
+ <の新しいファイルの仕様の>に改名された<の古いファイルの仕様の>。
-File wasn't renamed because (reason)
-ファイルは改名されませんでした。(理由)
DONE
します。
Tells the remote system you are done.
あなたが完了しているとリモートシステムに言います。
The remote system replies:
リモートシステムは返答します:
+(the message may be charge/accounting info)
+(メッセージは充電/会計インフォメーションであるかもしれません)
and then both systems close the connection.
そして、両方のシステムは接続を終えます。
Lottor [Page 9]
Lottor[9ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
RETR file-spec
RETRファイル仕様
Requests that the remote system send the specified file.
リモートシステムが指定されたファイルを送るという要求。
Receiving a '-' from the server should abort the RETR command
and the server will wait for another command.
サーバからの'--'を受けると、RETRコマンドは中止になるべきです、そして、サーバは別のコマンドを待っています。
The reply from the remote system is:
リモートシステムからの回答は以下の通りです。
<number-of-bytes-that-will-be-sent> (as ascii digits)
<番号、-、バイト、-、それ、-意志でいてください、-、>を送ります。(ASCIIケタとしての)
-File doesn't exist
-ファイルは存在していません。
You then reply to the remote system with:
そして、あなたは以下でリモートシステムに答えます。
SEND (ok, waiting for file)
発信してください。(ファイルを待っているOK
The file is then sent as a stream of exactly the number
of 8-bit bytes specified. When all bytes are received
control passes back to you (the remote system is waiting
for the next command). If you don't receive a byte
within a reasonable amount of time you should abort the
file transfer by closing the connection.
そして、ちょうど8ビットのバイトの数のストリームが指定したようにファイルを送ります。 すべてのバイトが受け取られているとき、コントロールはあなたに通って戻ります(リモートシステムは次のコマンドを待っています)。 妥当な時間以内に1バイト受信しないなら、あなたは、接続を終えることによって、ファイル転送を中止するべきです。
STOP (You don't have enough space to store file)
停止(あなたには、ファイルを保存できるくらいのスペースがありません)
Replies could be:
回答は以下の通りであるかもしれません。
+ok, RETR aborted
+ OK、中止されたRETR
You are then ready to send another command to the remote host.
あなたはその時、別のコマンドをリモートホストに送る準備ができています。
Lottor [Page 10]
Lottor[10ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
STOR { NEW | OLD | APP } file-spec
STOR NEW|OLD|APP、ファイル仕様
Tells the remote system to receive the following file and save
it under that name.
以下のファイルを受け取って、その名前の下でそれを保存するようにリモートシステムに言います。
Receiving a '-' should abort the STOR command sequence and the
server should wait for the next command.
'--'を受けると、STORコマンド・シーケンスは中止になるべきです、そして、サーバは次のコマンドを待つべきです。
NEW specifies it should create a new generation of the file and
not delete the existing one.
NEWはそれを指定します。ファイルの新しい世代を創設して、既存のものを削除するべきではありません。
Replies could be:
回答は以下の通りであるかもしれません。
+File exists, will create new generation of file
+ ファイルは存在していて、ファイルの新しい世代を創設するでしょう。
+File does not exist, will create new file
+ ファイルは存在していなくて、新しいファイルを作成するでしょう。
-File exists, but system doesn't support generations
-ファイルは存在していますが、システムは何世代もサポートしません。
OLD specifies it should write over the existing file, if any,
or else create a new file with the specified name.
OLDはそれを指定します。既存ファイルの上にもしあれば書くべきであるか、または指定された名前で新しいファイルを作成するべきです。
Replies could be:
回答は以下の通りであるかもしれません。
+Will write over old file
+ ウィルは食えない奴の上に書きます。
+Will create new file
+ ウィルは新しいファイルを作成します。
(OLD should always return a '+')
(OLDはいつも'+'を返すはずです)
APP specifies that what you send should be appended to the file
on the remote site. If the file doesn't exist it will be
created.
APPは、あなたが送るものがリモートサイトのファイルに追加されるべきであると指定します。 ファイルが存在していないと、それは作成されるでしょう。
Replies could be:
回答は以下の通りであるかもしれません。
+Will append to file
ウィルがファイルするために追加する+
+Will create file
+ ウィルはファイルを作成します。
(APP should always return a '+')
(APPはいつも'+'を返すはずです)
Lottor [Page 11]
Lottor[11ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
You then send:
次に、あなたは発信します:
SIZE <number-of-bytes-in-file> (as ASCII digits)
サイズ<番号、-、バイト入力ファイル、>。(ASCIIケタとしての)
where number-of-bytes-in-file
どこ、バイト入力ファイルの数
is the exact number of 8-bit bytes you will be
sending.
あなたが送る8ビットのバイトがはっきりした数ありますか?
The remote system replies:
リモートシステムは返答します:
+ok, waiting for file
+ ファイルを待つOK
You then send the file as exactly the number of bytes
specified above.
そして、ちょうどバイト数が上で指定したようにあなたはファイルを送ります。
When you are done the remote system should reply:
あなたが完了していると、リモートシステムは返答するはずです:
+Saved <file-spec>
+ 保存している<ファイル仕様>。
-Couldn't save because (reason)
-節約できませんでした。(理由)
-Not enough room, don't send it
-十分は同居するというわけではなくて、それを送らないでください。
This aborts the STOR sequence, the server is waiting for
your next command.
これはSTOR系列を中止して、サーバはあなたの次のコマンドを待っています。
You are then ready to send another command to the remote host.
あなたはその時、別のコマンドをリモートホストに送る準備ができています。
Lottor [Page 12]
Lottor[12ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
AN EXAMPLE
例
An example file transfer. 'S' is the sender, the user process. 'R' is the reply from the remote server. Remember all server replies are terminated with <NULL>. If the reply is more than one line each line ends with a <CRLF>.
例のファイル転送。 '、'送付者、ユーザ・プロセスはそうです。 'R'はリモートサーバからの回答です。すべてのサーバ回答が<NULL>で終えられたのを覚えていてください。 回答が1つ以上の系列であるなら、各系列は<CRLF>で終わります。
R: (listening for connection)
S: (opens connection to R)
R: +MIT-XX SFTP Service
S: USER MKL
R: +MKL ok, send password
S: PASS foo
R: ! MKL logged in
S: LIST F PS: <MKL>
R: +PS: <MKL>
Small.File
Large.File
S: LIST V
R: +PS: <MKL>
Small.File 1 69(7) P775240 2-Aug-84 20:08 MKL
Large.File 100 255999(8) P770000 9-Dec-84 06:04 MKL
S: RETR SMALL.FILE
R: 69
S: SEND
R: This is a small file, the file is sent without
a terminating null.
S: DONE
R: +MIT-XX closing connection
R: (接続の聞こうとします) S: (Rに接続を開きます) R: + MIT-XX SFTP、サービスS: ユーザMKL R: + MKL、OK、パスワードSを送ってください: PASS foo R: ! MKLはSにログインしました: F PSを記載してください: <MKL>R: + PS: <MKL>Small.File Large.File S: V Rを記載してください: + PS: <のMKLの>のSmall.Fileの1 69(7) P775240の1984年8月2日20時8分のMKL Large.File100 255999(8) P770000 1984年12月9日6時4分MKL S: RETR SMALL.FILE R: 69秒間: Rを送ってください: これが小さいファイルである、終わりヌルなしでファイルを送ります。 S: Rをします: + MIT-XX、接続を終えること。
Lottor [Page 13]
Lottor[13ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
EDITORS NOTE
エディタ注意
Mark Lotter receives full credit for all the good ideas in this memo. As RFC editor, i have made an number of format changes, a few wording changes, and one or two technical changes (mostly in the TYPEs). I accept full responsibility for any flaws i may have introduced.
マークLotterはこのメモによるすべての名案のために完全なクレジットを受けます。 RFCエディタとして、私は形式変化、いくつかの言葉遣い変化、および1か2回の技術変化(ほとんどTYPEsの)の数を作りました。 私は私が導入したどんな欠点への完全な責任も引き受けます。
A draft form of this memo was circulated for comments. I will attempt to list the issues raised and summarize the pros and cons, and resolution for each.
このメモの手形様式はコメントのために循環しました。 私は、それぞれのために提起された問題を記載して、賛否両論、および解決をまとめるのを試みるつもりです。
ASCII Commands vs Binary Operation Codes
ASCIIコマンド対ブール演算コード
The ASCII command style is easier to debug, the extra
programming cost in minimal, the extra transmission cost is
trivial.
ASCIIコマンドスタイルがデバッグ、最小量の付加的なプログラミング費用により簡単である、付加的なトランスミッション費用は些細です。
Binary operation codes are more efficient, and a few days of
debugging should not out weigh years of use.
ブール演算コードは、より効率的、そして、アウトが何年もの使用を熟慮するならデバッグする数日です。
Resolution: I have kept the ASCII Commands.
解決: 私はASCII Commandsを保ちました。
Additional Modes
追加モード
Pro: For some machines you can't send all the bits in a word
using this protocol. There should be some additional mode to
allow it.
プロ: いくつかのマシンに関しては、あなたは、一言で言えばこのプロトコルを使用することですべてのビット発信できません。 それを許容する何らかの追加モードがあるべきです。
Con: Forget it, this is supposed to be SIMPLE file transfer.
If you need those complex modes use real FTP.
以下をだましてください。 それを忘れてください、そして、これはSIMPLEファイル転送であるべきです。 あなたが複雑なそれらを必要とするなら、モードは本当のFTPを使用します。
Resolution: I have added the Continuous mode.
解決: 私はContinuousモードを加えました。
Lottor [Page 14]
Lottor[14ページ]
RFC 913 September 1984 Simple File Transfer Protocol
RFC913の1984年9月の簡単なファイル転送プロトコル
CRLF Conversion
CRLF変換
Pro: In ASCII type, convert the local end of line indicator to
CRLF on the way out of the host and onto the network.
プロ: ASCIIタイプで、ホストとネットワークへの途中でローカルの行末インディケータをCRLFに変換してください。
Con: If you require that you have to look at the bytes as you
send them, otherwise you can just send them. Most of the time
both sides will have the same end of line convention anyway.
If someone needs a conversion it can be done with a TECO macro
separately.
以下をだましてください。 それらを送るときあなたがバイトを見なければならないのが必要でしたら、さもなければ、あなたはただそれらを送ることができます。 たいてい、両側はとにかく同じ行末コンベンションを開くでしょう。 だれかが変換を必要とするなら、別々にTECOマクロでそれができます。
Resolution: I have required CRLF conversion in ASCII type. If
you have the same kind of machines and the same end of line
convention you can avoid the extra cost of conversion by using
the binary or continuous type.
解決: 私はASCIIタイプにおけるCRLF変換を必要としました。 同じ種類のマシンと同じ行末コンベンションがありましたら、あなたは、2進の、または、連続したタイプを使用することによって、付加的な転化費を避けることができます。
TCP Urgent
TCP緊急です。
Pro: Use TCP Urgent to abort a transfer, instead of aborting
the connection. Then one could retry the file, or try a
different file without having to login again.
プロ: TCP Urgentを使用して、接続を中止することの代わりに転送を中止してください。 そして、再びログインする必要はなくて、ものは、ファイルを再試行するか、または異なったファイルを試すかもしれません。
Con: That would couple SFTP to TCP too much. SFTP is supposed
to be able to be work over any reliable 8-bit data stream.
以下をだましてください。 それはTCPとSFTPを結合し過ぎるでしょう。 SFTPはどんな信頼できる8ビットのデータストリームの上の仕事であることでできるべきです。
Resolution: I have not made use of TCP Urgent.
解決: 私はTCP Urgentを利用していません。
Random Access
ランダムアクセス
Pro: Wouldn't it be nice if (WIBNIF) SFTP had a way of
accessing parts of a file?
プロ: (WIBNIF)SFTPにファイルの部分にアクセスする方法があるなら、良くないでしょうか?
Con: Forget it, this is supposed to be SIMPLE file transfer.
If you need random access use real FTP (oops, real FTP doesn't
have random access either -- invent another protocol?).
以下をだましてください。 それを忘れてください、そして、これはSIMPLEファイル転送であるべきです。 ランダムアクセスを必要とするなら、本当のFTPを使用してください(おっと、本当のFTPには、ランダムアクセスがありません(別のプロトコルを発明してください))。
Resolution: I have not made any provision for Random Access.
解決: 私はRandom Accessに少しも備えていません。
-- jon postel.
-- jon postel。
Lottor [Page 15]
Lottor[15ページ]
一覧
スポンサーリンク
