summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1862.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1862.txt')
-rw-r--r--doc/rfc/rfc1862.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc1862.txt b/doc/rfc/rfc1862.txt
new file mode 100644
index 0000000..37d3eec
--- /dev/null
+++ b/doc/rfc/rfc1862.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group M. McCahill
+Request For Comments: 1862 University of Minnesota
+Category: Informational J. Romkey, Editor
+ M. Schwartz
+ University of Colorado
+ K. Sollins
+ MIT
+ T. Verschuren
+ SURFnet
+ C. Weider
+ Bunyip Information Systems, Inc.
+ November 1995
+
+
+ Report of the IAB Workshop on Internet Information Infrastructure,
+ October 12-14, 1994
+
+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 document is a report on an Internet architecture workshop,
+ initiated by the IAB and held at MCI on October 12-14, 1994. This
+ workshop generally focused on aspects of the information
+ infrastructure on the Internet.
+
+1. Introduction
+
+ The Internet Architecture Board (IAB) holds occasional workshops
+ designed to consider long-term issues and strategies for the
+ Internet, and to suggest future directions for the Internet
+ architecture. This long-term planning function of the IAB is
+ complementary to the ongoing engineering efforts performed by working
+ groups of the Internet Engineering Task Force (IETF), under the
+ leadership of the Internet Engineering Steering Group (IESG) and area
+ directorates.
+
+ An IAB-initiated workshop on the architecture of the "information
+ infrastructure" of the Internet was held on October 12-14, 1994 at
+ MCI in Tysons Corner, Virginia.
+
+ In addition to the IAB members, attendees at this meeting included
+ the IESG Area Directors for the relevant areas (Applications, User
+ Services) and a group of other experts in the following areas:
+
+
+
+McCahill, et al Informational [Page 1]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ gopher, the World Wide Web, naming, WAIS, searching, indexing, and
+ library services. The IAB explicitly tried to balance the number of
+ attendees from each area of expertise. Logistics limited the
+ attendance to about 35, which unfortunately meant that many highly
+ qualified experts were omitted from the invitation list.
+
+ The objectives of the workshop were to explore the architecture of
+ "information" applications on the Internet, to provide the IESG with
+ a solid set of recommendations for further work, and to provide a
+ place for communication between the communities of people associated
+ with the lower and upper layers of the Internet protocol suite, as
+ well as allow experience to be exchanged between the communities.
+
+ The 34 attendees divided into three "breakout groups" which met for
+ the second half of the first day and the entire second day. Each
+ group wrote a report of its activities. The reports are contained in
+ this document, in addition to a set of specific recommendations to
+ the IESG and IETF community.
+
+2. Summary
+
+ Although there were some disagreements between the groups on specific
+ functionalities for architectural components, there was broad
+ agreement on the general shape of an information architecture and on
+ general principles for constructing the architecture. The discussions
+ of the architecture generalized a number of concepts that are
+ currently used in deployed systems such as the World Wide Web, but
+ the main thrust was to define general architectural components rather
+ than focus on current technologies.
+
+ Research recommendations include:
+
+ - increased focus on a general caching and replication architecture
+
+ - a rapid deployment of name resolution services, and
+
+ - the articulation of a common security architecture for information
+ applications.
+
+ Procedural recommendations for forwarding this work in the IETF
+ include:
+
+ - making common identifiers such as the IANA assigned numbers
+ available in an on-line database
+
+ - tightening the requirements on Proposed Standards to insure that
+ they adequately address security
+
+
+
+
+McCahill, et al Informational [Page 2]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ - articulating the procedures necessary to facilitate joining IETF
+ working group meetings, and
+
+ - reviewing the key distribution infrastructure for use in
+ information applications
+
+3. Group 1 report: The Distributed Database Problem
+
+ Elise Gerich, Tim Berners-Lee, Mark McCahill, Dave Sincoskie, Mike
+ Schwartz, Mitra, Yakov Rekhter, John Klensin, Steve Crocker, Ton
+ Verschuren
+
+ Editors: Mark McCahill, Mike Schwartz, Ton Verschuren
+
+3.1 Problem and Needs
+
+ Because of the increasing popularity of accessing networked
+ information, current Internet information services are experiencing
+ performance, reliability, and scaling problems. These are general
+ problems, given the distributed nature of the Internet. Current and
+ future applications would benefit from much more widespread use of
+ caching and replication.
+
+ For instance, popular WWW and Gopher servers experience serious
+ overloading, as many thousands of users per day attempt to access
+ them simultaneously. Neither of these systems was designed with
+ explicit caching or replication support in the core protocol.
+ Moreover, because the DNS is currently the only widely deployed
+ distributed and replicated data storage system in the Internet, it is
+ often used to help support more scalable operation in this
+ environment -- for example, storing service-specific pointer
+ information, or providing a means of rotating service accesses among
+ replicated copies of NCSA's extremely popular WWW server. In most
+ cases, such uses of the DNS semantically overload the system. The
+ DNS may not be able to stand such "semantic extensions" and continue
+ to perform well. It was not designed to be a general-purpose
+ replicated distributed database system.
+
+ There are many examples of systems that need or would benefit from
+ caching or replication. Examples include key distribution for
+ authentication services, DHCP, multicast SD, and Internet white
+ pages.
+
+ To date there have been a number of independent attempts to provide
+ caching and replication facilities. The question we address here is
+ whether it might be possible to define a general service interface or
+ protocol, so that caches and replica servers (implemented in a
+ variety of ways to support a range of different situations) might
+
+
+
+McCahill, et al Informational [Page 3]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ interoperate, and so that we might reduce the amount of wasted re-
+ implementation effort currently being expended. Replication and
+ caching schemes could form a sort of network "middleware" to fulfill
+ a common need of distributed services.
+
+ It should be noted that it is an open question whether it would be
+ feasible to define a unified interface to all caching and replication
+ problems. For example, very different considerations must go into
+ providing a system to support a nationwide video service for
+ 1,000,000 concurrent users than would be needed for supporting
+ worldwide accesses to popular WWW pages. We recommend research and
+ experimentation to address this more general issue.
+
+3.2 Characteristics of Solutions
+
+ While on the surface caching and replication may appear to occupy two
+ ends of a spectrum, further analysis shows that these are two
+ different approaches with different characteristics. There are cases
+ where a combination of the two techniques is the optimal solution,
+ which further complicates the situation.
+
+ We can roughly characterize the two approaches as follows:
+
+ Caching:
+
+ - a cache contains a partial set of data
+
+ - a cache is built on demand
+
+ - a cache is audience-specific, since the cache is built in
+ response to demands of a community
+
+ Replication:
+
+ - replicated databases contain the entire data set or a
+ server-defined subset of a given database
+
+ - a replicated database can return an authoritative answer about
+ existence of an item
+
+ - data is pushed onto the replicating server rather than pulled on
+ demand
+
+ While there are important differences between caches and replicated
+ databases, there are some issues common to both, especially when
+ considering how updates and data consistency can be handled.
+
+
+
+
+
+McCahill, et al Informational [Page 4]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ A variety of methods can be used to update caches and replicas:
+
+ - master-slave
+
+ - peer-to-peer
+
+ - flooding techniques (such as that used by NNTP).
+
+ Which strategy one chooses influences important characteristics of
+ the cache or replicated database, such as:
+
+ - consistency of data
+
+ - is locking used to achieve consistency? this influences
+ performance...
+
+ - are there a priori guarantees of existence of an item in the
+ database (is the answer authoritative, do you detect conflicts
+ after the fact, or is there no guarantee on authoritativeness of
+ the answer?)
+
+ Consistency guarantees depend on the granularity of synchronization
+ (ms, sec, hr, day), and there are cases where it is acceptable to
+ trade consistency for better performance or availability. Since there
+ is a range of qualities of service with respect to consistency and
+ performance, we would like to be able to tune these parameters for a
+ given application. However, we recognize that this may not be
+ possible in all cases since it is unlikely one can implement a high
+ performance solution to all of these problems in a single system.
+
+ Beyond simply performing replication or caching, there is a need for
+ managing cache and replication servers. There are several models for
+ organizing groups of caches/replication servers that range from
+ totally adaptive to a rigidly administered, centrally controlled
+ model:
+
+ - a club model. Minimal administrative overhead to join the club.
+ Participation is a function of disk space, CPU, available
+ network bandwidth.
+
+ - centrally coordinated service. Here administrators can take
+ advantage of their knowledge of the system's topology and the
+ community they intend to serve. There may be scaling problems
+ with this model.
+
+ - hybrid combinations of the club and centrally coordinated models
+
+
+
+
+
+McCahill, et al Informational [Page 5]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ There are a couple of models for how to organize the management of a
+ group of cooperating servers, but this does not address the question
+ of what sorts of commands the manager (be it a person or a program)
+ issues to a cache or replicated server. A manager needs to be able to
+ address issues on a server such as:
+
+ - control of caching algorithms, defining how information is aged
+ out of the cache based on disk space, usage demands, etc. This is
+ where you would control time-to-live and expiry settings.
+
+ - flushing the cache. There are circumstances where the
+ information source has become inaccessible and the normal cache
+ aging strategy is inappropriate since you will not be able to
+ get the information again for an indeterminate amount of time.
+
+ - management control might also be a way for information providers
+ to control how information is pushed on servers for maintaining
+ data consistency, but this raises tricky problems with trust and
+ authentication.
+
+ Given a common set of management controls needed, a common protocol
+ would allow for simplified management of a collection of caching and
+ replicating servers since you would be able to both control them with
+ a single set of commands and query them about their capabilities. A
+ common language/protocol would also allow different implementations
+ to interoperate.
+
+ Replicating or caching information immediately raises issues of
+ billing, access control and authentication. Ignoring authentication
+ and access control issues simplifies the replication and caching
+ problem a great deal. Exactly who is running the replication or
+ caching server makes a big difference in how you approach this issue.
+ If the information publisher runs a set of servers, they can easily
+ handle billing and authentication. On the other hand, if an
+ organization is running a cache on its firewall (a boundary cache),
+ and purchasing information from a vendor, there are sticky issues
+ regarding intellectual property in this scenario.
+
+ Selecting an appropriate cache or replica of a database is simple in
+ the case of a captive user group (for instance a company behind a
+ firewall). In this case, configuring the user's software to go
+ through one or more boundary caches/replication servers directs the
+ users to the closest server. In the more general case, there are
+ several replicated/cached copies of an object, so you may receive
+ several URLs when you resolve a URN. How do you select the best URL?
+
+ Either client developers create ad hoc performance metrics or (in an
+ ideal world) the lower level protocols would give the client
+
+
+
+McCahill, et al Informational [Page 6]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ application some guidance about the "closest" copy of the object. In
+ other words, if better information about network performance was
+ available from lower levels of the protocol stack, applications would
+ not have to build ad hoc models of network topology
+
+ We did not model the functions of a cache/replication server in
+ detail, but we did an (incomplete) model of some of the functions
+ (see Figure 1). The idea here was to start work on a general form
+ which might include features such as a push function for use in both
+ maintaining consistency and in preloading information that the
+ information publisher believes will be requested in the near future.
+
+ Preloading information via a push command might be a function of
+ observed behavior patterns (when you ask for A you'll probably want B
+ and C). The decision about what to preload can be made either by the
+ information publisher or by the cache server. The cache server has
+ the advantage that it has better knowledge of the use patterns of its
+ community. The distributed nature of links to other servers also
+ limit the knowledge of a single information publisher. In any case,
+ being able to accurately predict usage patterns can result in
+ significant performance enhancements for caches.
+
+Figure 1: a rough cut at functions
+
+ requests from client (in)
+ |
+ |
+ |
+ \|/
+ +---------------------+
+ | | (management)
+ | cache/replicated db |<--- commands from admins,
+ | | publishers, caches
+ +---------------------+
+ |
+ |
+ |
+ \|/
+ requests sent to information providers (out)
+
+ in: (requests from a client)
+
+ - give me meta-info about cached object (how up-to-date,
+ ttl, expiry, signatures/checksum, billing information )
+
+ - give me the object
+
+ - go get the object from the net
+
+
+
+McCahill, et al Informational [Page 7]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ - cache, what objects should I pre-fetch?
+ (this assumes that the client software believes that the
+ cache/replica has some knowledge of use patterns and can
+ predict what the user will do next)
+
+ out: (requests sent to an information publisher or a
+ cache further up the food chain)
+
+
+
+ - server, do I have latest copy of this object?
+
+ - give me object x and the meta data for object x
+
+ - I have a copy of object x (announcing you have a copy
+ of object x to other caches or URN to URL server)
+
+ - info publisher, what objects should I pre-fetch?
+ (this assumes that the information publisher has some
+ knowledge of use patterns and can predict what the user
+ will do next)
+
+ management: (commands from administrators, other
+ cooperating caches, and object publishers)
+
+
+ - turn parameters (e.g. consistency) on/off
+
+ - flush the cache
+
+ - there's a new version of object x, take it
+
+3.3 Recommendations
+
+ Caching and replication are important pieces of Internet middleware,
+ and solutions need to be found soon. Caches and replicas have
+ different performance characteristics, and there are cases where a
+ combination of the two provides the best solution. There are also
+ many strategies for updating and maintaining consistency of caches
+ and replicated databases, and we do not believe any single
+ implementation can suffice for the broad range of needs in the
+ Internet. One possible solution would be to define a general
+ protocol for a replicated distributed database and for caching so
+ that different information application implementations can
+ interoperate and be managed via a common management interface. A
+ common protocol would provide a framework for future protocols (e.g.,
+ URN2URL, DHCP) or existing protocols (e.g., Gopher or WWW) that
+ presently lack a consistent solution.
+
+
+
+McCahill, et al Informational [Page 8]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+4. Group 2A report: Building an Information Architecture
+
+ Karen Sollins, Abel Weinrib, Barry Leiner, Clifford Neuman, Dan
+ LaLiberte, Erik Huizer, John Curran, John Klensin, Lixia Zhang,
+ Michael Mealling, Mitchell Charity, Mike St. Johns, Paul Mockapetris
+
+ This group took as its central agenda exploring an information
+ architecture, the services that would instantiate such an
+ architecture, and the functional interfaces between a realization of
+ such an architecture and both layers on which it would sit and the
+ layers that would sit on it. In order to describe an architecture,
+ one must describe not only what it includes, but also what it
+ excludes.
+
+4.1. The core model and service structure
+
+ The general architecture has as its centerpiece objects, or as they
+ are known in the Uniform Resource Identifier Working Group,
+ resources. An object in this architecture has several
+ characteristics. First, it has an identifier, assigned within the
+ context of some namespace. Such an identifier is globally unique and
+ will not be reassigned to another object. Thus, it can be said to be
+ globally unique for a long time. Because such an identifier must
+ remain unique for all time, it cannot contain location-relevant
+ information ... locations can and will be reused. Also, since
+ resources may appear in zero, one, or many locations simultaneously,
+ location-dependent information can lead to a vast number of
+ identifiers for an object, which will make it difficult to identify
+ separately retrieved copies of an object as being the same object.
+ These locations are defined by the supporting layers that provide
+ transport and access. Therefore the definition of locations is not
+ within the architecture, although their existence is accepted.
+ Second, an object will support one or more abstract types. Further
+ determination beyond this statement was not made. One can conclude
+ from these two points that an object cannot be part of such an
+ architected universe without having at least one such identifier and
+ without supporting at least one type if it has at least one location.
+
+ In addition, the architecture contains several other components.
+ First, there will be a prescribed class of objects called links that
+ express a relationship among other objects including the nature of
+ that relationship. It is through links that composite objects
+ composed of related objects can be created and managed. Finally,
+ there is a need for several sorts of meta-information, both in order
+ to discover identifiers (e.g. for indices and in support of
+ searching) and to aid in the process of mapping an identifier to one
+ or more potential locations. Both of these sorts of meta-information
+ are associated with objects, although they will be used and therefore
+
+
+
+McCahill, et al Informational [Page 9]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ most likely managed differently, to support their distinctive access
+ and update requirements.
+
+ Given this architecture of information objects, one can identify
+ several boundary points. First, something that does not have an
+ identifier or type is outside the architecture. Second, the
+ architecture does not, at this point, include any statement about
+ computations, or communications paradigms other than second-handedly
+ by assuming that traversal of links will occur. Third, although
+ pre-fetching, caching, and replication are important, such details
+ may be hidden from higher level software components, and thus are not
+ part of the data model exposed to the application in the normal case
+ (though some applications may want to specify such characteristics).
+
+ Now one can ask how such a model fits into a layered network model,
+ how it might be modularized and realized. We envisioned this
+ information layer as an information "wholesale" layer. It provides
+ the general, broad model and provision of shared, network-based
+ information. Above this sit the "retailers," the marketers or
+ providers of information to the marketplace of applications users.
+ Below the "wholesalers" lie the providers of "raw materials." Here
+ will be the provision of supporting mechanisms and architecture from
+ which information objects can come.
+
+ The remainder of this group's report describes the modular
+ decomposition of the wholesale layer, including the interactions
+ among those modules, separate discussions of the interactions first
+ between the retail and wholesale layers and then between the
+ wholesale and raw material layers. The report concludes with
+ recommendations for where the most effective immediate efforts could
+ be made to provide for the wholesale layer and make it useful.
+
+4.2. The Wholesale Layer
+
+ In order to realize the information architecture in the network a
+ variety of classes of services or functionality must be provided. In
+ each case, there will be many instances of a sort of service,
+ coordinating to a lesser or greater degree, but all within the
+ general Internet model of autonomy and loose federation. There also
+ may be variants of any sort of service, to provide more specialized
+ or constrained service. In addition, services may exist that will
+ provide more than one of these services, where that is deemed useful.
+ Each such service will reside in one or more administrative domains
+ and may be restricted or managed based on policies of those domains.
+ The list of core services is described below. Because there are many
+ interdependencies, there may often be forward references in
+ describing a service and its relationships to other services.
+
+
+
+
+McCahill, et al Informational [Page 10]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ * RESOURCE DISCOVERY: Much of the activity of resource discovery,
+ indexing and searching, will be in the domain of the retailers,
+ although there are supporting hooks that can be provided by the
+ wholesaler layer as well. A resource discovery service will hold
+ mappings from descriptions to identifiers of objects. They will need
+ to be queried. Thus there is a general functionality for a wholesale
+ layer service that answers queries formulated in certain ways and
+ responds with identifiers. The business of on what basis indices are
+ computed or how they are managed will be domain specific.
+
+ * NAMING or IDENTIFICATION: There are two aspects to assigning an
+ identifier to an object, one in the wholesale layer, and one,
+ arguably, in the retail layer. In the wholesale layer, one can
+ generate identifiers that are guaranteed to be unique. In the retail
+ layer one might ask the question about whether two objects are the
+ same or different by the rules of an identification authority that
+ therefore would determine whether they should bear the same or
+ different identification from that authority. It should be noted
+ that the URI Working Group has included these two functions in the
+ requirements document for URNs.
+
+ An identification service will obviously provide functionality to the
+ uniqueness authority. It will also provide identification in the
+ process of publication of objects, as will be discussed below, in the
+ management of resource discovery information, object location and
+ storage services, as well as cache and replication management.
+
+ * NAME or IDENTIFICATION RESOLUTION: Since identifiers are presumed
+ to be location independent, there is a need for a resolution service.
+ Such a service may sometimes return other identifiers at this same
+ level of abstraction (the equivalent of aliases) or location
+ information, the information delivered to a transport service to
+ access or retrieve an object.
+
+ * OBJECT RETRIEVAL: Object retrieval is tightly coupled to
+ resolution, because without resolution it cannot proceed. Object
+ retrieval provides the functionality of causing a representation of
+ an object to be provided locally to the requester of an object
+ retrieval. This may involve the functionality of object publication
+ (see below) and object storage, caching and replication services as
+ well as the supporting transport facilities.
+
+ * OBJECT PUBLICATION: When an object comes into existence in the
+ universe of the information infrastructure, it is said to be
+ "published." There will be two common scenarios in publication. One
+ will be the use of tools to directly enter and create the information
+ that comprises an object in the information infrastructure. Thus
+ there may be object creation tools visible to users in applications.
+
+
+
+McCahill, et al Informational [Page 11]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ In contrast there may also be tools outside the information
+ infrastructure (for example word processing or text editing tools)
+ that provide for the entry of data separately from the operation of
+ assigning an object an identifier and causing it to support
+ information infrastructure definitions of objects. Thus, there will
+ also be visible at the interface between the wholesale and retail
+ layers the ability to cause some pre-existing data to become one or
+ more objects. In addition to interacting with the identification
+ service, publication is likely to cause interaction with object
+ storage, and possibly caching and replication.
+
+ * DEFINITIONS: If the information infrastructure is to both survive
+ and evolve over a long time period, we must be prepared for a wide
+ variety and growing number of different sorts of information with
+ different functionalities that each supports. For objects available
+ on the net, the functionality that each provides must be exposed or
+ able to be learned. To do this objects must be able to indicate by
+ name or identifier the types of functionality they are supporting.
+ Given such an identifier, an object is only useful to a client, if
+ the client can discover the definition and perhaps a useful
+ implementation of the type in question. This will be acquired from a
+ definitions service, which will be used in conjunction with
+ applications themselves directly, object publication, and object
+ retrieval.
+
+ * ATTRIBUTE MANAGEMENT: The attributes considered here relate to
+ policy, although any understanding of that policy will be above the
+ wholesale level. There are, for example, access management and
+ copyright attributes. There is a question here about whether there
+ is or should be any access time enforcement or only after the fact
+ enforcement. The information is likely to be in the form of
+ attribute-value pairs and must be able to capture copyright knowledge
+ effectively.
+
+ * ACCOUNTING: An accounting service provides metering of the use of
+ resources. The resources wholly contained in the wholesale layer are
+ the services discussed here. It will also be important to provide
+ metering tools in the wholesale layer to be used by the retail layer
+ to meter usage or content access in that layer. Metering may be used
+ for a variety of purposes ranging from providing better utilization
+ or service from the resources to pricing and billing. Hence
+ accounting services will be used by object storage, caching and
+ replication, lower layer networking services, as well as pricing and
+ billing services. In the form of content metering it will also
+ interact with attribute management.
+
+
+
+
+
+
+McCahill, et al Informational [Page 12]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ * PRICING, BILLING and PAYMENT: Pricing and payment services straddle
+ two layers in the information infrastructure. Servers that maintain
+ account balances and with which users interact to retrieve and edit
+ account information are applications that will be built on top of
+ wholesale layer services. Pricing will be determined in the
+ applications environment for application level activities. However,
+ it must be possible for middle layer services to process payment
+ instruments analogous to cash, credit card slips, and checks, without
+ an understanding of the specific implementation of the payment
+ mechanism. Application programming interfaces supporting payment
+ should be provided, and a common tagged representation of payment
+ instruments should allow instruments from a variety of payment
+ systems to be presented within middle layer protocols.
+
+ * OBJECT STORAGE, CACHING and REPLICATION: There is a recognition
+ that caching and replication are important, but the discussion of
+ that was left to another group that had taken that as the focus of
+ their agenda. Object storage will take an object and put it
+ somewhere, while maintaining both the identity and nature of the
+ object. It is tightly coupled to caching and replication, as well as
+ accounting, often in order to determine patterns of caching and
+ replication. It is also tightly coupled to object publication,
+ translation, and provides interfaces to both supporting storage
+ facilities such as local file systems, as well as direct access from
+ applications, needing access to objects.
+
+ * TRANSLATION: A translation service allows an object to behave with
+ a nature different than that it would otherwise support. Thus, for
+ example, it might provide a WYSIWYG interface to an object whose
+ functionality might not otherwise support that, or it might generate
+ text on the fly from an audio stream. Translation services will be
+ used by object publication (allowing for identification of an object
+ including a translation of it) and with object storage, providing an
+ interface only within the wholesale or to the retail layers.
+
+ * SERVER AND SERVICE LOCATION: It will be necessary as part of the
+ infrastructure to be able to find services of the kinds described
+ here and the servers supporting them. This service has direct
+ contact with the lower layer of raw materials, in that it will
+ provide, in the final analysis, the addresses needed to actually
+ locate objects and services using lower level protocols, such as the
+ existing access protocols in use today, for example FTP, SMTP, HTTP,
+ or TCP. This service will provide functionality directly to resource
+ discovery as well as remote object storage services.
+
+
+
+
+
+
+
+McCahill, et al Informational [Page 13]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ * ADAPTIVE GLUE: This is not a single service as much as a
+ recognition that there must be a path for a flow of information
+ between the network layers and the applications. The application may
+ have constraints, based both on its own needs as well as needs of the
+ objects in the wholesale layer. Only the application can really know
+ what compromises in services provided below are acceptable to it. At
+ the same time, the supporting network layers understand what
+ qualities of service are available at what price. Hence there is the
+ potential for flow of information both up and down through the
+ wholesale layer, perhaps mediated by the wholesale layer. Hence the
+ adaptive glue has hooks into all three levels.
+
+ * SECURITY: Security services will be a critical piece of the
+ infrastructure architecture. For any real business to be conducted,
+ organizations must make their information available over the network,
+ yet they require the ability to control access to that information on
+ a per user and per object basis. To account properly for the use of
+ higher level services, organization must be able to identify and
+ authenticate their users accurately. Finally, payment services must
+ be based on security to prevent fraudulent charges, or disclosure of
+ compromising information.
+
+ The two biggest problems in providing security services at the
+ wholesale layer are poor infrastructure and multiple security
+ mechanisms that need to be individually integrated with applications.
+ The poor state of the infrastructure is the result of a lack of an
+ accepted certification hierarchy for authentication. A commonly held
+ position is that there will not be a single hierarchy, but there must
+ be established authorities whose assertions are widely accepted, who
+ indirectly certify the identities of individuals with which one has
+ not had prior contact.
+
+ Integration with applications is made difficult because, though
+ security services are themselves layered upon one another, such
+ services do not fit into the information architecture at a single
+ layer. By integrating security services with lower layers of the
+ information infrastructure, security can be provided to higher
+ layers, but some security information, such as client's identity, may
+ be needed at higher layers, so such support will not be completely
+ transparent. Further, the security requirements for each middle
+ layer information service, and of the application itself, must be
+ considered and appropriate use must be made of the middle-layer
+ security services applied.
+
+ Integration with applications will require user demand for security,
+ together with common interfaces such as the GSS-API, so that
+ applications and middle layer information services can utilize the
+ security services that are available, without understanding the
+
+
+
+McCahill, et al Informational [Page 14]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ details of the specific security mechanism that is employed.
+
+ * BOOTSTRAPPING: In order for a newly participating machine to join
+ the infrastructure, it must have some way of finding out about at
+ least one instance of many of the services described here. This can
+ be done either by providing it with some form of configuration
+ provided by the human bringing it up or by a bootstrapping service.
+ The bootstrapping service is more flexible and manageable; it is
+ included here in recognition that this information must be provided
+ in some form or other. The bootstrapping service will sit directly
+ on the raw materials layer and will have contact with all the
+ services described here.
+
+ This completes the description of the services as identified by this
+ group in the wholesale layer. Although this section suggests which
+ services have interfaces to the retail and raw materials layers, each
+ of these topics will need to be described separately as well, to
+ clarify the functionality expected by each layer of the layer below.
+
+3. Interface to retail layer
+
+ The interface to the retail layer is the embodiment of the object
+ model and attendant services. Thus the interface provides the
+ application environment with a collection of objects having
+ identifiers for distinguishing them within the wholesale layer and
+ support for a typing or abstract functionality model. It provides
+ for the ability to create or import objects into this object world by
+ the publication paradigm, and allows objects to evolve to support new
+ or evolving functionality through the translation paradigm. Access
+ to the objects is provided by object storage, enhanced with caching
+ and replication services and mediated by the attributes managed by
+ attribute management and accounting or content metering. Discovery
+ of resources (figuring out which identifier to be chasing) is
+ provided by resource discovery services. Types are registered and
+ hence available both as definitions and perhaps in the form of
+ implementations from a definition service. Lastly, there is a
+ vertical model of providing the two-way services of adaptive glue for
+ quality of service negotiation and for security constraints and
+ requirements, with access and services at all three layers.
+
+4. Interface to the raw materials layer
+
+ The raw materials layer falls into networking and operating systems.
+ Hence it provides all those services currently available from current
+ networking and operating systems. Wholesale services such as object
+ management will be dependent on local operating system support such
+ as a file system, as well as perhaps transport protocols. In fact,
+ all instances of any of the above services will be dependent on local
+
+
+
+McCahill, et al Informational [Page 15]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ storage, process management, local access control and other security
+ mechanisms, as well as general transport protocols for communications
+ both often among services of the same sort and among services
+ dependent on each other that may not be collocated. In addition the
+ group identified a set of issues that appear important for the
+ networking components of the raw materials layer to provide to the
+ wholesale layer in addition to the basic best effort transmission
+ services that are commonly available. These take the form of a wish
+ list with the recognition that they are not all equally easy or
+ possible.
+
+ * Connectivity: It is useful and important for the operation of
+ applications and the wholesale services to understand what
+ connectivity is currently available. The group identified four
+ categories of connectivity that it would be useful to know about
+ represented by four questions:
+
+ 1) Is there a wire out of the back of my machine?
+
+ 2) Am I connected to a router?
+
+ 3) Am I connected to the global internet? (Can I get beyond
+ my own domain?)
+
+ 4) Am I connected to a specific host?
+
+ These are probably in increasing difficulty of knowing.
+
+ * Connectivity forecast: Although this is recognized as either
+ extremely difficult or impossible to do, some form of connectivity
+ forecast would be very useful to the upper layers
+
+ * Bandwidth availability and reservation: It is useful for the
+ application to know both what bandwidth might be available to it and,
+ better yet, for it to be able to make some form of reservation.
+
+ * Latency availability and reservation: It is useful for the
+ application to know both what latency the network is experiencing
+ and, better yet, be able to set limits on it by means of a
+ reservation.
+
+ * Reliability availability and reservation: Again, reliability
+ constraints are important for many applications, although they may
+ have differing reliability constraints and may be able to adapt
+ differently to different circumstances. But, if the application
+ could make a statement (reservation) about what level of
+ unreliability it can tolerate, it might be able to make tradeoffs.
+
+
+
+
+McCahill, et al Informational [Page 16]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ * Burstiness support: Although it is unlikely that the network can
+ make predictions about the burstiness of its services, if the
+ application can predict to the network its burstiness behavior, the
+ network might be able to take advantage of that knowledge.
+
+ * Service envelope: It is possible that, as an alternative to the
+ above four issues, the raw materials layer could negotiate a whole
+ service envelope with the layers it is supporting.
+
+ * Security availability: In many cases, it will be important for the
+ upper layers to be able to know what sorts and levels of security are
+ available from the raw materials layer. This is true of both any
+ operating system support as well as transmission.
+
+ * Cost: If there is to be usage charging at other than fixed flat
+ rates, it will be important for applications and users to understand
+ what those costs or at least estimates of them will be.
+
+ * Policy routing: If it will be important for transport services to
+ support policy routing, it will be important for users of the
+ transport services to identify into which policy classes they might
+ fall.
+
+4.5. Recommendations
+
+ This group has two categories of recommendations. One is those
+ services in the wholesale layer that will both be especially useful
+ and readily achieved because work is soon to be or already underway.
+ The other set of recommendations was a three item rank ordering of
+ services that are most important for the lower layer to provide to
+ the wholesale layer.
+
+ Within the wholesale layer, the first services that should be
+ provided are:
+
+ * Object retrieval,
+
+ * Name resolution,
+
+ * Caching and replication.
+
+ In addition, the group rank ordered three areas in which there would
+ be quick payoff if the raw materials layer could provide them. They
+ are:
+
+ 1. Connectivity
+
+ 2. Bandwidth, latency, and reliability or service envelope
+
+
+
+McCahill, et al Informational [Page 17]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ 3. Security constraints on communication and transactions
+
+5. Group 2B Report: Components of an Internet Information Architecture
+
+ Cecilia Preston, Chris Weider, Christian Huitema, Cliff Lynch, John
+ Romkey, Joyce Reynolds, Larry Masinter, Mitra, Jill Foster
+
+ Group 2B discussed various aspects of problems in the Internet
+ Information Infrastructure, thinking about recommendations to the
+ IESG to focus on particular areas, and also paying attention to some
+ of the philosophical and economic backgrounds to some of the
+ problems. Economics can dictate some points of architecture: one can
+ see economically why a publisher might bear the burden of the costs
+ of publishing, or a consumer might bear the burden of costs
+ associated with consumption, but not how some free-floating third
+ party would necessarily bear the costs of providing services (such as
+ third-party translators).
+
+ The group discussed the following topics:
+
+ access(URL)
+
+ gateways
+
+ URN resolution
+
+ definitions
+
+ updates
+
+ service location
+
+ cache & replication
+
+ security & authentication
+
+ payments, charging
+
+ presentation
+
+ search & index
+
+ metainformation
+
+ boot service
+
+ general computation
+
+
+
+
+McCahill, et al Informational [Page 18]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+5.1 URNs
+
+ There are several issues in the use of Uniform Resource Names and
+ Uniform Resource Locators. URN resolution is a database lookup that
+ returns the URLs associated with a URN. The architecture must take
+ into account not only how the lookup is performed, but how the
+ database is maintained. Both the lookup problem and the update
+ problem must be solved at the same time to allow deployment of URNs.
+
+ There are at least two problems in human interaction with unique
+ names. First, the notion of a unique name is a fallacy. Unique naming
+ cannot be enforced. Names may be forged or may simply be duplicated
+ due to human error. The architecture must accept this observation and
+ still operate in the face of it. Designing for global uniqueness, but
+ not requiring it, was adequate. Errors based on names not being
+ unique are likely to be insignificant compared to other errors.
+
+ Also, people frequently make assertions and assumptions about names
+ rather than the documents that are being named. Making assertions
+ about names is working at the wrong level of indirection. Making
+ assumptions about names, such as determining the contents of the
+ named object from the syntax of the name, can lead to nasty
+ surprises.
+
+ Having a single, unified naming system is vital. While it is healthy
+ to have multiple competing forms of other aspects of the information
+ architecture, the naming system is what ties it all together. There
+ must be only one naming system. If there is more than one, it may not
+ be possible to compare names or to lookup locations based on names,
+ and we will continue (to our detriment) to use locators rather than
+ names.
+
+5.2 Global Service Location
+
+ The IANA has become the central switch point for service
+ identification. and recommended that numbers that are formally
+ defined and kept in documents for use in distributed information
+ systems (for instance, Assigned Numbers) should also be distributed
+ online in some kind of database for use by applications. This
+ distribution requires both an access method (perhaps multiple access
+ methods) and an update method.
+
+5.3 Security
+
+ Issues involving security arose over and over again. Security
+ includes things like validation of authority, confidentiality,
+ integrity of data, integrity of services, access control. The group
+ agreed that, although often overlooked, confidentiality is important,
+
+
+
+McCahill, et al Informational [Page 19]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ and, more strongly: anonymity is important. It should be possible to
+ access documents or objects without the architecture requiring you to
+ leave digital fingerprints all over the place.
+
+ Security must occur on an end-to-end basis. Documents or objects used
+ on the Internet may not only traverse the Internet. Relying on
+ security mechanisms in the underlying protocol suite does not
+ necessarily provide end-to-end authentication or confidentiality.
+
+ Currently lower layer security is ill-defined and widely
+ unimplemented. Designers building information applications atop the
+ Internet currently receive little guidance in how to design security
+ features into their applications, leading to weak ad hoc or
+ nonexistent security in new applications. Designers are also unclear
+ as to how to deal with the "security considerations" section that is
+ mandatory in RFCs, and often fill them with boilerplate text.
+
+ Furthermore, retrofitting security into existing architectures does
+ not work well. The best systems are built considering security from
+ the very beginning. Some systems are being designed that, for
+ instance, have no place for a digital signature to authenticate the
+ data they pass. These issues apply to data management as well.
+
+ The group makes the following recommendations to the IESG regarding
+ security:
+
+ A. Develop and communicate a security model usable by designers of
+ information applications - current models are not considered usable.
+
+ B. RFC authors should be given advice on what security considerations
+ need to be outlined and how to write them. The IESG security area
+ should prepare guidelines for writing security considerations.
+
+ C. Proposed Standards should not be accepted by the IESG unless they
+ really consider security. This will require that recommendations A
+ and B have been implemented and that the guidelines have received
+ enough visibility to reasonably expect authors to know of their
+ existence.
+
+ D. Develop security modules usable by the implementors of information
+ clients and servers - reusable across many different, heterogeneous
+ applications and platforms.
+
+ E. Make clear what security services you can expect from the lower
+ layers.
+
+ F. Make sure that the key distribution infrastructure is reviewed for
+ usability by information applications.
+
+
+
+McCahill, et al Informational [Page 20]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+5.4 Search and Index
+
+ Searching is looking through directories that point to information.
+ Indexing is scanning information to create directories. A "unified
+ directory" is the result of combining several indices.
+
+ Indexing is currently done on the Internet via many mechanisms. Given
+ the current ad hoc nature of the indexing, information is frequently
+ indexed multiple times. This is wasteful, but due to the current
+ economics of the Internet, it tends not to cost more money. If the
+ Internet (or parts of thereof) transitions to usage based charging,
+ it may cost the information provider too much to allow the
+ information to be indexed. In general, the provider should have
+ control over how the information they control is indexed.
+
+ Above all, the architecture should not encourage a situation where
+ information is normally not indexed. It should encourage the
+ collection of indexing data only a single time. Having a local
+ computation of a summary which is sent to a search/index server is
+ vastly preferable to having that server "walk the net" to discover
+ information to index.
+
+ Indexing and search techniques are quite varied. It is quite likely
+ that index and search are too close to general computation to try to
+ standardize on a single protocol for either. Instead, it is important
+ that the architecture allow multiple search techniques. There are
+ currently certain types of indices that can only be generated by
+ humans because of their level of semantic content. There are large
+ differences in the quality and usability of indices that are
+ machine-generated vs. human generated.
+
+ Unified directories tend to combine indexing results from quite
+ different techniques. The architecture should constrain indexing so
+ that it remains possible to merge the results of two searches done by
+ different protocols or indexing systems. Returning information in
+ standard formats such as URNs can help this problem.
+
+ Vocabulary issues in search and index are very difficult. The library
+ and information services communities do not necessarily use
+ vocabulary that is consistent with the IETF community, which can lead
+ to difficult misunderstandings.
+
+ "Searching the Internet" is an inappropriate attempt to categorize
+ the information you're attempting to search. Instead, we search
+ certain public spaces on the Internet. The concept of public space
+ vs. private space on the Internet deserves further investigation.
+
+
+
+
+
+McCahill, et al Informational [Page 21]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ Indexing can run afoul of access control considerations. Access
+ control must be done at the object, but access control information
+ should be propagated through indices as well. The index should be
+ able to say "you're not allowed to ask that" rather than the user
+ attempting to retrieve the object and being denied.
+
+ An architectural point was raised that an index query should return
+ the same result independent of who is asking. This is an important
+ notion in the Domain Name System. This is inconsistent with some
+ real-world indexing (for instance, corporate record management
+ systems) which doesn't want to admit that some documents exist if
+ you're not allowed to read them.
+
+5.5 Miscellaneous
+
+ Electronic mail, netnews, FTP and the web are frequently used to
+ access information on the net today. Each protocol seems to provide a
+ consistent view of the information on the Internet. In addition, the
+ recent popularity of multi-protocol clients such as Mosaic seem to
+ imply that the information content of the Internet is uniformly
+ retrievable and manageable. This perception is misleading because
+ most protocols are used for other applications than they were
+ originally designed for. In addition, Telnet, which has no concept of
+ information retrieval and management, is often used to access
+ information as well, for example in DIALOG and card file accesses.
+ Since each protocol has different access and management capabilities,
+ the inconsistencies show up in erratic search and retrieval results,
+ puzzling error messages, and a basic lack of standard techniques for
+ dealing with information. A consistent underlying information
+ architecture will go a long way towards alleviating these problems.
+
+ As the information architecture develops we should reconsider the
+ electronic mail and netnews architecture in terms of the new
+ architecture.
+
+ The group noted that there have been difficulties in scheduling joint
+ working group meetings and recommends that there be a clearly defined
+ process inside the IETF to facilitate scheduling such meetings.
+
+6. Conclusions and Recommendations
+
+ The workshop provided an opportunity for ongoing conversations about
+ the architecture to continue and also provided space for focused
+ examination of some issues and for some new voices and experience
+ from other areas of Internet growth to participate in the
+ architectural process.
+
+
+
+
+
+McCahill, et al Informational [Page 22]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ Part of the conclusion of the workshop is a set of recommendations to
+ the IESG and IETF community.
+
+ Recommendations on research/implementation directions:
+
+ 1. Caching and replication are important and overlooked pieces of
+ Internet middleware. We should do something about it as soon as
+ possible, perhaps by defining an architecture and service model for
+ common implementation.
+
+ 2. Within the 'wholesale' layer, i.e. within the layer which provides
+ a consistent view of the information resources available on the
+ Internet, the first services that should be provided are:
+
+ * Object retrieval,
+
+ * Name resolution,
+
+ * Caching and replication.
+
+ 3. There would be quick payoff if the raw materials layer, i.e. the
+ layer in which information resources are physically transmitted to
+ computers, could provide the following services:
+
+ * Connectivity
+
+ * Bandwidth, latency, and reliability or a service envelope
+
+ * Security constraints on communication and transactions
+
+ 4. Develop security modules usable by the implementors of information
+ clients and servers - reusable across many different, heterogeneous
+ applications and platforms
+
+Recommendations to the IESG, IETF, and IANA
+
+ 1. Numbers that are formally defined and kept in documents in
+ distributed information systems (for instance, Assigned Numbers)
+ should be available in some kind of database for use by applications.
+
+ 2. Develop and communicate a security model usable by designers of
+ information applications - current models are not considered usable
+ or are not widely accepted on the Internet.
+
+ 3. RFC authors should be given advice on how security considerations
+ need to be written. The IESG security area should prepare guidelines
+ for writing security considerations.
+
+
+
+
+McCahill, et al Informational [Page 23]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ 4. Proposed Standards should not be accepted by the IESG unless they
+ really consider security. This will require recommendations 2 and 3
+ to be implemented first.
+
+ 5. Make clear what security services you can expect from the lower
+ layers.
+
+ 6. Make sure that the key distribution infrastructure is reviewed for
+ usability by information applications.
+
+ 7. There needs to be a process inside the IETF for scheduling a joint
+ meeting between two working groups - for example, so that the key
+ distribution WG can meet jointly with IIIR.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCahill, et al Informational [Page 24]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+APPENDIX A - Workshop Organization
+
+ The workshop was held at MCI's facility in Tyson Corners, Virginia.
+ The workshop organizers and attendees wish to thank MCI for the use
+ of their facilities to host the workshop.
+
+ All attendees met in joint session for the first half of October 12.
+ They then split into three groups. The first group considered the
+ "distributed database" problem which has arisen over and over again
+ in the design of parts of the Internet. The two other groups met to
+ consider a list of issues pertaining to the information
+ infrastructure. The groups ran independently until the morning of
+ October 14, when they met again in joint session.
+
+ The following people attended the workshop:
+
+ Abel Weinrib abel@bellcore.com
+
+ Barry Leiner BLeiner@ARPA.MIL
+
+ Cecilia Preston cpreston@info.berkeley.edu
+
+ Chris Weider clw@bunyip.com
+
+ Christian Huitema Christian.Huitema@SOPHIA.INRIA.FR
+
+ Cliff Lynch calur@uccmvsa.ucop.edu
+
+ Clifford Neuman bcn@isi.edu
+
+ Dan LaLiberte liberte@ncsa.uiuc.edu
+
+ Dave Sincoskie sincos@THUMPER.BELLCORE.COM
+
+ Elise Gerich epg@MERIT.EDU
+
+ Erik Huizer Erik.Huizer@SURFnet.nl
+
+ Jill Foster Jill.Foster@newcastle.ac.uk
+
+ John Curran jcurran@near.net
+
+ John Klensin klensin@infoods.mit.edu
+
+ John Romkey romkey@asylum.sf.ca.us
+
+ Joyce Reynolds jkrey@isi.edu
+
+
+
+
+McCahill, et al Informational [Page 25]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+ Karen Sollins sollins@lcs.mit.edu
+
+ Larry Masinter masinter@parc.xerox.com
+
+ Lixia Zhang LIXIA@PARC.XEROX.COM
+
+ Mark McCahill mpm@boombox.micro.umn.edu
+
+ Michael Mealling Michael.Mealling@oit.gatech.edu
+
+ Mitchell Charity mcharity@lcs.mit.edu
+
+ Mike Schwartz schwartz@cs.colorado.edu
+
+ Mike St. Johns stjohns@DARPA.MIL
+
+ Mitra mitra@pandora.sf.ca.us
+
+ Paul Mockapetris pvm@zephyr.isi.edu
+
+ Steve Crocker Crocker@TIS.COM
+
+ Tim Berners-Lee tbl@info.cern.ch
+
+ Ton Verschuren Ton.Verschuren@surfnet.nl
+
+ Yakov Rekhter yakov@WATSON.IBM.COM
+
+Security Considerations
+
+ This memo discusses certain aspects of security and the information
+ infrastructure. It contains general recommendations about security
+ enhancements required by information applications on the Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+McCahill, et al Informational [Page 26]
+
+RFC 1862 IAB Workshop Report November 1995
+
+
+Authors' Addresses
+
+ Mark McCahill
+ University of Minnesota
+ room 190 Shepherd Labs
+ 100 Union Street SE
+ Minneapolis, MN 55455
+ EMail: mpm@boombox.micro.umn.edu
+
+
+ John Romkey [Editor]
+ 1770 Massachusetts Ave. #331
+ Cambridge, MA 02140
+ EMail: romkey@apocalypse.org
+
+
+ Michael F. Schwartz
+ Department of Computer Science
+ University of Colorado
+ Boulder, CO 80309-0430
+ EMail: schwartz@cs.colorado.edu
+
+
+ Karen Sollins
+ MIT Laboratory for Computer Science
+ 545 Technology Square
+ Cambridge, MA 02139-1986
+ EMail: sollins@lcs.mit.edu
+
+
+ Ton Verschuren
+ SURFNet
+ P.O. Box 19035
+ 3501 DA Utrecht
+ The Netherlands
+ EMail: Ton.Verschuren@surfnet.nl
+
+
+ Chris Weider
+ Bunyip Information Systems
+ 310 St. Catherine St. West
+ Suite 300
+ Montreal, PQ H2A 2X1
+ CANADA
+ EMail: clw@bunyip.com
+
+
+
+
+
+
+McCahill, et al Informational [Page 27]
+