RFC414 日本語訳

Network Working Group                                         A. Bhushan
Request for Comments: 414                                        MIT-MAC
Updates: RFC 354, RFC 385                               29 November 1972
NIC: 12406

Bhushanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 414 MIT-MACアップデート: RFC354、RFC385 1972年11月29日NIC: 12406

        FILE TRANSFER PROTOCOL (FTP) STATUS AND FURTHER COMMENTS

ファイル転送プロトコル(FTP)状態とさらなるコメント

   A number of HOSTs have working server and user FTPs now.  The
   following reflects the status of FTP implementations to the best of
   my knowledge:

多くのHOSTsには、現在、働くサーバとユーザFTPがあります。 私の知っている限りでは、以下はFTP実装の状態を反映します:

      BBN(A and B), SRI-ARC, UTAH, CASE, USC-ISI, CCA, MIT-AI MIT-
      Mathlab, MIT-DMCG, CMU, AMES-67, and SU-AI have fully functionning
      server and user FTPs.

BBN(AとB)、SRI-ARC、ユタ、CASE、USC-ISI、CCA、MIT-AI MIT Mathlab、MIT-DMCG、米カーネギーメロン大学、エームズ-67、およびSU-AIには、完全にfunctionningしているサーバとユーザFTPがあります。

      MIT-Multics has user and server FTPs but the server does not
      listen on socket 3 (it can be started by normal login and the
      command ftp_server).  UCSB will soon have user and server FTP's.

MIT-Multicsには、ユーザとサーバFTPがありますが、サーバはソケット3の上に聴かれません(通常のログインとコマンドftp_サーバはそれを始めることができます)。 UCSBには、すぐ、ユーザとサーバFTPのものがあるでしょう。

   The servers at all the TENEX systems are more or less identical
   (developed by Bob Clements at BBN).  The servers at MIT-AI and MIT-ML
   are also identical (developed by Pitts Jarvis of MAC).  Others
   currently involved with FTP include Arvola Chan (AC@MIT-DMCG), Ken
   Pogran (Multics), Greg Hicks (HICKS@UTAH), Wayne Hathaway (AMES-67),
   Ralph Gorin (SU-AI), Rick Werme (CMU), and Ron Stoughton (UCSB).

すべてのTENEXシステムのサーバは多少同じです(BBNでボブ・クレメンツによって開発されます)。 また、MIT-AIとMIT-MLのサーバも同じです(MACのピッツジャービスによって開発された)。 現在FTPにかかわっている他のものはArvolaチェン( AC@MIT-DMCG )、ケンPogran(Multics)、グレッグ・ヒックス( HICKS@UTAH )、ウェインハザウェイ(エームズ-67)、ラルフ・ゴリン(SU-AI)、リックWerme(米カーネギーメロン大学)、およびロンストートン(UCSB)を入れます。

   The User-FTP or the user interface to FTP is where desirable and
   interesting features can be put in.  An example of such a features is
   the BBN (and other TENEXes) "SNDMSG USER@HOST" feature which allows a
   local user to send messages (or mail) to other network users.  If the
   remote host is not up, the message is stored as "--UNSENT-MAIL--
   USERHOST" in the user's directory and a background job periodically
   checks for such files to send mail.  MIT-AI and MIT-ML have a "TRANS"
   command which allows convenient transfer of files.  At MIT-DMCG we
   have developed under the "CALICO" subsystem, generalized commands
   which allow local users to send mail, copy files efficiently, and
   list users and directories over the network in a manner similar to
   local usage (that is without having to explicitly connect, login, and
   send commands to a remote HOST).  We also allow TELNET, FTP, and RJS
   users to automatically "login" and perform other command sequences
   from an "initial" file.

