Foundation for Intelligent Physical Agents
Tokyo, Japan October 1996	F I P A

FIPA's First Call for Proposals

( CFP1 )

Executive summary

The First FIPA Call for Proposals is an invitation to submit proposals for technologies usable in a selected number of emerging agent-based applications and services, specifically in the following four categories:

• Personal Assistant
• Personal Travel Assistance
• Audio-Visual Entertainment and Broadcasting
• Network Provisioning and Management

These proposed technologies are intended to be utilised in the development of specifications of component technologies that may be used by application developers for first implementations of the aforementioned application areas. The time scale of specification development is 1997.

Deadline for proposal submission is 10 January 1997 for consideration at the fourth FIPA meeting on 20-24 January 1997.

Click here for detailed information on how to submit.

Table of Contents

• 1. Introduction
• 2. Structure of this Call for Proposals
• 3. Nature of FIPA specifications
• 4. Target applications of this Call for Proposals

• 4.1. Rationale
• 4.2. Personal Assistant

• 4.2.1. Rationale
• 4.2.2. Description and Reference Model

• 4.3. Personal Travel Assistance

• 4.3.1. Rationale
• 4.3.2. Description and Reference Model

• 4.4. Audio/Visual Entertainment and Broadcasting

• 4.4.1. Rationale
• 4.4.2. Description and reference model

• 4.5. Network Provisioning and Management

• 4.5.1. Rationale
• 4.5.2. Description and Reference Model

• 5. Technologies requested by this Call for Proposals

• 5.1. Introduction
• 5.2. Agent management

• 5.2.1. Introduction
• 5.2.2. Agent Interface Description Language (AIDL)
• 5.2.3. Agent Security
• 5.2.4. Agent Lifecycle Model

• 5.3. Human/agent and agent/agent communication

• 5.3.1. Introduction
• 5.3.2. Message types
• 5.3.3. Message contents
• 5.3.4. Interaction protocols
• 5.3.5. Enabling technologies

• 5.4. Agent/software interaction

• 5.4.1. Introduction
• 5.4.2. Attachment to external software, applications and services
• 5.4.3. Attachment to internal components
• 5.4.4. Enabling Technologies

• 6. Example applications made possible by FIPA 1997 specification

• 6.1. Introduction
• 6.2. Personal Assistant
• 6.3. Personal Travel Assistance
• 6.4. Audio/Visual Entertainment and Broadcasting

• 6.4.1. Overview
• 6.4.2. Application: System Configuration and Capability

• 6.5. Network management/provisioning

• 6.5.1. Introduction and Context
• 6.5.2. Application: Service provisioning, activation and resource allocation
• 6.5.3. Application: Remote Autonomous Element Management
• 6.5.4. Application: Federated Customer Care

• 7. Guidelines for submission

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. The current environment is one in which agent-based systems are designed and deployed on an ad-hoc basis. FIPA has been established to promote a larger deployment of interoperable agent systems. This is accomplished through the standardisation 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.

Although there is a large number of applications that can benefit from agent technologies, addressing too many of them simultaneously in this early stage would be impractical. Therefore this Call for Proposals concentrates on a subset of services and applications with a first set of functionalities, in the areas of Personal Assistant, Personal Travel Assistance, Audio-Visual Entertainment and Broadcasting, and Network Provisioning and Management.

It should be realised, 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.

Those intending to submit a proposal(s) should consult Chapter 7 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.

A healthy cross-industry response from interested parties will ensure that the technologies will be adopted which will be in support of the interoperable agent based applications.

FIPA meetings may be attended by member companies only, however, companies who have submitted proposals but are not FIPA members will be allowed and invited to attend the January 1997 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 7.

Application for membership to FIPA can be found on the FIPA homepage

http://www.cselt.it/fipa

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
2. Replace previously specified technology as new technology matures

A first draft of the FIPA specifications, based on the submissions received, will be produced at the 5th meeting in April 1997. A second draft will be produced at the 6th meeting in July 1997 and a final specification approved and issued at its 7th meeting in October 1997. While FIPA intends to work by consensus, this very aggressive schedule may require the use of membership voting. The FIPA governing statutes are available on the FIPA Homepage.

2. Structure of this Call for Proposals

Chapter 3 of this document describes the nature of FIPA specification. 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 standardised 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 4 provides a detailed explanation of the four target applications, as they can be implemented using agents.

Chapter 5 contains the list of component technologies target of this Call. This has been produced from an analysis of the requirements from the selected applications.

Chapter 6 provides a description of possible implementations of the four selected applications as a result of the specification of agent component technologies listed in Chapter 5.

3. Nature of FIPA specifications

Promotion of the development and specification of agent component technologies is the task of the Foundation for Intelligent Physical Agents (FIPA). The following are the main features of FIPA's specifications

1. Specifications are produced by identifying, selecting, augmenting and developing, in a timely fashion, specifications of generic agent component technologies that are usable across a large number of agent based applications and provide a high level of interoperability between applications. The goals are realized through the open international collaboration of all players in the field.
2. The following principles are followed in FIPA's specification development
   1. FIPA specifications must be produced before industries make commitment;
   2. As a rule, systems will not be specified but generic component technologies usable in different systems will be. Therefore, not systems but subsystems, not the internal working but only the external behavior are standardised;
   3. It is desirable that each functionality needed by FIPA be supported by only one component technology;
   4. Component technologies needed to support functionalities must be relocatable;
   5. Specifications should cover only the minimum that is needed for interoperability.
3. As a rule FIPA selects and adapts existing technologies and only occasionally develops its own technologies. Therefore, FIPA will keep close contact with formal standards bodies, industry consortia and government agencies, such as ARPA, CEC, DAVIC, IETF, MPEG, OMG, TINA, W3C etc. as a source of candidate technologies.
4. It is FIPA's intent to specify tools that can then be assembled to provide systems of practical interest. It is the responsibility of the subsystem integrator to ensure that the overall system is fit for the purpose intended and complies with all relevant regulatory requirements.
5. The FIPA specification development activity is based on a workplan, organized in work items. Each work item identifies a date of completion and a list of subsystems whose specification is believed to feasible by the agreed date and whose enabling component technology is believed to become available for use by around the date of work item completion.
6. As a rule FIPA will acquire information on candidate component technologies for the subsystems it intends to specify in the context of a work item by means of Calls for Proposals such as this 1st CFP. Such Calls are public and anyone, member and non-member, may submit technologies for consideration by FIPA.
7. FIPA specifications are of two kinds: normative and informative. A specification is normative when it mandates the behavior of a subsystem to ensure interoperability with other FIPA-specified subsystems. A specification is informative when its aim is to provide guidance to industry on some particular aspects of a subsystem.
8. FIPA Members (companies, organizations, governmental institutions etc.) pay yearly membership fees, have right to vote on matters that require this instrument and are allowed to join the technical committees developing technical specifications.

