FIPA’s Fifth Call for Proposals

Executive summary

The Fifth Call for Proposals of the Foundation for Intelligent Physical Agents (FIPA) is an invitation to submit proposals for technologies to be used in extending the FIPA 97 and 98 specifications as well as creating new specifications for agent-based applications, services and equipment.

These proposed technologies are intended to be utilized in the development of specifications of component technologies that may be used by application developers. Specification development is to be completed by October, 1999.

1. Introduction

Rapid developments in agent technology are creating conditions for the deployment of applications, services, and products that are attractive to users by virtue of their ability to offer improved functionalities compared to those of existing technologies. FIPA has been established to promote a larger deployment of interoperable agent systems. This is accomplished through the standardization of component technologies that may be used by application developers across a wide variety of applications and providing a high level of interoperability across those applications. Currently, FIPA has produced two sets of specifications whose field trials are being carried out by FIPA members since early 1998.

FIPA has so far provided four reference applications on which FIPA normative specifications can be tested during the field trials. (A fifth application is currently under preparation and will appear early in 1999.) Clearly the wider community that has been following the work taking place in FIPA (and at whom this call is aimed), has an interest in many more applications of the kind of intelligent software agent technology than those targetted by FIPA. FIPA needs to be made aware of such additional applications areas for two reasons. Firstly, FIPA is aware that the specifications have a much wider applicability and so FIPA work can be of service to a correspondingly wider commercial community. Secondly because FIPA members are also aware that there are applications of intelligent software agents that have additional requirements (for example, where the applications have real-time constraints) that need appropriate extensions. It would obviously be beneficial to produce such extensions in a manner that is consistent with the specifications that have been produced so far.

It should be realized, however, that FIPA is not attempting to specify applications but only uses models of existing or possible applications to identify and assist in specifying the agent component technologies required to implement them. This enables the assembly of applications which would not have otherwise been feasible without standardization.

FIPA members are of the opinion that the current specifications are already a great advance and a remarkable achievement for two years' effort. FIPA has therefore resolved to continue its activities and launch a new initiative for a further standardization effort. The FIPA specifications themselves are perceived to be valuable in building commercial level applications. However, in the course of producing the various parts of these specifications the members have felt that there are additional items on which FIPA can begin a consensus forming work on in 1999 using its well proven FIPA process. The purpose of this call is to define and explain these additional items. This is given in Chapter 4 of this call.

Those intending to submit a proposal(s) should consult Chapter 5 of this Call for Proposals.

FIPA is concerned only with specifications of interfaces and protocols associated with component technologies, but it may nevertheless be necessary to be made aware of certain technological solutions and to understand their technical operations sufficiently for the purpose of accurately capturing their operation as a ‘black box’ specification.

It is the intention to have the FIPA specifications considered by formal standards bodies for endorsement wherever appropriate.

FIPA meetings may be attended by member institutions only, however, organization who have submitted proposals but are not FIPA members will be allowed and invited to attend the January 1999 meeting for the purpose of introducing their proposals.

FIPA is an open organization and expressly encourages any entity to become a member. Inquiries on membership should be directed to the address given in Chapter 5.

The new FIPA homepage

http://www.fipa.org

includes further details about FIPA, including the FIPA process, governing statutes and the application for membership.

While FIPA plans to have a series of Calls for Proposals concerning different aspects of agent technology, there is currently no plan to have a further call on the specific subject of this document. Therefore, proponents should ensure that their contributions are submitted during this opportunity and comply with the deadlines specified. However, FIPA recognizes the evolution of technology and plans to issue further Calls for Proposals in order to:

1. extend the range of applications supported by specification of new technologies, and
2. update previously specified technology as new technology matures.

An outline of the FIPA '99 specifications, based on the submissions received, will be produced at the12^th meeting in January 1999. First and second drafts will be produced at the following two meetings, and a final specification approved and issued at the 15^th meeting in October 1999. While FIPA intends to work by consensus, this very aggressive schedule may require the use of membership voting. It is possible that the 1999 output will be output in two separate phases, one affecting the informative application-specific specifications and the other affecting the normative technological specifications.

2. Structure of this Call for Proposals

Unlike other bodies which issue specifications targeted to specific applications, FIPA only uses applications for the purpose of identifying requirements for component technologies ("tools" in FIPA language) that are needed to implement the applications. This approach makes it possible to use standardized tools for building applications serving different needs with a high degree of interoperability. This point must be borne in mind to understand the structure of the document.

Chapter 3 provides the background to this call. FIPA has recently completed its second set of specifications and most of the items of this call arise from the work that has been carried out so far in FIPA.

Chapter 4 contains the list of component technologies that are the target of this call. This has been produced based on experience gained so far within FIPA, and considerations of future needs.

Chapter 5 presents the guideline for responding to this call.

3. Background to the Third Call

The two FIPA specifications of October 1997 and October 1998 form the starting point for this call. This chapter gives the summary of the FIPA Specifications and the scope beyond it. The full document of the FIPA specifications can be obtained from the FIPA home page: http://www.fipa.org

3.1 Summary of the FIPA Specifications

The FIPA specification is the main output of FIPA. It is again important to appreciate that these specifications do not provide means to address the requirements for all kinds of software agents. They satisfy the requirements for the four applications targetted by FIPA so far. These applications appear in parts 4, 5, 6, and 7 of the FIPA 97 specifications. Work has started in 1998 on a fifth application concerning manufacturing, this specification is expected to appear early 1999.

