RFC180 日本語訳
0180 File system questionnaire. A.M. McKenzie. June 1971. (Format: TXT=8154 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group Alex McKenzie Request for Comments #180 BBN NIC #7123 25 June 1971 Categories: D.7, G.3 Updates: none Obsoletes: none
コメント#180BBN NIC#7123の1971年6月25日のカテゴリを求めるワーキンググループアレックスマッケンジーRequestをネットワークでつないでください: D.7、G.3アップデート: Obsoletesのいずれも:でない なし
File System Questionnaire
ファイルシステムアンケート
As noted in RFC #164 (page 35), a subcommittee of the NWG, under the chairmanship of Abhay Bhushan, is currently generating proposals for a "data transfer protocol" and a "file transfer protocol".
RFC#164(35ページ)で注意されるように、Abhay Bhushanを議長として、NWGの小委員会は現在、「データ転送プロトコル」と「ファイル転送プロトコル」のための提案を生成しています。
The subcommittee has decided that the file transfer protocol should provide standard methods for requesting the transfer of a file but should not, at this time, attempt to standardize file naming conventions, access control conventions, and the like. Thus a user who is, for example, trying to store a file on a remote Host will be required to use the file naming conventions appropriate to the remote Host.
小委員会は、ファイル転送プロトコルが、ファイルの転送を要求するための標準方法を提供するべきですが、このときファイル命名規則、アクセス制御コンベンション、および同様のものを標準化するのを試みるはずがないと決めました。 したがって、例えばリモートHostのファイルを保存しようとしているユーザが、リモートHostに適切なファイル命名規則を使用するのに必要でしょう。
Given the above point of view, it becomes imperative for users to have some source of information about Host file conventions. Such information, once compiled, will also serve as input to possible standardization efforts of the file transfer subcommittee. For this reason Abhay has asked me to solicit information on file conventions from the Host organizations. What follows is a description of the kinds of information of interest. I am well aware of the fact that many of you are tired of writing system descriptions; Xerox copies of short sections of your local documentation are fine if the result is complete and comprehensible. (In the case that your Host will never permit network use of your file system, a note to that effect would be sufficient.)
上の観点を考えて、Hostファイル規約に関してユーザには何らかの情報源があるのは必須になります。 また、そのような一度コンパイルされた情報はファイル転送小委員会の可能な標準化取り組みに入力されるように役立つでしょう。 この理由で、Abhayは、Host組織からファイル規約の情報に請求するように私に頼みました。 続くことは情報の種類の興味がある記述です。 私はあなたの多くにシステム記述を書くのに飽きているという事実をよく知っています。 結果が完全であって、分かりやすいなら、地元のドキュメンテーションの短いセクションのゼロックスコピーはすばらしいです。 (あなたのHostがあなたのファイルシステムのネットワーク使用を決して可能にしないで、注意はその趣旨で十分でしょう。)
Information Requested
要求された情報
1. File naming conventions - We (loosely) define a pathname to be the data string which must be input to the file system by a user (a network user if your system makes a distinction between local and network users) in order to identify a file. We are interested in syntax, semantics, and defaults. Typical components of pathnames are:
1. ファイル命名規則--私たちは、ユーザ(ネットワーク利用者はあなたのシステムであるなら地方とネットワークユーザの間で区別をする)がファイルを特定するためにファイルシステムに入力しなければならないデータ列になるように(緩く)パス名を定義します。 私たちは構文、意味論、およびデフォルトに興味を持っています。 パス名の典型的な成分は以下の通りです。
- "device" fields - user names - version numbers - index names - punctuation marks
- 「デバイス」分野--ユーザ名--バージョン番号--インデックス名--句読点
[Page 1] Common types of defaults are:
[1ページ] 普通形のデフォルトは以下の通りです。
- device is disk - version number is largest in system
- デバイスはディスクです--バージョン番号はシステムで最も大きいです。
For hierarchical file structures, descriptions may be fairly complex, but with lots of defaults; in such cases an illustration of a "normal" pathname might be helpful.
かなり複雑ですが、階層ファイル構造において、記述は多くのデフォルトでそうするかもしれません。 そのような場合「正常な」パス名のイラストは有用であるかもしれません。
2. Access control mechanisms - Access control mechanisms range from simply knowledge of a file's pathname to elaborate hierarchies of group-project-task-username membership with passwords and separate controls for reading and writing. There are two aspects of the access control mechanism which are of interest:
2. アクセス管理機構--アクセス管理機構は、読み書きのためのパスワードと別々のコントロールでグループプロジェクトタスクユーザ名会員資格の階層構造について詳しく説明するために単にファイルのパス名に関する知識から変化します。 アクセス管理機構の興味がある2つの局面があります:
a. A description of what inputs the user should give the file system, both at the time of file creation and at the time of retrieval, in order to define the permitted modes of access and to gain access. What are the syntax and semantics of these inputs?
a。 ユーザを入力することに関する記述は、ファイル作成時点と検索時点で、アクセスの受入れられた方法を定義して、アクセサリーを獲得するためにファイルシステムを与えるべきです。 これらの入力の構文と意味論は何ですか?
b. A description of the ways in which the access control mechanism is designed to help (or hinder) the sharing of files. For example, may two users "simultaniously" update a given file? May the creator of the file define a set of authorized users to the file system (and how)? Is it possible to define different access controls for various subunits of a given file?
b。 アクセス管理機構がファイルの共有を助ける(妨げになる)ように設計されている方法の記述。 例えば、2人のユーザが「simultaniouslyに」与えられたファイルをアップデートするかもしれませんか? ファイルのクリエイターはファイルシステム(そして、どのように)と1セットの認定ユーザを定義するかもしれませんか? 与えられたファイルの様々な「副-ユニット」のために異なったアクセス制御を定義するのは可能ですか?
3. Directories - Many systems maintain file directories which are designed to be helpful to the user. A directory might, for example, provide a list of all files created by a particular individual, along with some information regarding file size, file structure, access controls, etc. In general, such systems allow the user to input a pathname and retrieve the directory to which that pathname refers. Aspects of the directory structure of interest are:
3. ディレクトリ--多くのシステムが、ユーザにとって、設計されているファイルディレクトリが有用であると主張します。 例えば、ディレクトリは特定の個人によって作成されたすべてのファイルのリストを提供するかもしれません、ファイルサイズ、ファイル構造、アクセス制御などの何らかの情報と共に 一般に、ユーザは、そのようなシステムで、パス名を入力して、そのパス名が参照されるディレクトリを検索します。 ディレクトリ構造の興味がある局面は以下の通りです。
a. What are the syntax and semantics of a directory pathname?
a。 ディレクトリパス名の構文と意味論は何ですか?
b. What use is a directory, i.e., what type of information does the directory contain?
b。 ディレクトリはどんな使用であるか、すなわち、ディレクトリがどんな情報の種類を含みますか?
c. What access controls are used for access to the directories? For example, must a user supply a password in order to retrieve a directory, and is this password typically the same as the password he would use to retrieve a file listed in that directory.
c。 どんなアクセス制御がディレクトリへのアクセスに使用されますか? 例えば、ユーザはディレクトリを検索するためにパスワードを提供しなければなりません、そして、彼がファイルを取るのに使用するパスワードがリストアップされたのと通常同じこのパスワードがそのディレクトリにありますか?
[Page 2] 4. Commands and functions of the file system - A general description of what the file system is designed to do would be useful. For example, the system might simply accept an entire file and store it sequentially on a tape; with the only mode of retrieval being to retrieve the entire file. On the other hand, the system might provide the ability to access any "subfield" with a unique pathname. Perhaps there is the ability to restructure a file, change the access control, delete all the fields associated with a directory, etc. We realize that this aspect of the file system begins to overlap the area of "data management", which is the responsibility of another subcommittee; therefore, use your judgement as to what functions are an intrinsic aspect of the file-handling system and which are aspects of "data-management".
[2ページ] 4。 コマンドとファイルシステムの機能--ファイルシステムがするように設計されている何に関する概説は役に立つだろうか。 例えば、システムは、テープに連続して単にファイル全体を受け入れて、それを保存するかもしれません。 唯一で、検索の方法はファイル全体を取ることです。 他方では、システムはユニークなパス名でどんな「部分体」にもアクセスする能力を提供するかもしれません。 恐らく、ファイルを再構築して、アクセス制御を変えて、ディレクトリに関連しているすべての分野を削除するなど能力があります。 私たちは、ファイルシステムのこの局面が別の小委員会の責任である「データ管理」の領域を重ね合わせ始めるとわかります。 したがって、「データ管理」のどんな機能がファイル操作システムの本質的な局面であるか、そして、どれが局面であるかに関して判断を使用してください。
5. Internal representation and I/O modes - The remote user of a file system will normally be interested in internal representation of data only insofar as that representation of data is reflected in the I/O interface between the file system and the network. For example, if all of the file system's I/O is in 8-bit ASCII characters, then the user is unlikely to care if they are stored in ASCII, EBCDIC, or some other form. However, if an alternate transmission mode is available it may be useful; for example, two PDP-10's, both of which store 5 characters and one "filler" bit per word, might find it advantageous to transfer information in this mode rather than converting between internal representation and 8-bit ASCII for each character. Other information on internal representation which would be of interest to the user might include (if applicable):
5. 内部の表現と入出力モード--データのその表現がファイルシステムとネットワークとの入出力インターフェースに反映されるので、通常、ファイルシステムのリモート・ユーザーはデータの内部の表現にその程度においてだけ興味を持つでしょう。 例えば、ファイルシステムの入出力のすべてが8ビットのASCII文字にあるなら、彼らがASCII、EBCDIC、またはある他のフォームに保存されるかどうか気にかけるとはユーザはありそうもないです。 しかしながら、代替の転送方式が利用可能であるなら、役に立つかもしれません。 例えば、2PDP-10のもの(どの1単語あたり5つのキャラクタと1「フィラー」ビットの店の両方)は、各キャラクタのための内部の表現と8ビットのASCIIの間で変換するよりむしろこのモードによる情報を移すのが有利であることがわかるかもしれないか。 ユーザにとって、興味深い内部の表現の他の情報は以下を含むかもしれません(適切であるなら)。
- range of numeric data permitted - maximum text string lengths - whether the user must indicate "record" boundaries on input - what "logical structure" information the user may specify for a new file, and what he must specify - whether the user must specify the file size before beginning input, and how he does it
- 入力を始める前にファイルサイズを指定しなければならないか否かに関係なく、ユーザが入力(ユーザはどんな「論理構造」情報を新しいファイルに指定するかもしれませんか、そして、彼が指定しなければならないこと)のときに「記録的な」境界を示さなければならないか否かに関係なく、受入れられた(最大のテキストストリング長)数値データの範囲と、彼はどうそれをするか。
6. Undoubtedly, there will be aspects of each file system which don't fit neatly into the categories above, but which users will find important or essantial in using the system. These should be identified and described if possible.
6. 確かに、システムを使用するのにおいて上のカテゴリにきちんと収まりませんが、ユーザが重要であることがわかるそれぞれのファイルシステムかessantialの局面があるでしょう。 できれば、これらは、特定されて、説明されるべきです。
Please address responses to this questionnaire to:
以下のことのためにこのアンケートへの応答を扱ってください。
Alex McKenzie Bolt Beranek and Newman Inc. 50 Moulton Street Cambridge, Massachusetts 02138
モールトン・通りケンブリッジ、アレックスマッケンジーボルトBeranekとニューマン株式会社50マサチューセッツ 02138
[Page 3] If the questions above are confusing, don't hesitate to call me for clarification at (617) 491-1850 ext. 441. I will issue another RFC summarizing the responses after I have received a significant number of them.
[3ページ] 上の質問が混乱させられているなら、(617)491-1850extでの明確化のために遠慮なく私に電話をしてください。 441. 私は私が多くのそれらを受けた後に応答をまとめる別のRFCを発行するつもりです。
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Stefan Hinker 6/97 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ステファンHinker6/97によるオンラインRFCアーカイブへの]
[Page 4]
[4ページ]
一覧
スポンサーリンク