4. Target applications of this Call for Proposals

4.1 Rationale

Agents here mean relatively autonomous units that can adapt to, and interact with, the environment (both software and hardware) that they live in. Some functionalities of the applications can also be supported with non-agent technology. FIPA believes, however, that the use of agent technology and inter-agent communication protocols provides an effective means for building large (i.e. commercial) systems of services in a modular way by producing "plug-in" software, and painless extension of capabilities.

The use of rational agents allows the definition of intelligent personal assistants, brokers and more generally of "combination of services". The benefit we can expect from rational agents is the ability to develop more and more complex services, far beyond existing technology possibilities.

A small number of application areas for the use of agent technologies has been selected as example applications. This allows FIPA to address relevant applications that are interesting in the business world and not only to agent-technology researchers. It also allows FIPA to select and focus on relevant technologies that are available, now or in the near future, in the research and development community that can be put together to build the first FIPA standards set.

4.2 Personal Assistant

4.2.1 Rationale

One central class of intelligent agents is that of a personal assistant (PA) or intelligent personal agent. A personal assistant is a software agent that acts semi-autonomously for and on behalf of a user, modelling the interest of the user and provide services to user or other people/PAs as and when required.

The notion of a personal assistant is very open-ended. There are many, many internal and external functions/services that can and will be used to provide and extend a Personal Assistant's basic functionalities. In fact, such openness to new services is a critical requirement where interoperability of PAís functions/services is desirable.

The examples of such functions/services are to include: to communicate with the user to help managing his/her directories and diaries (e.g., meeting scheduling), filtering and sorting mails (e.g., electronics mails), locating and delivering (multimedia) information, recommending movies, purchasing desired items, planning travel, etc. The other FIPA application scenarios - especially the Personal Travel Assistance and the Audio-Visual Entertainment and Broadcasting - also include this notion of end-user personal assistance, but this application focuses on the generic requirements for personal assistant.

4.1.2 Description and Reference Model

A personal assistant comprises:

1. Intelligence and associated capabilities such as rationality (reasoning and planning) and adaptability/learning.
2. Knowledge including facts, rules and adapted/learned knowledge for and about an end-user.
3. Interaction capabilities and facilities with the user, other agents and software/hardware services/functions.
4. The services/functions and their procedures for the agent to work with them.

The scope of this composite is limited to the tasks which are given by the user as goals and preferences for behaviour. Other agents will also exist and interact with the personal assistant, but such other agents will not tend to represent particular user's preferences, or access authority and other differentiators. The composite is visualised in the following reference model.

Fig. 1 - Reference model for Personal Assistant.

The reference model includes the following interfaces/protocols of interaction that are candidates for standardisation.

1. User-Agent Dialogue
2. Multi-Modal User-Agent Interface
3. Agent-Agent Communication Interface
4. Protocols for Agent-Agent Interaction
5. Agent-Software Interfaces
6. Agent-Software Communication Protocols
7. Agent-Functions Interfaces
8. Function Interoperability Interfaces/mechanisms

Multi-modality is the ultimate goal for human-agent interfaces. As a user interacts with a real personal assistant, he/she can speak face-to-face with the assistant or over the phone. Obviously, unconstrained natural language comprehension is also desirable. However, as first steps toward this general goal, "multi-modal" interaction is taken not as requirement for all agents to support all modalities, but merely that any single application should be able to select the one or more modalities required for the application. The composition of the personal assistant should be media-independent in order to allow for this choice, and otherwise provide the multi-modal conversions required such as converting text to speech in order to pass information over the phone.

In order to provide some concrete examples, the following scenarios serve to expose the basic PAís functions/services needed.

Directory Services

One of the basic functions of a PA is the management of the user's directory. This directory includes other people's/organisations' telephone numbers, addresses and personal and useful information about them. This information facilitates responses the PA may provide to user's needs in an intelligent way, based on the context of the request. For example, if the user asks to call an organisation and the PA by reference to the opening and closing time notices that the call cannot be made, it will suggest alternative actions by inferring the user's possible intentions on the basis of the services provided by the organisation. A request for a call to a specific travel agency out of opening hours may result in the PA suggesting contacting a 24-hour call centre of an airline company.

Meeting Scheduling Services

The personal agent includes, obviously, a calendar facility, that among other things can be used for scheduling of meetings, and negotiation with users and other agents. The functionality includes:

• Identifying a mutually appropriate time for all participants to attend a meeting
• Reserving an appropriate venue for the meeting
• Organising associated facilities (e.g., lunch, OHP, etc.)
• Issuing reminders to participants
• Handling any problems which might arise at a later date
• Canceling meetings.

Information Management Services

This is a very large and nebulous set of tasks but also addresses one of the most critical needs for intelligent personal agents. Most professionals are now inundated with too many sources of information, generally this is called "information overload". An agent can serve to semi-autonomously filter, sort, or otherwise respond to all these sources to help off-load some of the more mundane tasks these professionals now must do themselves. Such task include:

1. E-mail and news filtering (such as "junk" mail or news appends)
2. Sorting and prioritising all sorts of received information
3. Automatically responding or forwarding information to another user

A key aspect of such information management is not just filtering out the low priority information, but also providing the timely delivery of high priority items - anywhere, anytime, anyhow. Such delivery is dependent on the user's location, media/equipment limitations, and user preferences. For instance, an agent can be instructed to deliver important e-mail to an end-user even if the user only has a mobile phone by converting the text to speech. Of course, this same text-to-speech delivery of e-mail over a mobile phone can be applied to any text-based information source such as NNTP news, stock quotes, etc. Furthermore, given the cost of mobile phone connectivity, other technologies such as text summarisation can be employed, for most efficient delivery of the users time and cost. The provision of such summarisation and media to media transformation could be provided, for example, via external services.

