FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

FIPA ACL Message Structure Specification

Document title	FIPA ACL Message Structure Specification
Document number	XC00061F	Document source	FIPA TC Communication
Document status	Experimental	Date of this status	2002/11/01
Supersedes	None
Contact	fab@fipa.org
Change history	See Informative Annex A — ChangeLog

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 where appropriate.

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 Document Policy [f-out-00000] and the FIPA Specifications Policy [f-out-00003]. A complete overview of the FIPA specifications and their current status may be found on the FIPA Web site.

FIPA is a non-profit association registered in Geneva, Switzerland. As of June 2002, the 56 members of FIPA represented many countries worldwide. Further information about FIPA as an organization, membership information, FIPA specifications and upcoming meetings may be found on the FIPA Web site at http://www.fipa.org/.

Contents

1 Scope. 1

2 FIPA ACL Message Structure. 2

2.1 Type of Communicative Act 3

2.1.1 Performative. 3

2.2 Participants in Communication. 3

2.2.1 Sender 3

2.2.2 Receiver 3

2.2.3 Reply To. 4

2.3 Content of Message. 4

2.3.1 Content 4

2.4 Description of Content 4

2.4.1 Language. 4

2.4.2 Encoding. 4

2.4.3 Ontology. 4

2.5 Control of Conversation. 5

2.5.1 Protocol 5

2.5.2 Conversation Identifier 5

4 Informative Annex A — ChangeLog. 8

4.1 2002/10/01 - version F by TC X2S. 8

1 Scope

This document contains specifications for the FIPA ACL message parameters. 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.

2 FIPA ACL Message Structure

A FIPA ACL message contains a set of one or more message parameters. Precisely which parameters are needed for effective agent communication will vary according to the situation; the only parameter 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 parameters.

If an agent does not recognize or is unable to process one or more of the parameters or parameter values, it can reply with the appropriate not-understood message.

Specific implementations are free to include user-defined message parameters other than the FIPA ACL message parameters specified in Table 1. The semantics of these user-defined parameters is not defined by FIPA, and FIPA compliance does not require any particular interpretation of these parameters. The prefatory string “X-” must be used for the names of these non-FIPA standard additional parameters.

Some parameters 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 parameters are not guaranteed to interoperate with each other.

The full set of FIPA ACL message parameters is shown in Table 1 without regard to their specific encodings in an implementation. FIPA-approved encodings and parameter 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 parameter message payload identified in the [FIPA00001].

Parameter	Category of Parameters
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 Parameters

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 parameters described in the table.

· Parameter. This identifies each component within the frame. The type of the parameter 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 parameter. Notes are included to clarify typical usage.

· Reserved Values. This is a list of FIPA-defined constants associated with each parameter. This list is typically defined in the specification referenced.

All of the FIPA message parameters share the frame and ontology shown in Table 2.

Frame	fipa-acl-message
Ontology	fipa-acl

Table 2: FIPA ACL Message Frame and Ontology

2.1 Type of Communicative Act

2.1.1 Performative

Parameter	Description	Reserved Values
performative	Denotes the type of the communicative act of the ACL message	See [FIPA00037]

Notes: The performative parameter is a required parameter of all ACL messages. Developers are encouraged to use the FIPA standard performatives (see [FIPA00037]) whenever possible.

2.2 Participants in Communication

2.2.1 Sender

Parameter	Description	Reserved Values
sender	Denotes the identity of the sender of the message, that is, the name of the agent of the communicative act.

Notes: The sender parameter will be a parameter of most ACL messages. It is possible to omit the sender parameter if, for example, the agent sending the ACL message wishes to remain anonymous. The sender parameter refers to the agent which performs the communicative act giving rise to this ACL message.

2.2.2 Receiver

Parameter	Description	Reserved Values
receiver	Denotes the identity of the intended recipients of the message.

Notes: Ordinarily, the receiver parameter will be a part of every ACL message. It is only permissible to omit the receiver parameter 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 parameter 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.

2.2.3 Reply To

Parameter	Description	Reserved Values
reply-to	This parameter indicates that subsequent messages in this conversation thread are to be directed to the agent named in the reply-to parameter, instead of to the agent named in the sender parameter.

2.3 Content of Message

2.3.1 Content

Parameter	Description	Reserved Values
content	Denotes the content of the message; equivalently denotes the object of the action. The meaning of the content of any ACL message is intended to be interpreted by the receiver of the message. This is particularly relevant for instance when referring to referential expressions, whose interpretation might be different for the sender and the receiver.

Notes: Most ACL messages require a content expression. Certain ACL message types, such as cancel, have an implicit content, especially in cases of using the conversation-id or in-reply-to parameters.

2.4 Description of Content

2.4.1 Language

Parameter	Description	Reserved Values
language	Denotes the language in which the content parameter is expressed.	See [FIPA00007]

Notes: The ACL content parameter is expressed in a formal language. This field may be omitted if the agent receiving the message can be assumed to know the language of the content expression.

2.4.2 Encoding

Parameter	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 parameter is optionally used to specify this encoding to the recipient agent. If the encoding parameter is not present, the encoding will be specified in the message envelope that encloses the ACL message.

2.4.3 Ontology

Parameter	Description	Reserved Values
ontology	Denotes the ontology(s) used to give a meaning to the symbols in the content expression.

Notes: The ontology parameter is used in conjunction with the language parameter to support the interpretation of the content expression by the receiving agent. In many situations, the ontology parameter will be commonly understood by the agent community and so this message parameter may be omitted.

2.5 Control of Conversation

2.5.1 Protocol

Parameter	Description	Reserved Values
protocol	Denotes the interaction protocol that the sending agent is employing with this ACL message.	See [FIPA00025]

Notes: The protocol parameter defines the interaction protocol in which the ACL message is generated. This parameter 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.

Any ACL message that contains a non-null value for the protocol parameter is considered to belong to a conversation and it is required to respect the following rules:

· the initiator of the protocol must assign a non-null value to the conversation-id parameter,

· all responses to the message, within the scope of the same interaction protocol, should contain the same value for the conversation-id parameter, and,

· the timeout value in the reply-by parameter must denote the latest time by which the sending agent would like to have received the next message in the protocol flow (not be confused with the latest time by which the interaction protocol should terminate).

2.5.2 Conversation Identifier

Parameter	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 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.

It is required the usage of globally unique values for the conversation-id parameter in order to allow the participants to distinguish between several concurrent conversations. A simple mechanism to ensure uniqueness is the concatenation of the globally unique identifier of the sender agent to an identifier (for example, a progressive number) that is unique within the scope of the sender agent itself

2.5.3 Reply With

Parameter	Description	Reserved Values
reply-with	Introduces an expression that will be used by the responding agent to identify this message.

Notes: The reply-with parameter 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>

2.5.4 In Reply To

Parameter	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.

2.5.5 Reply By

Parameter	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 receive 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 the reply-with parameter, through the use of a conversation-id and so forth. The way that the reply message is identified is determined by the agent implementer.

3 References

[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/

4 Informative Annex A — ChangeLog

4.1 2002/10/01 - version F by TC X2S

Page 1, line 64: Removed references to maintenance procedures and inclusion criteria

Page 2, line 83: Added requirement that additional parameters have the “X-“ prefix

Page 4, line 148: Specified that the content is intended to be interpreted by the receiver

Page 5, line 178: Added requirements to control the conversations

Page 5, line 184: Added requirement that conversation-id parameter be a globally unique identifier

Page 7, lines 222-260: Removed section 3 on maintenance of FIPA ACL