RFC1727 日本語訳

Network Working Group                                          C. Weider
Request for Comments: 1727                                    P. Deutsch
Category: Informational                       Bunyip Information Systems
                                                           December 1994

コメントを求めるワーキンググループC.ワイダーの要求をネットワークでつないでください: 1727年のP.ドイツ語カテゴリ: 情報の詐欺師情報システム1994年12月

         A Vision of an Integrated Internet Information Service

統合インターネット情報サービスのビジョン

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

要約

   This paper lays out a vision of how Internet information services
   might be integrated over the next few years, and discusses in some
   detail what steps will be needed to achieve this integration.

この論文は、インターネット情報サービスがこの数年間にわたってどう統合しているかもしれないかに関するビジョンについて説明して、どんなステップがこの統合を達成するのに必要であるかと何らかの詳細に議論します。

Acknowledgments

承認

   Thanks to the whole gang of information service wonks who have
   wrangled with us about the future of information services in
   countless bar bofs (in no particular order): Cliff Lynch, Cliff
   Neuman, Alan Emtage, Jim Fullton, Joan Gargano, Mike Schwartz, John
   Kunze, Janet Vratny, Mark McCahill, Tim Berners-Lee, John Curran,
   Jill Foster, and many others. Extra special thanks to George Brett of
   CNIDR and Anders Gillner of RARE, who have given us the opportunity
   to start tying together the networking community and the librarian
   community.

無数のバー転炉の情報サービスの未来(特に決まった順番でなく)頃に私たちと共に口論した情報サービスガリ勉の全体のギャングをありがとうございます: クリフ・リンチ、クリフ・ヌーマン、アランEmtage、ジムFullton、ジョーン・ガルガノ、マイク・シュワルツ、ジョン・クンツェ、ジャネットVratny、マークMcCahill、ティム・バーナーズ・リー、ジョン・カラン、ジル・フォスター、および多くの他のもの。 CNIDRのジョージ・ブレットとRAREのアンダースGillnerへの余分な特別な感謝。(RAREはネットワーク共同体と司書社会を結びつけ始める機会を私たちに与えました)。

1. Disclaimer

1. 注意書き

   This paper represents only the opinions of its authors; it is not an
   official policy statement of the IIIR Working Group of the IETF, and
   does not represent an official consensus.

この紙は作者の意見だけを表します。 それは、IETFのIIIR作業部会の公式方針声明でなく、また公式のコンセンサスを表しません。

2. Introduction

2. 序論

   The current landscape in information tools is much the same as the
   landscape in communications networks in the early 1980's.  In the
   early 80's, there were a number of proprietary networking protocols
   that connected large but autonomous regions of computers, and it was
   difficult to coalesce these regions into a unified network. Today, we
   have a number of large but autonomous regions of networked
   information.  We have a vast set of FTPable files, a budding WAIS
   network, a budding GOPHER network, a budding World Wide Web network,

情報ツールにおける現在の風景は1980年代前半に風景として通信網で似たり寄ったりです。 80年代前半にはコンピュータの大きい、しかし、自治の領域をつなげた多くの独占ネットワーク・プロトコルがありました、そして、これらの領域を統一されたネットワークと合体させるのは難しかったです。 今日、私たちには、ネットワークでつながれた情報の多くの大きい、しかし、自治の領域があります。 私たちには、広大なセットのFTPableファイルがあります、芽生え始めたWAISネットワーク、芽生え始めたゴーファーネットワーク、芽生え始めたWWWネットワーク

Weider & Deutsch                                                [Page 1]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[1ページ]RFC1727リソーストランスポンダー1994年12月

   etc.  Although there are a number of gateways between various
   protocols, and information service providers are starting to use
   GOPHER to provide a glue between various services, we are not yet in
   that golden age when all human information is at our fingertips. (And
   we're even farther from that platinum age when the computer knows
   what we're looking for and retrieves it before we even touch the
   keyboard.)

など 様々なプロトコルの間には、多くのゲートウェイがあります、そして、情報サービスプロバイダーは様々なサービスの間に接着剤を提供するのにゴーファーを使用し始めていますが、まだすべての人間の情報がすぐ使えているその最盛期には私たちがいません。 (そして、私たちはコンピュータが私たちが何を探しているかを知って、私たちがキーボードに触れる前にさえそれを検索するその黄金時代からさらに遠いです。)

   In this paper, we'll propose one possible vision of the information
   services landscape of the near future, and lay out a plan to get us
   there from here.

この紙では、私たちは、近い将来の情報サービス風景の1つの可能なビジョンを提案して、ここから私たちをそこに到着させる計画を発表するでしょう。

3. Axioms of information services

3. 情報サービスの原理

   There are a number of unspoken assumptions that we've used in our
   discussions.  It might be useful to lay them out explicitly before we
   start our exploration.

私たちが議論に使用した多くの暗黙の了解があります。 私たちが探検を始める前に明らかにそれらを広げるのは役に立つかもしれません。

   The first is that there is no unique information protocol that will
   provide the flexibility, scale, responsiveness, worldview, and mix of
   services that every information consumer wants.  A protocol designed
   to give quick and meaningful access to a collection of stock prices
   might look functionally very different from one which will search
   digitized music for a particular musical phrase and deliver it to
   your workstation. So, rather than design the information protocol to
   end all information protocols, we will always need to integrate new
   search engines, new clients, and new delivery paradigms into our
   grand information service.

1番目はすべての情報消費者が欲しいサービスの柔軟性、スケール、反応性、世界観、およびミックスを提供するどんなユニークな情報プロトコルもないということです。 株価の収集への迅速で重要なアクセスを与えるように設計されたプロトコルは非常に機能上特定の音楽の句のためにデジタル化している音楽を捜して、それを届けるものからあなたのワークステーションまで異なるように見えるかもしれません。 そのように、むしろ、私たちは、すべての情報プロトコルを終わらせるように情報プロトコルを設計するよりいつも新しいサーチエンジン、新しいクライアント、および期近物パラダイムを私たちの壮大な情報サービスと統合する必要があるつもりです。

   The second is that distributed systems are a better solution to
   large-scale information systems than centralized systems.  If one
   million people are publishing electronic papers to the net, should
   they all have to log on to a single machine to modify the central
   archives? What kind of bandwidth would be required to that central
   machine to serve a billion papers a day?  If we replicate the central
   archives, what sort of maintenance problems would be encountered?
   These questions and a host of others make it seem more profitable at
   the moment to investigate distributed systems.

2番目は分散システムが大規模な情報システムの集権制より良い解答であるということです。100万人の人が電子論文をネットに発行しているなら、それらは皆、主要なアーカイブを変更するために単一マシンにログオンしなければならないはずですか? どういう帯域幅が、1日あたり10億個の書類に役立つのにその中央のマシンに必要でしょうか? 私たちが主要なアーカイブを模写するなら、どういう維持問題が行きあたられるでしょうか? これらの質問と多くの他のものがそれを分散システムを調査するのにおいて現在より有益に見せます。

   The third is that users don't want to be bothered with the details of
   the underlying protocols used to provide a given service. Just as
   most people don't care whether their e-mail message gets split up
   into 20 packets and routed through Tokyo to get to its destination,
   information service users don't care whether the GOPHER server used
   telnet to get to a WAIS database back-ended by an SQL database.  They
   just want the information. In short, they care very much about how
   they interact with the client; they just don't want to know what goes
   on behind.

3番目は使用される基本的なプロトコルの詳細でユーザが与えられたサービスを提供するように苦しめられたくないということです。 ほとんどの人々が、20のパケットに分けられて、彼らのメールメッセージが目的地に着くように東京を通って発送されるかどうか気にかけるだけではないように、情報サービス利用者は、ゴーファーサーバがSQLデータベースで終わったWAISデータベース後部に着くのにtelnetを使用したかどうか気にかけません。 彼らはただ情報が欲しいです。 要するに、彼らはどうクライアントと対話するかをたいへん心配します。 彼らは、何が後ろで起こるかをただ知りたがっていません。

Weider & Deutsch                                                [Page 2]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[2ページ]RFC1727リソーストランスポンダー1994年12月

   These axioms force us to look at solutions which are distributed,
   support multiple access paradigms, and allow information about
   resources to be handed off from one system (say Gopher) to another
   (say WWW).

これらの原理は、私たちが、分配された解決策を見て、複数のアクセスパラダイムを支持して、リソースの情報が1台のシステム(ゴーファーを言う)から別のシステムまで渡されるのを許すのを強制します(WWWを言ってください)。

4. An architecture to provide interoperability and integration.

4. 相互運用性と統合を提供する構造。

   The basic architecture outlined in this paper splits up into 4 levels
   [Fig. 1].

基本的な構造はこの紙に4つのレベル[図1]に上がっている股割りについて概説しました。

   At the lowest level, we have the resources themselves. These are such
   things as files, telnet sessions, online library catalogs, etc. Each
   resource can have a resource transponder attached [Weider 94a], and
   should have a Uniform Resource Name (URN) [Weider 94b] associated
   with it to uniquely identify its contents. If a resource transponder
   is attached, it will help maintain the information required by the
   next level up.

最も低いレベルでは、私たちはリソース自体を持っています。 これらはファイル、telnetセッション、オンライン図書館カタログなどのようにものです。 各リソースで、添付のリソーストランスポンダー[ワイダー94a]を持つことができて、唯一コンテンツを特定するために、Uniform Resource Name(URN)[ワイダー94b]をそれに関連づけるべきです。 リソーストランスポンダーが付属していると、それは、次のレベルによって必要とされた情報を上がるのに保守するのを助けるでしょう。

   At the next level, we have a 'directory service' that takes a URN and
   returns Uniform Resource Locators (URLs) [Berners-Lee 94] for that
   resource. The URL is a string which contains location information,
   and can be used by a client to access the resource pointed to by the
   URL.  It is expected that a given resource may be replicated many
   times across the net, and thus the client would get a number of URLs
   for a given resource, and could choose between them based on some
   other criteria.

次のレベルでは、私たちはURNを取って、そのリソースのために、Uniform Resource Locator(URL)[バーナーズ・リー94]を返す'電話番号案内'を持っています。 URLを、位置情報を含むストリングであり、クライアントは、URLによって示されたリソースにアクセスするのに使用できます。 与えられたリソースがネットの向こう側に何回も模写されるかもしれないと予想されて、その結果、クライアントは、与えられたリソースのために多くのURLを得て、ある他の評価基準に基づいてそれらを選ぶことができました。

Weider & Deutsch                                                [Page 3]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[3ページ]RFC1727リソーストランスポンダー1994年12月

     ______________________________________________________________
     |           |              |       |               |
     |           |              |       |               |
     |  Gopher   |  WAIS        | WWW   | Archie        | Others ...
     |           |              |       |               |
     |___________|______________|_______|_______________|___________
          |                                |
          |                       _________|____________
          |                      |                      |
          |                      | Resource Discovery   |
          |                      |  System (perhaps     |
          |                      |  based on whois++)   |
          |                      |______________________|
          |                                |
          |                                |
     _____|________________________________|____
    |                                           |
    | Uniform resource name to uniform resource |
    | locator mapping system (perhaps based on  |
    | whois++ or X.500)                         |
    |___________________________________________|
                        |
                        |
        ________________|______________________________________
        |                  |                 |                 |
  ______|______     _______|_____      ______|______     ______|______
 |             |   |             |    |             |   |             |
 | Transponder |   | Transponder |    | Transponder |   | Transponder |
 |_____________|   |_____________|    |_____________|   |_____________|
 |             |   |             |    |             |   |             |
 |             |   |             |    |             |   |             |
 |             |   |             |    |             |   |             |
 |  Resource   |   |  Resource   |    |  Resource   |   |  Resource   |
 |             |   |             |    |             |   |             |
 |             |   |             |    |             |   |             |
 |_____________|   |_____________|    |_____________|   |_____________|