Even under the most constrained situations, such as the user only having a pager, a personal assistant can at least notify the user about the existence and accessibility of an important new multimedia document. Even though the pager device cannot deliver the information, the personal assistant can notify the user of the appropriate equipment in the locality of the user that is available where the multimedia document could/would be sent to.

A less well-developed but equally important aspect of information management is the personal storage and retrieval of information. Even personal computer storage is becoming difficult to manage. Files are often duplicated, directory structures are haphazard, and the file systems themselves does not provide rich indexing and content search facilities. Within an intelligent personal agent, such functions also take the metaphorical role of a personal assistant; like a personal secretary, it can be asked to file and retrieve documents or even isolated bits of information.

As an example of a desired service provided by a PA we can mention Travel Planning service.

Travel Planning Service

The personal agent can assist in planning the userís trip. To achieve that the PA interacts with the user, other agents and external directory services (such as yellow pages) and provides an appropriate plan of an intended trip and other guidance services. See Personal Travel Assistance Application in this call.

4.3 Personal Travel Assistance

4.3.1 Rationale

A wide variety of travel related services are becoming increasingly available through electronic means. There is a need for convenient and ready access to these services, in particular for travelers. This presents a prime example to showcase the benefits of agent technology. 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 of a trip. A system supporting these services is called a PTA (Personal Travel Assistance) system.

In order to accomplish this assistance these agents will interact with the user and with other agents representing the available travel services. The agent system is responsible for the configuration and delivery -- at the right time, cost, QoS, and appropriate security and privacy measures -- of trip planning and guidance services (e.g. multimodal route planning, hotel and parking-lot reservations, individualised traffic guidance, tourism, plane reservation, metro guidance). Further, there is interaction with other supporting agents such as media agents, directory services (yellow and white pages), and information brokers that seek, evaluate, and deliberate on information.

For travel services to be available in an open and free market economy, it is crucial that the agents of different vendors be interoperable. An initial framework for this end will be accomplished by the FIPA standardisation initiative.

4.3.2 Description and Reference Model

The PTA system should support the following functionalities:

• different modes for request/response: the user does not need to be connected while the request is completed,
• vertical brokering: composition of services,
• horizontal brokering: comparison of services,
• learning the user profile,
• speech- recognition and text understanding,
• interoperability of communication means (phone, pager, email, cellular phones/GSM),
• administration of agency: ability to track agents,
• alerts triggered by events and forwarded by agents to the user,
• financial transaction,
• brokers are services, and can be used by other services. The schema above distinguishes between basic services (plane, weather information) and brokered services (travel agency, bank). The distinction is artificial and introduced here for the clarity of the schema.

The reference model for the PTA application is introduced next. User devices, example services and expected communications means are discussed. Finally, expected agent types are listed.

Terminal

The user accesses the PTA System via software running on a variety of standard end-user computing devices (called PTA Devices). These may typically be:

• Stationary computers and information kiosks (primarily for pre-trip planning)
• Automotive navigation systems (primarily for drivers)
• Mobile Digital Assistants
• Common peripherals for notification (pager, fax, phone, ...)

Interaction among these devices may be desirable.

Travel services

