RFC949 日本語訳
0949 FTP unique-named store command. M.A. Padlipsky. July 1985. (Format: TXT=4017 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Mike Padlipsky Request for Comments: 949 Mitre Semisupersedes RFC 505 July 1985
ネットワークワーキンググループマイクPadlipskyはコメントのために以下を要求します。 949 斜め継ぎSemisupersedes RFC505 1985年7月
FTP UNIQUE-NAMED STORE COMMAND
FTPのユニークに命名された格納命令
STATUS OF THIS MEMO
このメモの状態
This RFC proposes an extension to the File Transfer Protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCはARPA-インターネットコミュニティ、および要求議論のためのFile Transferプロトコルへの拡大と改良のための提案を提案します。 このメモの分配は無制限です。
DISCUSSION
議論
There are various contexts in which it would be desirable to have an FTP command that had the effect of the present STOR but rather than requiring the sender to specify a file name instead caused the resultant file to have a unique name relative to the current directory. This would be useful for all sorts of "pool" directories; the directories that serve as queues for printer daemons come immediately to mind (so do fax and even cardpunch daemons' queues), although naturally the sort of printer queue that a local command has to manage the interface to isn't what's meant by "pool" in this context.
しかし、送付者が結果のファイルがカレントディレクトリに比例してユニークな名前を持つために代わりに引き起こされたファイル名を指定するのが必要であるというよりも現在のSTORの効果を持っていたFTPコマンドを持っているのが望ましい様々な文脈がむしろあります。 これはいろいろな「プール」ディレクトリの役に立つでしょう。 プリンタデーモンのための待ち行列として機能するディレクトリはすぐに思い浮かびます(ファックスとカードパンチデーモンの待ち行列さえもそうします)、ローカルのコマンドがインタフェースを管理しなければならないプリンタのキューの種類は当然「プール」によってこのような関係においては意味されることではありませんが。
If we accept the need for such an FTP extension, and that it should not be done with an "X" command because it needs to be relied on "everywhere," the interesting question then becomes how to mechanize it. Probably the most natural way to do it would be either to add a "control argument" of -UNM to the syntax of STOR, now that there are enough UNIXtm's around so that this good old Multics trick isn't alien any more, or even to declare that STOR with no argument should cause a directory-unique name to be generated. However, either of these would necessitate "reopening" the STOR command code, which is a distasteful sort of exercise. Since most FTP's presumably do a dispatch sort of thing off a list of command names to begin with, then, an additional command would seem to be the way to go.
私たちが、そのようなFTP拡大の必要性と、「いたる所で」当てにされるのが必要であるので「X」コマンドでそれをするべきでないと受け入れるなら、面白い質問はどうそれを機械化するかになります。 それをするたぶん最も自然な方法は、STORの構文への-UNMの「コントロール議論」と、現在、UNIXtmの十分なものが周囲にあるのでこの良い古いMulticsトリックがもう異質でないと言い足すか、または議論のないSTORがディレクトリユニークな名前を発生させるべきであると宣言するのさえどちらかでしょう。 しかしながら、これらのどちらかが、STORコマンドコードを「再開させること」を必要とするでしょう。(コマンドコードは不快な種類の運動です)。 FTPのほとんどのものが初めにおそらくコマンド名のリストからものの発信種類をするので、そして、追加コマンドは行く方法であるように思えるでしょう。
Naming the command calls for a bit of thought. STore Uniquely Named (-> STUN) is silly; UNIQue comes to close to free advertising or even trademark infringement (and confuses fingers if you're typing); Store Uniquely NaMed (-> SUNM) doesn't avoid free advertising either; Uniquely Named STore (-> UNST) might look like a synonym for DELEte, though it's not all that bad; SToRe Uniquely named (-> STRU) is taken; and so it goes. The best bet seems to be STOU.
コマンドを命名すると、少しの考えが求められます。 STore Uniquely Named(->STUN)は愚かです。 UNIQueは無料の広告か商標権侵害(そして、あなたがタイプしているなら、指を混乱させる)の近くでさえ意識を取り戻します。 ストアUniquely NaMed(->SUNM)は無料の広告を避けません。 唯一、それはそんなにすべて悪くはありませんが、Named STore(->アンスト)はDELEteのための同義語に似るかもしれません。 (->STRU)というSToRe Uniquelyを取ります。 そして、したがって、それは行きます。 最善の策はSTOUであるように思えます。
Of somewhat more practical import, there's also the question of whether the sender needs to be apprised of what the unique name turned out to be. Intuitively, sometimes this would be the case and sometimes it wouldn't. Making it optional is almost certainly too
また、いくらか実用的な輸入には、送付者が、ユニークな名前が判明したものについて通告される必要があるかどうかに関する質問があります。 時々、これは直観的に、そうでしょう、そして、時々それはそうでないだろうこと。 またそれを任意にするのが、ほぼ確実にそうである。
Padlipsky [Page 1]
Padlipsky[1ページ]
RFC 949 July 1985 FTP Unique-Named Store Command
RFC949 1985年7月のFTPのユニークに命名された格納命令
much like work, though--even if it does have the subtle virtue of finally getting control arguments into FTP. Therefore, why not just include it in a suitable response-code's free text field (unless, of course, an avalanche of comments comes in urging it not be done at all)?
もっとも、仕事のように、それに最終的に得ることの微妙な美徳があっても、FTPに議論を制御してください。 したがって、なぜ適当な応答コードの無料のテキストフィールドにただそれを含んでいませんか?(コメントの雪崩がもちろんそれを促しながら入らない場合、全くしないでください)
Note, by the way, that the intent here is emphatically not to sidestep whatever access control, authentication, and accounting mechanisms Hosts might have in play before the user can do an old STOR or a new STOU, but with suitable publicized ID's and passwords it could be almost as good as the proposal made in RFC 505.
ここの意図がHostsがプレーにどんなアクセス管理、認証、および会計機構も持つかもしれなくてもユーザが古いSTORか新しいSTOUができる前に強調して寄らないことですが、適当なIDのピーアールされたものとパスワードによって、それがRFC505でされた提案とほとんど同じくらい良いかもしれないことにところで、注意してください。
RECOMMENDATION
推薦
Add a new command, STOU, to FTP, which behaves like STOR except that the resultant file is to be created in the current directory under a name unique to that directory. The 250 Transfer Started response should include the name generated (unless the copy of FTP I have is so old that 250 isn't the right number any more).
新しいコマンド、FTPへのカレントディレクトリの中でそのディレクトリにユニークな名前の下で作成されるのを除いて、結果のファイルがことであるSTORのように振る舞うSTOUを加えてください。 250Transfer Started応答は発生という名前を含むべきです(私が持っているFTPのコピーがとても古いので250がそれ以上正しい数であるなら)。
Padlipsky [Page 2]
Padlipsky[2ページ]
一覧
スポンサーリンク