Furthermore, FIPA does not define a software agent. What FIPA members understand by a software agent is implicit in how they intend to use them as is described in the specifications of these five applications. However, FIPA expects that what will fit the needs of these five applications will also extend to agents to be deployed in other applications; and, that these provide the specifications of basic agent technologies that can be integrated by agent systems developers to make their own complex systems with a high degree of interoperability.

FIPA specifies the interfaces of the different components in the environment with which an agent can interact, i.e. humans, other agents, non-agent software and the physical world. FIPA produces two kinds of specification:

• normative specifications that mandate the external behavior of an agent and ensure interoperability with other FIPA-specified subsystems;
• informative specifications of applications for guidance to industry on the use of FIPA technologies.

The current set of specifications has twelve parts:

• seven normative parts for basic agent technologies: Agent Management (1); Agent Communication Language (2); Agent/Software Integration (3); Human Agent Interaction (8); Agent Security (10); Agent Mobility (11); and, Agent Ontology Services (12).
• four informative application descriptions that provide examples of how the normative items can be applied: Personal Travel Assistance (4); Personal Assistant (5); Audio-Visual Entertainment and Broadcasting (6); and Network Management and Provisioning (7).
• One guide to aid the developers (13).

Overall, these seven FIPA technologies allow:

• the construction and management of an agent system composed of different agents, possibly built by different developers; (1)
• agents to communicate and interact with each other to achieve individual or common goals; (2)
• legacy software or new non-agent software systems to be used by agents; (3)
• means by which agents may interact with humans in a consistent manner; (8)
• the interactions within an agent community to take place in a secure manner given that the community of agents will be open; (10)
• the agents or parts thereof to be mobile with respect to the hardware platforms; (11) and,
• the services needed to provide uniform ontologies within an open community of agents operating in a given applications (12).

In October 1997, FIPA released its first set of specifications, called FIPA 97, Version 1.0. During 1998, comments on this specification were received. Based upon these comments, parts of FIPA 97 were superseded by a second version released in October 1998, introducing minor changes only.

Furthermore, in October 1998 FIPA released a new set of specifications, called FIPA 98, version 1.0, of which this document is a part.

The following tables provide an overview of the complete set of FIPA specifications.

Sorted by part:

N == normative; I == informative; M == methodology; Italicised == superseded

Sorted by topic:

The parts of the FIPA 97 and 98 specifications are briefly described below.

Part 1 - Agent Management

This part provides a normative framework within which FIPA compliant agents can exist, operate and be managed. It defines an agent platform reference model containing such capabilities as white and yellow pages, message routing and life-cycle management. True to the FIPA approach, these capabilities are themselves intelligent agents using formally sound communicative acts based on special message sets. An appropriate ontology and content language allows agents to discover each other’s capabilities.

Part 2 - Agent Communication Language

The FIPA Agent Communication Language (ACL) is based on speech act theory: messages are actions, or communicative acts, as they are intended to perform some action by virtue of being sent. The specification consists of a set of message types and the description of their pragmatics, that is the effects on the mental attitudes of the sender and receiver agents. Every communicative act is described with both a narrative form and a formal semantics based on modal logic. The specification includes guidance to users who are already familiar with KQML in order to facilitate migration to the FIPA ACL. The specification also provides the normative description of a set of high-level interaction protocols, including requesting an action, contract net and several kinds of auctions etc.

Part 3 - Agent/Software Integration

This part applies to any other non-agentised software with which agents need to "connect". Such software includes legacy software, conventional database systems, middleware for all manners of interaction including hardware drivers. Because in most significant applications, non-agentised software may dominate software agents, part 3 provides important normative statements. It suggests ways by which Agents may connect to software via "wrappers" including specifications of the wrapper ontology and the software dynamic registration mechanism. For this purpose, an Agent Resource Broker (ARB) service is defined which allows advertisement of non-agent services in the agent domain and management of their use by other agents, such as negotiation of parameters (e.g. cost and priority), authentication and permission.

Part 4 - Personal Travel Assistance

This part demonstrates the use of agent technology in supporting individualised, automated access to travel services by providing informative specifications and examples based on the FIPA normative specifications. Travel services are provided by a heterogeneous range of content providers, brokers, and personalization services. Agents operating on behalf of their users can provide assistance in the pre-trip planning phase, as well as during the on-trip execution phase. A Personal Travel Assistance (PTA) system is composed of agents representing the user, available travel services and brokerage services between the two. The system is responsible for the configuration and delivery - at the right time, cost, Quality of Service, and appropriate security and privacy measures - of trip planning and guidance services.

Part 5 - Personal Assistant

The Personal Assistant (PA) represents a central class of intelligent agents which acts semi-autonomously for and on behalf of a user, modelling the interests of the user and providing services to the user or other people and PAs as and when required. This part provides a specification for managing a user's personal meeting schedule, in particular in determining time and place arrangements for meetings with several participants.

Part 6 - Audio/Video Entertainment & Broadcasting

This part promotes the use of agent technology for effectively negotiating, filtering, and retrieving audio-visual information, in particular for digital broadcasting networks, via collaboration between user agents with content/service provider agents. This allows considering the user’s personal preferences, providing the information in a customized manner, and for keeping the human interaction with the system as simple and intuitive as possible.

Part 7 - Network management & provisioning

Across the world, numerous service providers emerge that combine service elements from different network providers in order to provide a single service to the end customer. The ultimate goal of all parties involved is to find the best deals available in terms of Quality of Service and cost. This part utilizes agent technology to provide dynamic Virtual Private Network (VPN) services where a user wants to set up a multi-media connection with several other users. Agents representing the interests of human users, service providers and network providers facilitate automatic negotiation of appropriate deals and configuration of services at different levels.

