RFC1728 日本語訳
1728 Resource Transponders. C. Weider. December 1994. (Format: TXT=12092 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Weider Request for Comments: 1728 Bunyip Information Systems Category: Informational December 1994
コメントを求めるワーキンググループC.ワイダーの要求をネットワークでつないでください: 1728年の詐欺師情報システムカテゴリ: 情報の1994年12月
Resource Transponders
リソーストランスポンダー
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
Although a number of systems have been created in the last several years to provide resource location and navigation on the Internet, the information contained in these systems must be maintained and updated by hand. This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information.
インターネットでリソース位置とナビゲーションを提供するここ数年間で多くのシステムを作成しましたが、手でこれらのシステムに含まれた情報を、維持して、アップデートしなければなりません。 この論文は、リソース位置情報を維持するために機械的なメカニズム、リソーストランスポンダーについて説明します。
Author's Note:
著者注:
This document is being circulated as sort of a research paper; consequently there are no protocol specifications or anything of the sort. I hope that we can go from here and actually design them if there's consensus that they are potentially useful. Once we have some idea of the required functionality, we can then go out and standardize them.
このドキュメントは研究報告の種類として循環しています。 その結果、どんなプロトコル仕様も種類について何かもありません。 私たちがそれらが潜在的に役に立つというコンセンサスがあれば実際にそれらを設計しにここから行くことができることを願っています。 必要な機能性の何らかの考えがいったんあると、私たちは、次に、出かけて、それらを標準化できます。
Disclaimer
注意書き
This paper represents only the opinions of the author; it does not represent the consensus of the IIIR Working Group, although it is recognized by them as one legitimate approach to a solution of the problem.
この紙は作者の意見だけを表します。 それはIIIR作業部会のコンセンサスを表しません、それが問題の解決への1つの正統のアプローチとして彼らによって認識されますが。
1. Introduction
1. 序論
In the past few years, we've seen the invention and growth of a number of information location systems on the Internet, e.g., archie, Gopher, and WAIS. However, as these systems have become widely deployed, a number of maintenance and security problems have arisen with them. Some of the major ones:
過去数年間で、私たちはインターネット、例えば、archie、ゴーファー、およびWAISにおける多くの情報位置測定システムの発明と成長を見ました。 しかしながら、これらのシステムが広く配布されるようになるのに従って、多くのメインテナンスと警備上の問題はそれらで起こりました。 主要なもののいくつか:
1) Out of necessity, most of these systems contain pointers to the desired resources rather than the resources themselves. Therefore, if a resource becomes obsolete, is modified, or is moved, the
1) 必要に迫られて、これらのシステムの大部分はリソース自体よりむしろ必要なリソースに指針を含んでいます。 リソースがしたがって、時代遅れになるか、変更されているか、または動かされるなら
Weider [Page 1] RFC 1728 Resource Transponders December 1994
ワイダー[1ページ]RFC1728リソーストランスポンダー1994年12月
location system must be updated by hand. Some systems (archie in particular) proactively create updated indexes by contacting every resource on a certain time schedule (every 30 days or so) but this means that the system can be up to 30 days out of date, and this process can be highly inefficient depending on the percentage of information that has changed.
手で位置測定システムをアップデートしなければなりません。 これは、最大30日間が時代遅れであったならシステムがそうすることができることを意味します、そして、いくつかのシステム(特にarchie)が、ある時間割(およそ30日間毎)へあらゆるリソースに連絡することによって、アップデートされたインデックスを予測して作成しますが、変化した情報の割合によって、このプロセスは非常に効率が悪い場合があります。
2) Conversely, anyone who maintains a resource that they wish indexed must keep track of every directory which contains a pointer to that resource, so that if it is modified, all the directories can be updated. This obviously is an optimistic scenario.
2) 逆に、彼らが願っているリソースが索引をつけたと主張するだれでもそのリソースに指針を含むあらゆるディレクトリの動向をおさえなければなりません、それが変更しているなら、すべてのディレクトリをアップデートできるように。 これは明らかに楽観的なシナリオです。
3) Many organizations which have installed these systems do not have the the available resources or expertise to maintain the information in the systems. Thus we have long periods where the information drifts, then a short period when the information is updated again.
3) これらのシステムをインストールした多くの組織がシステムの情報を保守する利用可能資源か専門的技術を持っていません。その結果、情報が漂流するところで私たちは長期を過します、次に、再び情報をアップデートする短期。
4) Even though these systems are almost always out of date today, this problem will become increasingly harder for humans to manage by hand as everyone on the net becomes their own publisher. Also, as the net speeds up and people rely more and more on accurate information, human-induced delays in updates of these systems will become increasingly intolerable.
4) これらのシステムは今日、ほとんどいつも時代遅れですが、この問題はネットの皆がそれら自身の出版社になるとき人間がますます手でより管理しにくいようになるでしょう。 これらのシステムのアップデートのネットが加速して、人々がますます的確な情報を当てにするので人間によって誘発されたも遅れはますます堪え難くなるでしょう。
5) Most, if not all, of these systems provide no security whatsoever; if a pointer to a resource appears in a locator system, then it is assumed to be meant for public consumption. There are many potential information providers who would like to use publicly deployed information systems to publish to a very selected clientele, and do not wish to allow the whole net access to their resources.
5) これらのシステムの大部分(すべてでなくても)はセキュリティを全く提供しません。 リソースへの指針がロケータ制に現れるなら、表向きは意味されると思われます。 非常に選択された顧客に発行するのに公的に配布している情報システムを使用したくて、それらのリソースへの全体のネットのアクセスを許したがっていない多くの潜在的情報提供者がいます。
2. Requirements for a Solution
2. ソリューションのための要件
There are several objectives which must be met by any proposed solution to these problems:
どんな提案されたソリューションでもこれらの問題を満たさなければならないいくつかの目的があります:
1) We need to decrease the personnel resources needed for indexing and pointer maintenance.
1) 私たちは、インデックスと指針メインテナンスに必要である人材を減少させる必要があります。
2) We need to increase the reliability and accuracy of the information held in resource location systems.
2) 私たちは、リソース位置測定システムに保持された情報の信頼性と精度を増強する必要があります。
3) We need to provide some mechanisms for security, particularly by mediating access to the resources.
3) 私たちは、特にリソースへのアクセスを調停することによっていくつかのメカニズムをセキュリティに提供する必要があります。
Weider [Page 2] RFC 1728 Resource Transponders December 1994
ワイダー[2ページ]RFC1728リソーストランスポンダー1994年12月
4) We need to make it easy for non-experts, such as librarians, archivists, and database maintainers, to announce their new resources to the various resource location services.
4) 私たちは、それを司書や、記録係や、データベース維持装置などの非の専門家にとって簡単にして、様々なリソース位置のサービスにそれらの新しいリソースを発表する必要があります。
Many of these problems can be solved by a 'resource transponder' mechanism.
'リソーストランスポンダー'メカニズムはこれらの問題の多くを解決できます。
3. Resource Transponders
3. リソーストランスポンダー
The resource transponder system works by adding two new layers to every resource: metainformation and an agent to update a resource location system (RLS) with that metainformation. The metainformation layer is physically attached to every resource, so that when the resource is moved or altered, the metainformation is immediately available to update the RLS. The agent layer may also be attached to the resource or may not be; the implications of both of these options are discussed in detail below.
リソーストランスポンダーシステムは各リソースあたり2つの新しい層を加えることによって、動作します: そのmetainformationでリソース位置測定システム(RLS)をアップデートするmetainformationとエージェント。 metainformation層は物理的にあらゆるリソースに取り付けられます、リソースが動かされるか、またはすぐに変更されるとき、metainformationがRLSをアップデートするために利用可能であるように。 エージェント層は、また、リソースに付けられていないか、ないかもしれません。 以下で詳細にこれらのオプションの両方の含意について議論します。
3.1 Metainformation
3.1 Metainformation
The metainformation layer of a given resource contains any information which might be required to create a pointer to this resource, and any information which may be useful for indicating how to catalog or index the resource. For example, the metainformation layer of a text document might contain such things as the Uniform Resource Name (URN) of the document (this is sort of a ISBN number for electronic resources), the title of the document, a Uniform Resource Locator (URL) for the document (this is a combination net address and access method indicator, used for retrieval), the size of the document, etc. Thus the metainformation layer contains data about the resource to which it is attached.
与えられたリソースのmetainformation層はこのリソースに指針を作成するのに必要である情報、およびリソースにカタログに載せるか、または索引をつける方法を示すことの役に立つかもしれないどんな情報も含んでいます。 例えば、テキストドキュメントのmetainformation層はドキュメント(これはちょっと電子リソースのISBN番号である)のUniform Resource Name(URN)、ドキュメントのタイトル、ドキュメント(これは、組み合わせのネットのアドレスとアクセス法インディケータです、検索において、使用されている)のためのUniform Resource Locator(URL)、ドキュメントのサイズなどのようなものを含むかもしれません。 したがって、metainformation層はそれが付けているリソースに関するデータを含んでいます。
This metainformation is expected to be modifiable. For example, the metainformation layer may contain a history of where this particular copy of a resource has been. Let's say that a resource/transponder pair has been moved. When it gets to its new location, the agent can then attempt to contact the resource at its old location to determine whether the resource is still there (in which case the agent will simply cause the new location to be added to the RLS) or whether the resource is not there (in which case the agent can tell the RLS to add the current pointer and delete the old one).
このmetainformationが修正できると予想されます。 例えば、metainformation層はリソースのこの特定のコピーがあったところに関する歴史を含むかもしれません。 リソース/トランスポンダー組が動かされたと言いましょう。 新しい位置に着くと、エージェントは、リソースがまだそこにあるかどうか(その場合、エージェントは新しい位置をRLSに単に加えさせるでしょう)、またはリソースがそこにないかどうか(その場合、エージェントは現在の指針を加えて、古い方を削除するようにRLSに言うことができます)決定するために古い位置でリソースに連絡するのを試みることができます。
A number of other possibilities for the contents of the metainformation level are contained in section 4.1.
metainformationレベルのコンテンツのための他の多くの可能性がセクション4.1に含まれています。
Weider [Page 3] RFC 1728 Resource Transponders December 1994
ワイダー[3ページ]RFC1728リソーストランスポンダー1994年12月
3.2 Agents
3.2 エージェント
The agent layer of a given resource contains an executable program which is responsible for reading the metainformation attached to the resource and using that information to update a RLS. It is also responsible for updating the metainformation where necessary and for running any indexing programs required by the RLS it is attempting to update.
与えられたリソースのエージェント層はリソースとRLSをアップデートするのにその情報を使用するのに添付のmetainformationを読むのに原因となる実行可能プログラムを含んでいます。 また、それも必要であるところでmetainformationをアップデートして、プログラムがそれがアップデートするのを試みているRLSで必要としたインデックスを実行するのに責任があります。
When the tools required to build agents are constructed and deployed, the author expects the agents to begin mediating access to the resource, particularly for agents attached to resources which are not currently considered active processes, such as text files and digitized images. In this futuristic model, someone wishing to read a given document would have to first negotiate access to the data with the agent; the agent would then be responsible for delivering the data to the client. However, it is expected that this type of agent will not be widely deployed for some time.
エージェントを建てるのに必要であるツールが構成されて、配布されるとき、作者は、エージェントがリソースへのアクセスを調停し始めると予想します、特に、エージェントが現在テキストファイルなどのアクティブなプロセスであると考えられないリソースに付いて、イメージをデジタル化したので。 この未来のモデルでは、与えられたドキュメントを読みたがっているだれかが最初に、エージェントとデータへのアクセスを交渉しなければならないでしょう。 エージェントはその時、データをクライアントに提供するのに責任があるでしょう。 しかしながら、このタイプのエージェントがしばらく広く配布されないと予想されます。
Different ways of implementing agents are discussed in section 4.2.
セクション4.2でエージェントを実装する異なった方法について議論します。
4. Models for implementations of resource transponders
4. リソーストランスポンダーの実装のためのモデル
4.1. Models for implementations of the metainformation layer
4.1. metainformation層の実装のためのモデル
The metainformation layer can be impelemented in a number of ways, depending on the resource with which it is associated. For an 'active' resource, such as an on-line catalog or a mail-based service, the metainformation can be stored in a file with a well- known name in the software distribution. Alternatively, the metainformation could be stored as a record in the data which the resource serves. For a text document, the metainformation could be stored as the first or last N bytes of the document (which would break a number of editors and file display techniques, but would guarantee that the metainformation is moved with the resource), or perhaps as a file with a logically associated name (paper2.meta associated with paper2.txt, for example). The problem with this second approach is that the user must know that they have to move the metainformation with the file itself, or things will start breaking. If an agent is explicitly attached to the resource, the agent could contain the metainformation internally.
それが関連しているリソースによって、多くの方法でmetainformation層をimpelementedされることができます。 オンライン・カタログかメールベースのサービスなどの'アクティブな'リソースに関しては、ファイルにソフトウェア配布におけるよく知られている名前でmetainformationを保存できます。 あるいはまた、リソースが役立つデータでの記録としてmetainformationを保存できました。 テキストドキュメントに関しては、ドキュメント(多くのエディタとファイルディスプレイのテクニックを調教するでしょうが、metainformationがリソースに動かされるのを保証する)の1番目か最後のNバイトとして、または、恐らく論理的に関連している名前(例えば、paper2.txtに関連しているpaper2.meta)があるファイルとしてmetainformationを保存できました。 この2番目のアプローチに関する問題はユーザが、彼らがファイル自体でmetainformationを動かさなければならない、さもなければ、いろいろなことが壊れるのを出発するのを知らなければならないということです。 エージェントが明らかにリソースに付けられるなら、エージェントは内部的にmetainformationを含むかもしれません。
In any case, the resource transponder system must be able to guarantee that the metainformation is moved when the resource is moved.
どのような場合でも、リソーストランスポンダーシステムは、リソースが動かされるとき、metainformationが動かされるのを保証できなければなりません。
Weider [Page 4] RFC 1728 Resource Transponders December 1994
ワイダー[4ページ]RFC1728リソーストランスポンダー1994年12月
4.2 Models for implementations of the agents
4.2 エージェントの実装のためのモデル
The agent layer can also be implemented in a number of ways, depending on such things as system loads, desired sizes of resources, multitasking capabilities, etc.
また、多くの方法でエージェント層を実装することができます、システム・ロードのようなものによって、リソースの必要なサイズ、能力などをマルチタスキングして
The easiest and for many unitasking systems the cleanest way of implementing an agent is to have one agent per computer. Then when a resource is moved onto that computer, the agent is explicitly activated and notified where the new resource is. For example, let's say that someone wishes to download a copy of a resource and then let the RLS know that that resource is available for public consumption. She would download the resource and then run the agent, which would then notify the RLS and update the metainformation attached to the resource. This model could also be used to track files on a LAN, or to provide local location services with no need to run a larger RLS.
そして、最も簡単である、多くのunitaskingシステムのために、エージェントを実装する最も清潔な方法は1コンピュータあたり1人のエージェントがいることです。 次に、リソースがそのコンピュータに動かされるとき、エージェントは、新しいリソースがあるところで明らかに動かされて、通知されます。 例えば、だれかがリソースのコピーをダウンロードして、次に、RLSにそのリソースが表向きは利用可能であることを知らせたがっていると言いましょう。 彼女は、リソースをダウンロードして、次に、エージェントを車で送るでしょう。(そのエージェントは、次に、RLSに通知して、リソースに取り付けられたmetainformationをアップデートするでしょう)。 また、LANのファイルを追跡するか、または、より大きいRLSを実行する必要性を全く地方の位置のサービスに提供しないようにこのモデルを使用できました。
Another model for implementation of the agent is to have one agent per resource. In this model, the agent would be moved along with the resource and the metainformation. The agent could be implemented in a file which would be associated with the resource; in that case the agent would have to be explicitly activated when the resource was moved. Alternatively, the agent/metainformation/resource system could be implemented as one system, or in one file. In this case, the agent itself would always be active, and would be responsible for mediating access to the resource. When one did a 'telnet' to a resource with an active agent, the agent would accept the telnet connection and be responsible for providing security and translation for the data. This could provide great security for resources while still allowing pointers to them to be placed in public RLS's; the data in the resource could be encrypted, with the agent responsible for decrypting it.
エージェントの実装のための別のモデルには、1リソースあたり1人のエージェントがいることになっています。 このモデルでは、エージェントはリソースとmetainformationと共に動かされるでしょう。 リソースに関連しているファイルでエージェントを実装することができました。 リソースが動かされたとき、その場合、エージェントは明らかに動かされなければならないでしょう。 あるいはまた、1台のシステム、または1個のファイルでエージェント/metainformation/リソースシステムを導入されることができました。 この場合、エージェント自身は、いつも活発であるだろう、リソースへのアクセスを調停するのに責任があるでしょう。 1つが活発なエージェントと共に'telnet'をリソースにしたとき、エージェントは、telnet接続を受け入れて、データのためのセキュリティと翻訳を提供するのに責任があるでしょう。 それらへの指針が公共のRLSのものに置かれるのをまだ許容している間、これはすばらしいセキュリティをリソースに提供するかもしれません。 それを解読するのに責任があるエージェントと共にリソースのデータを暗号化できました。
5. Security Considerations
5. セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
6. Author's Address
6. 作者のアドレス
Chris Weider Bunyip Information Systems, Inc. 2001 S. Huron Parkway, #12 Ann Arbor, MI 48104 USA
クリスワイダー詐欺師情報システムInc.2001秒間ヒューロン族パークウェイ、#12アナーバーMI48104米国
Phone: +1 313-971-2223 Fax: +1 313-971-2223 EMail: clw@bunyip.com
以下に電話をしてください。 +1 313-971-2223Fax: +1 313-971-2223 メールしてください: clw@bunyip.com
Weider [Page 5] RFC 1728 Resource Transponders December 1994
ワイダー[5ページ]RFC1728リソーストランスポンダー1994年12月
Weider [Page 6]
ワイダー[6ページ]
一覧
スポンサーリンク