A variety of travel services (called PTA Services) are integrated into the system by travel service agents (TSA's) establishing a common "front-end" for automated access to these services. Examples of such services are:

• Timetable information
• Traffic status
• Multimodal route planning
• Hotel, car park, and tourism information and reservations
• Plane, train and car-rental ticketing and reservation

Communication

A variety of communication services are available for relaying information and data between the PTA devices, PTA services and user:

• Broadcast (e.g. RDS/TMC, DAB)
• Wireless Data exchange (e.g. GSM, SMS)
• Standard LAN, WAN
• Standard delivery services (telephone, fax, pager)

Not all methods of communication are always accessible and their availability can change during different phases of the trip.

The following gives the general reference model for a PTA system.

Fig. 2 - PTA Reference Model

Summary of Agent Types

• Personal Travel Manager (PTM) provides full trip planning and user preference profiling.
• mini-PTM a PTM specialised for mobile platform, possibly with lesser trip planning capabilities, which are delegated to a broker agent in the fixed network.
• Travel Service Agent (TSA) provides travel service information and interacts with PTM or Broker.
• Broker provides added-value based on other TSAs.
• Directory Agent used by Brokers and PTMs to identify TSAs.
  

4.4 Audio/Visual Entertainment and Broadcasting

4.4.1 Rationale

The expansion of digital broadcasting is expected to transform conventional television and radio into multi-functional, high-quality, and multi-channel systems and enable the provision of a wide variety of new information services. A vast amount of multimedia information is produced on a daily basis and browsing through 500 plus programs is no longer realistic or desirable. This offers potential markets for new businesses, and test-beds for agent-based systems to be used as filtering-retrieval-and-presentation component based on the user preferences. On the other hand, program production itself has to adapt to this new way of using and selecting the information. Furthermore, agent technology can increase the quality of the produced programs by allowing special kind of processing (e.g. object tracking).

Therefore, the application scenario described here consists of a Production Studio connected to the Receiver (User) side over a network. Autonomy and Intelligence is expected to be in both sides in order to support more functionalities that agent components are able to provide in a more efficient way.

4.4.2 Description and reference model

Production side

The production of a multi-media program in a studio can eventually benefit of the agent technology as here described.

A Camera-Tracking Agent handles the video streams, coming at real time rates from a number of cameras, to be combined within a production environment, for example for mixing, then composited with other elements, e.g. synthetic scenes, to form a sequence which is then broadcast live or stored for post production. The functionalities required from the cameras is simply the visual representation of the real world as seen by the eye. This electronic recreation of the world could be transmitted to another point in space or used to extract some useful information, such as an object to be tracked in the scene, or the position of the camera itself. Such a camera/vision agent may implement functionalities such as: 2D video manipulations, e.g. mixing and fading, object extraction/chroma keying and feature extraction. It may add value to applications such as TV production live/pre-recorded, virtual studio, enhanced reality, teleconferencing, cooperative working, and shared Virtual Reality.

Of course, this kind of functionalities should be implemented and synchronized also in the audio part of the system to provide a fully-integrated production.

Fig. 3: Production Side

Production agents support program production by providing information to the user agents through the broadcasting networks. They can be used as production supporters which retrieve the bulk of information from the video archives located at the studios or from other databases in networks. They could provide the production staff with the required information to support program production. The information comprises video images and other data needed for the entire production procedure, from planning and shooting to editing (post-production).

They can also be used as communicators for exchanging information with other agents, in particular with user agents, to provide feedback and user reactions to new program productions.

Receiver Side

This multi-agent system can be seen as an add-on to the structure of the set-top-box receiver that is proposed by other groups, e. g. DAVIC. Its main function is to assist the user in gathering information from incoming TV programs and from other networks (i.e. Internet), and then eventually store information users may be interested on. Therefore, capability to control digital storage media (e.g. VCR) at the user's home could be also integrated.

The agent-based entertainment assistant evaluates the service information of the actual programs. These Service Information (SI), as defined in DVB (Digital Video Broadcasting) or DAB (Digital Audio Broadcasting) and ATSC (Advanced Television Systems Committee), includes information representing contents of the program like basic program-service label (i.e. the name of a program service), program-type label (i.e. news, sports, classical music, etc.), more detailed contents description (i.e. keywords, sentences with parsed tree, logical form, etc.), etc. These are evaluated to create, on the basis of the knowledge of the preferences and the habits of the viewer/listener, a list of possible films/channels (Personal Electronic Program Guide).

Fig. 4 - Receiver Side

The Retrieval Agent is also autonomously able to access other information providers and start a retrieval for a desired purpose (e.g. Video On Demand Server, Internet, etc.).

User profile/interface agents must possess ability for autonomous learning of the user's profile (i.e. the likes and dislikes of the user) and to provide a personal friendly interface to the user interaction with the system (e.g. natural language, text-to-speech, ...).

The multi-agent system is expected to survey automatically detailed background information of ongoing programs at the user's request. For instance, if the user asks for further information about a program, it will provide names, and detailed information about actors and more.

An automatic program generation agent is also part of the expected scenario. It should have the capability to personalize and produce unique programs for that user by manipulating the incoming information by super-imposing sub-titles, music, changing objects in the scene, ... Again, all this kind of manipulation should be done according to the User Profile that is updated, day-by-day, by the User Profile Agent.

4.5 Network Provisioning and Management

4.5.1 Rationale

The applications described here form a cluster in the domain of network and service layer management. It has been recognized that this is a large and complex domain, and so a focused set of applications, that could benefit from the use of agent technology in the near-medium term, has been chosen.

The question then arises as to the benefits of agent technologies in this domain. Agents will be autonomous and adaptive. These capabilities allow for easier and more robust implementation of network management actions across boundaries, be they layers in the TMN (Telecommunications Management Network) models of ITU-T, or boundaries between networks and network management domains. In practical terms, the ease of implementation is due to a paradigm shift in which the locus of control and the architectural knowledge of the environment moves from the global platform, as determined by current standards, to a local authority: the agent. It is possible that these agents start with a only basic set of assumptions, then add to their knowledge throughout their lifecycle.

The application cluster area is described below from two perspectives. The first is a mapping of agents to the most well known architectural model of network management, the TMN model, possible applications and their relationship to the agents in the model are described. The second perspective focuses on the general properties of agents in the model.

4.5.2 Description and Reference Model

Agents may correspond to management activities currently found in many places in the TMN model. TMN presents a layered view of management. It comprises four layers, ranging from the management of individual physical elements to the management driven by the business processes. In practice a TMN managed network is not alone in the world, but may be connected to other networks, TMN managed or not, perhaps belonging to a competitor. In addition, as the sophistication of private networks increases, and home networks become commonplace, agent technology may be essential to deliver management services.

Another aspect orthogonal to the layered view, and not shown in the figure below, is the dissection of management into functions: fault management, performance management, accounting, etc. While these concepts from the model are valid and useful abstractions, they create numerous boundaries that, in any given implementation, are crossed by standardized function calls, protocols, procedures, etc. With the use of agent technology, we foresee implementation strategies which alleviate many of these problems. Agent based implementations will be more robust to change, and allow for interworking between networks with different management models, and of different scales.

Fig. 5 - Mapping of agents to TMN layers

In the figure above, example agents, or agent clusters, and their mapping onto the TMN environment are shown. The figure shows only two networks, but the principles apply to interactions amongst many networks. All agents belong to some authority. The agents in the area between the two networks above could be owned by the network operator, jointly owned by multiple operators, or owned by a third party. Below we summarize the functionality of the example agents in the figure, labeled A through E:

• (A) Remote autonomous element monitoring: network elements can monitor themselves and take appropriate actions in an intelligent way, and report actions to other interested parties (human or agent)
• (B) Distributed network management
• (C) Home network management
• (D) Service provisioning, activation and resource allocation: the agent covers a complex business process, including interaction with the customer and appropriate network operator(s), and is responsible for service layer requests;
• (E) Federated customer care: the agent provides for the outsourcing of the help-desk function across networks, friendly or unfriendly, and is capable of taking action to resolve network problems.

The concept of network management agents is most powerfully described by a 'flat agent model', which means that no pre-determined fixed relationships between agents is presumed. Agents operate by providing services to each other in a non pre-determined way. Agents can:

• function in one or more domains
• function in one or more layers
• function in one or more networks
• act as brokers
• have devolution of control and authority to empower other agents.

Agents have a notion of acquaintances, i.e. other agents which can perform actions that the agent requires to fulfill its own purposes and meet its obligations. It is this relationship that determines the distribution of actions. It should be noted that such relationships, and hence the distribution of tasks, may change over time. Thus the agent model itself is flat, but it contains knowledge located inside the agents, that will create a structure. Note that the power of this model is that it allows interworking of management between many types of networks, with different hierarchies determined by the type of network management model, e.g. TINA, Internet or a small home network.

To be able to function in such an environment an agent has to have certain domain information and capabilities. These include:

• access to application domain functions
• the network resources the agent has under its control, or requires
• access to the layers and domains of the network, model of the agents in the networks, permissions
• acquaintance model
• negotiation model
• responsibilities
• authority
• identity
  

5. Technologies requested by this Call for Proposals

5.1 Introduction

This chapter presents the essence of this Call. The following three sections describe the areas of technology proposed for specification in 1997, including descriptions, examples and criteria for each.

Each section also refers to additional enabling technologies which are not candidates for standardisation in 1997 but may be required to implement the target applications.

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

5.2 Agent management

5.2.1 Introduction

This section addresses the issue of managing agents in a system. An agent system can be much less structured than hardwired or pre-defined systems. However, there is a need to have standards describing how the knowledge about the system -- and agents therein -- is conveyed to other agents and to a human operator configuring and managing the system. The call for techniques in this section addresses the minimum amount of technology deemed necessary by FIPA to allow agent to cooperate in a system in a sensible and efficient way and, thus, ensure interoperability among agents. Examples of technologies mentioned in this section are for purposes of focus only, and not in any way deemed normative.

5.2.2 Agent Interface Description Language (AIDL)

Description

Language that describes how to identify, access and interact with an agent. Used by agents to locate, identify and access other agents which may be helpful to fulfill their purposes. This language should be used by agents to describe themselves to other agents, and can be used internally to represent a model of other known agents (i.e. acquaintance model). AIDL expressions may be interchanged in messages between agents (cf. Section 5.3).

Example

An agent may look for another agent which is capable of performing a specific task using a query expressed in AIDL.

Criteria:

• Be able to describe the following properties of agents:
  • name
  • location
  • communication access
  • execution model (e.g. migrating or stationary, reactive or deliberative)
  • means of invocation
  • state of the agent in its lifecycle (cf. Section 5.2.4)
  • skills and capabilities (cooperative, referring to interaction protocols of 5.3.2, and others)
• Build upon current standards (e.g. CORBA's IDL, COM) if and when possible.
• Be extensible

5.2.3 Agent Security

Description

A security model for agent interaction with each other and with their environment (i.e. user, SW and HW).

Example

A travel agent needs to prove its identity and authorisation to make a reservation with a service on behalf of its user. After making the reservation, it can not deny having made it.

Criteria

• Provide for
  • Agent authentication
  • Agent integrity
  • Authorisation of agents to perform changes in its environment
  • Authorisation of agents for their interaction with other agents
  • Delegation of authority to other agents
  • Non-repudiation of agent actions
• Build upon current security models and standards (e.g. Netscape SSL, Kerberos)

Enabling Technologies

Security in the underlying communication network is not addressed by this call, and is considered to be an available enabling technology.

5.2.4 Agent Lifecycle Model

Description

A model which allows for creation, modification, migration, and deletion of agents in a system. This allows for the management of a system with agents and gives the framework for agents in the system. The model may incorporate several different lifecycles, depending on the particular system requirements.

Example

Upon creation an agent announces its description (in AIDL) to relevant parties, does its work, and notifies relevant parties before leaving the system.

Criteria

• Allow for
  • Locating agents according to specified needs (as represented in AIDL) by other agents
  • Specification of the execution model (e.g. migrating or stationary)
  • Agent persistence
  • Monitoring of agents for human operators (e.g. via dedicated monitoring agents)
• Be efficient
• Build upon current lifecycle models if and when possible.
  

5.3 Human/agent and agent/agent communication

5.3.1 Introduction

Agents need to interact both with other agents, and with humans. There is a significant overlap in the requirements for both agent to agent, and agent to human interaction, so FIPA believes that there is enough commonality to consider attempting to meet both sets of requirements with one technology. The categories of messages that are exchanged, and the higher level structures of the dialogue, could be viewed as essentially the same in both cases. The dialogue with the human will need extra layers of translation to be understandable by both parties. We also recognise that, while agent interactions are modeled on human to human interactions, the current state of the art in computationally recreating these interactions may mean that agent only protocols are simpler than their human counterparts.

To ensure that independently developed, heterogeneous agents are able to communicate effectively, a precise syntax and precise semantics for messages is essential. The semantics of the messages should be expressed formally.

Cooperation and coordination are basic common behaviours in both agent to agent, and agent to human interaction. FIPA requires common protocols which are flexible enough to allow different types of cooperation. The execution of these protocols is dependent on, and possibly controlled by, the interpretation by the agent of currently expressed intentions.

Standardised interaction arises from correctly executing shared communication protocols. In the following text we consider a protocol to be a collection of messages that will be exchanged by the parties in the interaction, together with the rules, constraints and additional semantics that govern the various sequences of exchanged messages, and the meaning the agents should derive from them. We adopt the view that a protocol is more useful when viewed more as a dynamic, flexible entity emerging from the actions that agents take in response to messages and able to change in response to changes in the environment, rather than a stable, predetermined script.

To support this view we also adopt a design stance with respect to the conceptual design of the protocol, without prejudicing the choice of any given implementation. In this design stance, we view messages as self-contained abstract entities, and as the primitives in the construction of protocols. The semantics of messages then are defined locally to that message, and semantic expressions that are functions of multiple messages (e.g. the expected reply to a given message) are specified in the protocol. A given message then, could be used in the definition of multiple different protocols.

5.3.2 Message types

Description

The message types should correspond not only to primitive communicative acts (e.g. request, inform, confirm, etc.), but also to complex combinations (e.g. sequences, alternatives) required by the negotiation and coordination protocols used by the agents.

Examples

• travel agent asks for information on flight schedules from certain airlines
• a personal assistant may propose (part of a negotiation strategy) to the user that the time of a meeting is changed; the propose message might be composed from an inform action followed by a request for a response
• a user asks the AV-entertainment assistant to recommend a movie; this is translated down to a request message and passed to the agent. Once the user is happy with the selection, she answers "OK" which is translated into an accept message with authority to begin billing the user.

Criteria

• set of primitive communicative acts
• set of message composition operators to construct more complex messages from primitives
• minimal set of message types understood by all agents, sufficient to guarantee basic communication (it should be noted that FIPA wishes to allow for the implementation of lightweight agents)
• it is desirable that messages should be understandable by reactive and deliberative architectures
• extensive set of message types (possibly constructed from primitive messages using composition operators) sufficient to implement all supported interaction protocols
• clearly defined semantics and syntax for both primitive messages and the composition operators

  5.3.3 Message contents

Description

The content of the message is the argument to the communication act specified above. The actual message content description formalism is an implementation choice. However, to facilitate communication, the content must be accessible in a general way. Characteristics of the content, such as the ontology and encoding scheme, are available in a standard.

Examples

A user requests the agent to reserve a seat on a plane. The content of the message must allow the representation, in general way, of a domain action from the ontology, and other domain specific information. In this example, the action is "reserve", and the domain information is "a seat on a plane" (a formula with a free variable).

A user asks the AV-entertainment/broadcast agent the scores of the baseball games today. The agent informs the user that there was no game today. The answer is a quantified formula ("there was no game").

Criteria

• The message content types must be conform to the semantic category of the arguments of the message types. For example, inform should have a proposition as an argument, request should take an action.
• Message content formalism must be expressive enough to represent the argument to the message, as required by the message type or the needs of the domain.
• A message is self-documenting, in that it refers to the ontology and representation formalism used. Agents are guaranteed to share a minimal non domain-specific ontology, and can extend their domain ontology as required to perform a given task.

  5.3.4 Interaction protocols

Description

Agents can enter into negotiation or cooperation processes with other agents or humans. These processes vary in complexity, from simple handshaking, through cooperative task achievement to complex negotiation and trading exchanges. At one time, an agent may be engaged in several overlapping interactions for the purpose of attaining a particular goal.

Protocols are implemented through the exchange of messages, but they impose constraints and expectations on the way that the agents behave with respect to the other agents or humans in the interaction. Simple human-agent protocols may be accomplished as directive dialogues, in which the set of responses expected from the human is indicated through the interface.

The protocols for these interactions can be specified at different levels. At one level, we specify the kinds of response we expect in reply to certain communication acts: for example, a question is followed by an answer. At another level, we can view the protocol as creating intentions and obligations in the parties to the interaction, for example the intention to reply to a request, or the intention to be cooperative and helpful. These intentions may or may not be explicitly encoded in the agent.

By agreeing to be bound by a given protocol, an agent is required to act in a given way. For example, an agent which declares itself to be cooperative will then be expected to generate cooperative responses, such as answers which are over-informative, corrective, suggestive, etc.

Interaction protocols may imply a number of different models for the delivery of messages to other agents or users. For example, point-to-point, multi-casting, broadcasting, etc.

Interactions controlled by a protocol may persist over varying periods of time, e.g. a agent may be required to commit to performing some action or actions at a later time. The protocol gives a framework in which different characteristics may change dynamically. An example would be: an agent must drop a commitment if the goal it was committed to is no longer relevant.

Examples

• The user is trying to set up a meeting with some colleagues on a particular date. The personal assistant agent checks the user's schedule, and replies that the user already has meeting with clients on that day, but the next day is free, but there is no room available. The user suggests to the agent to use a local hotel, and to stay within a given budget. The agent contacts the hotel booking system and reserves the room.
• In the AV-entertainment application, a retrieval agent contacts video-on-demand servers to locate a movie for the user to watch, and requests suggestions and prices. One video-on-demand server agent answers with a highly rated movie that the user has not watched, at a good price. The retrieval agent accepts the price, and cancels the request to the other servers. A more sophisticated protocol would include checking with the user that this movie is acceptable, and initiating a charge to the user's credit card.
• The travel agent is attempting to set up a trip between two cities. The agent requests a broker to suggest possible routes. The broker multicasts a request for bids from agents to suggest various routes, such as plane, train or rental car. The broker negotiates a contract with one of the route agents, and suggests it to the user's travel agent.
• In the network management application, a transmission agent needs to set up a stream for a high-bandwidth multimedia stream. The agent knows that various routing agents auction bandwidth so it joins such an auction and bids for enough bandwidth to transmit the signal. Once the bid is accepted, the two agents negotiate a service contract, guaranteeing the availability of bandwidth for the duration of the transmission.

Criteria

• formal, computational framework for representing protocols
• pre-defined protocols using above framework, such as: information exchange, co-operative task, brokering, monitoring, trading, service contracting, monetary transactions
• the protocols must allow for general failure to meet expectations. Some of these are generic (e.g. the agent cannot be contacted), and some are protocol specific (e.g. failure to respect the rules of a bidding procedure). A specific class of failures that must be handled reliably and robustly is communication exceptions, failures, errors etc.

  5.3.5 Enabling technologies

• knowledge representation formalism(s), for both domain independent and domain specific knowledge (e.g. logics, belief and intention models, action models)
• domain specific content encoding schemes
• reasoning, planning models (e.g. formal principles of rationality)
• communication and cooperation models (e.g. formal models of speech acts, formal principles for cooperative behaviour)
• techniques for computing the content of cooperative responses (e.g. constraint relaxation and restriction algorithms)
• automated inference algorithms and techniques
• dialogue models
• natural language understanding and generation to support agent-human interaction
• speech recognition and synthesis
• message distribution mechanisms

5.4 Agent/software interaction

5.4.1 Introduction

Agents do not exist in a vacuum. In order to support an open and interoperable set of standards, it is necessary for FIPA-compliant agents to adapt to existing and future applications, services and devices. Furthermore, to support the agent-designer in constructing a FIPA agent it is also advisable to standardize how toolbox / component software should be integrated into the internal agent architecture. Each of these presents special requirements and will be dealt with in turn below. FIPA believes that both of these are fundamentally important in pioneering an open component market.

The following call contains two major requests for technologies: attachment to external applications and inclusion of (internal) cooperative software components. Every existing agent application has to date implemented some notions of the application attachment; many have also combined internal software components to varying degrees. It is not the expected result of this call to select one specific technique: neither to define the nature of component technologies, nor any specific internal agent execution architecture. FIPA solutions will be combined and refined into a set of protocols during 1997.

5.4.2 Attachment to external software, applications and services

Description

To enable an agent to attach to external software systems. This requires that both a computational and an informational description of the service exist together with necessary functions (in the external agent infrastructure) to attach the agent to the service. The working metaphor is to provide the "eyes, ears and hands" of the agent.

In its broadest sense, the same mechanism of direct attachment to devices is also applicable to the attachment to services. For instance, locating potential services, obtaining a description of these potential services, connecting and supporting the lifetime of these connections.

Example

Connecting an agent to a video server (e.g. DSM) for the purpose of filtering information. The agent needs to be able to locate a video server of the required type by referring to a suitable semantic description. It must be able to perform a filtering operation on the located server based on the stream / symbolic attributes of the media. There should be a set of support services available to maintain the integrity of the connection, for example, the agent responding to error or event-notifications.

Criteria

The interface within the agent to external applications should contain the minimum following set of features:

• The interface must be able to register events from the external application and receive notifications from it. Management functions to enable the processing of the incoming event stream must be provided to the agent core.
• Interface registration. The representation of the application to the agent composition must address the syntax and semantics of the interface. The syntax addresses the computational description of the interface, whereas the semantics identifies the information to be transferred across this interface. For example, the syntax of a video-server would describe operations such as play, stop and rewind; whereas the semantics would identify the content of the video-stream, for instance, the Service Information (SI) of the Digital Video Broadcasting (DVB) standard.
• The interface will require an Interface Definition Language (IDL) to abstract the underlying implementation of the method of interaction. The implementation of the method of interaction can be specific or based-on a middleware standard such as CORBA or OLE.
• The interface must be able to obtain information relating to the error-handling of the application.
• The IDL mentioned above must be able to support bound function calls must be ideally able to support simple return values, structured information, lists of simple or structured information, or streams of simple or structured information.
• An agent must be able to support multiple instances of such an interface. An implicit understanding by the agent core of both the knowledge and operational models of the application's interface is assumed.

  5.4.3 Attachment to internal components

Description

To enable the inclusion and peer-to-peer coordination between internal software components. This interface will probably be similar to way in which the external interface attaches the agent core to applications. In the internal case, the interface attaches parts of the agent core to each other. On the other hand, dissimilarities essentially arise from the fact that the relationships between these internal software components are peer-to-peer and will require knowledge-sharing and possibly blackboard techniques.

Example

An agent designer wishes to construct a network planning agent using standard application components. In this case the agent might well include two components: a neural-network learning component which can provide predictions of traffic levels; and an operations-research algorithm which can dimension a network given a set of traffic models and constraints. The agent core provides standard interfaces to enable the straightforward inclusion of these components and for the sharing of information between them.

Criteria

The following criteria are concerned with the interface within the agent core to included software components:

• The interface must be able to register events from internal software components and receive notifications from it. For example, learning functions can achieve confidence thresholds and notify the agent core of this occurrence. Management functions to enable the processing of the incoming internal events must be provided to the agent core.
• Interface (semantic and syntactic) registration and method of interaction as per external interface. These components will tend to register their requirements and utility, for example, such as those found in taxonomies of learning.
• The interface must be able to obtain information relating to the error-handling of the software components.
• Bound function calls must be ideally able to support simple return values, structured information, lists of simple or structured information, or streams of simple or structured information.
• The interface and the agent core together must provide facilities to support knowledge sharing between the agent core and the software components; and perhaps also between the software components themselves.

The unification of software components within the agent core is provided by a task architecture. The nature and implementation of this task architecture is not the subject of standardization.

5.4.4 Enabling Technologies

The following technologies deserve consideration for the realization of the interfaces.

• Content representation schemes. For example, electronic news-paper and TV news-on-demand services will require content-based indexing schemes as a form of content representation.
• Tools and technologies to support the definition and realization of the mapping between the knowledge model (e.g. KIF) and the syntactical model (e.g. object model) of the interface.
  

6. Example applications made possible by FIPA 1997 specification

6.1 Introduction

As an aid to those who will propose technologies the following paragraphs provide examples based on the scope of the four selected applications made possible by the availability of FIPA 1997 specification. It should be noted that by utilising the FIPA 1997 specification new and innovative applications can be brought to market.

FIPA is open to receive recommendations on how other applications or services might be served by this Call for Proposal and possible future calls made by FIPA.

6.2 Personal Assistant

A personal assistant is a software agent that acts semi-autonomously for and on behalf of a user, modeling the interest of the user and provide services to user or other people/PAs as and when required. For 1997 the intention is to construct a PA with a limited set of functionalities, using the FIPA specified technologies, as follows :

• Basic intelligent directory services
• Basic scheduling of meetings
• Basic multi-modal interaction with the system by the user
• Basic cooperative user-agent and agent-agent interaction (e.g. suggestive responses to user requests)
• Delivery of multi-media information to users anywhere, anyplace and anyhow.
• Information handling of services like e-mail filtering, sort, and forwarding, NNTP news, and HHTP documents.
• A plug ën play architecture for adding new services (as internal functions or as interfaces to existing value added services).

To illustrate some of the above characteristics a small application is outlined below.

An e-mail request for a meeting is received by the userís PA from an important customer, while the user is away from his desk. The agent notifies the user by GSM phone, using a text-to-speech conversion service to convey the message to him. For the meeting the user engages in a dialogue with the PA requesting that the agent sets up the meeting with a number of participants (e.g., finding out a convenient time frame and an appropriate location). This would involve the meeting scheduling and directory services of the PA.

As a preparation for the meeting a multi-media document is to be forwarded to each of the participants. Due to differences in the computer equipment, available to each participant, there is a need for conversion of the document (or parts there of) to formats like text (i.e. leaving out pictures etc.), so that comprehensible information becomes available to each participant. In addition some users have only shared access to multi-media facilities and these users must be notified of the information to be delivered. When appropriate network information is available the notification might include a specification of the location of the closest vacant multi-media facility (i.e., a Multi-Media PC) that will enable them to read the document. The agent is expected to initiate all these services. For the people unavailable, the agent will try to negotiate an arrangement with the corresponding personal user agents. In the event of failure or problems the agent will either have to return to the user for assistance or determine alternative actions.

6.3 Personal Travel Assistance

The agent standards established by FIPA in 1997 will enable the development of a first prototype of a fully functional PTA system. User input to the PTM and mini-PTM may be restricted to form-based textual input. Likewise, agent output to the user may be restricted to graphics and image display. Connection to existing travel services with defined API's and text-based interfaces (e.g. HTTP/HTML-based services) will be possible.

An example 1997 application of PTA is as follows:

A user queries a "personal assistant" (running on a portable device or on a personal computer) using natural language (voice recognition and/or typed text):

"I must meet M. Kane of Rosebud company in New York in the afternoon of the 29th of September. Plan me a trip for this appointment. I would like an answer by tomorrow evening, take my standard preferences into account."

The system is expected to take, at a minimum, the following actions:

• recognize the fact that the user will be in Chicago, that the meeting is in New York, and therefore contact a travel agency to plan a trip,
• book the trip via plane/train through an appropriate travel service,
• use a profile of the user to choose between means of transportation, company, comfort level and price,
• book a hotel, if necessary (depending on time of arrival/departure and also on user profile to choose hotel),
• return an itinerary of the planned trip within the given deadline,
• insert travel-related time in the agenda, together with an alarm-clock,
• notification of intra-city transportation means to be used:
  • intra-city means can be: bus, metro, taxi, car-rental etc.,
  • travel from home to airport/station (taking into account travel-time and real-time traffic information),
  • travel means to be used at destination: airport-hotel, hotel to appointment, appointment-entertainment.
• put a watchdog on train/plane schedules, warning for delayed/modified schedules via the user-preferred notification means (pager, SMS-GSM, fax ...), re-plan the trip if requested to do so by the user,
• survey traffic if car/taxi is to be used,
• if the user travels by car s/he can use an individual traffic guidance system
  

6.4 Audio/Visual Entertainment and Broadcasting

6.4.1 Overview

The need for information filtering and retrieval is necessary, in particular for digital broadcasting networks. The selection and storage of one's favorite choice from the great many programs on offer is practically impossible. The information has to be provided in a customized manner to suit a user's personal preferences (Profile). In order to implement the information filtering and retrieval, the semantic and syntactic content of the broadcasting data streams need to be made compatible to provide a consistent method for selection. It is important that the human interaction with the system must be "user friendly" by providing an intuitive human-system interface. These functionalities such as profiling, filtering and retrieving, and interfacing can be reinforced by introducing agent technologies. The possible applications that require these functionalities are: TV Broadcasting, Radio Broadcasting, Data Broadcasting (e.g., Weather forecasting, Stock Market Price), Electronic Newspaper, Commercial Database Service, Internet Service, Computer Aided Education, Video- and Multimedia-on-Demand Service, Entertainment, Home Automation, and so on.

The identified necessity for this application is as follows:

• Information Filtering and Retrieval
• Information Customization
• User Friendliness
• Home Automation - Education - Entertainment
• Information Compatibility

  6.4.2 Application: System Configuration and Capability

This application consists of the following three types of agents:

• interface agent
• profile agent
• filtering and retrieval agent

Interface Agent

• Interacts directly with user via natural language dialogue, browser and other modalities;
• Interprets the user's requests into agent communication language;
• Coordinates other agents to accomplish the goal;
• Presents the information in a user-friendly manner.

Profile Agent

• Maintains (i.e., generates, modifies and controls) the user's profile;
• Provides information on user's preferences (with content regulation) to filtering & retrieval agent.

• Filtering and Retrieval Agent
  • Filters and regulates the incoming information stream according to the information content representation, the user's profile and requests;
  • Retrieves the information requested by the user from data base referring to the profile.

6.5 Network management/provisioning

6.5.1 Introduction and Context

The following applications and their detailed descriptions are offered as examples of network provisioning and management applications that FIPA specifications will enable in 1997. They are chosen with recognition that they are useful, practical and that ongoing research and development exists which may fulfill some of their requirements and functionality. It should be noted that agents implemented from FIPA specifications are intended to exist within the context of ongoing network management technologies and standards initiatives, such as TMN and TINA. Agent technologies are intended to complement such activities by providing technological support to the computational and knowledge level tasks of integrating and coordinating applications and software components in an open-ended manner.

6.5.2 Application: Service provisioning, activation and resource allocation

The agent (or collection of agents) assists in the elicitation and fulfillment of customer requests for network services. These may take many forms: a large corporation constructing a corporate intranet, a cable-TV operator connecting a new home installation, to a consumer purchasing a home communication appliance from a retail point of sale, which needs to be connected to the home network and hence to the wider network.

These activities take place in the context of the operator's business model. The agent (D in Fig. 5), spans the business layer and the service layer. Typical steps in the process are shown below:

6.5.3 Application: Remote Autonomous Element Management

The agent (or collection of agents) perform a full spectrum of network element management and monitoring services. Considerable latitude is granted for the agent(s) to undertake autonomous actions both to respond to network fault conditions and to apply preventative measures. Many different networks may benefit from this agent-oriented approach: telephony, satellite, broadband video, wireless, etc.

These activities take place primarily in the context of the operator's network management operation. The agent (A in Fig. 5), operates primarily in the element management layer, but will require considerable interaction with entities in other layers. Typical steps in the process are shown below:

6.5.4 Application: Federated Customer Care

The agent (or collection of agents) assists in the elicitation and fulfillment of customer care requests. These could involve such examples as: a small business experiencing telephony service problems, a home video services subscriber with a billing problem or a large Internet Service Provider experiencing routing problems in connections to a backbone network.

These activities take place primarily in the context of the operator's business model, but will involve contact with entities within other layers, domains or networks. The agent (E in Fig. 5), spans the business layer and the service layer. Typical steps in the process are shown below:

7. 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 1996 to:

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

3. Bring 100 copies of their proposals to the 4th meeting in Torino, Italy.

4. Attend the meeting on 20-24 January 1997. Additionally, proponents should be prepared with visual aids for a brief (15 minutes) presentation of their proposal in the event it is requested.

In the submission the proponent should

• provide a description of their proposed technology and further should identify how that technology meets the relevant criteria;
• optionally identify and describe additional technologies which can be utilised to enhance the applications target of the FIPA 1997 specification.
• optionally state the proponent's position vis-a-vis the IPR 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 '97 meeting. Proposals received will be posted on the FIPA home page and will be made accessible for consultation by FIPA members.