______________________________________________________________ | | | | | | | | | | | ゴーファー| WAIS| WWW| アーチー| 他のもの… | | | | | |___________|______________|_______|_______________|___________ | | | _________|____________ | | | | | リソース発見| | | システム、(恐らく|、|、|、基づいて、+ +がwhoisする、)| | |______________________| | | | | _____|________________________________|____ | | | 一定のリソースへの一定のリソース名| | ロケータマッピングシステム(恐らく、| whois++かX.500を|に基礎づけます)| |___________________________________________| | | ________________|______________________________________ | | | | ______|______ _______|_____ ______|______ ______|______ | | | | | | | | | トランスポンダー| | トランスポンダー| | トランスポンダー| | トランスポンダー| |_____________| |_____________| |_____________| |_____________| | | | | | | | | | | | | | | | | | | | | | | | | | リソース| | リソース| | リソース| | リソース| | | | | | | | | | | | | | | | | |_____________| |_____________| |_____________| |_____________|

        Figure 1: Proposed architecture of an integrated information
                        service

図1: 統合情報サービスの提案された構造

   The third level of the architecture is a resource discovery system.
   This would be a large, distributed system which would accept search
   criteria and return URNs and associated information for every
   resource which matched the criteria. This would provide a set of URLs
   which the information service providers (GOPHER servers, etc.) could
   then select among for incorporation.

構造の第3レベルはリソース発見システムです。 これは多大(評価基準に合っていたあらゆるリソースのために検索評価基準を受け入れて、URNsと関連情報を返す分散システム)でしょう。 これは次に情報サービスプロバイダー(ゴーファーサーバなど)が選択できた1セットのURLを編入に提供するでしょう。

Weider & Deutsch                                                [Page 4]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[4ページ]RFC1727リソーストランスポンダー1994年12月

   The fourth level of the architecture is comprised of the various
   information delivery tools.  These tools are responsible for
   collating pointers to resources, informing the user about the
   resources to which they contain pointers, and retrieving the
   resources when the user wishes.

構造の第4レベルは様々な情報送達ツールから成ります。 これらのツールはリソースにポインタを照合するのに原因となります、ユーザがいつ願っているかをそれらがポインタを含むリソースと、リソースを検索することに関するユーザに知らせて。

   Let's take a look in greater detail at each of these levels.

詳細に、よりすばらしいそれぞれのこれらのレベルでは、ちょっと見ましょう。

4.1 Resource layer

4.1 リソース層

   The resources at this layer can be any collection of data a publisher
   wishes to catalog. It might be an individual text file, a WAIS
   database, the starting point for a hypertext web, or anything else.
   Each resource is assigned a URN by the publisher, and the URL is
   derived from the current location of the resource. The transponder is
   responsible for updating levels 2 and 3 with the appropriate
   information as the resource is published and moves around.

この層のリソースは出版社がカタログに載せたがっているデータのどんな収集であるかもしれません。 それは、個々のテキストファイル、WAISデータベース、ハイパーテキストウェブのための出発点、または他の何かであるかもしれません。 出版社は各リソースにURNを割り当てます、そして、リソースの現在の位置からURLを得ます。 トランスポンダーはリソースが発表されて、動き回るので適切な情報でレベル2と3をアップデートするのに原因となります。

4.2 URN -> URL mapping

4.2 URN->URLマッピング

   This level takes a URN and returns a number of URLs for the various
   instantiations of that resource on the net.  It will also maintain
   the URN space. Thus the only functionality required of this level is
   the ability to maintain a global namespace and to provide mappings
   from that namespace to the URLs. Consequently, any of the distributed
   'directory service' protocols would allow us to provide that service.
   However, there may be some benefit to collapsing levels 2 and 3 onto
   the same software, in which case we may need to select the underlying
   protocol more carefully. For example, X.500 provides exactly the
   functionality required by level 2, but does not (yet) have the
   functionality required to provide the level 3 service.  In addition,
   the service at level 2 does not necessarily have to be provided by a
   monolithic system. It can be provided by any collection of protocols
   which can jointly satisfy the requirements and also interoperate, so
   that level 2 does appear to level 3 to be universal in scope.

このレベルは、ネットに関するそのリソースの様々な具体化のためにURNを取って、多くのURLを返します。 また、それはURNスペースを維持するでしょう。 したがって、このレベルについて必要である唯一の機能性がグローバルな名前空間を維持して、その名前空間からURLまでマッピングを提供する能力です。 その結果、分配された'電話番号案内'プロトコルのいずれでも、私たちはそのサービスを提供できるでしょう。 しかしながら、レベル2と3を同じソフトウェアまで潰すことへの何らかの利益があるかもしれません、私たちが、より慎重に基本的なプロトコルを選択するために必要とするかもしれないどの場合に。 例えば、X.500は、まさにレベル2によって必要とされた機能性を提供しますが、3サービスをレベルに提供するために機能性を(まだ)必要とさせていません。 さらに、一枚岩的なシステムは必ずレベル2におけるサービスを提供する必要はありません。 レベル3への範囲で普遍的になるためにはどれがプロトコルのどんな収集でも、共同で要件を満たして、また、共同利用できるかのでレベル2が現れるかどうかということであるかもしれません。

4.3 Resource discovery

4.3 リソース発見

   This is the level which requires the most work, and where the
   greatest traps lurk to entangle the unwary. This level needs to serve
   as a giant repository of all information about every publication,
   except for that which is required for the URI -> URL mapping. Since
   this part is the least filled in at the moment, we will propose a
   mechanism which may or may not be the one which is eventually used.

