GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1727

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.

4.4 Information delivery tools

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

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

 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.

4.5 Using the architecture to provide interoperability between services

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

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

 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

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

5. Human interactions with the architecture

 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

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

 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.

5.2 A librarian role in this architecture

 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.

5.3 Serving the users

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

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

 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

 [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.
 Deutsch, P., Master's Thesis, June 1992.
 Available for anonymous FTP as
 <ftp://archives.cc.mcgill.ca/pub/peterd/peterd.thesis>.
 [Weider 94a] Weider, C., "Resource Transponders", RFC 1728, Bunyip
 Information Systems, December 1994.
 [Weider 94b] Weider, C. and P. Deutsch, "Uniform Resource Names",
 Work in Progress.

Security Considerations

 Security issues are not discussed in this memo.

7. Authors' Addresses

 Chris Weider
 Bunyip Information Systems, Inc.
 2001 S. Huron Parkway #12
 Ann Arbor, MI 48104
 Phone: +1 313-971-2223
 EMail: clw@bunyip.com
 Peter Deutsch
 Bunyip Information Systems, Inc.
 310 Ste. Catherine St. West, Suite 202
 Montreal, Quebec, CANADA
 Phone: +1 514-875-8611
 EMail: peterd@bunyip.com

Weider & Deutsch [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1727.txt · Last modified: 1994/12/14 23:34 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki