FOUNDATION FOR INTELLIGENT
PHYSICAL AGENTS
FIPA ACL Message Structure Specification
|
Document title |
FIPA ACL Message Structure Specification |
||
|
Document number |
XC00061D |
Document source |
FIPA TC C |
|
Document status |
Experimental |
Date of this status |
2000/08/01 |
|
Supersedes |
None |
||
|
Contact |
fab@fipa.org |
||
|
Change history |
|||
|
2000/08/01 |
Approved for Experimental |
||
© 2000 Foundation for Intelligent Physical Agents - http://www.fipa.org/
Geneva, Switzerland
|
Notice |
|
Use of the technologies described in this specification may infringe
patents, copyrights or other intellectual property rights of FIPA Members and
non-members. Nothing in this specification should be construed as granting
permission to use any of the technologies described. Anyone planning to make
use of technology covered by the intellectual property rights of others
should first obtain permission from the holder(s) of the rights. FIPA
strongly encourages anyone implementing
any part of this specification to determine first whether part(s)
sought to be implemented are covered by the intellectual property of others,
and, if so, to obtain appropriate licenses or other permission from the
holder(s) of such intellectual property prior to implementation. This
specification is subject to change without notice. Neither FIPA nor any of
its Members accept any responsibility whatsoever for damages or liability,
direct or consequential, which may result from the use of this specification. |
Foreword
The Foundation for Intelligent Physical Agents
(FIPA) is an international organization that is dedicated to promoting the
industry of intelligent agents by openly developing specifications supporting
interoperability among agents and agent-based applications. This occurs through
open collaboration among its member organizations, which are companies and
universities that are active in the field of agents. FIPA makes the results of
its activities available to all interested parties and intends to contribute
its results to the appropriate formal standards bodies.
The members of FIPA are individually and
collectively committed to open competition in the development of agent-based
applications, services and equipment. Membership in FIPA is open to any
corporation and individual firm, partnership, governmental body or
international organization without restriction. In particular, members are not
bound to implement or use specific agent-based standards, recommendations and
FIPA specifications by virtue of their participation in FIPA.
The FIPA specifications are developed through
direct involvement of the FIPA membership. The status of a specification can be
either Preliminary, Experimental, Standard, Deprecated or Obsolete. More detail about the process of
specification may be found in the FIPA Procedures for Technical Work. A
complete overview of the FIPA specifications and their current status may be
found in the FIPA List of Specifications. A list of terms and abbreviations
used in the FIPA specifications may be found in the FIPA Glossary.
FIPA is a non-profit association registered in
Geneva, Switzerland. As of January 2000, the 56 members of FIPA represented 17 countries worldwide. Further
information about FIPA as an organization, membership information, FIPA
specifications and upcoming meetings may be found at http://www.fipa.org/.
Contents
2.2 Participants in
Communication
3 Maintenance of the FIPA ACL Message Elements List
This document contains specifications for the FIPA ACL message elements including: the list of current FIPA ACL message elements, procedures for maintenance of this list, and criteria for adopting new elements in the list.
The objectives of standardizing the form of a FIPA compliant ACL
message are:
·
To help ensure interoperability by providing a standard set of ACL
message structure, and,
·
To provide a well-defined process for maintaining this set.
A FIPA ACL message contains a set of one or more message elements. Precisely which elements are needed for effective agent communication will vary according to the situation; the only element that is mandatory in all ACL messages is the performative, although it is expected that most ACL messages will also contain sender, receiver and content elements.
If an agent does not recognize or is unable to process one or more of the elements or element values, it can reply with the appropriate not-understood message.
Specific implementations are free to include user-defined message elements other than the FIPA ACL message elements specified in Table 1. The semantics of these user-defined elements is not defined by FIPA, and FIPA compliance does not require any particular interpretation of these elements.
Some elements of the message might be omitted when their value can be deduced by the context of the conversation. However, FIPA does not specify any mechanism to handle such conditions, therefore those implementations that omit some message elements are not guaranteed to interoperate with each other.
The full set of FIPA ACL message elements is shown in Table 1 without regard to their specific encodings in an implementation. FIPA-approved encodings and element orderings for ACL messages are given in other specifications. Each ACL message representation specification contains precise syntax descriptions for ACL message encodings based on XML, text strings and several other schemes.
A FIPA ACL message corresponds to the abstract element message payload identified in the [FIPA00001].
|
Element |
Category of Elements |
|
performative |
Type
of communicative acts |
|
sender |
Participant in communication |
|
receiver |
Participant in communication |
|
reply-to |
Participant in communication |
|
content |
Content of message |
|
language |
Description of Content |
|
encoding |
Description of Content |
|
ontology |
Description of Content |
|
protocol |
Control of conversation |
|
conversation-id |
Control of conversation |
|
reply-with |
Control of conversation |
|
in-reply-to |
Control of conversation |
|
reply-by |
Control of conversation |
Table 1: FIPA ACL Message Elements
The
following terms are used to define the ontology and the abstract syntax of the
FIPA ACL message structure:
·
Frame. This is the mandatory name of this entity, that must be used to
represent each instance of this class.
·
Ontology. This is the name of the
ontology, whose domain of discourse includes their elements described in the
table.
·
Element. This identifies each component
within the frame. The type of the
element is defined relative to a particular encoding. Encoding specifications
for ACL messages are given in their respective specifications.
·
Description. This is a natural language
description of the semantics of each element.
Notes are included to clarify typical usage.
·
Reserved
Values. This is
a list of FIPA-defined constants associated with each element. This list is typically defined in the
specification referenced.
All of
the FIPA message elements share the frame and ontology shown in Table 2.
|
Frame |
FIPA-ACL-Message |
|
Ontology |
FIPA-ACL |
Table 2: FIPA ACL Message Frame and Ontology
|
Element |
Description |
Reserved Values |
|
performative |
Denotes the type of the communicative act
of the ACL message |
See [FIPA00037] |
Notes: The performatives is a required
element of all ACL messages. Developers are encouraged to use the FIPA standard
performatives (see [FIPA00037]) whenever possible.
|
Element |
Description |
Reserved Values |
|
sender |
Denotes the identity of the sender of the
message, i.e. the name of the agent of the communicative act. |
|
Notes: The sender element will be an
element of most ACL messages. It is
possible to omit the sender if, for example, the agent sending the ACL message
wishes to remain anonymous. The sender refers to the agent which performs the
communicative act giving rise to this ACL message.
|
Element |
Description |
Reserved Values |
|
receiver |
Denotes the identity of the intended
recipients of the message. |
|
Notes: Ordinarily, the receiver will be
a part of every ACL message. It is only
permissible to omit the receiver if the message recipient can be reliably
inferred from context, or in special cases such as the embedded ACL message in
proxy and propagate.
The
receiver may be a single agent name, or a non-empty set of agent names. The
latter corresponds to the situation where the message is multicast. Pragmatically, the semantics of this
multicast is that the sender intends the message for each recipient of the CA
encoded in the message. For example, if an agent performs an inform act with a
set of three agents as receiver, it denotes that the sender intends each of
these agents to come to believe the content of the message.
|
Element |
Description |
Reserved Values |
|
reply-to |
This element indicates that subsequent
messages in this conversation thread are to be directed to the agent named in
the reply-to element, instead of to the agent named in the sender element. |
|
|
Element |
Description |
Reserved Values |
|
content |
Denotes the content of the message;
equivalently denotes the object of the action. |
|
Notes:
Most ACL messages require a content expression. Certain ACL message types, such
as cancel, have an implicit content, especially in cases of using
conversation-id or in-reply-to.
|
Element |
Description |
Reserved Values |
|
language |
Denotes the language in which the content
element is expressed. |
See [FIPA00007] |
Notes: The ACL content element is
expressed in a formal language. This field may be omitted if the agents
receiving the message can be assumed to know the language of the content
expression.
|
Element |
Description |
Reserved Values |
|
encoding |
Denotes the specific encoding of the
content language expression. |
See [FIPA00007] |
Notes: The content expression might be
encoded in several ways. The encoding element is optionally used to specify
this encoding to the recipient agent. If the encoding element is not present,
the encoding will be specified in the message envelope that encloses the ACL
message.
|
Element |
Description |
Reserved Values |
|
ontology |
Denotes the ontology(s) used to give a
meaning to the symbols in the content expression. |
|
Notes: The ontology(s) is/are used in conjunction
with the language element to support the interpretation of the content
expression by the receiving agent. In
many situations, the ontology(s) will be commonly understood by the agent
community, and so this message element may be omitted.
|
Element |
Description |
Reserved Values |
|
protocol |
Denotes the interaction protocol that the
sending agent is employing with this ACL message. |
See [FIPA00025] |
Notes:
The protocol
message element defines the interaction protocol in which the ACL message is
generated. This element is optional; however, developers are advised that
employing ACL without the framework of an interaction protocol (and thus
directly using the ACL semantics to control the agent’s generation and
interpretation of ACL messages) is an extremely ambitious undertaking.
|
Element |
Description |
Reserved Values |
|
conversation-id |
Introduces an expression (a conversation
identifier) which is used to identify the ongoing sequence of communicative
acts that together form a conversation. |
|
Notes:
An agent may
optionally tag ACL messages with a conversation identifier to manage its
communication strategies and activities. Typically this will allow an agent to
identify individual conversations with multiple agents. It will also allow
agents to reason across historical records of conversations.
|
Element |
Description |
Reserved Values |
|
reply-with |
Introduces an expression that will be used
by the responding agent to identify this message. |
|
Notes: This message element is designed to be used
to follow a conversation thread in a situation where multiple dialogues occur
simultaneously. For example, if agent i
sends to agent j a message which contains:
reply-with <expr>
Agent j will respond with a message
containing:
in-reply-to <expr>
|
Element |
Description |
Reserved Values |
|
in-reply-to |
Denotes an expression that references an
earlier action to which this message is a reply. |
|
Notes: See notes for Section 2.5.3, Reply
With.
|
Element |
Description |
Reserved Values |
|
reply-by |
Denotes a time and/or date expression
which indicates the latest time by which the sending agent would like to have
received a reply. |
|
Notes:
The time will be
expressed according to the sender’s view of the time on the sender’s platform.
The reply message can be identified in several ways: as the next sequential
message in an interaction protocol, through the use of reply-with, through the
use of a conversation-id
and so forth. The way that the reply message is identified is determined by the
agent implementer.
The most
effective way of maintaining the FIPA ACL message element list is through the
use of the elements themselves by different agent developers. This is the most
direct way of discovering possible bugs, errors, inconsistencies, weaknesses,
possible improvements, as well as capabilities, strengths, efficiency etc.
In order
to collect feedback on the FIPA ACL message elements in this document and to
promote further research, FIPA encourages coordination among designers, agent
developers, and FIPA members. FIPA will make an annual report on the use of the
ACL element in this document.
FIPA
will designate a Technical Committee (TC) to maintain the FIPA ACL message
elements. This TC will manage the FIPA ACL message elements and will be
responsible for the following items:
·
Collecting
feedback and the comments about the FIPA ACL elements. Depending on interest,
the TC may organize more specific Working Groups. These groups would be
responsible for maintaining public lists referring projects and people that are
currently using ACL elements of interest.
·
Inviting
contributions in various forms: e-mail comments, written reports, papers,
technical documents, and so forth. The current email address of the TC is: comm@fipa.org
·
All
TC members will be notified about contributions, comments or proposed changes
and should be able to access them.
·
The
proposed updates to the FIPA ACL elements must be discussed and approved during
an official FIPA meeting, in order that the FIPA community may be involved with
and informed of all of the FIPA approved FIPA ACL elements in this document
library.
To
populate the FIPA ACL element list, it is necessary to set some basic
guidelines for the selection of specific FIPA ACL elements. The minimal
criteria that must be satisfied for a FIPA ACL element to be FIPA compliant
are:
·
Substantial
and clear documentation must be provided,
·
The
message element must not duplicate an existing element, and,
·
The
usefulness of a new ACL element should be made clear.
The
latest version of this document may be found on the FIPA web site
(http://www.fipa.org). Comments and questions regarding this document and the
specification therein should be addressed to agent_comm@fipa.org.
[FIPA00001] FIPA Abstract
Architecture Specification. Foundation for
Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00001/
[FIPA00007] FIPA Content
Languages Library Specification. Foundation for
Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00007/
[FIPA00025] FIPA Interaction
Protocol Library Specification. Foundation for
Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00025/
[FIPA00037] FIPA Communicative Act Library Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00037/