これは最大級の罠が不注意をもつれさせるように潜むところで最も多くの仕事を必要とするレベルです。 このレベルは、あらゆる公表のすべての情報の巨大な倉庫として機能する必要があります、URI->URLマッピングに必要であるそれを除いて。 この部分が現在の最もいっぱいにしているものでないので、私たちは結局使用されるものであるかもしれないメカニズムを提案するつもりです。

   When a new resource is created on the network, it is assigned a URN
   determined by the publisher of the resource. Section 4.1 discusses in
   more detail the role of the publisher on the net, but at the moment

新しいリソースがネットワークで作成されるとき、リソースの出版社で断固としたURNはそれに割り当てられます。 セクション4.1は、ネットでさらに詳細に出版社の役割について議論しますが、瞬間に議論します。

Weider & Deutsch                                                [Page 5]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[5ページ]RFC1727リソーストランスポンダー1994年12月

   we can consider only 2 of the publisher's functions. The publisher is
   responsible for assigning a URN out of the publishers namespace, and
   is responsible for notifying a publishing agent [Deutsch 92] that a
   new resource has been created; that agent will either be a part of
   the resource location service or will then take the responsibility
   for notifying an external resource location service that the resource
   has been created. Alternatively, the agent can use the resource
   location service to find parts of the RLS which should be notified
   that this resource has been created.

私たちは出版社の2つの機能しか考えることができません。 出版社は、出版社名前空間からURNを割り当てるのに責任があって、新しいリソースを作成してあることを出版エージェント[ドイツ語92]に通知するのに責任があります。 そのエージェントがリソース位置のサービスの一部になるだろうか、またはそして、リソースを作成してあることを外部のリソース位置のサービスに通知することへの責任を取るでしょう。 あるいはまた、エージェントは、このリソースを作成してあることに通知されるべきであるRLSの部分を見つけるのにリソース位置のサービスを利用できます。

   To give a concrete example, let's say that Peter and Chris publish a
   multi- media document titled, "Chris and Peter's Bogus Journey",
   which talks about our recent trip to the Antarctic, complete with
   video clips. P & C would then ask their publishing agent to generate
   a URN for this document. They then ask their publishing agent to
   attach a transponder to the document, and to look around and see if
   anyone a) has asked that our agent notify them whenever anything we
   write comes out; or b) is running any kind of server of 'trips to
   Antarctica'. Janet has posted a request that she be notified, so the
   agent tells her that a new resource has been created. The agent also
   finds 3 servers which archive video clips of Antarctica, so the agent
   notifies all three that a new resource on Antarctica has come out,
   and gives out the URN and a URL for the local copy.

具体的な例を示すために、ピーターとクリスがドキュメントが題をつけたマルチメディア、南極への私たちの最近の旅行に関して話す「クリスとピーターのにせの旅行」を発行すると言いましょう、ビデオクリップで、完全です。 そして、P&Cは、このドキュメントのためにURNを発生させるように彼らの出版エージェントに頼むでしょう。 彼らは、次に、トランスポンダーをドキュメントに付けて、見回すように彼らの出版エージェントに頼んで、a)が、だれであるならも私たちが書くことが出て来るときはいつも、私たちのエージェントがそれらに通知するように頼んだのを見ます。 または、b)は'南極大陸への旅行'のどんな種類のサーバも走らせています。 ジャネットが彼女が通知されるという要求を掲示したので、エージェントは、新しいリソースを作成してあると彼女に言います。 また、エージェントが、3つのサーバが南極大陸のどのアーカイブビデオクリップであるかがわかるので、エージェントは、南極大陸に関する新しいリソースが出て来たことをすべての3に通知して、地方のコピーのためのURNとURLを配ります。

4.4 Information delivery tools

4.4 情報送達ツール

   One of the primary functions of an information delivery tool is to
   collect and collate pointers to resources. A given tool may provide
   mechanisms to group those pointers based on other information about
   the resource, e.g.  a full-text index allows one to group pointers to
   resources based on their contents; archie can group pointers based on
   filenames, etc. The URLs which are being standardized in the IETF are
   directly based on the way World Wide Web built pointers to resources,
   by creating a uniform way to specify access information and location
   for a resource on the net. With just the URLs, however, it is
   impossible without much more extensive checking to tell whether two
   resources with different URLs have the same intellectual content or
   not. Consequently, the URN is designed to solve this problem.

情報送達ツールの第一の機能の1つは、リソースにポインタを集めて、照合することです。 与えられたツールはリソースの他の情報に基づくそれらのポインタを分類するためにメカニズムを提供するかもしれません、例えば、全文インデックスはポインタをそれらのコンテンツに基づくリソースに分類するために1つを許容します。 archieはファイル名などに基づくポインタを分類できます。 IETFで標準化されているURLは直接World Wide Webがリソースにポインタを組立てた方法に基づいています、アクセス情報と位置をリソースに指定する一定の方法をネットに作成することによって。 しかしながら、まさしくURLでは、異なったURLがある2つのリソースには同じ知的な内容があるかどうか言うのははるかに大規模な照合なしで不可能です。 その結果、URNは、この問題を解決するように設計されています。

   In this architecture, the pointers that a given information delivery
   tool would keep to a resource will be a URN and one or more cached
   URLs. When a pointer to a resource is first required (i.e. when a new
   resource is linked in a Gopher server), level 2 will provide a set of
   URLs for that URN, and the creator of the tool can then select which
   of those will be used. As it is expected that the URLs will
   eventually become stale (the resource moves, the machine goes down,
   etc.) the URN can be used to get a set of current URLs for the
   resource and an appropriate one can then be selected. Since the cost

