rfc1727.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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


         A Vision of an Integrated Internet Information Service

Status of this 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.

1. Disclaimer

   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.

2. Introduction

   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,



Weider & Deutsch                                                [Page 1]

RFC 1727                 Resource Transponders             December 1994


   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.

3. Axioms of information services

   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.

   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.

   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.



Weider & Deutsch                                                [Page 2]

RFC 1727                 Resource Transponders             December 1994


   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).

4. An architecture to provide interoperability and integration.

   The basic architecture outlined in this paper splits up into 4 levels
   [Fig. 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.

   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.

























Weider & Deutsch                                                [Page 3]

RFC 1727                 Resource Transponders             December 1994


     ______________________________________________________________
     |           |              |       |               |
     |           |              |       |               |
     |  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   |
 |             |   |             |    |             |   |             |
 |             |   |             |    |             |   |             |
 |_____________|   |_____________|    |_____________|   |_____________|


        Figure 1: Proposed architecture of an integrated information
                        service

   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.




Weider & Deutsch                                                [Page 4]

RFC 1727                 Resource Transponders             December 1994


   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.

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

4.1 Resource layer

   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.

4.2 URN -> URL mapping

   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.

4.3 Resource discovery

   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.

   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



Weider & Deutsch                                                [Page 5]

RFC 1727                 Resource Transponders             December 1994


   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.

   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.