User-FTPかFTPへのユーザーインタフェースが望ましくておもしろい特徴を入れることができるところです。 BBN(そして、他のTENEXes)が「SNDMSG USER@HOST 」であるという地元のユーザがメッセージ(または、メール)を他のネットワーク利用者に送ることができるそのような特徴機能に関する例。 リモートホストが起きていないなら、そのようなファイルがメールを送るようにユーザのディレクトリとバックグラウンドジョブの「--UNSENT-メール--USERHOST」が定期的にチェックするようにメッセージは保存されます。 MIT-AIとMIT-MLにはaがある、「移-、」 ファイルの便利な転送を許容するコマンド。 MIT-DMCGでは、私たちは、ネットワークの上にローカルの用法(すなわちリモートホストに明らかに接して、ログインして、コマンドを送る必要はなくて)と同様の方法で「キャラコ」サブシステムの下で展開して、地元のユーザがメールを送ることができるコマンドを広めて、効率的にファイルをコピーして、ユーザとディレクトリをリストアップします。 私たちは、TELNET、FTP、およびRJSユーザに「初期」のファイルから自動的に「ログインし」て、また、他のコマンド・シーケンスを実行させます。

   It should be noted that file transfer between PDP-10's in "Image 36"
   is an order of magnitude faster (and more efficient) than in "ASCII
   8".  Note also that it is useful to provide a "Quote" or "talk" mode
   in user-FTP, to enable a user to input commands directly to the FTP
   server (i.e. commands not implemented in user-FTP).  It is desirable

それが注意されるべきである、PDP-10のコネの間のそのファイル転送、「イメージ36インチは、1桁より速い、そして、(「ASCII8インチ」より効率的)です。 また、「引用文」を提供するか、またはユーザFTPにおけるモードが「話」であることがユーザが直接FTPサーバ(すなわち、ユーザFTPで実装されなかったコマンド)にコマンドを入力するのを可能にするために役に立つことに注意してください。 それは望ましいです。

Bhushan                                                         [Page 1]

RFC 414             FTP Status and Further Comments        November 1972

Bhushan[1ページ]RFC414FTP状態とさらなるコメント1972年11月

   that user and server FTP features and desirable modes of usage be
   documented and reported via the RFC mechanism.

用法のユーザ、サーバFTP機能、および望ましいモードは、RFCメカニズムで記録されて、報告されます。

   The following suggestions and additions pertain to the File Transfer
   Protocol as stated in NWG/RFC 354 and NWG/RFC 385.  After receiving
   comments to this RFC, I will have the three RFC's combined into a
   single document and have it issued as the ARPANET Official File
   Transfer Protocol, very soon.  It should however be noted that FTP is
   an open-ended protocol with room for experimentation.  New commands,
   reply codes, data representation types, and file structures may be
   defined in future.  If two sites agree, they can define their own
   experimental set of commands, data types, file structures, and/or
   transfer modes.  Such additions to the protocol should be well
   documented and clearly specified so that other sites can also make
   use of the same.

以下の提案と追加はNWG/RFC354とNWG/RFC385の述べられるとしてのFile Transferプロトコルに関係します。 このRFCにコメントを受けた後に、私は、3RFCのものをただ一つのドキュメントに結合させて、すぐ、アルパネットOfficial File Transferプロトコルとしてそれを発行させるつもりです。 しかしながら、FTPが実験の余地がある制限のないプロトコルであることに注意されるべきです。 新しいコマンド、回答コード、データ表現タイプ、およびファイル構造はこれから、定義されるかもしれません。 2つのサイトが一致しているなら、それらはコマンド、データ型、ファイル構造、そして/または、それら自身の実験的な転送モードを定義できます。 プロトコルへのそのような追加は、また、他のサイトが同じくらい利用できるように、よく記録されて、明確に指定されるべきです。

   1) The FTP assumes line-at-a-time interaction with local acho.  The
      server is not obliged to provide remote echo and may ignore TELNET
      control characters.  A server however should not give error or bad
      response on receiving TELNET control characters.