この構造では、既知情報配送ツールがリソースに保つポインタは、URNと1かさらにキャッシュされたURLになるでしょう。 リソースへのポインタが最初に必要であるときに(すなわち、新しいリソースはいつゴーファーサーバでリンクされますか)、レベル2は1セットのURLをそのURNに供給するでしょう、そして、次に、ツールの創造者はそれらのどれが使用されるかを選択できます。 URLが結局聞き古したであるなる(リソース移動、マシンは落ちますなど)と予想されるとき、リソースのために1セットの現在のURLを得るのにURNを使用できます、そして、次に、適切なものを選択できます。 費用以来

Weider & Deutsch                                                [Page 6]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[6ページ]RFC1727リソーストランスポンダー1994年12月

   of using the level 2 service is probably greater than the cost of
   simply resolving a URL, both the URN and the URL are cached to
   provide speedy access unless something has moved.

レベル2を使用するのにおいて、サービスがたぶん単にURLを決議する費用より大きい、何かが動いていない場合、URNとURLの両方が、迅速なアクセスを提供するためにキャッシュされます。

4.5 Using the architecture to provide interoperability between services

4.5 サービスの間に相互運用性を提供するのに構造を使用すること。

   In the simplest sense, each interaction that we have with an
   information delivery service does one of two things: it either causes
   a pointer to be resolved (a file to be retrieved, a telnet session to
   be initiated, etc.) or causes some set of the pointers available in
   the information service to be selected. At this level, the
   architecture outlined above provides the core implementation of
   interoperability. Once we have a means of mapping between names and
   pointers, and we have a standard method of specifying names and
   pointers, the interoperation problem becomes one of simply handing
   names and pointers around between systems. Obviously with such a
   simplistic interoperability scheme much of the flavor and
   functionality of the various systems are lost in transition. But,
   given the pointers, a system can either a) present them to the user
   with no additional functionality or b) resolve the pointers, examine
   the resources, and then run algorithms designed to tie these
   resources together into a structure appropriate for the current
   service. Let's look at one example (which just happens to be the
   easiest to resolve); interoperation between World Wide Web and
   Gopher.

最も簡単な意味で、私たちが情報デリバリ・サービスで持っている各相互作用は2つのものの1つをします: それで、ポインタが決議されることを(検索されるべきファイル、開始するべきtelnetセッションなど)引き起こすか、または情報サービスで利用可能なポインタの何らかのセットを選択します。 このレベルでは、上に概説された構造は相互運用性のコア実現を提供します。 いったん私たちが名前とポインタの間にマッピングの手段を持って、名前とポインタを指定する標準方法があると、interoperation問題はシステムの間で単に名前とポインタを回す1つになります。明らかにそのような安易な相互運用性計画するのに、風味の多く、様々なシステムの機能性は変遷で失われています。 しかし、ポインタ、システムを考えて、a)はノーが追加しているユーザへのそれらに機能性を寄贈するか、またはb)決心にポインタを贈って、リソースを調べて、次に、当期の勤務に、適切な構造にこれらのリソースを結びつけるように設計されたアルゴリズムを走らせることができますか? 1つの例(決議するのはただたまたま最も簡単である)を見ましょう。 WWWとゴーファーの間のinteroperation。

   Displaying a Gopher screen as a WWW document is trivial with these
   pointers.  Every Gopher screen is simply a list of menu items with
   pointers behind them (we'll ignore the other functionality Gopher
   provides for a moment), so is an extremely simple form of a hypertext
   document. Consequently with this architecture it is easy to show and
   resolve a Gopher screen in WWW.  For a WWW to Gopher map, the
   simplest method would be that when one accesses a WWW document, all
   the pointers associated with links off to other documents are brought
   in with the document. Gopher could then resolve the links and read
   the first line of each document to provide a Gopher style screen
   which contains everything in the WWW document. When a link is
   selected, all of the WWW links for the new document are brought in
   and the process repeats. Obviously we're losing a lot with the WWW ->
   Gopher mapping; some might argue that we are losing everything.
   However, this does provide a trivial interoperability capacity, and
   one can argue that the 'information content' has been preserved
   across the gateway.

WWWドキュメントとしてゴーファースクリーンを表示するのはこれらのポインタによって些細です。 あらゆるゴーファースクリーンが単にそれらの後ろにポインタがあるメニュー項目のリストである、(私たちが無視するつもりである、もう片方の機能性ゴーファーがちょっと提供される、)、したがって、ハイパーテキストドキュメントの非常に簡単なフォームはそうです。 その結果、この構造では、WWWでゴーファースクリーンを見せて、分解するのは簡単です。ゴーファー地図へのWWWに関して、最も簡単な方法は人がWWWドキュメントにアクセスするとき、他のドキュメントに下にリンクに関連づけられたすべてのポインタがドキュメントで持って入られているということでしょう。 ゴーファーは、次に、リンクを決議して、すべてを含むゴーファースタイルスクリーンをWWWドキュメントに供給するそれぞれのドキュメントの最初の線を読むかもしれません。 リンクが選択されるとき、新しいドキュメントのためのWWWリンクのすべてが持って入られています、そして、過程は繰り返されます。 明らかに、私たちはWWW->ゴーファーマッピングに大いに負けています。 或るものは、私たちがすべてを失っていると主張するかもしれません。 しかしながら、これは些細な相互運用性容量を前提とします、そして、1つは'情報量'がゲートウェイの向こう側に保存されたと主張できます。

   In addition, the whole purpose of gatewaying is to provide access to
   resources that lie outside the reach of your current client. Since
   all resources are identifiable and accessible through layers 2 and 3,
   it will be easy to copy resources from one protocol to another since

さらに、gatewayingする全体の目的はあなたの現在のクライアントの範囲の外にあるリソースへのアクセスを提供することです。 すべてのリソースが層2と3を通して身元保証可能であって、アクセス可能であるので、以来1つのプロトコルから別のプロトコルまでリソースをコピーするのは簡単でしょう。

Weider & Deutsch                                                [Page 7]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[7ページ]RFC1727リソーストランスポンダー1994年12月

   all we need to do is to move the pointers and reexpress the
   relationships between the pointers in the new paradigm.