Part 8 – Human-Agent Interaction

This part deals with the human-agent interaction part of an agent system. It specifies two agent services: User Dialog Management Service (UDMS) and User Personalization Service (UPS). A UDMS wraps many types of software components for user interfaces allowing for ACL level of interaction between agents and human users. A UPS can maintain user models and supports their construction by either accepting explicit information about the user or by learning from observations of user behavior.

Part 10 – Agent Security Management

Security risks exist throughout agent management: during registration, agent-agent interaction, agent configuration, agent-agent platform interaction, user-agent interaction and agent mobility. The Security Management specification identifies the key security threats in agent management and specifies facilities for securing agent-agent communication via the FIPA agent platform. This specification represents the minimal set of technologies required and is complementary to the existing FIPA 97 and FIPA 98, Part 1 specifications. This part does not mandate every FIPA-compliant agent platform to support agent security management.

Part 11 – Agent Management Support for Mobility

This specification represents a normative framework for supporting software agent mobility using the FIPA agent platform. This framework represents the minimal set of technologies required and is complementary to the existing FIPA 97 and FIPA 98, Part 1 specifications. Wherever possible, it refers to existing standards in this area. The framework supports additional non-mobile agent management operations such as agent configuration. The specification does not mandate that every FIPA-compliant agent platform must support agent mobility, nor does it cover the specific requirements for agents on mobile devices with intermittent connectivity, which is covered by the scope of the existing FIPA Agent Management activity.

Part 12 – Ontology Service

This part deals with technologies enabling agents to manage explicit, declaratively represented ontologies. It specifies an ontology service provided to a community of agents by a dedicated Ontology Agent. It allows for discovering public ontologies in order to access and maintain them; translating expressions between different ontologies and/or different content languages; responding to queries for relationships between terms or between ontologies; and, facilitating identification of a shared ontology for communication between two agents.

The specification deals only with the communicative interface to such a service while internal implementation and capabilities are left to developers. The interaction protocols, communicative acts and, in general, the vocabulary that agents must adopt when using this service are defined. The specification does not mandate the storage format of ontologies, but only the way the ontology service is accessed. However, in order to specify the service, an explicit representation formalism, or meta-ontology, has been specified allowing communication of knowledge between agents.

Part 13 – FIPA 97 Developer's Guide

The Developer’s Guide is meant to be a companion document to the FIPA 97 specifications, and is intended to clarify areas of specific interest and potential confusion. Such areas include issues that span more than one of the normative parts of FIPA 97.

3.2 Beyond the FIPA 97 and 98 Specifications

The specifications produced in 1997 have been undergoing field trials during 1998 and the experience gained from this work has had an important influence both on the revisions that have been produced in 1998 as well as in the production of this call. In other words, the items in this call are based to a good extent after having subjected the FIPA 97 to close scrutiny. Thus, these revisions, deletions, clarifications and extensions are the consequence of the experience being gained.

In particular, the call below is concerned with extensions to be made to the standards produced so far. As interest in FIPA has grown in recent months, so has the desire of both members and non-members to see a range of new items to be included into the FIPA specifications. Many of the items described are of critical significance to the further enhancements to the consensus beginning to appear as a result of FIPA’s activities. It may not be possible to cover all these items in a single year, and FIPA will need to exercise a judgement on what will actually be targetted given the human resources available within FIPA.

4. Technologies requested by this Call for Proposals

4.1 Introduction

This chapter presents the essence of this Call. The following sections describe the areas of technology and applications proposed for specification in 1999.

Any examples and reference solutions given in this chapter are for clarification. FIPA neither requires nor endorses them for use in this call for proposals.

This call is for two distinct types of input. New areas of applications for agent technology which will be strictly informative and serve the purpose of illustrating and testing the agent functionalities being developed by FIPA; and, additional technological specifications which will be normative and constitute a consensus on how agent based systems may be implemented.

4.2 New applications

The following provides the call for new application areas to be developed in the FIPA 99 effort.

4.2.1 Integrated Commerce

Electronic commerce is a major application domain especially for the future exploitation of the Internet. It is also not currently directly addressed by any of FIPA ‘97 Technical Committees (although it was included in the Third Call for Proposals in 1997). Yet electronic commerce appears to be ideally suited for multi-agent and intelligent agent technologies.

Integrated commerce refers to the complete integration of a commercial process—from on-line integrated catalogues to delivery monitoring. Such a concept would facilitate interoperability between organisations on a commercial level through the medium of agents. Of special interest is the possibility of integration between multiple organisations, where information and processing is being shared in a controlled fashion.

Responses to this call should specify how agents can be used in an integrated commerce environment. We expect that a specification would address matters such as:

• Buying and selling of goods and services between agents including tools and technologies for charging, electronic payment, general accounting practices and security.
• Protocols of negotiation that facilitate commerce between agents from different organisations. These include ontological descriptions, representational commitments and other contextual information to permit negotiation.
• Development of market mechanisms to allow agents to trade in a given environment for specific goods or services and to allow characteristics of those goods and services to be identified and reasoned about.
• We believe that in many of these areas, agents in general and FIPA compliant agents in particular, offer significant advantages over other approaches.

Normative Topics

