doc: Add RFC documents

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]
+