RFC615 日本語訳
0615 Proposed Network Standard Data Pathname syntax. D. Crocker. March 1974. (Format: TXT=9448 bytes) (Obsoleted by RFC0645) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Crocker (UCLA-NMC) Request for Comments: 615 MAR 74 NIC #21531
クロッカー(UCLA-NMC)がコメントのために要求するワーキンググループD.をネットワークでつないでください: 615 3月74日のNIC#21531
Proposed Network Standard Data Pathname Syntax
提案されたネットワーク標準のデータパス名構文
There seems to be an increasing call for a Network Standard Data Pathname (NSDP); that is, a standardized means of referring to a specific location for/of a collection of bits somewhere on the Network.
Network Standard Data Pathname(NSDP)のための増加する呼び出しはあるように思えます。 すなわち、ビットの収集の/について特定の位置についてNetworkのどこかに言及する標準化された手段。
The reasons for a standard or virtual anything have been discussed, at length, elsewhere and will not be elaborated upon here. Rather than attack the entire issue of virtual pathnames, I wish only to propose a standardized SYNTAX for specifying pathnames. Such a standard will be useful for 1) users who are unfamiliar with a site or who use several different sites and do not want to have to remember each site's idiosynchracies, 2) programs accessing data at several other sites, and 3) documentation:
標準の、または、何も仮想のものの理由は、十分と、ほかの場所で議論して、ここに詳しく説明されないでしょう。 攻撃よりむしろ、仮想のパス名の全体の問題であり、パス名を指定するために単に標準化されたSYNTAXを提案したいと思います。 そのような規格は、サイトになじみがないか、またはいくつかの異なったサイトを使用する1人の)ユーザの役に立って、各サイトのidiosynchraciesを覚えていなければならない必要がありません、2つの)プログラムが他のいくつかのサイト、および3)ドキュメンテーションでデータにアクセスして:
The syntax allows the user to specify the necessary network, host, peripheral device, directory, file, type, and site-specific fields. Adding other fields, as needed, is expected to be quite simple.
構文で、ユーザは必要なネットワーク、ホスト、周辺機、ディレクトリ、ファイル、タイプ、およびサイト特有の分野を指定できます。 必要に応じて他の分野を加えるのがかなり簡単であると予想されます。
First the BNF:
最初に、BNF:
<NSDP> ::= % <bulk> <cr><lf>
<NSDP>:、:= %<嵩の><cr><lf>。
<bulk> ::= <field> / <field> <bulk>
<嵩の>:、:= <分野>/<分野><嵩の>。
<field> ::= <key> <L-delim> <name> <R-delim>
<分野>:、:= 主要な<の<名前><R-delim><L-delim>>。
<key> ::= NETWORK / HOST / PERIPHERAL/ DIRECTORY / FILE / TYPE / SITEPARM / N / H / P / D / F / T / S
<の主要な>:、:= ネットワーク/ホスト/ PERIPHERAL/ディレクトリ/ファイル/タイプ/ SITEPARM /N/H/P/D/F/T/S
<L-delim> ::= any printable character that is not in the succeeding <name> field and that is acceptable to the object site: For visual aesthetics and to facilitate human parsing, anytime <L-delim> is a left-bracket character (<, [, (, _), <R-delim> must be the complementary right-bracket character (>, ], ), |).
<L-delim>:、:= 続く<名前>分野とそれにない少しの印刷可能なキャラクタもオブジェクトサイトに許容できます: いつでも、<L-delim>が視覚美意識、人間の構文解析を容易にするためには、左ブラケットキャラクタである、(<、[(_)、<R-delim>が補足的な正しいブラケットキャラクタであるに違いない(>]、)、|、)
<name> ::= any sequence of characters acceptable to the object site. This is the actual data field with the file, directory, device (or whatever) name.
<名前>:、:= オブジェクトサイトに許容できるキャラクタのどんな系列。 これはファイル、ディレクトリ、デバイス(または、何でも)名がある実際のデータ・フィールドです。
<R-delim> ::= Either 1) the same character as <L-delim> or 2) if the <L-delim> character is a left-bracket character (<, [, (, _) then its complementary right-bracket (>, ], ), |).
<R-delim>:、:= <L-delim>キャラクタであるなら<L-delim>と同じ1)キャラクタか2つのキャラクタのどちらかが)左ブラケットキャラクタである、(<、[(_) 次に、補足的な正しいブラケット(>]、)|).
-1- <cr> ::= carriage-return
-1<のcr>:、:= 復帰
<lf> ::= line-feed
<lf>:、:= 改行
And some elaboration:
いくらかの労作:
The syntax allows <name> fields to be an arbitrary number of rs long. Case is irrelevant to the syntax, though some sites will care about case in <name> fields:
構文は、長い間<名前>分野がrsの特殊活字の数字であることを許容します。 いくつかのサイトが<名前>分野のケースを心配するでしょうが、ケースは構文と無関係です:
<Key> indicates what part of the pathname the next <name> is going to refer to: The single-character keys are abbreviations for the respective full-word keys:
<の主要な>は、>という次の<名がパス名のどんな部分について言及するだろうかを示します: 単独のキャラクタキーはそれぞれのフルワードキーのための略語です:
<Fields> ARE order dependent, but defaulted ones may be omitted. The order is as indicated for <key>s: That is, Network, Host, ..: Siteparm:
<分野>はオーダー扶養家族ですが、デフォルトとした省略されるかもしれません。 オーダーが<の主要な>sのために示されるようにあります: すなわち、Network、Host。: Siteparm:
Fields may be repeated, as appropriate for the object site; that is, multiple Directory fields, etc:
分野は、繰り返されて、オブジェクトサイトに、適切であるかもしれません。 すなわち、複数のディレクトリ分野など:
The validity of any combination of <field>s is entirely site-dependent: For example, if a site will accept it, an NSDP with a Host field, and nothing more, is permissible:
<分野>sのどんな組み合わせの正当性もサイト完全に依存しています: 例えば、サイトがそれを受け入れるなら、Host分野、およびそれ以上何もがあるNSDPは許されています:
<delim> is used to delimit the beginning and end of the <name> field:
<delim>は<名前>分野の首尾を区切るのに使用されます:
Explanation of <key>s:
<の主要な>sに関する説明:
NETWORK or N: Currently, only ARPA is defined.
ネットワークかN: 現在、ARPAだけが定義されます。
HOST or H: Reference to host, by official name or nickname or number: The default radix is ten; a numeric string ending with "H" indicates hexadecimal, "O"(oh) indicates octal, and (gratuitously) "D" indicates decimal:
ホストかH: 正式名称かあだ名で主催する参照か数: デフォルト基数は10です。 「H」がある数値ストリング結末は16進を示します、そして、「O」(おお)は8進を示します、そして、(無償に)「D」は小数を示します:
PERIPHERAL or P: Peripheral device being referred to:
周辺機器かP: 以下のことに参照される周辺機
DIRECTORY or D: Name of a directory which contains a pointer to the entity (directory or filename) specified in the following <field>:
ディレクトリかD: 実体(ディレクトリかファイル名)に指針を含むディレクトリの名前は以下の<分野>で指定しました:
FILE or F: Basic name of the file or data set:
ファイルかF: ファイルかデータセットの基本的な名前:
TYPE or T: Optional modifier to filename: (Tenex calls it the extension.)
タイプかT: ファイル名への任意の修飾語: (Tenexは、それを拡大と呼びます。)
SITEPARM or S: A parameter, such as an access specification or version number, peculiar to the object site. The content of the <name> field must serve to identify what Siteparm is involved. Each site will be responsible for defining the syntax of Siteparm <name>s it will accept.
SITEPARMかS: アクセス仕様やバージョン番号のようにオブジェクトサイトに独特のパラメタ。 <名前>分野の内容は、Siteparmが何であるかをかかわった状態で特定するのに役立たなければなりません。 それぞれのサイトはそれが受け入れるSiteparm<名前>sの構文を定義するのに原因となるようになるでしょう。
-2- Some reserved PERIPHERAL <name>s:
-2 -或るものはPERIPHERAL<名前>sを予約しました:
DISK or DSK: Immediately accessible, direct-access storage.
ディスクかDSK: すぐに、アクセスしやすくて、ダイレクトアクセスしているストレージ。
ONLINE or ONL: Whatever immediately-accessible (measured in fractions of a second) storage the user accesses by default; usually disk:
または、オンライン、ONL: ユーザがデフォルトでアクセスするどんなすぐにアクセスしやすい(1秒の何分の一では、測定される)ストレージ。 通常ディスク:
TAPE or TAP: Industry-compatible magnetic tape:
以下をテープに録音するか、または叩いてください。 産業コンパチブル磁気テープ:
TAPE7 or TP7: 7-Track industry compatible tape:
TAPE7かTP7: 7道の産業コンパチブルテープ:
TAPE9 or TP9: 9-Track industry compatible tape:
TAPE9かTP9: 9道の産業コンパチブルテープ:
DECTAPE or DEC: DEC Tape.
DECTAPEか12月: 12月のテープ。
OFFLINE or OFF: Any tertiary storage; usually tape, though "devices" like the Datacomputer are permissible: The user should expect to wait minutes or hours before being able to access OFFLINE files:
オフラインかオフ: どんな第三のストレージ。 Datacomputerのように「デバイス」は許されていますが、通常、テープに録音してください: ユーザは、OFFLINEファイルにアクセスできる前に分間か時間待つと予想するべきです:
PRINTER or PTR: Any available line-printer:
プリンタかPTR: どんな利用可能なラインプリンタも:
DOCPRINTER or DOC:Upper-lower case line printer, preferably with 8 1/2" X 11" unlined paper.
DOCPRINTERかDOC: 望ましくは、11インチの8 1/2インチのX背抜き紙がある上側の小文字のラインプリンタ。
PAPER or PAP: Paper tape.
紙か乳首: 紙テープ。
PUNCH or PUN: Standard 8O-column card punch.
パンチするか、またはだじゃれを言ってください: 標準の8O-コラムカードパンチ。
READER or RDR: Standard 80-column card reader:
読者かRDR: 標準の80コラムのカードリーダ:
OPERATOR or OPR: System Operator's console.
オペレータかOPR: システムOperatorのコンソール。
CONSULTANT or CON: On-line consultant.
コンサルタントかまやかし: オンラインコンサルタント。
Defaults:
デフォルト:
Defaults will generally be context dependent. Consequently, the following defaults are offered only as guidelines:
一般に、デフォルトは文脈に依存するようになるでしょう。 その結果、単にガイドラインとして以下のデフォルトを提供します:
Network: ARPA
以下をネットワークでつないでください。 アルパ
Host: The host interpreting the NVP
以下を接待してください。 NVPを解釈するホスト
Peripheral: ONLINE (DISK)
周辺機器: オンライン(ディスク)
Directory: The user's current "working" directory, usually set by the logon process:
ディレクトリ: 通常、ログオンプロセスによって設定されたユーザの現在の「働く」ディレクトリ:
Filename: None.
ファイル名: なし。
Type: None.
以下をタイプしてください。 なし。
Siteparm: None.
Siteparm: なし。
-3-
-3-
General Comments
概評
The only field that must be considered in relation to any host's current syntax is the escape-to-NVP field (The per-cent sign as the first character of a pathname specification): It is not currently known to conflict with any host's syntax:
どんなホストの現在の構文と関連して考えなければならない唯一の分野がエスケープからNVPへの分野(パーセントはパス名仕様の最初のキャラクタとして署名する)です: 現在、それがどんなホストの構文とも衝突するのが知られません:
Exclamation mark (!) is the only other character that seems permissible (on the assumption that the character should be a graphic): Its use would cause minor problems at Multics; but more importantly as a graphic, it is too similar to the numeral "1":
感嘆符(!)は許されるように(キャラクタがグラフィックであるべきであるという前提での)思える他の唯一のキャラクタです: 使用はMulticsで小さな問題を引き起こすでしょう。 しかし、グラフィックとして、より重要に、それが数字と同様過ぎる、「1インチ:」
The syntax is intended to be adequate for all hosts, so any given portion of it may be inappropriate for any given host.
構文がすべてのホストにとって適切であることを意図するので、どんな与えられたホストにとっても、それのどんな与えられた部分も不適当であるかもしれません。
A site is expected to permit specifications in a given field iff that site already has a way of accepting the same information:
サイトがサイトが既に道を持っている与えられた分野iffの同じ情報を受け入れる仕様を可能にすると予想されます:
I believe that any modifications to the syntax will be graceful additions, rather than wholesale redesign, and thus can be deferred for a while. Currently, any undefined attributes must be specified in a Siteparm field:
私は構文へのどんな変更も大量の再設計よりむしろ優雅な追加であり、その結果、しばらく延期できると信じています。 現在、Siteparm分野でどんな未定義の属性も指定しなければなりません:
Perhaps Version, Access protection and Accounting, as well as other types of information, should be made standard <key>s, rather than buried as Siteparms. I expect that the next version of the NSDP Syntax specification will include them as <key>s, but I would like to wait for some comments from the community.
恐らく、バージョン(Access保護、Accounting、および他のタイプの情報)はSiteparmsとして埋められるよりむしろ人工の標準の<主要な>sであるべきである。私は、NSDP Syntax仕様の次のバージョンが<の主要な>sとして彼らを含みますが、共同体からいくつかのコメントを待ちたいと思うと予想します。
The syntax does not currently allow addressing any collection of bits smaller than a file: This can be remedied by adding PAGE, BYTE and other <key>s; but, again, I would like to solicit some comments first:
構文で、現在、ファイルよりわずかなビットの少しの収集も扱いません: ページ、BYTE、および他の<の主要な>sを加えることによって、これを治すことができます。 しかし、一方、最初に、いくつかのコメントに請求したいと思います:
Disclaimer
注意書き
A pathname specified in the proposed syntax is fairly easy to type but is quite ugly to read: So, at the expense of design cleanliness, the <L-delim>/<R-delim> syntax was modified in an attempt to remedy the problem somewhat: As you will see below, it is only partially successful.
提案された構文で指定されたパス名は、タイプするのがかなり簡単ですが、読むためにかなり醜いです: それで、デザインの清潔を犠牲にして、<L-delim>/<R-delim>構文は問題をいくらか改善する試みで変更されました: 単にあなたが以下を見るように、それは部分的にうまくいっています。
The first draft of this document had a syntax that was a mix of Tenex and Multics conventions: That is,
このドキュメントの最初の草稿には、TenexとMulticsコンベンションのミックスであった構文がありました: That is,
(Network)[Host]Peripheral:Directory>Filename:Type;Siteparm
(ネットワークでつなぎます) [接待します] 周辺機器: ディレクトリ>ファイル名: タイプしてください;、Siteparm
Though visually more attractive and generally quicker to type, it lacks extensibility. For example, adding Version number or Access protection as standard fields would be difficult:
タイプするのが目視により魅力的であって、一般により迅速ですが、それは伸展性を欠いています。 例えば、標準の分野としてバージョン番号かAccess保護を加えるのは難しいでしょう:
It is suggested that human interfaces be built to translate to/from NSDP syntax and the user's standard environment.
ヒューマンインターフェースがNSDP構文とユーザの標準の環境からの/に翻訳するために築き上げられることが提案されます。
-4-
-4-
Some sample pathnames:
或るものはパス名を抽出します:
%H[ISI]D<DCROCKER>F(MESSAGE)T/TXT/S(P77O4O4)<cr><lf> refers to my protected message file at ISI (<DCROCKER>MESSAGE:TXT;P77O4O4).
%H[ISI]D<DCROCKER>F(MESSAGE)T/TXT/S(P77O4O4)<cr><lf>はISI(<DCROCKER>MESSAGE: TXT; P77O4O4)の私の保護されたメッセージファイルを示します。
%H/OFFICE-l/D>JOURNAL>F<l8659>T.NLS.<cr><lf> refers to NIC Journal document #18659 (Tenex file <JOURNAL>l8659:NLS):
>JOURNAL>F<l8659>T. NLS%H/オフィスl/D<cr><lf>はNIC Journalドキュメント#18659(Tenexファイル<JOURNAL>l8659: NLS)について言及します:
%H/65/D.ARP061.D.LAD:F.DOCUMENT.<cr><lf> refers to a file ARPO6l:LAD.DOCUMENT at UCLA-CCN. Note the use of multiple Directory fields.
%H/65/D. ARP061.D. LAD: F. DOCUMENT<cr><lf>はファイルARPO6lについて言及します: UCLA-CCNのLAD.DOCUMENT。 複数のディレクトリ分野の使用に注意してください。
%H[540]D//D>udd>D>Comp=net>D>Map>F(Mail)<cr><lf> refers to file CompNet>Map>Mail at Mit-Multics. Note that the initial NSPD Directory <name> field is empty. This conforms to Multics' method of starting at the top of its directory structure:
ネットの>D>Map>F(郵送します)<cr><lf%H[540]D//D>udd>D>Comp=>はMit-MulticsのファイルCompNet>Map>メールを示します。 初期のNSPDディレクトリ<名前>分野が人影がないことに注意してください。 これはMulticsのディレクトリ構造の先端で始まるメソッドに従います:
I would like to thank Jon Postel, Vint Cerf, Jim White, Charlie Kline, Ken Pogran, Jerry Burchfiel and Tom Boynton for their suggestions.
彼らの提案についてジョン・ポステル、Vintサーフ、ジム・ホワイト、チャーリー・クライン、ケンPogran、ジェリーBurchfiel、およびトム・ボイントンに感謝申し上げます。
-5-
-5-
一覧
スポンサーリンク