• Mechanisms for establishing trust in an electronic environment (contracts, enforcement, insurance, warranties, goods and service descriptions).
• Security issues (encryption, certificates and signatures, authority and authentication).
• Technologies to support integrated commerce, such as electronic data interchange, digital currency, electronic catalogues and non-repudiation.
• Relationship to other FIPA Specifications, particularly Parts 1, 9 and 10 of FIPA ‘98.

Informative Topics

• Use cases for integrated commerce including retail, banks, publishing, entertainment, travel and automotive industries.
• Legalistic concerns associated with integrated commerce on a global scale (intellectual property, fraud, taxation, digital currencies, contractual settlements and regulatory frameworks).

4.2.2 Communication Assistant

This component of the call for proposals focuses on the theme of providing efficient and effective assistance for human communication. This application area recognizes the pervasive nature of communication, the expanding availability of intelligent telephones and communicators, and the growth in the telecommunications infrastructure.

Modern communication inherently involves a combination of modalities, such as voice, images, and video. A useful assistant would help a user manage those modalities and make the overall process smooth and coherent over a range of telecommunications infrastructure. In particular, it will have a special sensitivity to the issues of mobile telephony, especially low bandwidth, unreliability, and a potentially varying quality of service.

Proposals submitted in response to this call should consider agents applied as communication assistants. Agents can help reconcile the concerns of wireless connectivity with the increasing demands of end-user communicaitons. The following is a representative, but not exclusive, list of topics.

1. Agents to help in managing media scaling in a way that is sensitive to usage, platform, and network characteristics.
2. A bit-efficient syntax for agent communication languages and protocols.
3. Agent middleware to monitor and control underlying communications networks with a focus on recent and upcoming standards such as General Packet Radio Service (GPRS) and Wide-band Code Division Multiple Access (WCDMA).
4. An ontology of resources to be used for the agents to negotiate about platform features, connectivity, quality of service, and so on.
5. Specialized negotiation protocols for use in communication assistance.

4.2.3 Real-time applications

Real time systems with high performance requirements are presently a challenge for all kinds of technologies. The characterisation and objectives/requirements of these systems is highly application dependent, but they may have in common one or more critical issues:

• Rapid response demands
• Fast communication up to the Gbit/s;
• Intensive computation (Fast Decision Mechanisms, Neural Nets, Signal Processing);
• Critical synchronisation;
• Mass storage (up to the Terabyte);

These systems may benefit from agent-based technologies, mainly due to its high degree of adaptability, reactivity, autonomy and intelligence. When using agent-based technologies additional issues have to be integrated. This call for proposals solicits technologies and solutions for agent distributed real-time applications, including but not limited to:

• High-level semantic scene interpretations;
• Agent communication language (control and content semantics, efficient coding);
• Agent management architectures and protocols;
• High-level interaction protocol descriptions and specifications;
• Agent design for distributed security;
• Control and coordenation;
• Deliberative/reactive cooperation/collaboration strategies;
• Integrated Multimodal User/System Interfaces;
• Subsumption architectures;
• Integration of cognitive agents with rapid response time requirements;

A set of possible applications that may take advantage of agent-based technology is (non-exhaustive):

• Surveillance Systems - Today, more than ever, there is a need for effective systems that help humans in video surveillance and/or monitoring tasks. You can have lots of cameras along the main roads of a city (e.g. traffic surveillance) or in a number of critical points of your bank (e.g. security), but normally you do not have enough people to look, analyse, correlate and interpret this enormous quantity of images. Intelligent and cooperative agents for high level scene semantic interpretation for Audio/Video Objects characterisation, behaving, and tracking between cameras are only an example of a vast field of intelligent distributed problem solving activities for multimedia high level descriptions and reasoning. For instance, the surveillance can also take place via other methods than a camera (e.g. counting loops imbedded into the road), that also need high level interpretation. Here, a close relation between FIPA ongoing standardisations and other standardisation bodies such as MPEG7 may be a critical issue.

• Network Management - Agent technology offers the opportunity both to deliver intelligence to the end-user and to organise intelligence in the network itself. Given that reactivity and proactivity are characteristics of multi-agent systems, the adoption of an agent based approach may offer a timely solution to a large set of problems, such as efficient load control strategies using active (intelligent) networks or distributed networked systems sharing CPU resources. In this context, proposed technologies should address the objectives and requirements towards the enhancement of the performance and management of complex distributed telecommunications network environments using agent-based systems.

• Manufacturing Processing and Monitoring - Clearly, real time manufacturing control systems may take advantage of agent-based reactive systems. A number of agent-based architectures have in common a high degree of reactivity and adaptive conditions. The systems may be able to grow or adapt to new environmental conditions without direct reprogramming. Some useful and highly reactive architectures in manufacturing processing may be enumerated:

• subsumption architectures, based on stimulus-response rules and requiring a great deal of knowledge up front about the domain so that the appropriate rules can be developed;
• hybrid architectures, providing a great deal of flexibility with situations outside the original focus of the systems;
• emergent architectures, more chaotic and dealing with the overall system behaviour, developing during the execution of the system;

• Multimodal Real Time Interfaces - While computers are becoming more powerful, current interaction devices, such as keyboards, mice and windows, still limit human-computer interaction. Research in virtual reality and immersive environments brings support to a broad expansion of interaction techniques. Users will be able to interact with their "computers" using touch, gestures, voice and 3D sound and video - separately or in any combination. If applications become multimodal at a high (abstract) level, they could exploit alternative or complementary sensory modalities as individual user needs and preferences, working environments, etc.

• On line translation

• Remote Cooperative Work

