RFC385 日本語訳

NWG/RFC 385                                       Abhay K. Bhushan
NIC 11357                                                  MIT-MAC
Updates: RFC 354                                  August 18, 1972
RFC 354

NWG/RFC385Abhay K.Bhushan NIC11357MIT-MACアップデート: RFC354 1972年8月18日RFC354

            COMMENTS ON THE FILE TRANSFER PROTOCOL (RFC 354)
            ------------------------------------------------

ファイル転送プロトコル(RFC354)のコメント------------------------------------------------

   The following comments pertain to the File Transfer Protocol, NWG/RFC
   354.  The comments include errata, further discussion, emphasis
   points, and additions to the protocol.  I shall incorporate these
   comments into the main protocol document after we have had sufficient
   experience.

NWG/RFC354、以下のコメントはFile Transferプロトコルに関係します。 コメントは誤字、さらなる議論、強調ポイント、および追加をプロトコルに含んでいます。 私たちに十分な経験があった後に私は主なプロトコルドキュメントにこれらのコメントを組み入れるつもりです。

   1. Please note the following corrections:
       (i)    Page 2, line 15:  replace user-FTP by server-FTP.
       (ii)   Page 3, line 12:  replace III.A by III.C.
       (iii)  Page 15, last para, line 1:  replace user s by user is.
       (iv)   Page 28, line 21:  replace _CRCRLF_ by _CRLF_.
       (v)    Page 27, line 10:  replace 451,451 by 451.
       (vi)   Note that on Page 26, line 15 mode code is S|B|T|H.

1. 以下の修正に注意してください: (i) 2ページ 系列15: ユーザFTPをサーバFTPに取り替えてください。 (ii) 3ページ 系列12: III.AをIII.C.(iii)15ページ、最後のパラに取り替えてください、そして、1を裏打ちしてください: ユーザsをユーザに取り替えてください。あります。 (iv) 28ページ 系列21: _CRCRLF_を_CRLF_(v) 27ページに取り替えてください、そして、10を裏打ちしてください: 45万1451×451を取り替えてください。 (vi) 系列15モードコードが26ページでは、Sであることに注意してください。|B|T|H。

   2. The language of RFC 354 reads that it is recommended for
      hosts to implement the default parameters.  The sense of the
      word recommended should be taken as required.  Thus the
      required minimum implementations for FTP servers is:

2. RFC354の言語は、ホストが、デフォルトがパラメタであると実装するのが、お勧めであると読みます。 必要に応じてお勧めという単語の意味を取るべきです。 したがって、FTPサーバのための必要な最小の実装は以下の通りです。

           Type - ASCII (8-bit bytes)
           Mode - Stream
           Structure - File
           Commands - RETR, STOR, USER (and PASS), SOCK and BYE

タイプ--ASCII(8ビットのバイト)モード--ストリームStructure--ファイルCommands--RETR、STOR、USER(そして、PASS)、SOCK、およびBYE

   3. The "Print File-ASCII" and "EBCIDIC Print File" types are
      incorrectly specified (pages 10 and 11, RFC 354).  The real
      problem with print files is of ASA (Fortran) vertical format
      control.  Instead of the two print file types, there should
      really be three types as described below:

3. 「印刷ファイルASCII」と「EBCIDIC印刷ファイル」タイプは不当に指定されます(10と11ページ、RFC354)。 印刷ファイルの実際の問題はASA(Fortran)垂直書式コントロールのものです。 2つの印刷ファイルタイプの代わりに、3つのタイプが本当に以下で説明されるようにあるべきです:

           BCDIC - The sender transfers data using the EBCDIC
                    character code and 8-bit transfer byte size.
                    The _CRLF_ convention is used for vertical format
                    control.  This type will be used for efficient
                    transfer of EBCDIC files between systems which
                    use EBCDIC for their internal character
                    representation.

BCDIC--送付者は、EBCDlC文字コードと8ビットの転送バイトサイズを使用することでデータを移します。 _CRLF_コンベンションは垂直書式コントロールに使用されます。 このタイプは彼らの内部の文字表示にEBCDICを使用するシステムの間のEBCDICファイルの効率的な転送に使用されるでしょう。

                                                                [Page 1]

NWG/RFC 385 Page 2

[1ページ] NWG/RFC385 2ページ

           ASCII with ASA vertical format Control - This is the
                    "Print file-ASCII" defined in RFC 354.  The
                    server is to transform the data in accordance
                    with ASA (Fortran) vertical format control
                    procedures for printing on printers that
                    still use this standard.  The data is to be
                    transferred as 8-bit bytes.

