RFC686 日本語訳
0686 Leaving well enough alone. B. Harvey. May 1975. (Format: TXT=24605 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Brian Harvey Request for Comments: 686 SU-AI NIC 32481 10 May 1975 References: 354, 385, 630, 542, 640.
コメントを求めるワーキンググループブライアンハーヴェイRequestをネットワークでつないでください: 686 SU-AI NIC32481 1975年5月10日の参照: 354, 385, 630, 542, 640.
Leaving Well Enough Alone
十分よく単独でいなくなります。
I recently decided it was time for an overhaul of our FTP user and server programs. This was my first venture into the world of network protocols, and I soon discovered that there was a lot we were doing wrong -- and a few things that everyone seemed to be doing differently from each other. When I enquired about this, the response from some quarters was "Oh, you're running version 1!"
私は、最近、私たちのFTPユーザとサーバプログラムのオーバーホールのための時間であると決めました。これはネットワーク・プロトコルの世界への私の最初のベンチャーでした、そして、すぐ、私たちが悪いことをしていたいろいろな事、および皆がしているように思えたいくつかのことが互いと異なってあったと発見しました。 私がこれについて情報を得ようとしたとき、いくつかの方面からの応答は「おお、あなたはバージョン1を走らせています!」でした。
Since, as far as I can tell, all but one network host are running version 1, and basically transferring files OK, it seems to me that the existence on paper of an unused protocol should not stand in the way of maintaining the current one unless there is a good reason to believe that the new one is either imminent or strongly superior or both. (I understand, by the way, that FTP-2 represents a lot of thought and effort by several people who are greater network experts than I, and that it isn't nice of me to propose junking all that work, and I hereby apologize for it.) Let me list what strike me as the main differences in FTP-2 and examine their potential impact on the world.
私が判断できる限り、1人のネットワークホストを除いた皆がバージョン1を走らせて、基本的にファイルOKを移しているので、紙上の未使用のプロトコルの存在が新しい方が差し迫っているか、または強く優れていると信じるためにもっともな理由がない場合現在のものを維持するか、両方の邪魔をするべきでないように思えます。 (私はFTP-2が私より偉大なネットワークの専門家である数人による多くの考えと努力を表して、そのすべての仕事を廃棄するよう提案するとは私が親切でなく、これによりそれを謝るのをところで、理解しています。) FTP-2で主な違いと私に感じて、世界でそれらの可能性のある衝撃を調べることを記載させてください。
1. FTP-2 uses TELNET-2. The main advantage of the new Telnet
protocol is that it allows flexible negotiation about things like
echoing. But the communicators in the case of FTP are computer
programs, not people, and don't want any echoing anyway. The
argument that new hosts might not know about old Telnet seems an
unlikely one for quite some time to come if TELNET-2 ever does
really take over the world, FTP-1 could be implemented in it.
1. FTP-2はTELNET-2を使用します。 新しいTelnetプロトコルの主な利点は反響するようなものの周りでフレキシブルな交渉を許すということです。 しかし、FTPの場合における伝達者は、人々ではなく、コンピュータ・プログラムであり、とにかくどんな反響も欲しくはありません。 TELNET-2が本当に世界を買収するなら、新しいホストが古いTelnetに関して知らないかもしれない議論は長い間来るためにありそうもないものに見えて、それでFTP-1は実行できました。
2. FTP-2 straightens out the "print file" mess. This is more of a
mess on paper than in practice, I think. Although the protocol
document is confusing on the subject, I think it is perfectly
obvious what to do: if the user specifies, and the server
accepts, TYPE P (ASCII print file) or TYPE F (EBCDIC print file),
then the data sent over the network should contain Fortran control
characters. That is, the source file should contain Fortran
controls, and should be sent over the net as is, and reformatted
if necessary not by the SERVER as the protocol says but by the
RECIPIENT (server for STOR, user for RETR). As a non-Fortran-user
I may be missing something here but I don't think so; it is just
like the well-understood TYPE E in which the data is sent in
EBCDIC and the recipient can format it for local use as desired.
2. FTP-2は「印刷ファイル」混乱をまっすぐにします。 私は、これが習慣より紙上の混乱のものであると思います。 プロトコルドキュメントはこの件に関して混乱させられていますが、私は、何をしたらよいかが完全に明白であると思います: TYPE P(ASCII印刷ファイル)かTYPE F(EBCDIC印刷ファイル)、ユーザが指定して、サーバが受け入れるなら、ネットワークの上に送られたデータはFortran制御文字を含むべきです。 すなわち、ソースファイルをFortranコントロールを含むべきであり、そのままでネットの上に送って、必要ならいずれのSERVERもプロトコルが言いますが、RECIPIENTで再フォーマットするはずがありません(STORのためのサーバ、RETRのためのユーザ)。 非Fortranのユーザとして、何かを逃しているかもしれませんが、私はそのように思いません。 データがEBCDICと受取人で送られるよく理解されているTYPE Eが地方の使用のためにまさしく望まれているようにそれをフォーマットできるようです。
Harvey [Page 1] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[1ページ]RFC686
One never reformats a file from ASCII to EBCDIC at the sending
end. Perhaps the confusion happened because the protocol authors
had in mind using these types to send files directly to a line
printer at the server end, and indeed maybe that's all it's good
for and nobody's user program will implement TYPE P RETR. In any
event, using a two-dimensional scheme to specify the combinations
of ASCII/EBCDIC and ASA/normal conveys no more information than
the present A-P-E-F scheme. If there is any straightening out of
FTP-2, it could only be in the handling of these files once the
negotiation is settled, not in the negotiation process.
1つ、再フォーマットaは送信側にASCIIからEBCDICまで決してファイルされません。 恐らく、それが良いすべてであるサーバ終わりに、本当に、多分直接ラインプリンタにファイルを送るのにこれらのタイプを使用することで考えられていたプロトコル作者とだれのユーザ・プログラムがもTYPE P RETRを実行しないので、混乱は起こりました。 とにかく、ASCII/EBCDICとASA/標準の組み合わせを指定するのに二次元計画を使用するのは現在のA P電子F計画が情報でないことのようなどんな情報も伝えません。 何か真っすぐになることがFTP-2から脱していれば、それは交渉の過程にあるのではなく、これらのファイルの取り扱い、交渉がいったん決着すると中であるだけであるかもしれません。
3. FTP-2 approves of the Network Virtual File System concept even
though it doesn't actually implement it. It seems to me that the
NVFS notion is full of pitfalls, the least of which is the problem
of incompatibilities in filename syntax. (For example, one would
like to be able to do random access over the network, which
requires that different systems find a way to accommodate each
other's rules about record sizes and so on.) In any case, FTP-2
doesn't really use NVFS and I mention it here only because RFC 542
does.
3. 実際にそれを実行しませんが、FTP-2はNetwork Virtual File System概念に賛成します。 NVFS概念が落とし穴でいっぱいであるように思えます。その最少はファイル名構文による両立し難いことの問題です。 (例えば、1つはネットワークの上にランダムアクセスができたがっています。)ネットワークは、異系統がレコード・サイズなどに関する互いのやり方に対応する方法に当たるのを必要とします。 どのような場合でも、FTP-2は本当にNVFSを使用しません、そして、私は単にRFC542が言及するので、それについてここに言及します。
4. FTP-2 reshuffles reply codes somewhat. The reply codes in the
original FTP-2 document, RFC 542, don't address what I see as the
real reply code problems. The increased specificity of reply
codes doesn't seem to be much of a virtue; if, say, a rename
operation fails, it is the human user, not the FTP user program,
who needs to know that it was because of a name conflict rather
than some other file system error. I am all for putting such
information in the text part of FTP replies. Some real problems
are actually addressed in the reply code revision of RFC 640, in
which the basic scheme for assigning reply code numbers is more
rational than either the FTP-1 scheme or the original FTP-2
scheme. However, I think that most of the benefits of RFC 640 can
be obtained in a way which does not require cataclysmic
reprogramming. More on this below.
4. FTP-2は回答コードをいくらか改造します。 オリジナルのFTP-2ドキュメントの回答コード(RFC542)は私が本当の回答コード問題をみなすことを記述しません。回答コードの増加する特異性は大した美徳であるように思えません。 たとえば、aが操作をやり損ないに改名するなら、それはFTPユーザ・プログラムではなく、それがある他のファイルシステム・エラーよりむしろ名前闘争のためにそうであることを知る必要がある人間のユーザです。 私はFTP回答のテキスト部分にそのような情報をすべて入れるのに賛成します。 いくつかの実際の問題が実際にRFC640の回答コード改正で記述されます。(そこでは、回答コード番号を割り当てることの基本的な計画がFTP-1計画かオリジナルのFTP-2計画のどちらかより合理的です)。 しかしながら、私は、激動のプログラムを変えることを必要としない方法でRFC640の利益の大部分を得ることができると思います。 さらにこの下で。
5. FTP-2 was established by a duly constituted ARPAnet committee
and we are duty-bound to implement it. I don't suppose anyone
would actually put it that baldly, but I've heard things which
amounted to that. It's silly.
5. FTP-2は正しく構成されたARPAnet委員会によって確立されました、そして、私たちはそれを実行するのにおいて義務があります。 だれでも実際にそれをそんなにあからさまに置くと思いませんが、私はそれに達したことを聞きました。 それは愚かです。
6. FTP-2 specifies default sockets for the data connection. Most
places use the default sockets already anyway, and it is easy
enough to ignore the 255 message if you want to. This is a
security issue, of course, and I'm afraid that I can't work up
much excitement about helping the CIA keep track of what anti-war
demonstrations I attended in 1968 and which Vietnamese hamlets to
bomb for the greatest strategic effect even if they do pay my
6. FTP-2はデータ接続のためのデフォルトソケットを指定します。 ほとんどの場所が既にとにかくデフォルトソケットを使用します、そして、あなたが簡単でありたいなら、255メッセージを無視するほど簡単です。 残念ながら、これがもちろん安全保障問題であり、それらが支払っても私がCIAが私が1968年にどんな反戦デモンストレーションに出席したか、そして、どのベトナムの小村の動向をおさえるかを助けることに関する多くの興奮が最もすばらしい戦略の効果のために爆撃されるのが興奮させることができない、私
Harvey [Page 2] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[2ページ]RFC686
salary indirectly. I could rave about this subject for pages, and
probably will if I ever get around to writing an argument against
MAIL-2, but for now let me just get one anecdote off my chest: I
have access to an account at an ARPAnet host because I am
responsible at my own site for local maintenance of a program
which was written by, and is maintained by, someone at the other
site. However, the other site doesn't really trust us outsiders
(the account is shared by people in my position at several other
hosts) to protect their vital system security, so every week they
run a computer program to generate a new random password for the
account (last week's was HRHPUK) and notify us all by network
mail. Well, on my system and at least one of the others, that
mail isn't read protected. I delete my mail when I read it, but
since it is hard enough remembering HRHPUK without them changing
it every week, I naturally write it in a file on our system. That
file could in principle be read protected but it isn't, since
sometimes I'm in someone else's office when I want to use it, and
the other passwords in it are for open guest accounts which are
widely known. Moral #1: Security freaks are pretty wierd. Moral
#2: If you have a secret don't keep it on the ARPAnet. (In the
past week I have heard about two newly discovered holes in Tenex
security.)
間接的に、給与を払います。 私は、ページのためにこの対象を激賞できて、メール-2に対する議論を書くひまができるなら、たぶん激賞するつもりですが、当分1個の逸話をただ打ち明けさせてください: 私は私自身のサイトで書かれて、維持されるプログラムの地方の維持に責任があるので、ARPAnetホストでアカウントに近づく手段を持っています、もう片方のサイトのだれか。 しかしながら、もう片方のサイトが、私たち部外者(アカウントは数人の他のホストで私の地位で人々によって共有されます)が彼らの重大なシステムセキュリティを保護すると本当に信じないので、毎週、彼らはアカウント(先週のものはHRHPUKであった)のための新しい無作為のパスワードを発生させて、ネットワークメールで私たちに皆、通知するためにコンピュータ・プログラムを動かします。 さて、私のシステムと少なくとも他のもののひとりでは、メールが読まれないのは保護されました。 それを読むとき、私のメールを削除しますが、それはそれらなしでHRHPUKを覚えているのが十分毎週、それを変えるのが困難であるので、私は私たちのシステムのファイルに自然にそれを書きます。 原則として保護されていた状態でそのファイルを読むことができましたが、それはそのように読まれません、それを使用したいと思うとき、時々、他の誰かのものが私を在職させて、それの他のパスワードが広く知られている開いている客アカウントのためのものであるので。 教訓#1: セキュリティ熱狂者はきれいなwierdです。 教訓#2: 秘密がありましたら、ARPAnetにそれを保たないでください。 (この1週間私はTenexセキュリティのおよそ2つの新たに発見された穴を聞きました。)
7. FTP-2 is available online and FTP-1 isn't, so new hosts can't
find out how to do it. Aargh!!! What a reason for doing
anything! Surely it would be less costly for someone to type it
in again than for everyone to reprogram. Meanwhile these new
hosts can ask Jon or Geoff or Bobby or even me for help in getting
FTP up.
7. FTP-2はオンラインで利用可能です、そして、新しいホストがそれをする方法を見つけることができないように、FTP-1は利用可能ではありません。 Aargh! 何でもする何という理由! 確実に、だれかが再びそれをタイプするのは、皆がプログラムを変えるより高価でないでしょう。 その間、これらの新しいホストは助けのためにFTPを起こす際にジョン、ジェフ、ボビーまたは私にさえ尋ねることができます。
8. FTP-2 has some changes to the strange MODEs and STRUs. This is
another thing I can't get too excited about. We support only MODE
S and STR F and that will probably still be true even if we are
forced into FTP-2. If the relatively few people who do very large
file transfers need to improve the restart capability, they can do
so within FTP-1 without impacting the rest of us. The recent
implementation of paged file transfers by TENEX shows that
problems of individual systems can be solved within the FTP-1
framework. If the IBM people have some problem about record
structure in FTP-1, for example, let them solve it in FTP-1, and
whatever the solution is, nobody who isn't affected has to
reprogram.
8. FTP-2は奇妙なMODEsとSTRUsにいくつかの変化を持っています。 これはまた、私がエキサイトできない別のものです。 私たちはMODE SとSTR Fだけを支持します、そして、私たちがFTP-2に強制されても、それはたぶんまだ本当になっているでしょう。 非常に大きいファイル転送をする比較的わずかな人々が、再開能力を改良する必要があるなら、私たちの残りに影響を与えないで、それらはFTP-1の中でそうすることができます。 TENEXによる呼び出されたファイル転送の最近の実現は、FTP-1枠組みの中で個人能率給制の問題を解決できるのを示します。 例えば、IBMの人々がFTP-1で記録構造に関する何らかの問題を持っているなら、彼らにFTP-1と、解決策がことなら何でもであるかそれを解決させてください、一人も影響を受けない。プログラムを変えなければなりません。
Well, to sum up, I am pretty happy with the success I've had transferring files around the network the way things are. When I do run into trouble it's generally because some particular host hasn't implemented some particular feature of FTP-1, and there's no reason to suppose they'll do it any faster if they also have to convert to
よく、そして、要するに、ものがそうである方法で私が持っていた成功にネットワークの周りにファイルを移します。 私が困難に陥るとそれが特定のホストが一般にFTP-1の何らかの特定の特徴を実行していないからであるしたなら彼らが少しもより速くそれをすると思う変換する理由が全くありません。
Harvey [Page 3] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[3ページ]RFC686
FTP-2 at the same time. The main thing about FTP-2, as I said at the beginning, is that its existence is an excuse for not solving problems in FTP-1. Some such problems are quite trivial except for the fact that people are reluctant to go against anything in the protocol document, as if the latter were the Holy writ. A few actually require some coordinated effort. Here is my problem list:
同時にのFTP-2。 FTP-2時頃の主なものは私が始めに言ったように存在がFTP-1における問題を解決しない口実であるということです。 事実を除いて、人々がプロトコルドキュメントの何にでも反するのに気が重いというそのようないくつかの問題がかなり些細です、まるで後者が聖なる令状であるかのように。 いくつかは実際に何らかの連携努力を必要とします。 ここに、私の問題リストがあります:
1. It is almost true that an FTP user program can understand
reply codes by the following simple algorithm:
1. FTPユーザ・プログラムが以下の簡単なアルゴリズムに回答コードを解釈できるのは、ほとんど本当です:
a. Replies starting with 0 or 1 should be typed out and
otherwise ignored.
a。 タイプで打たれます。別の方法で、0か1から始まる回答は、無視されるべきです。
b. Replies starting with 2 indicate success (of this step or of
the whole operation, depending on the command).
b。 2から始まる回答が成功(このステップか操作全体がコマンドによる)を示します。
c. Replies starting with 4 or 5 indicate failure of the
command.
c。 4か5から始まる回答がコマンドの失敗を示します。
d. Replies starting with 3 are only recognized in three cases:
the initial 300 message, the 330 password request, and the 350
MAIL response. (Note that the user program need not
distinguish which 300 message it got, merely whether or not it
is expecting one right now.)
d。 3から始まる回答は3つの場合で認識されるだけです: 初期の300メッセージ、330パスワード要求、および350メール応答。 (それがたった今1つを期待しているか否かに関係なく、ユーザ・プログラムがそれが単に得たどの300メッセージを区別する必要はないかに注意してください。)
The only real problem with this, aside from bugs in a few servers
whose maintainers tell me they're working on it, is the HELP
command, which is not in the original protocol and which returns
0xx, 1xx, or 2xx depending on the server. (Sometimes more than one
message is returned.) The word from one network protocol expert
at BBN is that (a) 050 or 030 is the correct response to HELP, and
(b) there is a perfectly good mechanism in the protocol for
multi-line responses. Unfortunately this does not do much good in
dealing with reality. There seems to be a uniform, albeit
contra-protocol, procedure for handling the STAT command:
維持装置がそれに働いていると私に言ういくつかのサーバのバグは別として、この唯一の実際の問題が(1つのメッセージを返すより時々多く)のサーバによるHELPコマンドです。(そのHELPコマンドは、オリジナルのプロトコルにはなくて、0xx、1xx、または2xxを返します)。 BBNの1人のネットワーク・プロトコルの専門家からの単語は(a) 050か030がヘルプへの正しい応答であり、マルチ線応答のためのプロトコルには(b) 完全に良いメカニズムがあるということです。 残念ながら、これは現実に対処する際に多くを良くしません。 contra-プロトコル、STATコマンドを扱うための手順ですが、ユニフォームはあるように思えます:
151 information
151 information
151 ...
151 information
200 END OF STATUS
151 情報151情報151… 151 情報200END OF STATUS
which fits right in with the above algorithm. This is despite the
fact that 1xx is supposed to constitute a positive response to a
command like STAT, so that according to the protocol it ought to
be
上のアルゴリズムで、ぴったり合います。 1xxがSTATのようなコマンドへの積極的な応答を構成するべきであるという事実にもかかわらず、これはあります、プロトコルによると、それがそうあるべきであるように
Harvey [Page 4] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[4ページ]RFC686
151-information
information
...
151 information
151情報の情報… 151 情報
instead. (It seems to me, by the way, that 050 and 030 aren't
good enough as response to HELP since they "constitute neither a
positive nor a negative acknowledgment" of the HELP command and
thus don't tell the user program when it ought to ask the human
user what to do next.) I suggest that despite the protocol, a 200
response be given by all servers at the end of whatever other HELP
it gives as of, let's say, June 1. The alternatives are either to
let the current rather chaotic situation continue forever while
waiting for FTP-2, or to try to standardize everyone on a multi-
line 1xx for both HELP and STAT. I'm against changing STAT, which
works perfectly for everyone as far as I can tell, and it should
be clear that I'm against waiting for FTP-2. Unfortunately there
is no real mechanism for "officially" adopting my plan, but I bet
if TENEX does it on June 1 the rest of the world will come along.
代わりに。 (ところで、彼らが、050と030がヘルプへの応答として十分良くても、HELPコマンドについて「どちらも、積極的で否定的な承認を構成しない」で、またその結果、次にそれが、いつ何をしたらよいかを人間のユーザに尋ねるべきであるかをユーザ・プログラムに言わないように思えます。) 私が、プロトコル、200応答にもかかわらず、それがヘルプの他のどんなもそれが与える終わりにすべてのサーバによって与えられることを提案する、言いましょう、6月1 代替手段はFTP-2かヘルプとSTATの両方のためにマルチ線1xxの上の皆を標準化しようとするのを待っている間に現在のかなり混沌の状況がいつまでも続くどちらかです。 STATを変えることに反対して私はいます、そして、FTP-2を待つことに反対して私がいるのは、明確であるはずです。私が判断できる限り、STATは皆のために完全に働いています。 残念ながら、「公式に」私のプランを採用するためのどんな本当のメカニズムもありませんが、私は、TENEXが6月1日にそれをすると他の国々がやって来るのを賭けます。
2. Another reply code problem is the use of 9xx for
"experimental" replies not in the protocol. This includes the BBN
mail-forwarding message and one other that I know of. This
procedure is sanctioned by RFC 385, but it seems like a bad idea
to me. For one thing, the user program has no way of knowing
whether the reply is positive, negative, or irrelevant. The
examples I've been burned by all should have been 0xx messages. I
propose that all such messages be given codes in the 000-599
range, chosen to fit the scheme given above for interpreting reply
codes. x9x or xx9 could be used to indicate experiments.
2. 別の回答コード問題は9xxのプロトコルでないのにおける「実験的な」回答の使用です。 これはBBNメール転送メッセージと私が知っているあるもう一方を含んでいます。 この手順はRFC385によって認可されますが、私への悪い考えのように見えます。 一つには、ユーザ・プログラムには、回答が肯定する、否定する、または無関係であるかを知る方法が全くありません。 私がやけどされた例はすべて、0xxメッセージであるべきでした。 私は、コードが回答コードを解釈するために上に与えられた計画に合うように選ばれた000-599範囲でそのようなすべてのメッセージに与えられているよう提案します。実験を示すのにx9xかxx9は使用できました。
3. One more on reply: RFC 630 (the one about the TENEX mod to the
reply codes for MAIL and MLFL) raises the issue of "temporary"
versus "permanent" failures within the 4xx category. RFC 640
deals with this question in the FTP-2 context by changing the
meaning of 4xx and 5xx so that the former are for temporary errors
and the latter are for permanent errors. I like this idea, and I
think it could easily be adapted for FTP-1 use in a way which
would allow people to ignore the change and still win. At
present, I believe that the only program which attempts to
distinguish between temporary and permanent errors is the TENEX
mailer. For other programs, no distinction is currently made
between 4xx and 5xx responses; both indicate failure, and any
retrials are done by the human user based on the text part of the
message. A specific set of changes to the reply codes codes is
proposed below.
3. 回答でのもうひとつの: RFC630(メールとMLFLのための回答コードへのTENEXモッズに関するもの)は「永久的な」失敗に対して4xxカテゴリの中で「一時的」の問題を提起します。 4xxと5xxの意味を変えることによってRFC640がFTP-2文脈でのこの質問に対処するので、前者が一時的な誤りによってあって、後者は永続エラーのためのものです。 この考えが好きであり、私は、人々が変化を無視できる道におけるFTP-1使用のために容易にそれを適合させることができたと思って、まだ勝っています。 現在のところ、私は、一時的で永久的な誤りを見分けるのを試みる唯一のプログラムがTENEX郵送者であると信じています。 他の計画については、現在、4xxと5xx応答の間で区別を全くしません。 両方が失敗を示します、そして、どんな再試行もメッセージのテキスト部分に基づく人間のユーザによって行われます。 回答コードコードへの特定の変化は以下で提案されます。
Harvey [Page 5] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[5ページ]RFC686
Perhaps I should make a few more points about RFC 640, since it's
the best thing about FTP-2 and the only argument for it I find at
all convincing. Let me try to pick out the virtues of 640 and
indicate how they might be achieved in FTP-1.
恐らく、私はRFC640に関するポイントをもう少し指摘するべきです、私が納得させることを全く見つけるのが、FTP-2とそれのための唯一の議論の周りの最も良いものであるので。 640の美徳を選んで、それらがFTP-1でどう達成されるかもしれないかを示そうとするのをさせてください。
a. The 3xx category is used uniformly for "positive
intermediate replies" where further negotiation in the Telnet
connection is required, as for RNFR. I'm afraid this one can't
be changed without affecting existing user programs. (One of
my goals here is to enable exiting user programs to work while
some servers continue as now and others adopt the suggestions I
make below.) However, although this 3xx idea is logically
pleasing, it is not really necessary for a simple-minded user
program to be able to interpret replies. The only really new
3xx in RFC 640 is the 350 code for RNFR. But this would only
be a real improvement for the user program if there were also a
2xx code which might be returned after RNFR, which is not the
case. 640 also abolishes the 300 initial connection message
with 220, but again there is clearly no conflict here.
a。 3xxカテゴリはTelnet接続におけるさらなる交渉が必要である「積極的な中間的回答」に一様に使用されます、RNFRのように。 残念ながら、影響存在なしでこれを変えることができません。ユーザ・プログラム(ここの私の目標の1つはいくつかのサーバが現在のように続いて、他のものが私が以下でする提案を採用している間、ユーザ・プログラムを出るのが働くのを可能にすることです。) しかしながら、この3xx考えは論理的に微笑ましいのですが、純真なユーザ・プログラムが回答を解釈できるのは本当に必要ではありません。 RFC640における唯一の本当に新しい3xxがRNFRのための350コードです。 しかし、また、ケースでないRNFRの後に返されるかもしれない2xxコードがある場合にだけ、これはユーザ・プログラムのための本当の改良でしょうに。 640 また、220で300の初期の接続メッセージを撤廃しますが、闘争が全く再びここに明確にありません。
b. The use of 1xx is expanded to include what is now the 250
code for the beginning of a file transfer. The idea is that a
1xx message doesn't affect the state of the user process, but
this is not really true. Consider the file transfer commands.
The state diagram on page 13 of RFC 640 is slightly misleading.
It appears as if 1xx replies are simply ignored by the user
program. In reality, that little loop hides a lot of work: the
file transfer itself! If the server replied to the file
transfer command immediately with a 2xx message, it would be a
bug in the server, not a successful transfer. The real state
diagram is more like
b。 1xxの使用は、ファイル転送の始まりの間、現在250コードであることを含むように広げられます。 考えは1xxメッセージがユーザ・プロセスの状態に影響しないということですが、これは本当に本当ではありません。 ファイル転送命令を考えてください。 13RFCページの640上の州のダイヤグラムはわずかに紛らわしいです。 まるで1xx回答がユーザ・プログラムで単に無視されるかのように見えます。 ほんとうは、その小さい輪は多くの仕事を隠します: ファイル転送自体! サーバがすぐ2xxメッセージでファイル転送命令に答えるなら、それはうまくいっている転送ではなく、サーバのバグでしょうに。 ダイヤグラムが、より多い実況
B --> cmd --> W --> 1 --> W --> 2 --> S
B-->cmd-->W-->1-->W-->2-->S
(with branches out from the "W"s for bad replies). It should
be clear from this diagram that the user program, if it trusts
the server to know what it's doing, can expect a 2xx instead of
the 1xx without getting confused, since it knows which of the W
states it's in. In fact, the use of 1xx in file transfer is
very different from its other uses, which are indeed more like
the 0xx and 1xx replies in FTP-1. I'd call this particular
point a bug in RFC 640.
(悪い回答のための「W」sからのブランチがある。) それが何をしているかを知るためにサーバを信じるならユーザ・プログラムが面食らうことのない1xxの代わりに2xxを予想できるのは、このダイヤグラムから明確であるはずです、W州のどれにあるかを知っているので。 事実上、ファイル転送における1xxの使用は他の用途と非常に異なっています。(用途は本当に、さらにFTP-1における0xxと1xx回答に似ています)。 私は、RFC640にこの特定のポイントをバグと呼ぶでしょう。
c. Automatic programs which use FTP (like mailers) can decide
whether to queue or abandon an unsuccessful transfer based on
the distinction between 4xx and 5xx codes. I like this idea,
although those temporary errors virtually never happen in real
life. This could be accomplished in FTP-1 by moving many of
c。 FTP(郵送者のような)を使用する自動プログラムは、区別に基づく失敗の転送を4xxと5xxコードの間に列に並ばせるか、または捨てるかを決めることができます。 それらの一時的な誤りは実際には現実では決して起こりませんが、私はこの考えが好きです。 FTP-1で多く動くことによって、これを達成できるでしょう。
Harvey [Page 6] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[6ページ]RFC686
the 4xx replies to 5xx. Mailers would be modified to use the
first digit to decide whether or not to retry. This scheme
does not cause any catastrophes; if some server is slow in
converting it merely leads to unnecessary retries. A few CPU
cycles would be wasted in the month following the official
switch. Thus, this feature is very different from (a) and (b),
which could lead to catastrophic failures if not implemented
all at once. (Yes, I know that FTP-2 is supposed to be done on
a different ICP socket. I am not discussing FTP-2 but whether
its virtues can be transferred to FTP-1.) The specific codes
involved are listed below.
4xxは5xxに答えます。 郵送者は、再試行するかどうか決める最初のケタを使用するように変更されるでしょう。 この計画はどんなカタストロフィーも引き起こしません。 何らかのサーバが変換で遅いなら、それは単に不要な再試行に通じます。 CPU数サイクルが公式のスイッチに続く月の間、浪費されるでしょう。 したがって、この特徴は(a)と(b)と非常に異なっています。(一気に実行されないなら、(b)は突発故障に通じるかもしれません)。 (はい、私はFTP-2が異なったICPソケットでするべきであるのを知っています。 私は、FTP-2にもかかわらず、FTP-1に美徳を移すことができるかどうか議論していません。) かかわった特定のコードは以下に記載されています。
d. The use of the second digit to indicate the type of
message. (The proposed division is not totally clean; for
example, why is 150 ("file status okay; about to open data
connection") considered to be more about the file system than
about data connection?) This can easily be done, since the
second digit is not currently important to any user process--
the TENEX mailer is, in this plan, already due for modification
because of (c). Since this is mostly an aesthetic point, I'm
hesitant to do it if it would be difficult for anyone. In
particular, I would want to leave the 25x messages alone, in
case some user programs distinguish these. This is especially
likely for the ones which are entirely meant for the program:
251 and 255. Therefore I propose that if this idea is adopted
in FTP-1 the meanings of x2x and x5x be interchanged. This
proposal is reflected in the specific list below.
d。 メッセージのタイプを示す2番目のケタの使用。 (提案された分割は完全に清潔であるというわけではありません; 例えば、なぜデータ接続よりファイルシステムに関して150(「間違いなく状態をファイルしてください;データ接続を開こうとしている 」)があると考えられますか?) 容易にこれができます、2番目のケタが現在どんなユーザ・プロセスにも重要でないので--(c)のために、このプランでは、変更には、TENEX郵送者は既に当然です。 これがほとんど美的なポイントであるので、だれにとっても、それが難しいなら、私はそれをするのをためらっています。 いくつかのユーザ・プログラムがこれらを区別するといけないので、特に、25xメッセージを放っておきたいと思うでしょう。 プログラムのために完全に意味されるものに、これは特にありそうです: 251と255。 したがって、この考えがFTP-1のx2xの意味とx5xに採用されるなら、私はそれを提案します。交換されます。 この提案は以下の特定のリストに反映されます。
4. The print file thing again. Let's get it made "official" that
it is the recipient, not the server, who is responsible for any
reformatting which is to be done on these files. After all, the
recipient knows what his own print programs want.
4. 印刷は再びものをファイルします。 これらのファイルでするのが、サーバではなく、そうするどんな再フォーマットにも責任がある受取人である人工の「職員」をそれに得ましょう。 結局、受取人は、彼自身の印刷プログラムが何を必要とするかを知っています。
Let me summarize the specific changes to FTP-1 I'd like to see made, most of which are merely documentation changes to reflect reality:
作られているのを見たいと思うそれの大部分が単にドキュメンテーション変化であるFTP-1への特定の変化をまとめさせて、現実を反映してください:
1. HELP should return 200. All commands should return 2xx if
successful, and I believe all do except HELP.
1. ヘルプは200を返すべきです。 うまくいくなら、すべてのコマンドが2xxを返すべきです、そして、私はヘルプを除いて、すべてがすると信じています。
2. The definition of 1xx messages should be changed to read:
"Informative replies to status inquiries. These constitute
neither a positive nor negative acknowledgment."
2. 読むために1xxメッセージの定義を変えるべきです: 「資産調査に関する有益な回答。」 「これらは正数も否定応答も構成しません。」
3. Experimental reply codes should be of the form x9x or xx9,
where the first digit is chosen to reflect the significance of the
reply to automated user programs. Reply codes greater than 599
are not permitted. The xx9 form should be used if the reply falls
into one of the existing categories for the second digit. User
3. 実験回答コードは自動化されたユーザ・プログラムへのフォームx9xかxx9の最初のケタが回答の意味を反映するために選ばれているところのものであるはずです。599より大きい回答コードは可能にしました。 回答が2番目のケタのための既存のカテゴリの1つになるなら、xx9フォームは使用されるべきです。 ユーザ
Harvey [Page 7] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[7ページ]RFC686
programs are encouraged to determine the significance of the reply
from the first digit, rather than requiring a specific reply code,
when possible.
プログラムが特定の回答コードを必要とするより最初のケタから回答の意味をむしろ決定するよう奨励されます、可能であるときに。
4. The STAT command with no argument is considered a request for a
directory listing for the current working directory, except that
it may be given along with TELNET SYNCH while a transfer is in
progress, in which case it is a request for the status of that
transfer. (Everyone seems to do the first part of this. I'm not
sure if anyone actually implements the second. This is just
getting the protocol to agree with reality.) The reply to a STAT
command should be zero or more 1xx messages followed by a 200.
4. 議論のないSTATコマンドは転送が進行している間、それをTELNET SYNCHと共に与えるかもしれないのを除いて、現在の働くディレクトリのためにリストアップされているディレクトリに関する要求であると考えられます、その場合、それはその転送の状態を求めて要求です。 (皆は、この最初の部分をするように思えます。 私はだれかが実際に2番目を実行するかどうかを確信していません。 これで、プロトコルはただ現実に同意しています。) STATコマンドに関する回答はゼロであるべきですか、より多くの1xxメッセージが200従いました。
5. TYPEs P and F mean that the source file contains ASA control
characters and that the recipient program should reformat it if
necessary.
5. TYPEs PとFがソースファイルがASA制御文字を含んでいて、受取人プログラムがそうするべきであることを意味する、再フォーマット、それ、必要なら。
Here is a list of the current FTP-1 replies, and how they should be renumbered for the new scheme. The changes from 4xx to 5xx should be REQUIRED as of June 1; changes in the second or third digit are not so important. (As explained above, it will not be catastrophic even if some hosts do not meet the requirement.) The list also contains one new possible reply adapted from RFC 640.
ここに、現在のFTP-1回答と、それらが新しい計画のためにどう番号を付け替えられるべきであるかに関するリストがあります。 6月1日現在、4xxから5xxまでの変化はREQUIREDであるべきです。 2番目か3番目のケタにおける変化はそれほど重要ではありません。 (上で説明されるように、何人かのホストが条件を満たさないでも、壊滅的にならないでしょう。) また、リストはRFC640から適合させられた1つの新しい可能な回答を含んでいます。
OLD NEW TEXT
0x0 0x0 (These messages are not very well defined nor
very important. Servers should use their judgment.)
100 110 System status reply. (Since nobody does STAT
as in the protocol, this may be a moot point.)
150 150 "File status reply." (If this were really that,
it would be switched to 120, but I believe what is meant is
the response to a bare STAT in mid-transfer, which is more
a connection status reply than a file status reply.
151 121 Directory listing reply.
200 200 Last command ok.
201 251 ABOR ok.
202 252 ABOR ignored, no transfer in progress.
new 206 Command ignored, superfluous here.
230 230 Login complete.
231 231 Logout complete.
232 232 Logout command will be processed when
transfer is complete.
250 250 Transfer started correctly.
251 251 MARK yyyy = mmmm
252 252 Transfer completed ok.
253 223 Rename ok.
254 224 Delete ok.
255 255 SOCK nnnn
古い新しいテキスト0x0 0×0(これらのメッセージは非常によく定義されていません。または、非常に重要です。 サーバは自ら判断するべきです。) 100 110システム状態回答。 (だれもプロトコルのようにSTATをしないので、これは論点であるかもしれません。) 150 150は「状態回答をファイルします」。 (これが本当にそれである、それは120に切り換えられるでしょう; しかし、私は、何がむき出しのSTATへの意味されているのが、応答であるということであるかを中間の転送を信じています。(転送はファイル状態回答より接続形態回答です)。151 121ディレクトリリスト回答200 200LastはOK ABOR OK202 252ABORが無視した201 251を命令します、と進歩新しい206Commandでどんな転送も無視しませんでした、ここで、余計です; 230 230は完全な状態でログインします。231 231Logoutは. Logoutが転送が完全であるときに、処理されると命令する232 232を完成します。250 250Transferは正しく始まりました。mmmm252 252 251 251マークyyyy=TransferはOK253 223Rename OK254 224Delete OK255 255SOCK nnnnを完成しました。
Harvey [Page 8] RFC 686 Leaving Well Enough Alone May 1975
1975年5月を十分よく放っておくハーヴェイ[8ページ]RFC686
256 256 Mail completed ok.
300 300 Connection greeting
301 301 Command incomplete (no crlf)
330 330 Enter password
350 350 Enter mail.
400 huh? "This service not implemented." I don't
understand this; how does it differ from 506? If it means
no FTP at all, who gave the message? Flush.
401 451 Service not accepting users now, goodbye.
430 430 Foo, you are a password hacker!
431 531 Invalid user or password.
432 532 User invalid for this service.
434 454 Logout by operator.
435 455 Logout by system.
436 456 Service shutting down.
450 520 File not found.
451 521 Access denied.
452 452 Transfer incomplete, connection closed.
453 423 Transfer incomplete, insufficient storage space.
454 454 Can't connect to your socket.
500 500 Command gibberish.
501 501 Argument gibberish.
502 502 Argument missing.
503 503 Arguments conflict.
504 504 You can't get there from here.
505 505 Command conflicts with previous command.
506 506 Action not implemented.
256 256メールはOKを完成しました。 300 300接続挨拶301 301Commandの不完全な(crlfがない)330 330Enterパスワード350 350Enterメール。 400 えっ? 「実行されなかったこのサービス。」 私はこれを理解していません。 それはどのように506と異なっていますか? FTPを全く意味しないなら、だれがメッセージを与えましたか? 洗い流してください。 さようならを現在ユーザを受け入れない401 451は修理します。 430 430Foo、あなたはパスワードハッカーです! 431 531の無効のユーザかパスワード。 このサービスに、無効の432 532ユーザ。 434 454はオペレータでログアウトします。 435 455はシステムでログアウトします。 436 456は停止を修理します。 450 520、ファイルが見つからない。 451 521アクセス拒否。 452 452は不完全な状態で移されて、接続は閉じました。 453 423は不完全で、不十分な集積スペースを移します。 454 454はあなたのソケットに接続できません。 500 500はおしゃべりを命令します。 501 501議論おしゃべり。 502 502議論なくなります。 503 503の議論が闘争します。 あなたがここからそこに到着させることができない504 504。 505 505は前のコマンドとの闘争を命令します。 動作が実行しなかった506 506。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Via Genie 3/00 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][Via Genie3/00によるオンラインRFCアーカイブへの]
Harvey [Page 9]
ハーヴェイ[9ページ]
一覧
スポンサーリンク
