rfc2016.txt

RFC 的详细文档！

Network Working Group                                          L. Daigle
Request for Comments: 2016                                    P. Deutsch
Category: Experimental                                         B. Heelan
                                                              C. Alpaugh
                                                           M. Maclachlan
                                        Bunyip Information Systems, Inc.
                                                            October 1996

                     Uniform Resource Agents (URAs)

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This paper presents an experimental architecture for an agent system
   that provides sophisticated Internet information access and
   management.  Not a generalized architecture for active objects that
   roam the Internet, these agents are modeled as extensions of existing
   pieces of the Internet information infrastructure.  This experimental
   agent technology focuses on the necessary information structures to
   encapsulate Internet activities into objects that can be activated,
   transformed, and combined into larger structured activities.

Acknowledgements

   Several people have shared thoughts and viewpoints that have helped
   shape the thinking behind this work over the past few years.  We'd
   like to thank, in particular, Chris Weider, Patrik Faltstrom, Michael
   Mealling, Alan Emtage, and the participants in the IETF URI Working
   Group for many thought-provoking discussions.

   Sima Newell provided insightful comments on the document -- thanks to
   her it is much more readable!

Introduction

   This document outlines an experimental agent system architecture that
   was designed for the purpose of addressing high-level Internet
   activities through encapsulation of protocol-specific actions.
   Originally presented to the Uniform Resource Identifier (URI) working
   group at the IETF, this technology was seen as taking a step beyond
   resource location and resource naming.  By providing a structured
   mechanism for abstracting characteristics of desired information and



Daigle, et. al.               Experimental                      [Page 1]

RFC 2016                Uniform Resource Agents             October 1996


   distancing the necessary access incantations from the client, the
   notion of a Uniform Resource Agent (URA) was created.

   The evolution of Internet information systems has been characterized
   by building upon successive layers of encapsulated technologies.
   Machine address numbers were devised, and then encapsulated in
   advertised machine names, which has allowed the evolution of the
   Domain Name System (DNS) [RFC1034, RFC1035].  Protocols were
   developed for accessing Internet resources of various descriptions,
   and then uniform mechanisms for specifying resource locations,
   standardized across protocol types, were developed (URLs) [RFC1738].
   Each layer of Internet information primitives has served as the
   building blocks for the next level of abstraction and sophistication
   of information access, location, discovery and management.

   The work described in this paper is an experimental system designed
   to take another step in encapsulation.  While TCP/IP protocols for
   routing, addressing, etc, have permitted the connection and
   accessibility of a plethora of information services on the Internet,
   these must yet be considered a diverse collection of heterogeneous
   resources.  The World Wide Web effort is the most successful to date
   in attempting to knit these resources into a cohesive whole.
   However, the activity best-supported by this structure is (human)
   browsing of these resources as documents.  The URA initiative
   explores the possibility of specifying an activity with the same kind
   of precision accorded to resource naming and identification.  By
   focusing on activities, and not actions, URAs encapsulate resource
   access mechanisms based on commonality of information content, not
   protocol similarity.

   An invoker -- human or otherwise -- may delegate an entire set of
   tasks to a fully-instantiated URA.  The nature of the tasks is
   completely specified by the agent, because it encapsulates knowledge
   about relevant Internet resources and the information required in
   order to access them.  In this way, URAs insulate invokers from the
   details of Internet protocols while allowing them to carry out high-
   level Internet activities (such as searching a set of web pages and
   news groups relevant to a given topic).  Also, by formally specifying
   a high-level Internet activity in an agent, the same activity can be
   repeated at a later date by the same invoker, someone else or even
   another agent. Moreover, the agent object may easily be modified to
   carry out another related task.

   More detail describing the underlying philosophy of this particular
   approach can be found in [IIAW95].






Daigle, et. al.               Experimental                      [Page 2]

RFC 2016                Uniform Resource Agents             October 1996


Examples

   As a very simple example, consider the client task of subscribing to
   a mailing list.  There are many mechanisms for providing users with
   information necessary to complete a subscription.  Currently, all
   applications which provide the ability to subscribe to mailing lists
   must contain protocol-aware code to carry out the task once the
   requisite personal data has been solicited from the user.
   Furthermore, any application program that embeds the ability to
   subscribe in its code necessarily limits the set of mailing lists to
   which a client can subscribe (i.e, to those types foreseen by the
   software's creators).  If, instead, there is an agent to which this
   task can be delegated, all applications can make use of the agent,
   and that agent becomes responsible for carrying out the necessary
   interactions to complete the subscription.  Furthermore, that agent
   may be a client to other agents which can supply particular
   information about how to subscribe to new types of mail servers, etc.
   URAs have been explored as an agent technology to address just these
   types of issues.

Relationship to Other Internet Agents

   A number of Internet-aware agent and transportable code systems have
   become popular -- Java [JAVA], TCL [TCL] and Safe-TCL, Telescript
   [TELE], and the TACOMA system [TACOMA], to name a few of them.  To
   understand the scope of the problem that URAs tackle, it is helpful
   to understand how these systems differ from the URA approach.  Some
   of these agent systems, like Java, focus on providing mechanisms for
   creating and distributing (inter)active documents in the World Wide
   Web.  Others, like TACOMA, have more general intentions of providing
   environments for mobile, interacting processes.

   While each of these systems makes its individual contribution to
   solving the transportation, communication, and security issues
   normally associated with agent systems, they yield more objects that
   exist within the Internet information space.  That is, while they may
   permit individual users to have a more sophisticated interaction with
   a particular information resource, they do not address the more
   general Internet problems of naming, identifying, locating resources,
   and locating the same or similar resources again at a later date. It
   is this set of problems that URAs specifically set out to address.

   In order to create these URA objects that encapsulate a set of
   Internet activities, it is necessary to specify their operating
   environment and design structure.  Together, these form an
   experimental architecture for URAs, which can be evaluated in a
   preliminary way through a prototype implementation. The remainder of
   this paper describes such an experimental architecture, and outlines



Daigle, et. al.               Experimental                      [Page 3]

RFC 2016                Uniform Resource Agents             October 1996


   a prototype application built to test the concepts involved in the
   creation and execution of URAs.

The Experimental Architecture

   The main goal in designing the URA architecture was to provide a
   mechanism for separating client need descriptions from the
   specifications of mechanisms for satisfying those needs.  For
   example, from the client's perspective, the need to find MIDI music
   files is quite distinct from the particular Internet resource actions
   that might be necessary to find them at a given point in time.  This
   one need might be best met by integrating information from several
   very different sources.  Also, the client may have the same need on a
   different day, but there may be new or different resources to call on
   to satisfy it.

   A further goal was to provide very structured specifications of the
   Internet actions carried out by a particular URA.  By making the
   structure of an action explicit, it becomes possible to operate on
   portions of an agent structure without requiring an understanding of
   the complete semantics of its activity.

   At the centre of the URA architecture is the concept of a
   (persistent) specification of an activity.  For purposes that should
   become clear as the expected usage of URAs is described in more
   detail, we choose to support this concept with the following
   requirements of the architecture:

   - there is a formalized environment in which these specifications
     are examined and executed and otherwise manipulated.  This is
     referred to as a URAgency.

   - the activity specifications are modular, and independent of a
     given URAgency environment.  Thus, they exist as object constructs
     that can be shared amongst URAgencies.  There is a standardized
     _virtual_ structure of these URA objects, although different
     types may exist, with different underlying implementations.

Basic URAgency Requirements

   In the most abstract sense, a URAgency is a software system that
   manipulates URA objects.  In the terminology of objects, a URAgency
   identifies the types of URAs it handles, and is responsible for
   applying methods to objects of those types.  For the purposes of this
   experimental work, the only methods it is required to support are
   those to get information about a given URA, and to execute a URA.





Daigle, et. al.               Experimental                      [Page 4]

RFC 2016                Uniform Resource Agents             October 1996


   The expected result of applying the "get information" method to a URA
   is a description of some or all of the URA following the standardized
   virtual structure of a URA object, outlined below.

   The appropriate way to "execute" a URA is to supply information for
   the individual URA data segments (in effect, to permit the creation
   of an instance of a virtual object), or to identify a URA instance.
   Again, the information is to be supplied in accordance with the
   virtual structure below.

   A URAgency claiming to handle a particular type of URA must have the
   ability to map the implementation structure of that type of URA into
   and out of the standard virtual URA structure. The URAgency must also
   know how to activate the URA, and it must satisfy any runtime
   dependencies for that type of URA.

   For example, a URA type may consist of a Pascal program binary which,
   when run with particular command line arguments, yields information
   in the standard URA object structure.  Activating this type of URA
   might consist of executing the Pascal binary with an input file
   containing all the necessary data segments.  A URAgency claiming to
   handle this sort of URA type must first be able to provide an
   environment to execute the Pascal binary (for whatever platform it
   was compiled), and also be able to interact with the Pascal binary
   according to these conventions to get information about the URA, or
   execute it.

   As an alternative example, a URA type may consist of a script in some
   interpreted language, with the URA object structure embedded as data
   structures within the script.  A URAgency handling this type of URA
   might have to be able to parse the script to pull out the standard
   URA object structure, and provide the script language interpreter for
   the purposes of executing the URA.

URA Object Structure

   In order to capture the necessary information for carrying out the
   type of Internet activity described in the introductory paragraphs of
   this document, six basic (virtual) components of a URA object have
   been identified.  Any implementation of a URA type is expected to be
   able to conform to this structure within the context of a URAgency.

   The six basic components of a URA object are:

URA HEADER:
        Identification of the URA object, including a URA name, type
        and abstract, creator name, and the resources required by the
        URA.



Daigle, et. al.               Experimental                      [Page 5]

RFC 2016                Uniform Resource Agents             October 1996


ACTIVATION DATA:
        Specification of the data elements required to carry out the
        URA activity.  For example, in the case of an Internet search
        for "people", this could include specification of fields for
        person name, organization, e-mail address.

TARGETS:
        Specification of the URL/URN's to be accessed to carry out the
        activity.  Note that, until URN's are in common use, the
        ability to adjust URLs will be necessary.  A key issue for
        URAs is the ability to transport them and activate them far
        from the creator's originating site.  This may have
        implications in terms of accessibility of resource sites.  For
        example, a software search created in Canada will likely
        access a Canadian Archie server, and North American ftp sites.
        However, an invoker in Australia should not be obliged to edit
        the URA object in order to render it relevant in Australia.
        The creator, then, can use this section to specify the
        expected type of service, with variables for the parts
        that can be modified in context (e.g., the host name for an
        Archie server, or a mirror ftp site).

EXPERIENCE INFORMATION:
        Specification of data elements that are not strictly involved
        in conversing with the targets in order to carry out the
        agent's activity.  This space can be used to store information
        from one invocation of a URA instance to the next.
        This kind of information could include date of last
        execution, or URLs of resources located on a previous
        invocation of the agent.

ACTIVITY:
        If URAs were strictly data objects, specifying required data
        and URL/URN's would suffice to capture the essence of the
        composite net interaction.  However, the variability of
        Internet resource accesses and the scope of what URAs could
        accomplish in the net environment seem to suggest the need to
        give the creator some means of organizing the instantiation of
        the component URL/URN's.  Thus, the body of the URA should
        contain a scripting mechanism that minimally allows
        conditional instantiation of individual URL/URN's.  These
        conditions could be based on which (content) data elements the
        user provided, or accessibility of one URL/URN, etc.  It also
        provides a mechanism for suggesting scheduling of URL/URN
        instantiation.






Daigle, et. al.               Experimental                      [Page 6]

RFC 2016                Uniform Resource Agents             October 1996


        The activity is specified by a script or program in a language
        specified by the URA type, or by the URA header information.
        All the required activation data, targets, and experience
        information are referenced by their specification names.

RESPONSE FILTER:
        The main purpose of the ACTIVITY module is to specify the
        steps necessary to take the ACTIVATION DATA, contact the
        TARGETS, and collect responses from those services.  The
        purpose of the RESPONSE FILTER module is to transform those
        responses into the result of the URA invocation.  This
        transformation may be along the lines of reformatting
        some text, or it may be a more elaborate interpretation
        such as a relevance rating for a retrieved HTML page.

        The response filter is specified by a script or program in a
        language specified by the URA type, or by the URA header
        information.  All the required activation data, targets, and
        experience information are referenced by their specification
        names.

   See Appendix 1 for a more detailed description of the components of a
   URA.  Appendix 2 contains a sample virtual URA structure.

The Architecture in Action

   Having introduced the required capabilities of the URAgency and
   virtual structure of URA objects, it is now time to elaborate on the
   tasks and interactions that are best supported by URAs.

   URAs are constructed by identifying net-based resources of interest
   (targets) to carry out a particular task.  The activation data
   component of a URA is the author's mechanism for specifying (to the
   invoker) the elements of information that are required for successful
   execution .  An invoker creates an instance of a URA object by
   providing data that is consistent with, or fills in, this template.
   Such an instance encapsulates everything that the agent "needs to
   know" in order to contact the specified target(s), make a request of
   the resource ("get", "search", etc.) and return a result to the
   invoker.  This encapsulation is a sophisticated identification of the
   task results.

   For example, in the case of a mailing list subscription URA, the
   creator will identify the target URL for a resource that handles list
   subscription (e.g., an HTML form), and specify the data required by
   that resource (such as user name, user mail address, and mailing list
   identifier).  When an invoker provides that information and
   instantiates the URA, the resulting object completely encapsulates



Daigle, et. al.               Experimental                      [Page 7]