ASA垂直書式ControlがあるASCII--これはRFC354で定義された「印刷ファイルASCII」です。 サーバはASA(Fortran)垂直書式コントロール手順に応じて印刷のためにまだこの規格を使用しているプリンタでデータを変えることです。 データは8ビットのバイトとして移すことです。

           EBCDIC with ASA vertical format control - This is the
                    EBCDIC Print File defined in RFC 354.  The
                    server is to transform the data in accordance
                    with ASA (Fortran) vertical format control
                    standards but using the EBCDIC character code.
                    The data is to be transferred in 8-bit bytes.

ASA垂直書式コントロールがあるEBCDIC--これはRFC354で定義されたEBCDIC Print Fileです。 サーバはASA(Fortran)垂直書式制御基準にもかかわらず、EBCDlC文字コードを使用するのに応じてデータを変えることです。 データは8ビットのバイトで移すことです。

      The new types are to be denoted by symbols E for EBCDIC, P
      for Print file-ASCII and F for Formatted (ASA standard)
      EBCDIC print file.  A discussion of the ASA vertical format
      control appears in NWG/RFC 189, Appendix C, and in
      Communications of the ACM, Vol 7, No. 10, p. 606, October
      1964.  According to the ASA vertical format control
      standards, the first character of a formatted record is not
      printed but determines vertical spacing as follows:

新しいタイプはEBCDICのためにシンボルEで指示されることになっていて、PrintファイルASCIIのためのPとFormatted(ASA規格)EBCDIC印刷のためのFはファイルされます。 ASA垂直書式コントロールの議論はNWG/RFC189、Appendix CとACMのCommunicationsに現れます、Vol7、No.10、p。 606 1964年10月。 ASA垂直書式制御基準によると、書式付きレコードの最初のキャラクタは、印刷されませんが、以下の行送りを決定します:

           Character    Vertical Spacing before printing
           ---------    --------------------------------
            Blank          One line
              0            Two lines
              1            To first line of next page
              +            No advance

印刷の前のキャラクターVertical Spacing--------- -------------------------------- 空白のOne系列0Twoは次のページ+いいえ、進歩のTo1最初の系列を裏打ちします。

      In addition to the above four, there are more characters
      (defined in Appendix C, RFC 189) which represent an IBM
      extension to the ASA standard.

上の4に加えて、IBMの拡大をASA規格に表すより多くのキャラクタ(Appendix C、RFC189では、定義される)があります。

   4. A comparison of "stream" and "text" modes is in order.  The
      advantages of "stream" mode are:
           1) The receiver need not scan the incoming bytes.
           2) It is usable with all data types.

4. 「ストリーム」と「テキスト」モードの比較は整然としています。 「ストリーム」モードの利点は以下の通りです。 1) 受信機は入って来るバイトをスキャンする必要はありません。 2) それはすべてのデータ型で使用可能です。

      The disadvantages are:
           1) The EOF by closing the connection is not reliable.

損失は以下の通りです。 1) 接続を終えるのによるEOFは信頼できません。

           2) The EOR by ASCII _CRLF_ is unreliable as the _CRLF_
              really may be valid data rather than an EOR.  It is
              an EOR only if the sender and receiver have a _prior_
              agreement to that effect.

2) ASCII_CRLF_によるEORは、_CRLF_が本当にEORよりむしろ有効データであるかもしれなくて、頼り無いです。 送付者と受信機に_の先の_協定がその趣旨である場合にだけ、それはEORです。

                                                                [Page 2]

NWG/RFC 385 Page 2

[2ページ] NWG/RFC385 2ページ

   5. In the Block mode the protocol states that left-most bits not
      containing information should be zero.  It appears that some
      sites have difficulty sending null bytes in the beginning of
      a block.  Since it is really not necessary for these bytes to
      be zero, these bits are now defined to be "don't care" bits.

5. Blockモードで、プロトコルは、最も残されて、情報を含まないビットがゼロであるべきであると述べます。 いくつかのサイトには初めに1ブロックの困難の送付のヌルバイトがあるように見えます。 これらのバイトがゼロであることは本当に必要でないので、これらのビットは現在、「気にかけないでください」というビットになるように定義されます。

   6. In the use of block mode it is possible for two or more
      conditions requiring different descriptor codes (suspected
      errors and either end of record or end of file) to exist
      simultaneously.  Such a possibility may be handled by sending
      a separate EOR or EOF block with a zero byte count (this is
      allowed by the protocol).  Also it should be noted that an
      EOF is an implicit EOR.

