RFC463 日本語訳

Network Working Group                                  Abhay K. Bhushan
RFC # 463                                              MIT-DMCG
NIC # 14573                                            February 21, 1973

1973年2月21日のネットワークワーキンググループAbhay K.Bhushan RFC#463MIT-DMCG NIC#14573

                  FTP Comments and Response to RFC 430

FTPコメントとRFC430への応答

    Most of the comments in RFC 430 by Bob Braden are useful suggestions
which should be included in the forthcoming official FTP specification.
This RFC represents my response to Braden's comments and other views.
These comments should be useful for the FTP meeting on March 16 at BBN
(announcement warning AAM NIC #14417). The results of the FTP subgroup
meeting held at BBN on January 25 will be published in RFC 4541 (are
published?).

ボブ・ブレーデンによるRFC430のコメントの大部分は今度の公式のFTP仕様に含まれるべきである役に立つ提案です。 このRFCはブレーデンのコメントと他の視点への私の応答を表します。 これらのコメントは3月16日にBBN(発表警告AAM NIC#14417)でFTPミーティングの役に立つべきです。 1月25日にBBNで行われたFTPサブグループ会合の結果はRFC4541(発行されますか?)で発表されるでしょう。

SPECIFIC RESPONSES TO RFC 430.

RFC430への特定の応答。

    Item A1 - I will let Bob Braden handle the "print file" issues (the
    "still" should be removed).

項目A1--私はボブ・ブレーデンに「印刷ファイル」問題を扱わせるつもりです(「スチール写真」を取り除くべきです)。

    Item A2 - I agree that concessions are undesirable and should be
    removed unless people cannot "live" without them.

項目A2--人々が彼らなしで「住むことができる」なら、私は、譲歩が望ましくないのに同意して、外されるべきです。

    Item A3 - I strongly support "bit flag coding" for descriptors.
    Other definition improvement suggestions are ok too.

項目A3--私は強く記述子のための「噛み付いている旗のコード化」をサポートします。 また、他の定義改良提案は間違いありません。

    Item A4 - The diagram was useful. An alternate one is given on page
    17 of RFC 454. I prefer the latter.

項目A4--ダイヤグラムは役に立ちました。 17RFCページで454代替のものを与えます。 私は後者を好みます。

    Item A5 -  The FTP may not be privileged enough to alter passwords
    in many Host systems (e.g. Multics). I know that CCN allows changing
    passwords on-line. We can define a format for changing passwords in
    the pass command, but I don't think we can require that all servers
    allow password changing. This is a minor problem that can be easily
    solved.

項目A5--FTPは多くのHostシステム(例えば、Multics)のパスワードを変更するくらいには特権がないかもしれません。 私は、CCNがパスワードをオンラインで変えさせるのを知っています。 私たちはパスワードを変えるために通過コマンドで書式を定義できますが、私たちが、すべてのサーバがパスワード変化を許すのを必要とすることができると思いません。 これは容易に解決できる小さな問題です。

    Item A6 - Yes, the comment that TYPE should be before BYTE was for
    bad implementations. The server should reject data transfer
    parameters only when the data transfer command is received. The
    order of the parameter-change commands is not important.

項目A6--はい、TYPEがBYTEの前にあるはずであるというコメントは悪い実装のためのものでした。 データ転送コマンドが受け取られているときだけ、サーバはデータ転送パラメタを拒絶するべきです。 パラメータ変動コマンドの注文は重要ではありません。

    Item A7 - I do agree that NCP's should be fixed.  A 255 (socket
    number) reply should be required at a specific time, and NCP's
    should be able to provide it (this also permits the proposed GSOC
    command). Let us find out at next meeting if there is anyone who
    cannot live with this new requirement.

項目A7--私は、NCPのものが修理されるべきであるのに同意します。 255(ソケット番号)回答が特定の時に必要であるべきです、そして、NCPのものはそれを提供できるべきです(また、これは提案されたGSOCコマンドを可能にします)。 次のミーティングでは、この新しい要件を受け入れることができないだれかがいるかどうか見つけましょう。

Bhushan                                                         [Page 1]

RFC 463           FTP Comments and Response to RFC 430     February 1973

Bhushan[1ページ]RFC463FTPコメントとRFC430 1973年2月への応答

    Item A8 - Yes.

項目A8--はい。

    Item B - There are at least two ways to solve the FTP parameter
    encoding problem presented by Bob Braden. One is to allow multiple
    letter in the TYPE command as suggested by Bob and the other is to
    have a new command such as FORM (which could be P or U). Other
    solutions are equally acceptable to me.

項目B--ボブ・ブレーデンによって提示されたFTPパラメタコード化問題を解決する少なくとも2つの方法があります。 ボブによって提案されるように1つはTYPEコマンドで複数の手紙を許容することになっています、そして、もう片方はFORM(PかUであるかもしれない)などの新しいコマンドを持つことです。 他のソリューションは等しく許容できます。

    Item C - Our emphasis should be on working protocol as well as
    elegance. I like the proposed GSOC command over the listen.  In fact
    GSOC can be used for all data connection security checking. The 255
    reply should be sent with GSOC only, and the server should use only
    those sockets for data connection.

項目C--私たちの強調が優雅と同様に働くプロトコルにあるべきです。 私が、提案されたGSOCコマンドが終わっているのが好きである、聴いてください。 事実上、すべてのデータ接続セキュリティー検査にGSOCを使用できます。 GSOCだけと共に255回答を送るべきです、そして、サーバはデータ接続にそれらのソケットだけを使用するべきです。

    Item D - We need more discussion on the issue of site dependent FTP
    parameters. I will put it on the agenda for the forthcoming FTP
    meeting.

項目D--私たちはサイトに依存するFTPパラメタの問題についての、より多くの議論を必要とします。 私はそれを今度のFTPミーティングのための議題にするつもりです。

FURTHER COMMENTS

さらなるコメント

    1. The command-reply sequence needs to be tightened in both
    specification and implementations to allow convenient use of FTP by
    programs or "automatons".

1. コマンド回答系列は、プログラムか「オートマトン」でFTPの便利な使用を許すために仕様と実装の両方に締められる必要があります。

    2. A 300 reply greeting upon first connecting to the FTP server
    should be required and not optional. This avoids the programs having
    to wait an arbitrary time for such a greeting before issuing
    commands. Commands may only be sent after the 300 reply is received
    from the server.

2. 最初にFTPサーバに接続するときの300回答挨拶は、必要であって、任意であるべきではありません。 これは命令を出す前にそのような挨拶のための任意の時間を待たなければならないプログラムを避けます。 サーバから300回答を受け取った後にコマンドを送るだけであるかもしれません。

    3. RFC 454 needs a discussion of transfer between two FTP servers
    arranged by the user via the LSTN or GSOC commands.

3. RFC454は、ユーザがLSTNかGSOCコマンドで2つのFTPサーバの間の転送の議論をセッティングする必要があります。

    4. Perhaps we should allow specification of data transfer parameters
    in a single command line (for reasons of efficiency).  A suggested
    format is to have <SP> separate the parameters bunched together in a
    single line (requiring only a single reply).  Consider the following
    sequences:
            STRU F TYPE I BYTE 36 MODE S <CR><LF>
            reply - 200 OK

4. 恐らく、私たちはただ一つのコマンドライン(効率の理由による)でデータ転送パラメタの仕様を許すべきです。 提案された形式は<SP>に単線で一緒に束ねられたパラメタを切り離させる(ただ一つの回答だけを必要として)ことです。 以下の系列を考えてください: STRU F TYPE I BYTE36MODE S<CR><LF>回答--、200は承認します。

    5. Further discussion of MAIL and MAIL.file commands seems
    necessary. Perhaps we will get some useful input from the MAIL
    meeting at SRI on February 23, The following issues seem
    particularly relevant to me:
        a) Allowing mail to multiple users. It should be required that
    FTP servers allow this.