私たちがする必要があるすべてがポインタを動かすことであり、「再-急行」は新しい発想におけるポインタの間の関係です。

4.6 Other techniques for interoperability

4.6 相互運用性のための他のテクニック

   One technique for interoperability which has recently received some
   serious attention is the technique of creating one client which
   speaks the protocols of all the information delivery tools. This
   approach has been taken in particular by the UNITE (User's Network
   Interface To Everything) group in Europe. This client would sit on
   the top level of the architecture in Figure 1. This technique is best
   exemplified by the recent work which has gone into Mosaic, a client
   which can speak almost all of the major information services
   protocols. This technique has a lot of appeal and has enjoyed quite a
   bit of success; however, there are several practical difficulties
   with this approach which may hinder its successful implementation.

最近何らかの重大な配慮を受けた相互運用性のための1つのテクニックがすべての情報送達ツールのプロトコルを話す1人のクライアントを創造するテクニックです。 このアプローチはヨーロッパのUNITE(ユーザのNetwork Interface To Everything)グループによって特に取られました。 このクライアントは図1の構造のトップレベルに座るでしょう。 モザイク(主要な情報サービスプロトコルのほとんどすべてを話すことができるクライアント)を調べた近作でこのテクニックを例示するのは最も良いです。 このテクニックは、多くのアピールを持って、かなりの成功を楽しみました。 しかしながら、うまくいっている実現を妨げるかもしれないこのアプローチにおけるいくつかの実用的な困難があります。

   The first difficulty is one that is common to clients in general; the
   clients must be constantly updated to reflect changes in the
   underlying protocols and to accommodate new protocols. If the
   increase in the number of information services is very gradual, or if
   the underlying protocols do not change very rapidly, this may not be
   an insuperable difficulty. In addition, old clients must have some
   way of notifying their user that they are no longer current;
   otherwise they will no longer be able to access parts of the
   information mesh.

最初の困難は一般に、クライアントにとって、一般的なものです。 基本的なプロトコルにおける変化を反映して、新しいプロトコルに対応するために絶えずクライアントをアップデートしなければなりません。 基本的なプロトコルがそれほど急速に変化しないなら情報サービスの数の増加が非常にゆるやかであるなら、これは打ち勝ちがたい困難でないかもしれません。 さらに、年取ったクライアントには、彼らがもうよく見られないように彼らのユーザに通知する何らかの方法がなければなりません。 さもなければ、彼らはもう情報メッシュの部分にアクセスできないでしょう。

   The second problem is one which may prove more difficult. Each of the
   currently deployed information services provides information in a
   fundamentally different way. In addition, new information services
   are likely to use completely new paradigms for the organization and
   display of the information they provide. The various clients of these
   information services provide vastly different functionality from each
   other because the underlying protocols allow different techniques. It
   may very well prove impossible to create a single client which allows
   access to the full functionality of each of the underlying protocols
   while presenting a consistent user interface to the user.

2番目の問題は、より難しいと判明するかもしれないものです。 それぞれの現在配備された情報サービスは基本的に異なった方法で情報を提供します。 さらに、新情報サービスはそれらが提供する情報の組織と表示に完全に新しいパラダイムを使用しそうです。 基本的なプロトコルが異なったテクニックを許容するので、これらの情報サービスの様々なクライアントは広大に互いと異なった機能性を提供します。 独身のクライアントを創造するのが不可能であると非常によく判明するかもしれません(一貫したユーザーインタフェースをユーザに提示している間、それぞれの基本的なプロトコルの完全な機能性へのアクセスを許します)。

   Much of the success of Mosaic and other UNITE tools is due to the
   fact that Gopher, WWW, and other tools are still primarily text
   based. When new tools are deployed which depend more on visual cues
   than textual cues, it may be substantially more difficult to
   integrate all these services into a single client.

モザイクと他のUNITEツールの成功の多くがゴーファー、WWW、および他の道具がそれでも主として基づくテキストであるという事実のためです。 原文の手がかりより視覚的な合図による新しいツールが配備されるとき、これらのすべてのサービスを独身のクライアントと統合するのは実質的により難しいかもしれません。

   We will continue to follow this work and may include it in future
   revisions of this architecture if it bears fruit.

それが実を結ぶなら、私たちは、ずっとこの仕事に続いて、この構造の今後の改正でそれを入れるかもしれません。

Weider & Deutsch                                                [Page 8]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[8ページ]RFC1727リソーストランスポンダー1994年12月

5. Human interactions with the architecture

5. 構造との人間の交流

   In this section we will look at how humans might interact with an
   information system based on the above architecture.

私たちが見るつもりであるこのセクションでは、人間がどう情報システムと対話するかもしれないかが上の構造を基礎づけました。

5.1 Publishing in this architecture

5.1 この構造では発行すること。

   When we speak of publishing in this section, we are referring only to
   the limited process of creating a resource on the net, assigning it a
   URN, and spreading the information around that we have created a new
   resource.

このセクションでの出版について話すとき、私たちはリソースをネットに作成する限られた過程だけを示しています、URNをそれに割り当てて、私たちが新しいリソースを作成したというおよそ情報を広げて。

   We start with the creation of a resource. Simple enough; a creative
   thought, a couple of hours typing, and a few cups of coffee and we
   have a new resource.  We then wish to assign it a URN. We can talk to
   whichever publishing agent we would like; whether it is our own
   personal publishing agent or some big organization that provides URN
   and announcement services to a large number of authors.  Once we have
   a URN, we can provide the publishing agent with a URL for our local
   copy of the resource and then let it do its thing.  Alternatively, we
   can attach a transponder to the resource, let it determine a local
   URL for the resource, and let it contact the publishing agent and set
   up the announcement process. One would expect a publishing agent to
   prompt us for some information as to where it should announce our new
   resource.

