FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS
FIPA Policies and Domains
Request For Information
|
Document title |
FIPA Policies and Domains Request For Information |
||
|
Document number |
f-out-00080 |
Document source |
FIPA Architecture TC |
|
Document status |
Preliminary |
Date of this status |
2001/02/01 |
|
Submissions due by |
2001/04/02 |
||
|
Contact |
arch@fipa.org |
||
|
Change history |
|||
|
2001/01/30 |
Initial draft |
||
|
2001/02/01 |
Additional material |
||
© 2000 Foundation for Intelligent Physical Agents - http://www.fipa.org/
Geneva, Switzerland
|
Notice |
|
Use of the technologies described in FIPA's specifications may infringe patents, copyrights or other intellectual property rights of FIPA Members and non-members. Nothing in this document should be construed as granting permission to use any of the technologies described. Anyone planning to make use of technology covered by the intellectual property rights of others should first obtain permission from the holder(s) of the rights. FIPA strongly encourages anyone implementing any part of FIPA's specification to determine first whether part(s) sought to be implemented are covered by the intellectual property of others, and, if so, to obtain appropriate licenses or other permission from the holder(s) of such intellectual property prior to implementation. This document is subject to change without notice. Neither FIPA nor any of its Members accept any responsibility whatsoever for damages or liability, direct or consequential, which may result from the use of FIPA's specifications. |
Foreword
The Foundation for Intelligent Physical Agents (FIPA) is an international organization that is dedicated to promoting the industry of intelligent agents by openly developing specifications supporting interoperability among agents and agent-based applications. This occurs through open collaboration among its member organizations, which are companies and universities that are active in the field of agents. FIPA makes the results of its activities available to all interested parties and intends to contribute its results to the appropriate formal standards bodies.
The members of FIPA are individually and collectively committed to open competition in the development of agent-based applications, services and equipment. Membership in FIPA is open to any corporation and individual firm, partnership, governmental body or international organization without restriction. In particular, members are not bound to implement or use specific agent-based standards, recommendations and FIPA specifications by virtue of their participation in FIPA.
The FIPA specifications are developed through direct involvement of the FIPA membership. The status of a specification can be either Preliminary, Experimental, Standard, Deprecated or Obsolete.More detail about the process of specification may be found in the FIPA Procedures for Technical Work. A complete overview of the FIPA specifications and their current status may be found in the FIPA List of Specifications. A list of terms and abbreviations used in the FIPA specifications may be found in the FIPA Glossary.
FIPA is a non-profit association registered in Geneva, Switzerland. As of January 2000, the 56 members of FIPA represented 17countries worldwide. Further information about FIPA as an organization, membership information, FIPA specifications and upcoming meetings may be found at http://www.fipa.org/.
Contents
4.1.3 Completeness of Submissions
4.2 Confidential and Proprietary Information
5 General Requirements for Submissions
6 Specific Requirements for Information
6.1 Relationship to Existing FIPA Specifications
Action
A basic construct representing some activity an agent may perform. A special class of actions is the communicative acts.
Agent
An agent is the fundamental actor in a domain. It combines one or more service capabilities into a unified and integrated execution model that can include access to third party software, human users and communication facilities.
Agent Communication Language
A language with precisely defined syntax, semantics and pragmatics that is the basis of communication between independently designed and developed software agents.
Agent Platform
Provides an infrastructure in which agents can be deployed. An agent must be registered on a platform in order to interact with agents on that or other Agent Platforms.
Communicative Act
A special class of actions that correspond to the basic building blocks of dialogue between agents. A communicative act has a well-defined, declarative meaning independent of the content of any given act. Communicative acts are modelled on speech act theory.
Content
That part of a communicative act which represents the domain dependent component of the communication. Note that "the content of a message" does not refer to "everything within the message, including the delimiters", as it does in some languages, but rather specifically to the domain specific component. In the Agent Communication Language semantic model, a content expression may be composed from propositions, actions or Identifying Referring Expressions.
Content Language
The content of a FIPA message refers to whatever the communicative act applies. If, in general terms, the communicative act is considered as a sentence, then the content is the grammatical object of the sentence. This content can be encoded in any language, called the content language.
Conversation
An ongoing sequence of communicative acts exchanged between two (or more) agents relating to some ongoing topic of discourse. A conversation may (perhaps implicitly) accumulate context that is used to determine the meaning of later messages in the conversation.
Directory Service
That part of the Agent Platform providing a yellow pages directory service for agents. It stores descriptions of the agents and the services they offer.
Interaction Protocol
A common pattern of conversations used to perform some generally useful task. An interaction protocol is often used to facilitate a simplification of the computational machinery needed to support a given dialogue task between two agents.
Message
An individual unit of communication between two or more agents. A message corresponds to a communicative act, in the sense that a message encodes the communicative act for reliable transmission between agents. Note that communicative acts can be recursively composed, so while the outermost act is directly encoded by the message, taken as a whole a given message may represent multiple individual communicative acts.
Message Transport Service
A service provided by an Agent Platform. The Message Transport Service supports the transportation of Agent Communication Language messages between agents.
Ontology
An explicit specification of the structure of a certain domain (for example, e-commerce, sport, etc.). For the practical goals of FIPA (that is enabling development and deployment of inter-operable agent-based applications), this includes a vocabulary (that is, a list of logical constants and predicate symbols) for referring to the subject area and a set of logical statements expressing the constraints existing in the domain and restricting the interpretation of the vocabulary. Ontologies therefore provide a vocabulary for representing and communicating knowledge about some topic and a set of relationships and properties that hold for the entities denoted by that vocabulary.
Ontology Name
The ontologies referred to by agents that can be provided by different ontology servers. Consequently, these ontology names are constructed from the ontology agent name and the ontology logical name (given by the ontology designer, for example, "car").
The main objective of this Request For Information is to obtain information, which will allow FIPA to establish a specification document in the area of policies and domains. The document will form a logical extension to the FIPA Abstract Architecture specification [FIPA00001]. Submissions shall address one or more of the following issues:
· To define a taxonomy of policy types.
· To define requirements on the representation of policies and policy languages.
· To define the mechanisms necessary to support policies.
· To identify appropriate use cases to highlight policy issues.
The basic services offered by an agent platform to an agent are unconstrained. An agent may register any attributes that it chooses through the agent Directory Service; it may use the agent Message Transport Service to communicate with any reachable agent using any available transport and messages of any size or encoding, and it may operate on behalf of any principal.
In practice, however, developers and users of multi-agent systems often wish to place strong constraints on the behavior of agents within agent environments. This especially means being able to apply and enforce these constraints and policies across distributed agents and systems.
Typical constraints that we may wish to enforce include:
· Requiring that an agent use a particular encoding for its messages.
· Preventing an agent from communicating with non-local agents (agents which lie outside some domain, in the transport addressing sense of the word).
· Requiring than an agent selects a particular quality of service (e.g. transport) when communicating with non-local agents.
· Preventing an agent from registering certain attributes with the Agent Directory Service unless it is operating on behalf of a particular principal.
· Limiting the total number of agents registered with a platform.
· Restricting access to certain host directories or setting ceilings on the amount of system resources that can be used.
All of these constraints may be expressed as constraints over agent platform services. There may be other types of constraint that we wish to apply to an agent X for example, requiring the use of a particular conversation policy when interacting with a particular class of agent, or preventing an agent from transmitting confidential data to a non-local agent X but these lie outside the scope of this specification.
FIPA is therefore issuing a RFI, or Request For Information, in which individuals and organizations with expertise in policies and domains and related fields are invited to submit responses to some or all of the relevant issues. In Section 5 we identify the specific points we wish to address, together with a series of scenarios that demonstrate the contextual relationship to agent systems.
Submissions can address some or all of the issues identified and should indicate explicitly which areas are being addressed. We also invite submitters to comment on the relevance of their submission to given scenarios, and to offer additional scenarios where appropriate.
See Table 2 in Section 6.7, Timetable for submission deadlines.
A submitter may respond to any or all parts of this RFI as conjunctive or independent documents. The FIPA Policies and Domains TC will evaluate each submission independently.
Submissions for each separate response item need not be complete. However, reasons for not being complete must be clearly stated.
The FIPA specification adoption process is an open process. Responses to this RFI become public documents of the FIPA organisation and are available to members and non-members alike for perusal and comment. No confidentiality or proprietary information of any kind will be accepted in a submission to this RFI.
This section provides guidance on how to structure a submission.
· Submissions must be written in English.
· Submissions should be concise and easy to read.
· Submitted documentation should be directly relevant to the technology requested in the RFI.
· The file format of the submissions should be one of plain text, HTML, PDF, Microsoft Word or PostScript.
A two-part structure for a submission is suggested:
PART I
· Submission contact point, including name, postal address, affiliation, email address, telephone number, fax number.
· Completeness of the submission (see Section 4.1.3, Completeness ).
· Overview of the submission.
PART II
· Submission content.
Submitters should send an electronic version of their submission to the FIPA Secretariat (secretariat@fipa.org) and the FIPA Architecture Technical Committee mailing list (arch@fipa.org).
Feedback on submissions will be provided in accordance with the timescales shown in Table 2. The response will be sent to the email address provided by the submitter.
Submissions should not conflict with any existing FIPA specifications, particularly those given in Table 1.
Note the following when writing a submission:
· Submissions should indicate which of the areas identified in Section 6, Specific Requirements for Information they are addressing.
· Submissions must maintain an abstract perspective, unless aiming to be informative through highlighting implementation requirements.
· Any conflictions must be clearly identified, along with reasons for them.
· The use of UML modelling is desirable where appropriate, but not mandatory.
· Submissions shall indicate the current status of the submitted work, i.e. theoretical, experimental, operational, etc.
· Submissions shall reference relevant and related work.
Submissions shall describe policy and domain solutions that cover issues in one or more of the following areas:
· The definition of one or more Agent Service Policies in terms of their defining set of constraints.
· The declarative and propositional requirements on policy languages based on the semantics of the policy types.
· The definition of one or more appropriate system mechanisms to support Agent Service Policies:
- Mechanisms for policy enforcement.
- Mechanisms for policy conflict identification and resolution.
- Mechanisms for responding to policy exceptions, including:
§ Mechanisms for sanctions: remedies and rewards arising from policy exceptions.
- Mechanisms for managing policies, including lifecycle.
- Mechanisms for interpreting policies.
· The definition of appropriate communicative acts and interaction protocols.
· The identification of appropriate use cases that highlight relevant policy issues.
· Example policy architectures.
· Solicitation of comments on ontologies.
· Solicitation of comments on security aspects of policy distribution and enforcement.
· Solicitation of comments on the FIPA Policies and Domains Specification (see [FIPA00089]).
Before examining each of these, we consider the relevance and relationship to existing FIPA specifications.
We are only concerned with policies that are public, i.e., accessible to systems, machine readable, i.e., can be processed by computer systems and in particular declarative, i.e., amenable to inference.
To date we assume two fundamental kinds of policy constraints: those relating to permissions and those relating to obligations. These policies are often related in that by entering into particular obligations an agent may acquire specific permissions, and vice versa, when an agent is given permission to access a shared resource, it may incur obligations as a result. Not all platforms require or employ both kinds of policies; however the emerging specification will describe architectural elements relevant to both forms.
This RFI invites submissions that highlight the semantics of the existing obligation and permission policy types and that propose additional or alternative models and associated mechanisms.
Table 1 identifies existing FIPA Specifications that have a relationship to technologies requested in this RFI. All the specifications can be retrieved from http://www.fipa.org/specs/.
|
Specification Number |
Title |
|
FIPA00001 |
FIPA Abstract Architecture Specification |
|
FIPA00025 |
FIPA Interaction Protocol Library Specification |
|
FIPA00037 |
FIPA Communicative Act Library Specification |
|
FIPA00089 |
FIPA Policies and Domains Specification |
Table 1: Referenced Relevant FIPA Specifications
Damianou, N., Dulay, D., Lupu, E., Sloman, M., 'Ponder: A Language for Specifying Security and Management Policies for Distributed Systems'. Imperial College Research Report DoC 2000/1, http://www-dse.doc.ic.ac.uk/policies.
None.
None.
Submissions should discuss potential impact on FIPA specifications.
Submitters may be invited to give presentations of material to TC Architecture at the London meeting (2001-04-02).
The timetable for this RFI is given in Table 2. Note that FIPA may, in certain circumstances, extend deadlines while the RFI is running, or may elect to have more than one revised submission step.
|
Action |
Latest Date |
|
Electronic receipt of material |
2001/03/10 |
|
Acknowledgement of submission |
2001/03/16 |
|
FIPA Architecture TC reviews submissions at London |
2001/04/06 |
Table 2: Timescales