5. メールとMAIL.fileコマンドのさらなる議論は必要に見えます。 恐らく、私たちは2月23日にSRIでメールミーティングから何らかの役に立つ入力を得るつもりであり、次の問題は特に私に関連しているように見えます: a) 複数のユーザにメールを許容します。 FTPサーバがこれを許容するのが必要であるべきです。

Bhushan                                                         [Page 2]

RFC 463           FTP Comments and Response to RFC 430     February 1973

Bhushan[2ページ]RFC463FTPコメントとRFC430 1973年2月への応答

        b) Using NIC idents. FTP servers should accept some standard
    form of user name. This could be NIC idents or last name with
    optional use of initials.
        c) Uniform conventions for who the mail is from, day, time,
    etc., and how the mail is delivered to user. The mail usually gets
    tagged twice or sometimes not tagged at all.  Perhaps we need a
    different mechanism for indicating who the mail is from than
    provided by the USER command.
        d) handling bulk or junk mail (particularly the NIC documents
    that may be sent on-line by the NIC). Perhaps mail.file should put a
    file in user's directory and notify him of the same. The user does
    not see all the junk on his console but can print the file on a
    printer and read that class of mail at his leisure.

b) NIC identsを使用します。 FTPサーバはユーザ名の何らかの標準形式を受け入れるべきです。 これは、イニシャルc)の任意の使用があるNIC identsか姓であるかもしれません。 メールがだれから来るか一定のコンベンションと、日、時間と、などと、メールはどうユーザに提供されるか。 二度タグ付けをされるか、または通常、メールは時々全くタグ付けをされません。 恐らく、メールがだれから来ているかを示すのに私たちはUSERで、コマンドd)取り扱いが膨れるか、そして、ダイレクトメール(特にNICによってオンラインで送られるかもしれないNICドキュメント)と異なったメカニズムを必要とします。 恐らく、mail.fileはユーザのディレクトリにファイルを入れて、同じくらいについて彼に通知するはずです。 ユーザは、彼のコンソールの上のすべてのくずを見るというわけではありませんが、プリンタのファイルを印刷して、ゆっくりそのクラスのメールを読むことができます。

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社9/99]

Bhushan                                                         [Page 3]

Bhushan[3ページ]