1) FTPは地方のachoとの一度に系列相互作用を仮定します。 サーバは、リモートエコーを提供するのは強いられないで、TELNET制御文字を無視するかもしれません。 しかしながら、サーバはTELNET制御文字を受け取るときの誤りか誤応答を与えるべきではありません。

      The server does not explicitly provide any editing capability such
      as character delete or line kill characters.  All editing is
      assumed to be local.  TIP users should use FTP in line mode and
      send both <CR> and <LF> (by TIP commands @T O L and @I L).  In
      such a mode the TIP user can flush his current input line by the
      flush command (@F).

サーバが明らかにキャラクタなどの能力が削除するどんな編集も提供しないか、またはキャラクタは系列で死にます。 すべての編集が地方であると思われます。 TIPユーザは、ライン・モードでFTPを使用して、<CR>と<LF>の両方を送るべきです(TIPコマンド@T O Lと@I Lで)。 そのようなモードで、洗い流しコマンド(@F)でTIPユーザは彼の経常投入量系列を洗い流すことができます。

      The server should respond to the TELNET "SYNCH" by flushing the
      current command line and waiting for user input such as an "ABOR"
      command.  Other commands such as "BYE" or "STAT" may also
      constitute an acceptable input.

サーバは、現在のコマンドラインを洗い流して、"ABOR"コマンドなどのユーザ入力を待つことによって、TELNET「同時性」に反応するべきです。 また、「さようなら」か「スタット」などの他のコマンドは許容できる入力を構成するかもしれません。

   2) Commands such as "STAT" which will produce more than one line of
      output over the TELNET connection, require some way of positively
      indicating the end of status information.  It is proposed that a
      "200 status complete" reply give a positive indication for end of
      status information.  The reply to STAT should begin with a line
      starting with 1xx (where x=digit), with the following lines not
      having a digit as their first character, and the status ending
      with the 200 reply.  (Note that the requirement of three spaces is
      dropped in favour of the less restrictive requirement of the first
      character not being a digit.)  This change would make operations
      much easier for both user and server FTPs.

2) ウィル生産物1以上が立ち並ぶ「スタット」などのコマンドがtelnet接続の上で出力されて、明確に状態情報の終わりを示す何らかの方法を必要としてください。 「200状態完全な」回答が状態情報の終わりの積極的な指示を与えるよう提案されます。 系列が1xx(xがケタと等しいところ)から始まっていて、STATへの回答は始まるべきです、彼らの最初の性格としてケタを持っていて、200回答で状態結末は持っていない以下の系列で。 (3つの空間の要件がケタでない最初のキャラクタのそれほど制限していない要件を支持して下げられることに注意してください。) この変化で、操作はユーザとサーバFTPの両方にはるかに簡単になるでしょう。

   3) A reminder that BYE<CR><LF> is legal.  A space after a command
      name is not required if there is a null argument.

3) BYE<CR><LF>が法的であるということを思い出させるもの。 空の項があれば、コマンド名の後のスペースは必要ではありません。

Bhushan                                                         [Page 2]

RFC 414             FTP Status and Further Comments        November 1972

Bhushan[2ページ]RFC414FTP状態とさらなるコメント1972年11月

   4) The following response are proposed to the "STAT" and "LIST"
      commands (this was not clearly specified specially for the null
      argument case).  Responses to "STAT" and "LIST" shall always be
      over the TELNET and Data connections, respectively.  The "LIST"
      command with null argument should produce a list of files in
      user's current working or default directory.  The "STAT" command
      with null argument should (as suggested by Wayne Hathaway) produce
      tha status of all file transfer parameters (user, byte, size, data
      type, transfer mode, and file structure) if used between file
      transfers (i.e. no transfer in progress).  If STAT is sent during
      a file transfer operation (accompanied with TELNET synch), the
      server should respond with the status of the operation in
      progress.  If the argument of the "LIST" and "STAT" commands is a
      pathname, then a list associated with that pathname should be
      sent.