6. ブロックモードの使用で、異なった記述子コード(疑われた誤りと記録の終わりかファイルの終りのどちらか)を必要とする2つ以上の状態に、同時に存在するのは可能です。 そのような可能性は、ゼロがある別々のEORかEOFブロックにバイト・カウントを送ることによって、扱われるかもしれません(これはプロトコルによって許容されています)。 また、EOFが暗黙のEORであることに注意されるべきです。

   7. It needs to be emphasized again that the user-FTP must
      "listen" on the data socket prior to sending a command
      requiring a file transfer.  Specifically the user-FTP should
      not wait for a 255 reply (server data socket) before doing
      the "listen".  (The security check may be come later, as the
      data connection can be closed if connection is to a socket
      other than that specified by the 255 reply).  Although the
      protocol suggests that the 255 reply would be sent before
      making the connection, it does not guarantee that the 255
      reply would arrive before the initiating RFC at the user
      site.  The above argument also applies to receiving a a close
      (NCP-CLS) on the data connection before receiving a reply
      indicating the reason for the close (note assertion on page
      24, paragraph 3, RFC 354).

7. それは、再び強調される必要があります。コマンドにファイル転送を必要とさせる前に、ユーザFTPはデータソケットの上に「聴かれなければなりません」。 明確にユーザFTPは「聴く」前に、255回答(サーバデータソケット)を待つべきではありません。 (セキュリティチェックがそう、後で来てください、255回答で指定されるのを除いて、ソケットに接続があるならデータ接続が閉店できるとき) プロトコルは、接続を作る前に255回答が送られると示唆しますが、それは、255回答がユーザの現場の開始しているRFCの前で到着するのを保証しません。 また、上の議論は閉鎖の理由を示す回答を受け取る前にデータの閉鎖(NCP-CLS)接続を受けるのに適用されます(24ページにおける主張に注意してください、パラグラフ3、RFC354)。

   8. Although the protocol does not restrict closing or leaving
      open the data connection in Block and Text modes, it should
      be emphasized that the closing of the data connection, if it
      is to be done at all, should be done immediately after the
      file transfer rather than just after a new transfer command
      is received.  This is because the server and user may have to
      test whether the data connection is open or not before doing
      a "listen" or an "init" respectively.

8. プロトコルはそうしませんが、閉鎖を制限してください。さもないと、戸外のBlockでのデータ接続とTextをモードに残して、少しでも完了しているつもりであるならファイル転送直後コマンドが新しい転送のすぐ後に受け取られているよりむしろデータ接続の閉鎖をするべきであると強調されるべきです。 これはそれぞれ「聴取」か「イニット」をする前にデータ接続がオープンであるか否かに関係なく、サーバとユーザがテストしなければならないかもしれないからです。

   9. It should be emphasized again that 'Type' supersedes 'Byte',
      and that the TYPE command should be sent before the BYTE
      command.

9. BYTEが命令する前に'タイプ'が'バイト'に取って代わって、TYPEコマンドが送られるべきであると再び強調されるべきです。

   10. It should be noted that both upper and lower case alphabetic
       characters are to be treated identically in the command
       syntax.  This applies also to the symbols for type, mode,
       and structure.  For example, 'A' and 'a' both indicate ASCII
       type.

10. 両方の大文字と小文字英字が同様にコマンド構文で扱われることであることに注意されるべきです。 また、これはタイプ、モード、および構造のシンボルに適用されます。 例えば、'A'と'a'の両方がASCIIタイプを示します。

                                                                [Page 3]

NWG/RFC 385 Page 2

[3ページ] NWG/RFC385 2ページ

   11. It should be noted that in the 'LIST' command, the data
       transfer is over the data connection in type ASCII.

11. 'LIST'コマンドデータ転送がタイプASCIIというデータ接続の上で中であることに注意されるべきです。

   12. The following reply code is to be added:

12. 以下の回答コードは加えられることです:

               454 FTP:  Cannot connect to your data socket.

454FTP: あなたのデータソケットに接続できません。

       This is a fail response any of the commands requiring data
       transfer (including RETR, STOR, APPE, and LIST)

