rfc1862.txt

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

   * 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