RFC625 日本語訳
0625 On-line hostnames service. M.D. Kudlick, E.J. Feinler. March 1974. (Format: TXT=2172 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Mike Kudlick (SRI-ARC) RFC # 625 Jake Feinler (SRI-ARC) NIC # 22152 March 7, 1974
ネットワークワーキンググループマイクKudlick(様アーク)RFC#625ジェークFeinler(様アーク)NIC#22152 1974年3月7日
ON LINE HOSTNAMES SERVICE
系列ホスト名サービスに関して
We agree with the suggestion in RFC 623 that more than one Host should be responsible for maintaining a copy of the Hostnames data base. The NIC is certainly willing to continue to maintain the master data base, and make it available to any secondary Host that volunteers to maintain a copy. We would be pleased to have UCSB serve as one of the secondary Hosts.
私たちは1HostがHostnamesデータベースのコピーを維持するのに責任があるべきであるというRFC623での提案に同意します。 確かに、NICは、マスターデータベースを維持し続ける、コピーを維持するのを買って出るどんなセカンダリHostにも利用可能にしても構わないと思っています。 UCSBにセカンダリHostsの1つとして機能させるでしょう。
However, we disagree with the suggestion in RFC 623 that a server process should be implemented to give user processes access to the official Hostnames file at the NIC. The file in question is a sequential file and it seems to us that FTP is entirely appropriate for this need. As far as setting up common login parameters among the servers, this doesn't appear to be a major problem. Even with a user/server process there would be a requirement for additional protocol agreements, so it doesn't seem that much of an added burden to decide on common login parameters when using FTP.
しかしながら、私たちはサーバプロセスがNICの公式のHostnamesファイルへのユーザ・プロセスアクセスを与えるために実装されるべきであるというRFC623での提案と意見を異にします。 問題のファイルは順編成ファイルです、そして、私たちにとって、この必要性に、FTPが完全に適切であるように思えます。 遠くにサーバの中で一般的なログインパラメタをセットアップするように、これは大した問題であるように見えません。 ユーザ/サーバプロセスがあっても、追加議定書協定のための要件があるでしょう、したがって、FTPを使用するとき、一般的なログインパラメタを決めるのは加えられた負担のそれだけに思えません。
We are puzzled by the apparent distaste for FTP. In our opinion the goal has been to set up a network file transfer mechanism that everyone can use for a variety of needs without further programming required. If FTP is that bad, shouldn't the criticism and work be directed towards improving or replacing it, rather than making end runs around it? FTP is surely more complex than is required for any particular application including this one, but isn't that true by definition of a general facility?
私たちはFTPのための見かけの嫌悪で当惑しています。 目標がセットアップすることであるという私たちの意見では、皆がさまざまな必要性にさらにプログラムを作らないで使用できるネットワークファイル転送メカニズムが必要です。 FTPがそんなに悪いなら、それの周りで回避的な戦術をするよりむしろそれを改良するか、または取り替えるのに批評と仕事を向けるべきではありませんか? FTPは確実に何かこれを含む特定用途のために必要とされるより複雑ですが、それは定義上一般的な施設に関して本当ではありませんか?
We also prefer to maintain the file in ASCII. It is easier, it seems to us, to check out data or data transfer problems in that form rather than in binary.
また、私たちは、ASCIIでファイルを保守するのを好みます。 それは、より簡単です、と私たちにとって思えます、バイナリーでというよりむしろそのフォームでのチェックアウトデータかデータ転送問題に。
[ 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. 10/99 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした]、[アレックス・マッケンジーによるオンラインRFCアーカイブ、][GTEからのサポート、以前BBN社10/99]
Kudlick & Feinler [Page 1]
Kudlick&Feinler[1ページ]
一覧
スポンサーリンク