RFC691 日本語訳
0691 One more try on the FTP. B. Harvey. June 1975. (Format: TXT=32821 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
Brian Harvey
SU-AI
Re: File Transfer Protocol May 28, 1975
Ref: RFC 354, 385, 414, 448, 454, 630, 542, 640 1
ブライアンハーヴェイSU-AI Re: ファイル転送プロトコル1975年5月28日審判: RFC354、385、414、448、454、630、542、640 1
One More Try on the FTP 2
FTP2をもうひとつ試着します。
This is a slight revision of RFC 686, mainly differing in the discussion of print files. Reading several RFCs that I (sigh) never heard of before writing 686 has convinced me that although I was right all along it was for the wrong reasons. The list of reply codes is also slightly different to reflect the four lists in RFCs 354, 454, 542, and 640 more completely. Let me also suggest that if there are no objections before June 1, everyone take it as official that HELP should return 200, that SRVR should be used as discussed below, and that "permanent" 4xx errors be changed to 5xx. And thanks to Jon Postel who just spent all evening helping me straighten this all out. 2a
これは印刷ファイルの議論において主に異なるRFC686のわずかな改正です。 私がそれに沿って正しかったのですが、686を書くと納得させられる前に私(ため息をつく)が一度も聞いたことがない数個のRFCsにそれを読み込むのが間違った理由でありました。 また、回答コードのリストも、RFCs354、454、542、および640の4つのリストをより完全に反映するためにわずかに異なっています。 また、反論が全くなければ、皆が6月1日に職員としてヘルプが200を返すべきであり、SRVRが以下で議論するように使用されるべきであり、「永久的な」4xx誤りが5xxに変わるのを分かる前にそれを勧めさせてください。 そして、私がこれをすべてまっすぐにするのを助けるのにただすべての晩を費やしたジョン・ポステルをありがとうございます。 2a
Aside from a cry of anguish by the site responsible for the security hassle described below, I've only had one comment on this, which was unfavorable but, alas, unspecific. Let me just say, in the hopes of avoiding more such, that I am not just trying to step on toes for the fun of it, and that I don't think the positive changes to FTP-1 proposed here are necessarily the best possible thing. What they are, I think, is easily doable. The great-FTP-in-the-sky isn't showing any signs of universal acceptability, and it shouldn't stand in the way of solving immediate problems. 2b
私には、以下で説明されたセキュリティ苦労に原因となるサイトのそばでの苦悩の叫びは別として、この1つのコメントしかありませんでした。(好ましくないのですが、それは、残念ながら、「非-特定」でした)。 ただ言わせてください、より多くのそのようなものを避けるという私がただ面白半分に爪先を踏もうとしていなくて、ここで提案されたFTP-1への正の変化が必ず可能な限り良いものであると思わないという望みで。 私は、それらが何であるかが容易にできると思います。 空のすばらしいFTPは普遍的な受容性のどんな兆候も示していません、そして、それは手近な問題2bを解決する方法で立つべきではありません。
Leaving Well Enough Alone 3
3を十分よく放っておきます。
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!" 4
私は、最近、私たちのFTPユーザとサーバプログラムのオーバーホールのための時間であると決めました。これはネットワーク・プロトコルの世界への私の最初のベンチャーでした、そして、すぐ、私たちが悪いことをしていたいろいろな事、および皆がしているように思えたいくつかのことが互いと異なってあったと発見しました。 私がこれについて情報を得ようとしたとき、いくつかの方面からの応答は「おお、あなたはバージョン1を走らせています!」でした。 4
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
以来、私が判断できる限り、1人のネットワークホストを除いた皆は、紙上の未使用のプロトコルの存在がもっともな理由がない場合現在のものを維持する方法で立つべきでないバージョン1を走らせて、OK、それが私にとって見える基本的に移しているファイルです。
1
1
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
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. 5
新しい方が差し迫っているか、または強く優れていると信じてください。または、両方。 (私はFTP-2が私より偉大なネットワークの専門家である数人による多くの考えと努力を表して、そのすべての仕事を廃棄するよう提案するとは私が親切でなく、これによりそれを謝るのをところで、理解しています。) FTP-2で主な違いと私に感じて、世界でそれらの可能性のある衝撃を調べることを記載させてください。 5
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. 5a
1. FTP-2はTELNET-2を使用します。 新しいTelnetプロトコルの主な利点は反響するようなものの周りでフレキシブルな交渉を許すということです。 しかし、FTPの場合における伝達者は、人々ではなく、コンピュータ・プログラムであり、とにかくどんな反響も欲しくはありません。 新しいホストが古いTelnetに関して知らないかもしれない議論は長い間、来るためにありそうもないものに見えます。 TELNET-2が本当に世界を買収するなら、FTP-1はそれで実行されるかもしれません。 5a
2. FTP-2 straightens out the "print file" mess. First of all, there are two separate questions here: what command one ought to give to establish a print file transfer, and which end does what sort of conversion. For the second question, although all of the FTP-1 documents are confusing on the subject, I think it is perfectly obvious what to do: if the user specifies, and the server accepts, an ASCII or EBCDIC print file transfer parameter sequence, 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). (The "Telnet print file" non-issue will be debunked below.) 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. 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. 5b
2. FTP-2は「印刷ファイル」混乱をまっすぐにします。 まず、2つの別々の質問がここにあります: コマンド1は印刷ファイル転送を証明するために何を与えるべきであるか、そして、どの終わりがどういう変換をしますか? 2番目の質問のために、FTP-1ドキュメントのすべてがこの件に関して混乱させられていますが、私は、何をしたらよいかが完全に明白であると思います: ユーザは指定します、そして、サーバは受け入れます、ASCIIかEBCDICがファイル転送パラメタ系列を印刷するなら、ネットワークの上に送られたデータがFortran制御文字を含むべきです。 すなわち、ソースファイルをFortranコントロールを含むべきであり、そのままでネットの上に送って、必要ならいずれのSERVERもプロトコルが言いますが、RECIPIENTで再フォーマットするはずがありません(STORのためのサーバ、RETRのためのユーザ)。 (「telnet印刷ファイル」どうでもいい問題は以下ですっぱぬくでしょう。) 非Fortranのユーザとして、何かを逃しているかもしれませんが、私はそのように思いません。 データがEBCDICと受取人で送られるよく理解されているTYPE Eが地方の使用のためにまさしく望まれているようにそれをフォーマットできるようです。 1つ、再フォーマットaは送信側にASCIIからEBCDICまで決してファイルされません。 恐らく、それが良いすべてであるサーバ終わりに、本当に、多分直接ラインプリンタにファイルを送るのにこれらのタイプを使用することで考えられていたプロトコル作者とだれのユーザ・プログラムがもTYPE P RETRを実行しないので、混乱は起こりました。 5b
As for the specific commands used to negotiate such a transfer, there may currently be some confusion because the most recent FTP-1 document on the subject (RFC 454) invents a new command, FORM, which is not in general use as far as I know. (Most of my
そのような転送を交渉するのに使用される特定のコマンドに関して、話題(RFC454)の上の最新のFTP-1ドキュメントが新しいコマンド、FORM(一般に、私と同じくらい遠い使用が知っているということでない)を発明するので、現在、何らかの混乱があるかもしれません。 (だいたい、私
2
2
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
experiments have been on PDP-10s; perhaps other systems have adopted this command.) FTP-2 puts the format argument in the TYPE command as a second argument. Either way, 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. FTP-2 also introduces the notion of Telnet formatted vs. non-print files. These types are used when a Telnet format oriented system is sending a file to an ASA oriented one, and the recipient needs to know, not what is coming over the net, but how to solve a local file storage problem. It is unnecessary and unfair for hosts to have to negotiate something which does not acttually affect what gets sent over the net. It is unnecessary because the sending user process (there is no problem if the user process is receiving) need not understand what the issue is, it need only make the server understand by transmitting a message from the human user to the server process. Any TYPE parameter must be understood by both processes even if the user treats it just like some other type. 5c
実験が10PDP-年代にありました。 恐らく、他のシステムはこのコマンドを採用しました。) FTP-2は2番目の議論としてTYPEコマンドに形式議論を入れます。 いずれにせよ、ASCII/EBCDICとASA/標準の組み合わせを指定するのに二次元計画を使用するのは現在のA P電子F計画が情報でないことのようなどんな情報も伝えません。 また、FTP-2は非印刷ファイルに対してフォーマットされたTelnetの概念を紹介します。 指向のシステムがASAへのファイルを送るTelnet形式がしかし、ネットを襲っていること、どうローカルファイル格納問題を解決するかではなく、1、および知る受取人の必要性を適応させたとき、これらのタイプは使用されています。 ホストがacttuallyにネットの上に送られるものに影響しない何かを交渉しなければならないのは、不要であって、不公平です。 送付ユーザ・プロセス(ユーザ・プロセスが受信されるなら、問題が全くない)が、問題が何であるかを理解する必要はないので不要である、それで、サーバは、人間のユーザからサーバの過程まで送信することによって、分かるだけでよいです。 ユーザがまさしくある他のタイプのようにそれを扱っても、どんなTYPEパラメタも両方の過程に解釈しなければなりません。 5c
To take a specific example, if I want to send an ASCII file to a 360, my FTP user program needs to have built into it the knowledge that there are two TYPEs which are really the same, AN and AT in the FTP-2 notation. If tomorrow someone needs to know the ultimate use of a binary file (for instance, the old PDP-6 DECtape format stores dump files differently from ordinary data files), I will have to add another piece of information to my FTP user and server (maybe they try to read such a file from me). Instead, information which affects only the RECIPIENT of a file, and not the format AS SENT OVER THE NET, should be specified in some form which the sending process can ignore. This is what the SRVR command should be used for. 5d
特定の例を取るために、ASCIIファイルを360に送りたいと思うなら、私のFTPユーザ・プログラムは、FTP-2記法には2本当に同じTYPEs、AN、およびATがあるという知識をそれに組み込んだ必要があります。 だれかが、明日バイナリーファイルの究極の使用を知る必要があると(例えば、形式が格納する古いPDP-6 DECtapeはファイルを普通のデータファイルと異なって捨てます)、私はもう1片の情報をFTPユーザとサーバに追加しなければならないでしょう(多分、それらは私からそのようなファイルを読もうとします)。 代わりに、形式AS SENT OVER THE NETではなく、ファイルのRECIPIENTだけに影響する情報は送付の過程が無視できる何らかのフォームで指定されるべきです。 これはSRVRコマンドが何に使用されるべきであるかということです。 5d
If a user at a 360 wants to retrieve a "Telnet print file" from another system, he might tell his FTP user process something like 5e
360におけるユーザが別のシステムからの「telnet印刷ファイル」を検索したいなら、彼は5eのようにFTPユーザ・プロセスを言うかもしれません。
TYPE A
DISP PRINT
RETR FOO etc. 5e1
タイプA DISPはRETR FOOなどを印刷します。 5e1
(or whatever syntax they use in their FTP). If a user at a 10 wants to send such a file to a 360, he would say 5f
(彼らが自分達のFTPにどんな構文も使用しても。) 10歳のユーザがそのようなファイルを360に送りたいなら、彼は5fを言うでしょう。
TYPE A
Aをタイプしてください。
3
3
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
SRVR PRINT
STOR FOO etc. 5f1
SRVRはSTOR FOOなどを印刷します。 5f1
His FTP user program would send on the SRVR command without comment. Suppose that the transformation is one which might be used in either direction between the same two hosts. (This is not the case for the Telnet print file thing because two 360s would be using ASA format.) Then the user process could accept the equivalent of DISP PRINT from the user, and if the transfer turned out to be a STOR it would decide to send SRVR PRINT first. In this way the FTP user program can be written so that the human user types the same command regardless of the direction of transfer. 5g
彼のFTPユーザ・プログラムはコメントなしでSRVRコマンドを転送するでしょう。 変化が同じ2人のホストの間のどちらの方向にも使用されるかもしれないものであると仮定してください。 (2 360がASA形式を使用しているでしょう、したがって、これはTelnet印刷ファイルもののためのそうではありません。) 次に、ユーザ・プロセスはユーザからDISP PRINTの同等物を受け入れるかもしれません、そして、転送がSTORであると判明するなら、それは最初にSRVR PRINTを送ると決めるでしょうに。 このように、人間のユーザは、FTPユーザ・プログラムを書くことができるので、転送の指示にかかわらず同じコマンドをタイプします。 5g
Thus, FTP servers which care about the distinction between Telnet print and non-print could implement SRVR N and SRVR T. Ideally the SRVR parameters should be registered with Jon Postel to avoid conflicts, although it is not a disaster if two sites use the same parameter for different things. I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies. The following should be considered as registered: 5h
したがって、SRVRパラメタがそうするべきであるFTPサーバのTelnet印刷と非印刷の区別に関するどの注意がSRVR Nを実行できたか、そして、SRVR T.Ideallyが摩擦を避けるためにジョン・ポステルに登録されて、2つのサイトであるなら、それは災害ではありませんが、別物に同じパラメタを使用してください。 私は、パラメタが1つ以上の文字であることが許容されていて、大文字Xが本当に地方の特異性に使用されることを提案します。 以下は登録されているとみなされるべきです: 5h
T - Telnet print file 5h1
T--telnet印刷ファイル5h1
N - Normal. 5h2
N--正常です。 5h2
Means to turn off any previous SRVR in effect. (This makes
"non-print" the default case, rather than
making "Telnet print" and "non-print" equal. It is
probably a good idea if a user program can count on
being able to turn off an earlier SRVR without having
to know a specific inverse for it. Servers which do not
implement any other SRVR parameters need not implement
SRVR N either; user processes shouldn't send SRVR N
just for the hell of it.)
事実上、どんな前のSRVRもオフにすることを意味します。 (これは「telnet印刷」と「非印刷」を等しくするよりむしろ「非印刷」を不履行格にします。 ユーザ・プログラムが、それで特定の逆を知る必要はなくて以前のSRVRをオフにすることができるのを頼りにすることができるなら、それはたぶん名案です。 いかなる他のSRVRパラメタも実行しないサーバはSRVR Nを実行する必要はありません。 ユーザ・プロセスはちょうど面白半分にSRVR Nを送るべきではありません。)
3. FTP-2 reshuffles reply codes somewhat. There have been four attempts altogether, that I know of, at specifying a list of reply codes: RFCs 354 and 454 for FTP-1, and RFCs 542 and 640 for FTP-2. There is not much to choose from among the first three of these, which are basically the same, except for a slight increase in specificity each time through, e.g., the introduction of reply
3. FTP-2は回答コードをいくらか改造します。 そのIは、全体で4つの試みがあったのを回答コードのリストを指定するのに知っています: FTP-1のためのRFCs354と454、およびFTP-2のためのRFCs542と640。 これら特異性のわずかな増加を除いて、その都度基本的に同じ最初の3つから選ぶ多くがありません、例えば、回答の導入
4
4
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
code 456 for a rename which fails because a file of the same (new) name already exists. This increased specificity of reply codes doesn't seem to be much of a virtue; if 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. 5i
同じ(新しい)の名前のファイルが既に存在しているので、aのためのコード456はどのやり損ないを改名するか。 回答コードのこの増加する特異性は大した美徳であるように思えません。 aが操作をやり損ないに改名するなら、それはFTPユーザ・プログラムではなく、それがある他のファイルシステム・エラーよりむしろ名前闘争のためにそうであることを知る必要がある人間のユーザです。 私はFTP回答のテキスト部分にそのような情報をすべて入れるのに賛成します。 いくつかの実際の問題が実際にRFC640の回答コード改正で記述されます。(そこでは、回答コード番号を割り当てることの基本的な計画がFTP-1計画かオリジナルのFTP-2計画のどちらかより合理的です)。 しかしながら、私は、激動のプログラムを変えることを必要としない方法でRFC640の利益の大部分を得ることができると思います。 さらにこの下で。 5i
4. 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. 5j
4. FTP-2は正しく構成されたARPAnet委員会によって確立されました、そして、私たちはそれを実行するのにおいて義務があります。 だれでも実際にそれをそんなにあからさまに置くと思いませんが、私はそれに達したことを聞きました。 それは愚かです。 5j
5. 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 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
5. FTP-2はデータ接続のためのデフォルトソケットを指定します。 ほとんどの場所が既にとにかくデフォルトソケットを使用します、そして、あなたが簡単でありたいなら、255メッセージを無視するほど簡単です。 これはもちろん安全保障問題です、そして、残念ながら、それらが間接的に私の給料を支払っても、私はCIAが私が1968年にどんな反戦デモンストレーションに出席したか、そして、どのベトナムの小村の動向をおさえるかを助けることに関する多くの興奮が最もすばらしい戦略の効果のために爆撃されるのが興奮させることができません。 私は、ページのためにこの対象を激賞できて、メール-2に対する議論を書くひまができるなら、たぶん激賞するつもりですが、当分1個の逸話をただ打ち明けさせてください: 私は私自身のサイトで書かれて、維持されるプログラムの地方の維持に責任があるので、ARPAnetホストでアカウントに近づく手段を持っています、もう片方のサイトのだれか。 しかしながら、もう片方のサイトが、私たち部外者(アカウントは数人の他のホストで私の地位で人々によって共有されます)が彼らの重大なシステムセキュリティを保護すると本当に信じないので、毎週、彼らはアカウント(先週のものはHRHPUKであった)のための新しい無作為のパスワードを発生させて、ネットワークメールで私たちに皆、通知するためにコンピュータ・プログラムを動かします。 さて、私のシステムと少なくとも他のもののひとりでは、メールが読まれないのは保護されました。 それを読むとき、私のメールを削除しますが、それはそれらなしでHRHPUKを覚えているのが十分毎週、それを変えるのが困難であるので、私は私たちのシステムのファイルに自然にそれを書きます。 原則として保護されていた状態でそのファイルを読むことができましたが、それはそのように読まれません、私が使用に欲しいときに、他の誰かのものが私を時々在職させるので
5
5
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
it, and the other passwords in it are for open guest accounts which are widely known. Moral #1: Security freaks are pretty weird. 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.) 5k
それ、およびそれの他のパスワードはそうです。広く知られている開いている客アカウントのために。 教訓#1: セキュリティ熱狂者はかなり奇妙です。 教訓#2: 秘密がありましたら、ARPAnetにそれを保たないでください。 (この1週間私はTENEXセキュリティのおよそ2つの新たに発見された穴を聞きました。) 5k
6. 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. 5l
6. FTP-2はオンラインで利用可能です、そして、新しいホストがそれをする方法を見つけることができないように、FTP-1は利用可能ではありません。 Aargh! 何でもする何という理由! 確実に、だれかが再びそれをタイプするのは、皆がプログラムを変えるより高価でないでしょう。 その間、これらの新しいホストは助けのためにFTPを起こす際にジョン、ジェフ、ボビーまたは私にさえ尋ねることができます。 5l
7. 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 STRU 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. 5m
7. FTP-2は奇妙なMODEsとSTRUsにいくつかの変化を持っています。 これはまた、私がエキサイトできない別のものです。 私たちはMODE SとSTRU Fだけを支持します、そして、私たちがFTP-2に強制されても、それはたぶんまだ本当になっているでしょう。 非常に大きいファイル転送をする比較的わずかな人々が、再開能力を改良する必要があるなら、私たちの残りに影響を与えないで、それらはFTP-1の中でそうすることができます。 TENEXによる呼び出されたファイル転送の最近の実現は、FTP-1枠組みの中で個人能率給制の問題を解決できるのを示します。 例えば、IBMの人々がFTP-1で記録構造に関する何らかの問題を持っているなら、彼らにFTP-1と、解決策がことなら何でもであるかそれを解決させてください、一人も影響を受けない。プログラムを変えなければなりません。 5m
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-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: 6
よく、そして、要するに、ものがそうである方法で私が持っていた成功にネットワークの周りにファイルを移します。 私が困難に陥るとそれが特定のホストが一般にFTP-1の何らかの特定の特徴を実行していないからであるまた、同時にFTP-2に変えなければならないと彼らが少しもより速くそれをすると思う理由が全くありません。 FTP-2時頃の主なものは私が始めに言ったように存在がFTP-1における問題を解決しない口実であるということです。 事実を除いて、人々がプロトコルドキュメントの何にでも反するのに気が重いというそのようないくつかの問題がかなり些細です、まるで後者が聖書であるかのように。 いくつかは実際に何らかの連携努力を必要とします。 ここに、私の問題リストがあります: 6
1. It is almost true that an FTP user program can understand reply codes by the following simple algorithm: 6a
1. FTPユーザ・プログラムが以下の簡単なアルゴリズムに回答コードを解釈できるのは、ほとんど本当です: 6a
a. Replies starting with 0 or 1 should be typed out and
otherwise ignored. 6a1
a。 タイプで打たれます。別の方法で、0か1から始まる回答は、無視されるべきです。 6a1
6
6
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
b. Replies starting with 2 indicate success (of this step or
of the whole operation, depending on the command). 6a2
b。 2から始まる回答が成功(このステップか操作全体がコマンドによる)を示します。 6a2
c. Replies starting with 4 or 5 indicate failure of the
command. 6a3
c。 4か5から始まる回答がコマンドの失敗を示します。 6a3
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.) 6a4
d。 3から始まる回答は3つの場合で認識されるだけです: 初期の300メッセージ、330パスワード要求、および350メール応答。 (それがたった今1つを期待しているか否かに関係なく、ユーザ・プログラムがそれが単に得たどの300メッセージを区別する必要はないかに注意してください。) 6a4
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 procedure for handling the STAT command: 6b
維持装置がそれに働いていると私に言ういくつかのサーバのバグは別として、この唯一の実際の問題が(1つのメッセージを返すより時々多く)のサーバによるHELPコマンドです。(そのHELPコマンドは、オリジナルのプロトコルにはなくて、0xx、1xx、または2xxを返します)。 BBNの1人のネットワーク・プロトコルの専門家からの単語は(a) 050か030がヘルプへの正しい応答であり、マルチ線応答のためのプロトコルには(b) 完全に良いメカニズムがあるということです。 残念ながら、これは現実に対処する際に多くを良くしません。 STATコマンドを扱うための一定の手順はあるように思えます: 6b
151 information
151 information
151 ...
151 information
200 END OF STATUS 6b1
151 情報151情報151… 151 情報200END OF STATUS 6b1
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 RFC 354 it ought to be 6c
上のアルゴリズムで、ぴったり合います。 1xxがSTATのようなコマンドへの積極的な応答を構成するべきであるという事実にもかかわらず、これはあります、RFC354によると、それが6cであるべきであるように
151-information
information
...
151 information 6c1
151情報の情報… 151 情報6c1
instead. RFC 414, which approves of the 200 reply for STAT, also gives 200 for HELP. (It seems to me, by the way, that 050 and 030 aren't good enough as responses to HELP since they "constitute neither a positive nor a negative acknowledgement" of
代わりに。 また、RFC414(STATのために200回答に賛成します)はヘルプを求めて200を与えます。 (ところで、それらが「どちらも、積極的で否定的な承認を構成しない」ので050と030がヘルプへの応答として十分良くないように思えます。
7
7
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
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 RFC 354, 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. 6d
その結果、それが、いつ何をしたらよいかを人間ユーザに尋ねるべきであるかユーザ・プログラムに言わないでください。そして、HELPコマンド、次に)。 私が、RFC354にもかかわらず、200応答がヘルプの他のどんなもそれが与える終わりにすべてのサーバによって与えられることを提案する、言いましょう、6月1 代替手段はFTP-2かヘルプとSTATの両方のためにマルチ線1xxの上の皆を標準化しようとするのを待っている間に現在のかなり混沌の状況がいつまでも続くどちらかです。 STATを変えることに反対して私はいます、そして、FTP-2を待つことに反対して私がいるのは、明確であるはずです。私が判断できる限り、STATは皆のために完全に働いています。 残念ながら、「公式に」私のプランを採用するためのどんな本当のメカニズムもありませんが、私は、TENEXが6月1日にそれをすると他の国々がやって来るのを賭けます。 6d
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. 6e
2. 別の回答コード問題は9xxのプロトコルでないのにおける「実験的な」回答の使用です。 これはBBNメール転送メッセージと私が知っているあるもう一方を含んでいます。 この手順はRFC385によって認可されますが、私への悪い考えのように見えます。 一つには、ユーザ・プログラムには、回答が肯定する、否定する、または無関係であるかを知る方法が全くありません。 私がやけどされた例はすべて、0xxメッセージであるべきでした。 私は、コードが回答コードを解釈するために上に与えられた計画に合うように選ばれた000-599範囲でそのようなすべてのメッセージに与えられているよう提案します。実験を示すのにx9xかxx9は使用できました。 6e
3. One more on reply codes: 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 is proposed below. 6f
3. 以下を回答でのもうひとつコード化します。 RFC630(メールとMLFLのための回答コードへのTENEXモッズに関するもの)は「永久的な」失敗に対して4xxカテゴリの中で「一時的」の問題を提起します。 4xxと5xxの意味を変えることによってRFC640がFTP-2文脈でのこの質問に対処するので、前者が一時的な誤りによってあって、後者は永続エラーのためのものです。 この考えが好きであり、私は、人々が変化を無視できる道におけるFTP-1使用のために容易にそれを適合させることができたと思って、まだ勝っています。 現在のところ、私は、一時的で永久的な誤りを見分けるのを試みる唯一のプログラムがTENEX郵送者であると信じています。 他の計画については、現在、4xxと5xx応答の間で区別を全くしません。 両方が失敗を示します、そして、どんな再試行もメッセージのテキスト部分に基づく人間のユーザによって行われます。 回答コードへの特定の変化は以下で提案されます。 6f
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
恐らく、私はRFC640に関するポイントをもう少し指摘するべきです、FTP-2時頃にそれが最も良いものであり、それのための唯一の議論がI掘り出し物であるので
8
8
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
all convincing. Let me try to pick out the virtues of 640 and indicate how they might be achieved in FTP-1. 6g
すべて納得させます。 640の美徳を選んで、それらがFTP-1でどう達成されるかもしれないかを示そうとするのをさせてください。 6g
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 existing 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. 6g1
a。 3xxカテゴリはTelnet接続におけるさらなる交渉が必要である「積極的な中間的回答」に一様に使用されます、RNFRのように。 残念ながら、影響存在なしでこれを変えることができません。ユーザ・プログラム(ここの私の目標の1つはいくつかのサーバが現在のように続いて、他のものが私が以下でする提案を採用している間、既存のユーザ・プログラムが働くのを可能にすることです。) しかしながら、この3xx考えは論理的に微笑ましいのですが、純真なユーザ・プログラムが回答を解釈できるのは本当に必要ではありません。 RFC640における唯一の本当に新しい3xxがRNFRのための350コードです。 しかし、また、ケースでないRNFRの後に返されるかもしれない2xxコードがある場合にだけ、これはユーザ・プログラムのための本当の改良でしょうに。 640 また、220で300の初期の接続メッセージを撤廃しますが、闘争が全く再びここに明確にありません。 6g1
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 6g2
b。 1xxの使用は、ファイル転送の始まりの間、現在250コードであることを含むように広げられます。 考えは1xxメッセージがユーザ・プロセスの状態に影響しないということですが、これは本当に本当ではありません。 ファイル転送命令を考えてください。 13RFCページの640上の州のダイヤグラムはわずかに紛らわしいです。 まるで1xx回答がユーザ・プログラムで単に無視されるかのように見えます。 ほんとうは、その小さい輪は多くの仕事を隠します: ファイル転送自体! サーバがすぐ2xxメッセージでファイル転送命令に答えるなら、それはうまくいっている転送ではなく、サーバのバグでしょうに。 実況ダイヤグラムはさらに6g2に似ています。
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. 6g3
(悪い回答のための「W」sからのブランチがある。) それが何をしているかを知るためにサーバを信じるならユーザ・プログラムが面食らうことのない1xxの代わりに2xxを予想できるのは、このダイヤグラムから明確であるはずです、W州のどれにあるかを知っているので。 事実上、ファイル転送における1xxの使用は他の用途と非常に異なっています。(用途は本当に、さらにFTP-1における0xxと1xx回答に似ています)。 私は、RFC640にこの特定のポイントをバグと呼ぶでしょう。 6g3
c. Automatic programs which use FTP (like mailers) can decide
c。 FTP(郵送者のような)を使用する自動プログラムは決めることができます。
9
9
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
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 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. 6g4
失敗の転送を列に並ばせるか、または捨てるかが4xxと5xxの間でコードを区別に基礎づけました。 それらの一時的な誤りは実際には現実では決して起こりませんが、私はこの考えが好きです。 FTP-1で4xx回答の多くを5xxに動かすことによって、これを達成できるでしょう。 郵送者は、再試行するかどうか決める最初のケタを使用するように変更されるでしょう。 何らかのサーバが変換で遅いなら、この計画はどんなカタストロフィーも引き起こしません。 それは単に不要な再試行に通じます。 CPU数サイクルが公式のスイッチに続く月の間、浪費されるでしょう。 したがって、この特徴は(a)と(b)と非常に異なっています。(一気に実行されないなら、(b)は突発故障に通じるかもしれません)。 (はい、私はFTP-2が異なったICPソケットでするべきであるのを知っています。 私は、FTP-2にもかかわらず、FTP-1に美徳を移すことができるかどうか議論していません。) かかわった特定のコードは以下に記載されています。 6g4
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 the 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. 6g5
d。 メッセージのタイプを示す2番目のケタの使用。 (提案された分割は完全に清潔であるというわけではありません; 例えば、なぜデータ接続よりファイルシステムに関して150(「間違いなく状態をファイルしてください;データ接続を開こうとしている 」)があると考えられますか?) 容易にこれができます、2番目のケタが現在どんなユーザ・プロセスにも重要でないので--(c)のために、このプランでは、変更には、TENEX郵送者は既に当然です。 これがほとんど美的なポイントであるので、だれにとっても、それが難しいなら、私はそれをするのをためらっています。 いくつかのユーザ・プログラムがこれらを区別するといけないので、特に、25xメッセージを放っておきたいと思うでしょう。 プログラムのために完全に意味されるものに、これは特にありそうです: 251と255。 したがって、この考えがFTP-1のx2xの意味とx5xに採用されるなら、私はそれを提案します。交換されます。 この提案は以下の特定のリストに反映されます。 6g5
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: 7
作られているのを見たいと思うそれの大部分が単にドキュメンテーション変化であるFTP-1への特定の変化をまとめさせて、現実を反映してください: 7
1. HELP should return 200. All commands should return 2xx if successful, and I believe all do except HELP. 7a
1. ヘルプは200を返すべきです。 うまくいくなら、すべてのコマンドが2xxを返すべきです、そして、私はヘルプを除いて、すべてがすると信じています。 7a
2. The definition of 1xx messages should be changed to read: "Informative replies to status inquiries. These constitute neither a positive nor a negative acknowledgment." 7b
2. 読むために1xxメッセージの定義を変えるべきです: 「資産調査に関する有益な回答。」 「これらはどちらも積極的で否定的な承認を構成しません。」 7b
10
10
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
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 programs are encouraged to determine the significance of the reply from the first digit, rather than requiring a specific reply code, when possible. 7c
3. 実験回答コードは自動化されたユーザ・プログラムへのフォームx9xかxx9の最初のケタが回答の意味を反映するために選ばれているところのものであるはずです。599より大きい回答コードは可能にしました。 回答が2番目のケタのための既存のカテゴリの1つになるなら、xx9フォームは使用されるべきです。 ユーザ・プログラムが特定の回答コードを必要とするより最初のケタから回答の意味をむしろ決定するよう奨励されます、可能であるときに。 7c
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. 7d
4. 議論のないSTATコマンドは転送が進行している間、それをTELNET SYNCHと共に与えるかもしれないのを除いて、現在の働くディレクトリのためにリストアップされているディレクトリに関する要求であると考えられます、その場合、それはその転送の状態を求めて要求です。 (皆は、この最初の部分をするように思えます。 私はだれかが実際に2番目を実行するかどうかを確信していません。 これで、プロトコルはただ現実に同意しています。) STATコマンドに関する回答はゼロであるべきですか、より多くの1xxメッセージが200従いました。 7d
5. TYPEs P and F mean that the source file contains ASA control characters and that the recipient program should reformat it if necessary. Servers which care about Telnet-print vs. non-print should implement SRVR T and SRVR N. All user processes should provide a way for the human user to specify an arbitrary SRVR command. 7e
5. TYPEs PとFがソースファイルがASA制御文字を含んでいて、受取人プログラムがそうするべきであることを意味する、再フォーマット、それ、必要なら。 非印刷に対してTelnet-印刷を心配するサーバはSRVR Tを実行するべきです、そして、SRVR N.Allユーザ・プロセスは人間のユーザが任意のSRVRコマンドを指定する方法を提供するべきです。 7e
6. (This is just a resolution of a loose end in documentation.) Nested reply codes are not allowed. I don't think this really needs more discussion; they never happen and can't possibly work, and FTP user programs shouldn't have to worry about them. 7f
6. (これはただドキュメンテーションの未処理事項の解決です。) 入れ子にされた回答コードは許容されていません。 私は、これが本当により多くの議論を必要とすると思いません。 彼らは、決して起こらないで、働くことができません、そして、FTPユーザ・プログラムはそれらを心配するはずである必要はありません。 7f
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. Replies invented in RFC 454 are so noted; since some of them are for commands largely not implemented like REIN, they may be irrelevant. 7g
ここに、現在のFTP-1回答と、それらが新しい計画のためにどう番号を付け替えられるべきであるかに関するリストがあります。 6月1日現在、4xxから5xxまでの変化はREQUIREDであるべきです。 2番目か3番目のケタにおける変化はそれほど重要ではありません。 (上で説明されるように、何人かのホストが条件を満たさないでも、壊滅的にならないでしょう。) また、リストはRFC640から適合させられた1つの新しい可能な回答を含んでいます。 RFC454で発明された回答はそのように注意されます。 それらのいくつかがREINのように主に実行されなかったコマンドのためのものであるので、それらは無関係であるかもしれません。 7g
OLD NEW TEXT
7g1
0x0 0x0 (These messages are not very well defined nor very
または、OLD NEW TEXT 7g1 0x0 0×0、(これらのメッセージがそれほどよく定義されない、非常に。
11
11
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
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.)
110 111 System busy doing... (This RFC 454 message could
easily be considered an example of the one above,
but since the 454 authors want to distinguish it,
here it is in another number.)
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. 7g2
202 252 ABOR ignored, no transfer in progress.
new 206 Command ignored, superfluous here.
230 230 Login complete.
231 231 Logout complete. (RFC 454: Closing connection.)
232 232 Logout command will be processed when transfer is
complete. 7g3
233 233 Logout complete, parameters reinitialized. (RFC
454 for REIN) 7g4
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
256 256 Mail completed ok.
300 300 Connection greeting
301 301 Command incomplete (no crlf)
330 330 Enter password 7g5
331 331 Enter account (RFC 454)
350 350 Enter mail. 7g6
400 huh? "This service not implemented." I don't
understand
this; how does it differ from 506? If it means no
重要。 サーバは自ら判断するべきです。) 100 110システム状態回答。 (だれもプロトコルのようにSTATをしないので、これは論点であるかもしれません。) することで忙しい110 111システム… (上のものに関する例であると容易にこのRFC454メッセージを考えることができましたが、454人の作者がそれを区別したがっているので、もう1つの数にはそれがここに、あります。) 150 150は「状態回答をファイルします」。 (これが本当にそうであるなら、それは120に切り換えられるでしょう、しかし、私が何が意味されるかを信じているのは、ファイル状態回答より接続形態回答である中間の転送におけるむき出しのSTATへの応答でしょうに。) 151 121ディレクトリリスト回答。 200 200はOKにコマンドが続きます。 201 251ABOR OK。 202 252ABORが無視した7g2、進歩ここで無視されて、余計な新しい206Commandで転送がありません。 230 230は完全な状態でログインします。 231 231は完全な状態でログアウトします。 (RFC454: 接続を終えます。) 転送が完全であるときに、232 232ログアウトコマンドは処理されるでしょう。 7g3 233 233は完全な状態でログアウトして、パラメタは再初期化されました。 (たづなのためのRFC454) 7g4 250 250転送は正しく始まりました。 251 251マークyyyyはOKに完成したmmmm252 252Transferと等しいです。 253 223はOKを改名します。 254 224はOKを削除します。 255 255SOCK nnnn256 256メールはOKを完成しました。 不完全な状態で301 301Commandに挨拶している300 300接続(crlfがありません) 330 330はパスワード7g5 331 331Enterアカウント(RFC454)に入ります。 350 350はメールを入力します。 7g6、400 えっ? 「実行されなかったこのサービス。」 私はこれを理解していません。 それはどのように506と異なっていますか? それが、いいえを意味するなら
12
12
NWG/RFC# 691 BH 6-JUN-75 23:15 32700 One More Try on the FTP
NWG/RFC#691BH6 6月の75 23: もうものがFTPで試みる15 32700
FTP
at all, who gave the message? Flush. 7g7
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.
433 533 Need account to write files.
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. 7g8
453 423 Transfer incomplete, insufficient storage space.
454 454 Can't connect to your socket.
455 425 Random file system error (RFC 454) 7g9
456 526 Name duplication, rename failed (RFC 454)
457 557 Bad transfer parameters (TYPE, BYTE, etc) (RFC
454)
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.
507 507 Some other problem. (RFC 454)
550 520 Bad syntax in pathname. (RFC454) 7g10
全くFTP?(そのFTPはメッセージを与えました)。 洗い流してください。 さようならを現在ユーザを受け入れない7g7 401 451は修理します。 430 430Foo、あなたはパスワードハッカーです! 431 531の無効のユーザかパスワード。 このサービスに、無効の432 532ユーザ。 433 533は、ファイルを書くために説明されなければなりません。 434 454はオペレータでログアウトします。 435 455はシステムでログアウトします。 436 456は停止を修理します。 450 520、ファイルが見つからない。 451 521アクセス拒否。 452 452は不完全な状態で移されて、接続は閉じました。 7g8 453 423は不完全で、不十分な集積スペースを移します。 454 454はあなたのソケットに接続できません。 455 425ランダムファイルシステム・エラー(RFC454)7g9 456 526Name複製、457 557の失敗した(RFC454)Bad転送パラメタ(TYPE、BYTEなど)(RFC454)を500 500Commandおしゃべりに改名してください。 501 501議論おしゃべり。 502 502議論なくなります。 503 503の議論が闘争します。 あなたがここからそこに到着させることができない504 504。 505 505は前のコマンドとの闘争を命令します。 動作が実行しなかった506 506。 507 507、ある他の問題。 (RFC454) パス名の550 520誤りのある構文。 (RFC454) 7g10
13
13
一覧
スポンサーリンク