4) 以下の応答は「スタット」と「リスト」コマンドに提案されます(これは明確に特に空の項ケースに指定されませんでした)。 telnetとデータ接続の上にそれぞれ「スタット」と「リスト」への応答がいつもあるものとします。 空の項による「リスト」コマンドはユーザの現在の運用かデフォルトディレクトリのファイルのリストを作り出すべきです。 ファイル転送(すなわち、進行中の転送がない)の間で使用されるなら、空の項による「スタット」コマンドはすべてのファイル転送パラメタ(ユーザ、バイト、サイズ、データ型、転送モード、およびファイル構造)のtha状態を作り出すべきです(ウェインハザウェイによって示されるように)。 ファイル転送操作(TELNETの同時性で、伴われる)の間、STATを送るなら、操作の状態が進行していた状態で、サーバは反応するべきです。 「リスト」と「スタット」コマンドの議論がパス名であるなら、そのパス名に関連しているリストを送るべきです。

   5) Two new commands are hereby proposed.  First is a "HELP" command
      which should send to the user helpful hints about using the server
      and its implementation status (news).  The information will be
      sent over the TELNET connection starting with type 100 reply and
      ending with  a type 200 reply (completion).  It is suggested that
      the use of this command and the "MAIL" and "BYE" commands be
      allowed without the user having to "login" (i.e., supplying valid
      user, password, and account).

5) 2つの新しいコマンドがこれにより提案されます。 まず最初に、サーバとその実装状態(ニュース)を使用することに関してユーザの役立っているヒントに発信するべきである「援助」コマンドがあります。 タイプ200回答でタイプから100の回答と結末を始めるTELNET接続の上に情報を送るでしょう(完成)。 ユーザのいない「ログインします」でなければならないこと(すなわち、正規ユーザーを供給する、パスワード、およびアカウント)がこのコマンドの使用と「メール」と「さようなら」コマンドに許容されていることが提案されます。

      The other command (suggested by Bob Clements) is a new directory
      listing command called "NLST" which sends only the names of files
      (as valid pathname strings separated by CRLF) and no other useful
      but confusing information, so that it is possible to copy a whole
      directory automatically using this command and the store and
      retrieve commands.  The syntax and format of this command is
      identical to the "LIST" command (for some HOSTs they may be
      identical commands).

もう片方のコマンド(ボブ・クレメンツによって提案される)はファイル(有効なパス名ストリングがCRLFで分離したので)にもかかわらず、他の役に立ちますが、紛らわしい情報がない名前だけを送る"NLST"と呼ばれるコマンドを記載する新しいディレクトリです、自動的にこのコマンドと店を使用することで全体のディレクトリをコピーして、コマンドを検索するのが可能であるように。 このコマンドの構文と形式は「リスト」コマンドと同じです(何人かのホストにとって、彼らは同じコマンドであるかもしれません)。

   6) Although the minimum implementation does not require the TYPE,
      BYTE, MODE, and STRU commands, it is suggested that these commands
      be accepted with the default values by even those having a minimum
      implementation.  This would avoid some of the "ugly" error
      responses to input such as "TYPE A" and "STRU F", when these are
      perfectly acceptable to the server.

6) 最小の実装はTYPE、BYTE、MODE、およびSTRUコマンドを必要としませんが、これらのコマンドがデフォルト値で最小の実装を持っているものによってさえ受け入れられることが提案されます。 これは「タイプA」と「STRU F」としてそのようなものを入力するために「醜い」誤り応答のいくつかを避けるでしょう、これらがサーバに完全に許容できるとき。

   7) In using the "MLFL" and "LIST" commands, it is the user's (or
      user-FTP's) responsibility to ensure that the TYPE is ASCII (8-bit
      bytes).  If the TYPE is other than ASCII, the server may send an
      error response and refuse the command.  The user (or user-FTP)
      should therefore send the server "TYPE A" command if type is other
      than ASCII before sending the "MLFL" or "LIST" type commands.

7) "MLFL"と「リスト」コマンドを使用するのにおいて、タイプがASCII(8ビットのバイト)であることを保証するのは、ユーザ(または、FTPのユーザもの)の責任です。 ASCIIを除いて、TYPEがあるなら、サーバは、誤り応答を送って、コマンドを拒否するかもしれません。 したがって、"MLFL"か「リスト」タイプコマンドを送る前のASCIIを除いて、タイプがあるなら、ユーザ(または、ユーザFTP)はサーバ「タイプA」コマンドを送るべきです。

Bhushan                                                         [Page 3]

RFC 414             FTP Status and Further Comments        November 1972

Bhushan[3ページ]RFC414FTP状態とさらなるコメント1972年11月

   8) A useful suggestion is to allow multiple user names in the "MAIL"
      and "MLFL" commands.  Often a user wishes to send the same mail to
      a number of users at particular site.  It would be very convenient
      if he can do this by doing a single transfer and command.  It is
      strongly urged that server sites implement this option.

8) 役に立つ提案は「メール」と"MLFL"コマンドにおける複数のユーザ名を許容することです。 しばしば、ユーザは特定のサイトの多くのユーザに同じメールを送りたがっています。 彼が単一の転送とコマンドをすることによってこれができるなら、非常に便利でしょう。 強く、促されて、サーバサイトがこのオプションを実装するのは、そうです。

   9) Another suggestion that has been made is to standardize pathname
      syntax in FTP.  It appears that subdirectories will soon be
      introduced in the TENEX system.  Perhaps that will have some
      bearing on the standard pathname syntax.  The requirements of any
      pathname standard scheme are that it should allow convenient use
      of local pathname conventions, and not conflict with it.  A
      reasonable proposal seems to be to have the standard pathname
      start with a special character such as ">" (as in Multics), and to
      use this special character to separate the elements of a pathname.
      If the special character happens to ba valid part of a pathname
      element, use the literal quote convention of "'>" (single quote to
      precede the special character).

9) された別の提案はFTPにおけるパス名構文を標準化することです。 サブディレクトリがすぐTENEXシステムで紹介されるように見えます。 恐らく、それは標準のパス名構文に何らかの関係を持つでしょう。 どんなパス名の標準の体系の要件もそれで闘争ではなく、地方のパス名コンベンションの便利な使用を許すべきであるということです。 合理的な提案は標準のパス名に">"(Multicsのように)などの特殊文字から始まらせることになっていて、パス名の原理を切り離すのにこの特殊文字を使用するように思えます。 特殊文字がパス名要素のBaの有効な部分に起こるなら、「'>」(特殊文字に先行するただ一つの引用文)'の文字通りの引用文のコンベンションを使用してください。

      Examples of pathnames under this convention would be:

このコンベンションの下のパス名に関する例は以下の通りでしょう。

         >udd>CNet>Doe>foo_bar                       (for Multics)
         >DSK>JFD>foo bar                            (for ITS)
         >DOE>foo.bar1    (for TENEX)

>udd>CNet>ドウ>foo_バー(Multicsのための)>DSK>JFD>foo弁護士会(ITSのための)>DOE>foo.bar1(TENEXのための)

   10) The requirement of account numbers by TENEXes has caused a
       certain problems for automatons using FTP, under the present
       reply code sequences.  Therefore two new reply codes are defined
       to handle the account requirement.  A reply code of "331 Enter
       Account" shall be used if an account is required as part of user
       "login" sequence.  A reply code of "433 Cannot store files
       without valid account.  Enter account."  be used if an account is
       required only for a particular operation such as store.

10) TENEXesによる口座番号の要件はオートマトンのためにFTPを使用することで、ある問題を引き起こしました、現在の回答コード系列の下で。 したがって、2つの新しい回答コードが、アカウント要件を扱うために定義されます。 アカウントがユーザ「ログイン」系列の一部として必要であるなら、「331は勘定を記帳する」回答コードが使用されるものとします。 「433Cannotは有効なアカウントなしでファイルを保管する」回答コード。 「勘定を記帳してください。」アカウントが店などの特定の操作にだけ必要であるなら、使用されてください。

   11) The following suggestions made by Wayne Hathaway (RFC
       forthcoming) seem reasonable and should be included in the
       Protocol:

11) ウェインハザウェイ(RFC今度の)によってされた以下の提案は、妥当に思えて、プロトコルで含められるべきです:

       i) The following End-of-Record condition should be explicit on
       last record, and not implied in an End-of-File.  This change
       would simplify server implementation and improve reliability
       (better error control).

i) 以下の記録のEnd条件は、ファイルのEndで最後の記録で明白であって、暗示しているべきではありません。 この変化は、サーバ実装を簡素化して、信頼性(より良い誤り制御)を改良するでしょう。

       ii) Implementors of user-FTP's should note that it is trivial for
       them to implement record structures in ASCII type and Stream mode
       (the default CRLF convention for end-of-record).  All user-FTPs
       should allow store or retrieve of record structured files with
       ASCII type and stream mode.

ii) FTPのユーザものの作成者は、彼らが、ASCIIタイプとStreamモードによる記録的な構造が(記録の終わりのデフォルトCRLFコンベンション)であると実装するのが、些細であることに注意するべきです。 ユーザFTPが許容するべきであるすべてが、モードを保存するか、ASCIIタイプとの記録的な構造化ファイルを取って、または流します。

Bhushan                                                         [Page 4]

RFC 414             FTP Status and Further Comments        November 1972

Bhushan[4ページ]RFC414FTP状態とさらなるコメント1972年11月

       iii) It is possible to send record strutured "print-file" types
       (in addition to ASCII type) in either stream or text modes.  (RFC
       354 was not clear on this issue).

iii) どちらかのタイプ(ASCIIタイプに加えた)が流す記録的なstrutured「印刷ファイル」かテキストモードを送るのは可能です。 (RFC354はこの問題に関して明確ではありませんでした。)

       iv) The TELNET synch mechanism should be extended to other
       commands such as BYE and STAT in addition to ABOR.

iv) TELNET同時性メカニズムはABORに加えてBYEやSTATなどの他のコマンドに広げられるべきです。

       v) Comments are invited on the desirability of NOOP, CLSE, and
       SRVR commands.  In my opinion a STAT command with null argument
       serves the purpose of NOOP (to see if server is still alive), and
       BYE serves the purpose of CLSE (USER command should be used to
       change user name).  SRVR is a useful command.

v) コメントはNOOP、CLSE、およびSRVRコマンドの願わしさで招待されます。 私の意見では、空の項によるSTATコマンドはNOOP(サーバがまだ生きているかどうか確認する)の目的に役立ちます、そして、BYEはCLSEの目的に役立ちます(USERコマンドはユーザ名を変えるのに使用されるべきです)。 SRVRは役に立つコマンドです。

   12) Bob Clements raised the old issued of error detection and control
       again.  To handle this we can define two new descriptor codes in
       the Block mode, one that signals start of block check, and the
       other that indicates end of block check (and includes the block
       check bytes).  These codes may be ignored by any site not wishing
       to implement the error detection scheme.  Your comments on the
       error check scheme and the desirability of its inclusion in FTP
       are solicited.

12) ボブ・クレメンツは再び誤り検出とコントロールについて発行された老人を上げました。 これを扱うために、私たちはBlockモード、ブロック検査の始まりに合図する1つ、およびブロック検査の終わりを示すもう片方(そして、ブロック検査バイトを含んでいる)で2つの新しい記述子コードを定義できます。 これらのコードは誤り検出体系を実装したがっていないどんなサイトによっても無視されるかもしれません。 エラーチェック体系のあなたのコメントとFTPでの包含の願わしさは請求されます。

            [This RFC was put into machine readable form for entry]
       [into the online RFC archives by Helene Morin, Via Genie, 12/99]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリン、Via GenieによるオンラインRFCアーカイブへの12/99]

Bhushan                                                         [Page 5]

Bhushan[5ページ]