私たちはリソースの創造から始まります。 十分簡単。 創造的な考え、2、3の何時間ものタイプ、およびいくつかのカップのコーヒーと私たちには、新しいリソースがあります。 そして、URNをそれに割り当てたいと思います。 私たちが欲しい出版エージェントと話すことができます。 それが私たち自身の個人的な出版エージェントか何らかの大きい組織であることにかかわらず、それはURNとホームページの告知を多くの作者に提供します。 一度、URNを持っていて、私たちは、リソースの地元のコピーのために出版エージェントにURLを提供して、次に、それを自分のやりたいことをやることができます。 あるいはまた、私たちは、トランスポンダーをリソースに付けて、それにリソースのためにローカルのURLを決定させて、それを出版エージェントに連絡させて、発表の過程をセットアップできます。 人は、出版エージェントが何らかの情報のためにそれが私たちの新しいリソースを発表するべきであるところに関して私たちをうながすと予想するでしょう。

   For example, we may just wish a local announcement, so that only
   people in our company can get a pointer to the resource. Or we may
   wish some sort of global announcement (but it will probably cost us a
   bit of money!)

例えば、私たちはただ地方の発表を願うかもしれません、弊社の人々だけがポインタをリソースに手に入れることができるように。 または、私たちはある種のグローバルな発表を願うかもしれません。(私たちはたぶん少しのお金をそれに費やすつもりです!)

   Once the announcement has been made, the publishing agent will be
   contacted by a number of pieces of the resource location system. For
   example, someone running a WAIS server may decide to add the resource
   to their index. So they can retrieve the resource, index it, and add
   the indexes to their tables along with a URI - URL combination. Then
   when someone uses that WAIS server, it can go off and retrieve the
   resource if necessary. Or, the WAIS server could create a local copy
   of the resource; if it wished other people to find their local copy
   of the resource, it could provide the URI -> URL mapper with a URL
   for the local copy. In any case, publication becomes a simple matter.

いったん発表をすると、リソース位置測定システムの個数で出版エージェントに連絡するでしょう。 例えば、WAISサーバを走らせているだれかが、彼らのインデックスにリソースを追加すると決めるかもしれません。 彼らは、URIに伴う自分達のテーブルにそれに索引をつけて、リソースを検索するので、インデックスを加えることができます--URL組み合わせ。 次に、だれかがそのWAISサーバを使用すると、それは、去って、必要なら、リソースを検索できます。 または、WAISサーバはリソースの地方のコピーを作成するかもしれません。 他の人々にリソースの地元のコピーを見つけて欲しいなら、地方のコピーのためにURI->URLマッパにURLを提供するかもしれないでしょうに。 どのような場合でも、公表は簡単な事柄になります。

   So, where does this leave the traditional publisher? Well, there are
   a number of other functions which the traditional publisher provides
   in addition to distribution. There are editorial services, layout and
   design, copyright negotiations, marketing, etc.  The only part of the
   traditional role that this system changes is that of distributing the
   resource; this architecture may make it much cheaper for publishers

それで、どこで、これは伝統的な出版社を出ますか? さて、伝統的な出版社が分配に加えて提供する他の多くの機能があります。 編集のサービスとレイアウトとデザイン、著作権交渉、マーケティングなどがあります。 このシステムが変える伝統的な役割の唯一の部分がリソースを分配するものです。 この構造で、それは出版社にははるかに安くなるかもしれません。

Weider & Deutsch                                                [Page 9]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[9ページ]RFC1727リソーストランスポンダー1994年12月

   to distribute their wares to a much wider audience.

はるかに広い聴衆にそれらの商品を分配するために。

   Although copying of resources would be possible just as it is in
   paper format, it might be easier to detect republication of the
   resource in this system, and if most people use the original URN for
   the resource, there may be a reduced monetary risk to the publisher.

ちょうど紙の形式にそれがあるときリソースのコピーが可能でしょうが、このシステムにおける、リソースの再刊を検出するのが、より簡単であるかもしれなく、ほとんどの人々がリソースにオリジナルのURNを使用するなら、出版社への減少している通貨のリスクがあるかもしれません。

5.2 A librarian role in this architecture

5.2 この構造における司書の役割

   We've been in a number of discussions with librarians over the past
   year, and one question that we're frequently asked is "Does Peter
   talk this rapidly all the time?". The answer to that question is
   "Yes". But another question we are frequently asked is "If all these
   electronic resources are going to be created, supplanting books and
   journals, what's left for the librarians?".  The answer to that is
   slightly more complex, but just as straightforward.  Librarians have
   excelled at obtaining resources, classifying them so that users can
   find them, weeding out resources that don't serve their communities,
   and helping users navigate the library itself. None of these roles
   are supplanted by this architecture. The only differences are that
   instead of scanning publisher's announcements for new resources their
   users might be interested in, they will have to scan the
   announcements on the net. Once they see something interesting, they
   can retrieve it (perhaps buying a copy just as they do now), classify
   it, set up a navigation system for their classification scheme, show
   users how to use it, and provide pointers (or actual copies) of the
   resource to their users. The classification and selection processes
   in particular are services which will be badly needed on a net with a
   million new 'publications' a day, and many will be willing to pay for
   this highly value added service.