これによるaが応答をいくらかしそこなうということである、データ転送を必要とするコマンド(RETR、STOR、APPE、およびリストを含んでいます)

   13. Rather than use the append command for sending mail files, a
       new command 'MLFL' (for mail file) is defined.  The syntax
       of the mail file command is:

13. むしろ、新しいコマンド'MLFL'(メールファイルのための)は送付メールファイルに追加コマンドを使用するより定義されます。 メールファイルコマンドの構文は以下の通りです。

               MLFL <user>CRLF
               where
               <user> ::= <empty>| <NIC ident>| <sys ident>

MLFL<ユーザ>CRLF、どこ<ユーザ>:、:= <空です。>| <NIC ident>| <sys ident>。

       If the user field is empty or blank (one or more spaces),
       then the mail is destined for a printer or other designated
       place for site mail.  <NIC ident> refers to the standard
       identification described in the NIC Directory of Network
       Participant.  A serving host may keep a table mapping <NIC
       ident> into <sys ident>.  This would provide for uniform
       convenient usage.  <sys ident> is the user's normal
       identification at the serving HOST.  The use of <sys ident>
       would allow a network user to send mail to other users who
       do not have NIC identification but whose <sys ident> is
       known.

ユーザ分野が人影がないか、または空白であるなら(1つ以上の空間)、メールはサイトメールのためのプリンタか他の集合場所に運命づけられています。 <NIC ident>はNetwork ParticipantのNICディレクトリで説明された標準の識別について言及します。 給仕のホストはテーブルに<NIC ident>を<sys ident>に写像させ続けるかもしれません。 これは一定の便利な用法に備えるでしょう。 <sys ident>は給仕HOSTでのユーザの通常の識別です。<sys ident>の使用は、ネットワーク利用者がNIC識別を持っていませんが、<sys ident>が知られている他のユーザにメールを送るのを許容するでしょう。

       The intent of this command is to enable a user at the user
       site to mail data (in form of a file) to another user at the
       server site.  It should be noted that the files to be mailed
       are transmitted via the data connection in ASCII type.
       These files should be appended to the destination user's
       mail by the server in accordance with serving Host mail
       conventions.  The mail my be marked as sent from the
       particular using HOST and the user specified by the 'USER'
       command.  The reply codes for the "MLFL" command are
       identical to that in the "APPE" command, as shown below:

このコマンドの意図はユーザの現場のユーザがデータ(ファイルの形の)をサーバサイトの別のユーザに郵送するのを可能にすることです。 郵送されるファイルがASCIIタイプというデータ接続で送られることに注意されるべきです。 メールコンベンションにHostに役立つのに応じて、サーバは目的地ユーザのメールにこれらのファイルを追加するべきです。 メール、私、'USER'コマンドで指定された特定の使用HOSTとユーザから送るように、マークされてください。 "MLFL"コマンドのための回答コードは以下に示されるように"APPE"コマンドがそれと同じです:

              COMMAND         SUCCESS         FAIL
              -------         -------         ----
               MLFL            250             451,454,500-506
                Sec. reply     252             452,453

コマンド成功は失敗します。------- ------- ---- MLFL250 451,454,500-506Sec回答252 45万2453

   14. The 'MLFL' command for network mail, though a useful and
       essential addition to the FTP command repertoire, does not

14. FTPコマンドレパートリーへの役に立って不可欠の追加ですが、ネットワークのためのコマンドが郵送する'MLFL'はそうしません。

                                                                [Page 4]

NWG/RFC 385 Page 2

[4ページ] NWG/RFC385 2ページ

       allow TIP users to send mail conveniently without using
       third hosts.  It would be more convenient for TIP users to
       send mail over the TELNET connection instead of the data
       connection as provided by the 'MLFL' command.  The following
       'MAIL' command is therefore defined to send mail via the
       TELNET connection:

3番目のホストを使用しないで、TIPユーザにメールを便利に送らせてください。 TIPユーザには、データ接続の代わりにTELNET接続の上にメールを送るのは'MLFL'コマンドで提供するように、より都合がよいでしょう。 したがって、以下の'メール'コマンドはTELNET接続でメールを送るために定義されます:

               MAIL <user>CRLF

メール<ユーザ>CRLF

       the syntax of <user> is identical to that in the MLFL
       command described above.  After the 'MAIL' command is
       received, the server is to treat the following lines as text
       of the mail sent by the user.  The mail text is to be
       terminated by a line containing only a single period, that
       is the character sequence ".CRLF" in a new line.  The
       following new reply codes are defined to handle the mail
       command:

<ユーザ>の構文は上で説明されたMLFLコマンドがそれと同じです。 'メール'コマンドが受け取られていた後に、サーバはユーザによって送られたメールの原本として以下の系列を扱うことです。 メールテキストは復帰改行にすなわち、ただ一つの期間だけ、キャラクタシーケンス".CRLF"を含む系列によって終えられることです。 以下の新しい回答コードはメールコマンドを扱うために定義されます:

          350 Enter mail, terminate by a line with only a '.'
          256 Mail completed.

'350はメールを入力して、'.'256だけがメール完成していた状態で、系列で終わってください。

       The reply codes are:

回答コードは以下の通りです。

              COMMAND         SUCCESS         FAIL
              -------         -------         ----
               MAIL            350             450,451,500-506
                Sec Reply      256

コマンド成功は失敗します。------- ------- ---- 450,451,500-506秒の間のメール350回答256

   15. An additional access control command called account (ACCT)
       is now defined to facilitate accounting in systems such as
       TENEX which require in addition to user and password, a
       separate account specification.  The 'ACCT' command is
       different from the 'PASS' command in that it is not
       necessarily related to the 'USER' command and may arrive at
       any time.  For example, a user may transfer different files
       using different accounts.  The 'ACCT' command has the same
       reply codes as the 'PASS' command (230 for success and 430-
       432,500-506 for fail).  Some servers may require that an
       account command must be sent before the user is "logged in".
       For suchcases the success reply to the 'PASS' command could
       be '330 Enter account'.

15. アカウント(ACCT)と呼ばれる追加アクセス制御コマンドは、現在、ユーザとパスワード、別口の口座に加えて仕様を必要とするTENEXなどのシステムで説明するのを容易にするために定義されます。 'ACCT'コマンドは'PASS'コマンドと必ず'USER'コマンドに関連するというわけではなくて、いつでも到達するかもしれないという点において異なっています。 例えば、ユーザは、口座相違を使用することで異なったファイルを移すかもしれません。 'ACCT'コマンドには'PASS'コマンドと同じ回答コードがある、(成功と430- 432,500-506のための230、やり損ないのために) いくつかのサーバが、ユーザが「ログインされる」前にアカウントコマンドを送らなければならないのを必要とするかもしれません。 suchcasesに関しては、'PASS'コマンドに関する成功回答は'330Enterアカウント'であるかもしれません。

   16. Since password information is quite sensitive, it is
       desirable in general to "mask" it or suppress type out.  It
       appears that the server has really no fool-proof effective
       way to achieve this.  It is therefore the user-FTP process
       responsibility to hide the sensitive password information.

16. パスワード情報がかなり機密であるので、一般に、それに「マスクをかける」か、または外でタイプを抑圧するのが望ましいです。 サーバにはこれを達成する本当にどんなきわめて簡単な効果的な方法もないように見えます。 したがって、機密のパスワード情報を隠すのは、ユーザFTPプロセス責任です。

                                                                [Page 5]

NWG/RFC 385 Page 2

[5ページ] NWG/RFC385 2ページ

   17. The FTP is an open-ended protocol designed for easy
       expandability.  Experimental commands may be defined by
       sites wishing to implement such commands.  These
       experimental commands should begin with the alphabetic
       character 'X'.  Standard reply codes may be used with these
       commands.  If new reply codes need to assigned, these
       should be chosen between 900 and 999.  If the experimental
       command is useful and of general interest, it shall be
       included in the FTP command repertoire.

17. FTPは簡単な拡張可能性のために設計された制限のないプロトコルです。 実験的なコマンドはそのようなコマンドを実装したがっているサイトによって定義されるかもしれません。 これらの実験的なコマンドは英字'X'で始まるべきです。 標準の回答コードはこれらのコマンドと共に使用されるかもしれません。 新しい回答コードが、割り当てられた状態で必要があるなら、これらは900と999の間選ばれるべきです。 実験的なコマンドが役に立って、一般的興味では、それがFTPコマンドレパートリーに含まれているものとするなら。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by BBN Corp. under the   ]
       [ direction of Alex McKenzie.                      1/97 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[BBN社の下によるオンラインRFCアーカイブ、][ アレックス・マッケンジーの方向。 1/97 ]

                                                                [Page 6]

[6ページ]