From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1727.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc1727.txt (limited to 'doc/rfc/rfc1727.txt') diff --git a/doc/rfc/rfc1727.txt b/doc/rfc/rfc1727.txt new file mode 100644 index 0000000..575454c --- /dev/null +++ b/doc/rfc/rfc1727.txt @@ -0,0 +1,619 @@ + + + + + + +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 + . + + [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] + -- cgit v1.2.3