An e-mail reflector for discussing the requirements and critical issues in agent-based RT systems will be available at real_time@fipa.org.

4.3 Normative Specifications

A number of technological issues have been identified as a target for FIPA 99 consideration. This part of the Call for Proposals requests submissions for these issues to be adopted by FIPA 99 on a normative basis.

4.3.1 Agent Naming

FIPA requests proposals for agent naming schemes and associated services. Examples of desirable attributes include the following:

1. Agents should be able to refer/send to other agents by symbolic name (whether or not a delivery address can be derived from that name).
2. Agent names should reflect associations between agents and other agents, agent teams or agent domains.
3. Names may correspond to an individual agent, or to a (possibly empty) team of agents.
4. An agent may hold any number of names, relating to the associations mentioned above.
5. It should be possible to use agent names interchangeably.
6. A set of services associated with agent name should be defined, such as resolving agent names to current address/contact information, determining whether two names are aliases for the same agent, storing and retrieving public crytographic keys associated with agent names, etc.
7. Naming scheme should support recursive distribution of messages to teams of agents.

It is desirable that the naming scheme and associated services be consistent with emerging Internet standards such as LDAP.

4.3.2 ACL

The FIPA ACL was specified in the FIPA 97 Specification Part 2, whose first version was published in October 1997. A second version of the specification correcting typographical and other minor errors and improving the presentation was published in October 1998. During the last year, experience has been gained in implementing and using FIPA ACL for concrete applications. To this end, field trials have also been conducted.

It is expected that FIPA 99 will return its attention to FIPA ACL, drawing upon this experience and newly-recognised technologies to extend and improve FIPA ACL. This section outlines the specific topics of interest.

Responses should clearly outline the application-driven requirements for the proposed solutions. In particular, FIPA 99's charter includes consolidating previous experience. At the January 1999 meeting, the issues addressed by the responses will be prioritised and selected for further FIPA 99 development.

Communicative Acts

1 There may be a need to extend the current set of communicative acts (CAs) along the following lines:

• Add CAs within the current class of CAs. Examples of these are renegotiate and broker, which might be variants of existing CAs, but are potentially important enough to merit special consideration.
• Add features such as a range of strengths for existing CAs such as inform and request.
• Introduce new classes of CAs, such as expressives (e.g., thanks), commissives (e.g., promising), permissives, prohibitives, or declaratives (change of state caused by the act itself, e.g., naming some capability, introducing oneself to others).

Proposals should provide the reasons for the new CAs, and the semantics of the acts (either informally in English, as a composition of existing CAs or, formally in SL or other semantic specification language).

2 Classify, or develop an ontology of, performatives.

3 Define the framework for the fail, refuse and not-understood CAs more precisely. In particular, the reason parameters of these CAs are currently loosely specified.

4 Improve the FIPA 97 ACL semantics by extending or altering it, or suggesting completely new semantics. The reasons for doing so should be clearly identified. Potential reasons include

• application requirements beyond FIPA 97,
• compliance and verification issues, and
• technical reasons such as ease of composition of CA semantics.

Proposals for new semantics may impose additional requirements, remove some existing requirements, or introduce additional concepts such as commitments.

5 Develop different kinds of syntax or lexical conventions for ACL messages to suit a wider range of applications than at present. Likely topics include XML, RDF, bit-efficient representations (e.g., to support wireless communications)

Interaction Protocols

Proposals related to interaction protocols should also demonstrate the value of the proposed approach in applications, especially the applications being considered actively by FIPA.

1. Develop mechanisms to support notions such as binding contracts and service-level agreements, e.g., for best effort versus premium services.
2. Relate with CORBA and other object-management protocols where the FIPA content may be at a higher level.
3. Enhance protocols for settings involving large numbers of agents, e.g., in economic applications.
4. Extend the current standard set of protocols, e.g., with matchmaking and brokering.
5. Specify protocols supporting management of agent societies with repositories of abstract protocols and specifications of roles.
6. Produce repositories of protocols along with some boot-strapping protocols with which the repositories could be accessed.
7. Improve and formalise protocol representation for clarifying use and to facilitate sharing among developers. The representations should be understandable by people and agents. Of special importance are topics such as exceptions, commitments, dynamics, and active directories.
8. Relate the protocol semantics to the CA semantics.
9. Handle the relationships among protocols. For example, protocols may be invoked from within protocols, may spawn other protocols, or merge with other protocols.

4.3.3 Content Language

FIPA 97 Part 2, Agent Communication Language, defines the SL content language and its profiles in an informative annex. Some other parts of FIPA specification mandate the use of profiles of SL. The intention is that FIPA does not compel users to adopt the single content language, but a specific content language must be used for a specific task such as agent management or non-agent software integration. In other cases, choice of the content language depends on the application and communicating agents must make sure that they share the same content language and ontology.

Is this policy still acceptable? Do we need to specify a standard content language (or set of languages)? Like classic KQML had interoperability problems among different implementations, there is no compatibility between arbitrary subsets or supersets of KIF, for example. Even if the agents specify the same identifier in the :language slot, no guarantee is made that they actually speak the same language. Problems of this kind are quickly emerging as standard ACL and Ontology Service are used in the real applications. Proposals are therefore called for the specification of the content language including the following, but not limited to:

• The policy regarding the treatment of the content language in the standard specification;
• The standard specification of any specific language (both new and reference to the existing ones);
• The clarification of the usage of the SL languages; and
• The mechanism to register the mapping of :language identifier to the specification of the language.

4.3.4 Agent Management