私たちは司書との多くの議論昨年中です、そして、私たちが頻繁に尋ねられるという1つの質問は「ピーターは絶えず、急速にこれについて話しますか?」ということです。 その質問の答えは「はい」です。 しかし、私たちが頻繁に尋ねられるという別の質問は「これらのすべての電子リソースが作成されるべきである行くのと、本に取って代わって、ジャーナルであるなら、何が司書に向けて発ちましたか?」ということです。 その答えは、わずかに複雑ですが、ちょうど同じくらい簡単です。 司書はリソースを得るのに優れていました、ユーザが彼らを見つけることができるようにそれらを分類して、地域社会に奉仕しないリソースを取り外して、ユーザがライブラリ自体にナビゲートするのを助けて。 これらの役割のいずれもこの構造によって取って代わられません。 唯一の違いは彼らのユーザが興味を持つかもしれない新しいリソースのための出版社の発表をスキャンすることの代わりに彼らがネットで発表をスキャンしなければならないということです。 いったん何かおもしろいものを見ると、彼らは、ユーザにそれ(恐らく、ちょうど彼らが現在するようにコピーを買う)を検索して、それを分類して、それらの分類計画のためにナビゲーションシステムをセットアップして、どのようにそれを使用するかをユーザに示して、リソースのポインタ(または、実際のコピー)を前提とすることができます。 特に分類と選択の過程はネットで1日あたり100万新しい'刊行物'でとても必要であるサービスです、そして、多くがこの非常に付加価値が付いたサービスの代価を払っても構わないと思うでしょう。

5.3 Serving the users

5.3 ユーザに役立つこと。

   This architecture allows users to see the vast collection of
   networked resources in ways both familiar and unfamiliar. Bookstores,
   record shops, and libraries can all be constructed on top of this
   architecture, with a number of different access methods. Specialty
   shops and research libraries can be easily built, and then tailored
   to a thousand different users.  One never need worry that a book has
   been checked out, that a CD is out of stock, that a copy of Xenophon
   in the original Greek isn't available locally.  In fact, a user could
   even engage a proxy server to translate resources into forms that her
   machine can use, for example to get a text version of a Postscript
   document although her local machine has no Postscript viewer, or to
   obtain a translation of a sociology paper written in Chinese.

この構造で、ユーザは、道における、ネットワークでつながれたリソースの膨大な収集が身近であって、かつなじみがないのを見ることができます。 書店、店を記録してください。そうすれば、この構造の上でライブラリは皆、構成できます、多くの異なったアクセス法で。 専門店と研究図書館は、1,000人の異なったユーザに容易に建設されて、次に、合わせることができます。 人は本が調べられて、CDが切れていて、オリジナルのギリシア人によるクセノフォンのコピーが局所的に利用可能でないことを決して心配してはいけません。 事実上、ユーザは、彼女のマシンが使用できるフォームにリソースを翻訳するか、彼女の地方のマシンにはPostscriptビューアーが全くいませんが、例えばPostscriptドキュメントのテキストバージョンを得るか、または中国語で書かれた社会学論文に関する翻訳を得るためにプロキシサーバを従事させることさえできました。

   In any case, however the system looks in three, five, or fifty years,
   we believe that the vision we've laid out above has the flexibility

どのような場合でも、システムが3年か5年か50年後にどのように見ても、私たちは、私たちが上に広げたビジョンが柔軟性を持っていると信じています。

Weider & Deutsch                                               [Page 10]

RFC 1727                 Resource Transponders             December 1994

ワイダーとドイツ語[10ページ]RFC1727リソーストランスポンダー1994年12月

   and functionality to start tying everything together without forcing
   everyone to use the same access methods or to look at the net the
   same way. It allows new views to evolve, new resources to be created
   out of old, and for people to move from today to tomorrow with all
   the comforts of home but all the excitement of exploring a new world.

そして、皆に同じアクセス法を使用させないですべてを結びつけ始めるか、または同じネットの道を見る機能性。 それで、新しい視点は発展します、古いのから作成されて、人々が今日から明日まで家のすべての安らぎにもかかわらず、新世界を探検するすべての興奮をもって移る新しいリソース。

6. References

6. 参照

   [Berners-Lee 93] Berners-Lee, T., Masinter, L., and M. McCahill,
   Editors, "Universal Resource Locators", RFC 1738, CERN, The Xerox
   Corporation, University of Minnesota, December 1994.

[バーナーズ・リー93]バーナーズ・リーとT.とMasinter、L.とM.McCahill、エディターズ、「普遍的なリソースロケータ」、RFC1738、CERNゼロックス社、ミネソタ大学(1994年12月)。

   Deutsch, P., Master's Thesis, June 1992.
   Available for anonymous FTP as
   <ftp://archives.cc.mcgill.ca/pub/peterd/peterd.thesis>.

ドイツ語、P.、修士論文、1992年6月。 公開FTPに、<ftp://archives.cc.mcgill.ca/パブ/peterd/peterd.thesis>として、利用可能です。

   [Weider 94a] Weider, C., "Resource Transponders", RFC 1728, Bunyip
   Information Systems, December 1994.

[ワイダー94a] ワイダー、C.、「リソーストランスポンダー」、RFC1728、詐欺師情報システム、1994年12月。

   [Weider 94b] Weider, C. and P. Deutsch, "Uniform Resource Names",
   Work in Progress.

[ワイダー94b] P. 「一定のリソース名」というワイダー、C.、およびドイツ人は進行中で働いています。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

7. Authors' Addresses

7. 作者のアドレス

   Chris Weider
   Bunyip Information Systems, Inc.
   2001 S. Huron Parkway #12
   Ann Arbor, MI 48104

Inc.2001秒間アナーバー、クリスワイダー詐欺師情報システムヒューロン族公園道路#12MI 48104

   Phone: +1 313-971-2223
   EMail: clw@bunyip.com

以下に電話をしてください。 +1 313-971-2223 メールしてください: clw@bunyip.com

   Peter Deutsch
   Bunyip Information Systems, Inc.
   310 Ste. Catherine St. West, Suite 202
   Montreal, Quebec, CANADA

ピータードイツ語詐欺師情報システムInc.310Ste。 キャサリン通り西洋、Suite202モントリオール、ケベック(カナダ)

   Phone: +1 514-875-8611
   EMail: peterd@bunyip.com

以下に電話をしてください。 +1 514-875-8611 メールしてください: peterd@bunyip.com

Weider & Deutsch                                               [Page 11]

ワイダーとドイツ語[11ページ]