We identify a number of areas requiring standardization in agent management in FIPA’99: agent configuration, base line protocols for inter-agent platform communications and agent security.

Proposals pertaining to agent management should consider emerging software technology, specifically active directories initiatives and frameworks, JINI, JAVA-based mediation/matchmaking framework for services, CORBA, Directory Enabled Networks, Microsoft DNA, and active networks.

4.3.4.1 Agent configuration

Agent configuration is a critical aspect of managing large agent systems, especially when this involves large numbers of agents distributed over many computers. We identify a number of issues that are related to agent configuration, and we also identify the scope and role of FIPA standardisation of agent configuration:

• Agent lifecycle.
  In many applications, it is important to be able to ensure that certain agents can be controlled remotely: including restarting agents where they have died for any reason. Thus it is important for any agent configuration system to be able to start, stop and restart other agents, possibly from a remote site. Other areas within FIPA—most notably the agent mobility section (FIPA 98 Part 11) —address many of the issues here.
• Agent dependencies and resource allocation.
  In some situations, agents rely on other agents, or other resources being available in the context that the agent is executing. This relationship is within the scope of any given agent configuration system; and it may be necessary for any agent configuration system to be able to marshal both agent-related and non-agent related resources in order to be able to manage the agent.
• Agent monitoring.
  In complex systems, the management of errors and alarm reporting is also closely connected to the question of agent configuration. In addition, fault finding— finding out which agent is really the cause of an alarm—may be important. Therefore, standardised methods for controlling the flow of alarms and of monitoring the status of agents under management should also be considered to be under the scope of agent configuration.
• Agent auditing.
  This refers to the ability for agent configuration systems to collect information about the run-time behaviour of agents in a system; such as the messages sent between agents, and changes of registration of agents with the directory facilitator services.
• Dynamic agent configuration.
  Many agents may be dynamically configurable, an agent configuration system should be able to configure agents in a regular manner; for example by exposing a set of resources that external entities may modify.
  

It is not the purpose of FIPA to provide standards for agent configuration, since the particular requirements for agent configuration will vary between applications. However, where FIPA standardisation does have a role is in specifying standard methods that would allow agents to be configured by a FIPA-compliant agent configuration system.

That is, rather than providing standard agent configurators or even agent configuration services, FIPA provides standard hooks that 3rd party agent configurators may use to allow agents to be configured and managed.

Normative Topics

• A proposal for agent configuration should include specifications of standard agent management actions that permit agent creation, deletion, monitoring, updating, versioning.
• It should also include standard ontologies for non-agent resources and inter-agent dependencies, alarm reporting, querying the health of agents and for requesting the provision of non-agent resources.
• A proposal should clearly indicate its relationship to other FIPA Specifications, in particular Parts 1 and 2 of FIPA 98; especially in regard to the agent management actions defined under Agent Mobility FIPA 98-part 11.

Informative Topics

Use cases for agent configuration including example agent life cycles for particular scenarios.

4.3.4.2 Base model for agent management

Proposals are expected for the development of a base model, which describes the main concepts present in the FIPA Agent Management specifications. It is envisaged that such a base model may result in a more flexible and powerful way of extending future FIPA specifications and also allow for validation of FIPA messages and agent management related content against this model. For example, the model could state that both receiver and sender of a message are agents, agents can support one or more languages, can understand one or more ontologies, can send a message, and a message can only use one language and one ontology, agents can have addresses, types, maybe homepages etc. The level of detail considered for such a model may vary from defining the very basic concepts such as agents and messages towards more detailed ones, covering existing concepts in agent management ontology, mobility and security.

Proposals for such a base model may decouple this agent management model itself from possible syntactical representations (i.e. the serialization of the model). The latter has the advantage to allow the use of alternative languages to encode instances following those base concepts. Possible solutions for expressing the base model may use techniques such as for example entity-relationship based models, semantic networks, conceptual graphs, RDF Schemas, UML, etc. (including both visualization and possible syntax descriptions).

4.3.4.3 Base line protocol for interagent platform communication

The FIPA 97 and FIPA 98 specifications have both mandated that there should be a communication protocol which each Agent Communication Channel (ACC) should support to facilitate inter-operability between agents on different Agent Platforms (APs). In FIPA 97, this communication protocol was defined to be CORBA’s Internet Inter-Orb Protocol (IIOP). However, during the development of the FIPA 98 specification, a number of issues surrounding FIPA’s choice of IIOP and the description of its use within the FIPA 97 specification were raised. Therefore, the FIPA 98 specification introduced the notion of a baseline protocol which all ACCs should support (at the least) for the purpose of promoting interoperability amongst heterogeneous agents.

However, the FIPA 98 specification only identifies a set of characteristics and requirements that such a baseline protocol should possess; it did not describe how these features and requirements reflect upon the either the FIPA 97 or FIPA 98 specifications. The purpose of this CFP is to decide how inter-agent communication within FIPA is to be handled, in terms of requirements, functionality and readily available protocols and how this will impinge upon the FIPA specifications.

FIPA does not mandate how communication occurs between agents on the same AP; agents on different APs must communicate (initially, at least) through their respective ACCs either to exchange information or to negotiate a new communication protocol. These are the essential functions of the baseline protocol.

FIPA 98 provides specification to permit mobile agents and intermittently connected devices, however, it is apparent that a number of additional basic technologies are required over those envisaged. Briefly, these can be summarized as:

• Store and forward communication architecture to allow agents to send and receive messages in an truly asynchronous fashion.
• Message buffering to allow messages to be held for agents that are not currently connected, available or have not started executing yet.
• Message forwarding to allow messages to be redirected in the event of a machine becoming disconnected or a mobile agent migrating to a new location.
• Firewall negotiation to allow trusted agents to communicate across restricted network boundaries.
• Bit efficient message transfer to allow ACL message to be communicated efficiently over limited bandwidth communications media – such as wireless links to mobile telephones, pagers and PDAs.

The FIPA 98 specification outlined a number of requirements (FIPA 98 Part 1) that a baseline protocol should possess (which will form the basis of this proposal):

• It should be open and widely available (specification in the public domain; software implementations available; be supported and maintained).
• It should be accurate and reliable (messages received in the form sent; best effort on message delivery [It is not a requirement that messages are guaranteed to arrive in the order that they were sent.] ).
• It should be lightweight (minimise encoding/decoding engine, protocol overhead and development complexity of the API).
• It should support basic error-handling at the protocol level (time-out; message undeliverable; ...).
• It should be able to cross firewalls and express firewall policy.
• It should be extensible (support new functionality and enhancements to the protocol).
• It should be able to run on a broad range of networks (GSM, IP, etc.).
• It should be able to represent well-formed ACL messages.

Normative Topics

• A proposal to this call should describe a representation of ACL messages including encoding and decoding for network transportation that refers to the requirements listed above.
• A proposal should identify addressing mechanisms, such as how to specify proxy agents and agents with multiple locations within the communications protocol.
• A proposal should provide a specification of the baseline protocol and identification of suitable communication protocols currently available.
• A proposal may provide a specification of the standard functions and the API of the ACC.
• A proposal should identify appropriate message routing algorithms.
• A proposal should permit the specification of policies for message routing, delivery and buffering; including policies relating to the life time of messages, receipt of messages and error handling during message delivery.

Informative Topics

• Example routing algorithms and message handling and buffering policies for situations involving stationary and mobile agents and devices.
• Description of other suitable communication protocol which meet (or could meet) the baseline protocol specification.

4.3.4.4 Agent security management

• Solutions for implementing an agent-based public key infrastructures (PKI), based on X.509 public key certificates and certificate revocation lists.
• Payment protocols (e.g., SET) or micro payment mechanisms.
• Denial of service attacks that arise from access to native resources.
• Mobile agent security introduces new threat categories. Proposed solutions for protecting hosts against malicious agents, agents from other agents, and agents from malicious hosts are needed.
• Certificate Management agents are required to help in the administration of digital certificates.
• Solutions for auditing of agent and mobile agents across multiple platforms. What events should be audited and how distributed audit logs are maintained and accessed.

4.3.5 Human Agent Interaction

In FIPA 98 part 8, agent services were defined that are supposed to support the Human-Agent Interaction process. During the development of this specifications, several issues were detected that are considered important but could not resolved within the FIPA 98 time frame. Proposals covering these issues are invited.

User dialog management service

1. User driven interaction model: This model means that the initiation for interaction is started from the user end rather than the agent end. Further investigation is needed to determine whether new actions should be specified or current actions will meet the user driven interaction requirements.
2. Input and output ontology: FIPA part 8 currently leaves this feature of the specification open. All systems providing human agent interaction and being FIPA compliant will have to design and support these aspects. It would be possible in FIPA 99 part 8 to define some guidelines at an informative level to help illustrate how this aspect of the specification can be realised.
3. Policy protocol interaction between agents: Currently how the over-all system behaviour for finding the correct services is supported is not defined at either a normative or informative level. In the main the specification plays a passive role and assumes that an agent will contact the UMDA services some how. There are some scenario examples which suggest possible solutions but these scenarios could be refined as part of FIPA 99 part 8.
4. Coordination of multiple UDMAs on behalf of the user: Coordination is required in Multi-agent systems for all kind of reasons. Here we are concerned about defining some mechanisms to enable the sharing of UDMA information when a number of UDMA agents are supporting a human user. Although this feature is not always desirable, for example problems are encountered when security and privacy of information is required, at some level this aspect can be useful (for example supporting collaboration between user models, helping user information filtering and supporting personalisation and learning on behalf of the user).

User Model Types

FIPA98 part 8 does not make any assumption about structure and possible contents of user models. Instead, the existance of user model types is assumed, which specify all relevant properties of user models. However, means for defining these types, referring to or extending existing type definitions are not specified. We encourage proposals dealing with this problem, perhaps utilizing FIPA98 ontology mechanisms.

Privacy and Access Control

Mechanisms for controlling access to user models are provided by FIPA98 part 8. However, these are fairly primitive and do not support sophisticated negotiation of access conditions. Hence, proposals dealing with privacy of user models are requested.

User IDs / User Registration

FIPA 98 part 8 assumes that userIDs exist in the agent world. This may not be the case in all scenarios. It should be possible to identify the user by other means like names, email addresses, etc. In particular, user dialog management processes need to find users without having user IDs available. A mechanism for registering users in the agent world might be helpful. We encourage the proposal of solutions to user identification and detection problems.

User Personalization Service / Learning

Extended Specification of the scope action.

In FIPA98, the important requirement for well distributed selection sets was introduced. However, the optimal process and control of this functionality needs much more exploration and definition. In FIPA99, we would like to take the perspectives of information theory on one hand and decision making on the other to help us find principles that would create the selection of scope. There are at least four primary extensions:

• From the information theory perspective, orthogonal construction of alternatives is highly desirable. The best set of alternatives is not simply a collection of the best alternatives.
• From the individual user’s perspective, it is also important to create sets of options that allow them to choose easily, quickly, with high confidence and no regret.
• People also seek variety and novelty. We recognize that user’s reliance on agents will cause no variety seeking and perhaps lower level of satisfaction. We take it as a challenge to specify the appropriate injection of novelty into the action, scope.
• We also recognize that in many instances, users do not have well defined preferences. In such cases, the role of the agent extends to help educate the user construct their preferences. By presenting the user with a set of options that is representative of the environment, the user can learn about this space and the agent can best about the user.

We expect that specification of controlling scope (such as orthogonality of options), will have different approaches because of different application needs. Proposals should include both an informative part, addressing such application issues and general principles, as well as the engineering specification of the interface itself.

Integration of User Dialog Management with UPS-Learning.

From the learning perspective, the agent wants to maximize recommendation quality while at the same time minimize uncertainty. Asking users for direct information to achieve both of these goals can help the agent have a much faster learning curve. Simply observing behavior might not always be efficient, and can be facilitated by asking probing questions. Asking questions might be particularly informative in situations where there is an expectancy mismatch or very rare behaviors. We expect proposals to also address the cautions required in asking questions of the user:

• A Direct questions can sometimes be offensive (sexual fantasies etc.). There is resent work that shows that computers can ask users for such sensitive questions but doing so has to be done in a non threatening and friendly way.
• B It has been well documented that responses to questions often do not match actual behaviors (people say they care a lot about saving the rain forest but buy furniture made from this wood; people say they want to have only safe sex but at the heat of the moment take risks etc.). In line with these ideas, responses from direct questions should be limited in scope and in the weight given to them.

As well, there are a number of other integration possibilities, such as including issues of trust. We encourage proposals to address levels of autonomy between agents and users, a particularly important issue with a learning service.

Informative Specification

This part addresses further issues of an informative basis, which help in designing FIPA-compliant systems.

4.4.1 Methodologies

Software engineering aspects of agent technology. Extension/modification of UML to handle agents or even introduction of new UML-like framework, in case UML is inappropriate. This will provide significant value for increasing industrial acceptance of agent technology as a software engineering paradigm.

There is need for a formal procedure for introducing new CAs. Justifications for introducing new CAs include application requirements and lack of derivability, and potential use for reification. Specific suggestions for managing this process will be considered.

4.4.2 Content Languages

FIPA does not mandate the usage of one particular content language, but instead allows applications to choose an ‘appropriate’ one. However, in practice some content languages (such as SL0, KIF) are more obvious to be chosen as they are closer to the current FIPA specifications. When choosing less traditional content languages, such as for example RDF, OML/CKML, XML, one may need to enhance or to constrain (possibly even modify) those languages in order to better fulfill the requirements of a FIPA content language, i.e. being able to express ‘actions’, ‘statements’, ‘objects, or ‘concepts’.

As an example, a proposal about RDF could specify how to encode actions in FIPA content (enhancement to RDF Schema), or which syntax model to choose (abbreviated or basic). As usual in an informative specification, as soon as a particular content language has been chosen, these proposals specify how it should be used as content language within a FIPA message.

4.4.3 Agents on the Web

Proposals in this area may show how FIPA agent technology can be combined with common Web practice.

Indeed, the Web is definitely ‘the place to be’ for making real business of agent technology. However, up to now, there has been little usage of Web technologies in the FIPA community and both worlds are quite separated.

Some examples of problems which may be solved are:

• How to present FIPA messages, their content, or the ontologies in a human-readable way in a web browser.
  When users want to check the behaviour of agents which act on their behalf, they may want to have a look at the messages (possibly stored in some log file) which have been exchanged. Possible solutions include the usage of style-sheeting mechanisms (which separate the message content from formatting aspects) and linking mechanisms for easy navigation through the conversation instances or highly structured content expressions.
• How to use common Web processing techniques, such as validation, manipulation or query mechanisms acting upon messages, content or ontologies. Example solutions may use for example DOM, CGI, JavaScripts, etc...
• How to provide messages, content or even parts of the content with digital signatures in a Web compatible way, such as for example described in W3C/DSIG ?

Proposals may recommend the usage (or translation into) alternative syntaxes for both the ACL and content languages such as RDF, OML or XML in order to answer the above questions.

4.4.4 Reference Libraries

Proposals may suggest libraries of interaction protocols and other software aiding in agent-related development.

5. Guidelines for submission

Those intending to submit a proposal(s) should take note of the following important information.

1 Notify their intention to submit a proposal on or before 31 December 1998 to:

2 Submit their proposal in electronic form, MS Word (V6.0x or above) or HTML (the latter is preferred) by 10 January 1999 to the above address.

3 Attend the meeting on 25-29 January 1999 in Seoul, South Korea. Additionally, proponents should be prepared to briefly (15 minutes) present their proposal in the event it is requested.

In the submission the proponent should

• provide a description of the proposed technology and identify how that technology meets the relevant criteria;
• optionally identify and describe additional technologies which can be utilized to enhance the applications targetted by the FIPA 1999 specifications.
• optionally state the proponent’s position vis-a-vis the intellectual property rights possibly included in the submitted technology.

Proponents should be aware that all material presented to FIPA shall be deemed of a non-confidential nature and hence will be made available to FIPA members and participants in the January ’99 meeting. Proposals received will be made available on the FIPA web site for consultation by FIPA members. The titles and abstracts (if supplied) of the proposals will be made publicly available.