FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS
||Date of this
||FAB consistency and
This is an official document of FIPA, the Foundation for Intelligent Physical
Agents. Information about FIPA and FIPA documents, including copyright
notices, may be found on the world-wide web at http://www.fipa.org/.
This document defines the policies and procedures for the creation,
approval, and management of FIPA specifications. It is hereafter referred
to as the "FIPA Specifications Policy". This policy is established
to facilitate the evolution of the FIPA specifications, and support the
re-use of specification elements.
The primary mission of FIPA is to promote the use of multi-agent technologies
in the creation of complex software systems, and to foster the interoperability
of such systems by exploiting the communicative capabilities of multi-agent
techniques. To achieve these missions, FIPA identifies the best practices
in the computer science and software engineering of multi-agent systems
and creates specifications which codify these practices.
In many cases the identification of best practice involves collaborative
experimental work. To facilitate this work, FIPA may develop experimental
specifications which allow FIPA members and others to conduct joint experimental
programs using novel or unproven technologies. Some - perhaps most - of
these activities will eventually lead to the creation of standards. FIPA
standards represent proven technologies which can form the basis for commercial
product development and deployment, as well as the creation of supporting
businesses in the areas of tools, training, and software components.
Over time, existing specifications may be updated to correct deficiencies
and incorporate new material. They may also be superseded, as new technologies
emerge which displace earlier ones. This document defines the
procedures for managing the life cycle of FIPA specifications including changes
to the text and the status of each specification.
This document is divided into the following sections:
Specification Name Spaces
Specification Types and Status
Specification Structure, Formats and Storage
Component Specification Issues
Profile Specification Issues
Informational Specification Issues
Specification Types and Status
There are two types of FIPA specification:
A component specification describes a logically self-contained specification
for a technology or tightly-coupled set of technologies. It is, pragmatically,
indivisible, particularly with respect to establishing conformance.
- A profile specification describes how a set of component specifications
may be used to collectively define a higher-order entity for the purposes
of conformance. [We do not anticipate the need to generalize this so that
profiles might be defined in terms of other profiles.]
Every FIPA specification has a status. The possible values for status are
Preliminary, Experimental, Standard, Deprecated and Obsolete.
- A Preliminary specification is made available to FIPA members and others as
part of the process of developing an experimental or standard specification.
Any FIPA working group or committee may publish a Preliminary specification.
By default, if after six months a Preliminary specification has not been superseded by another
Preliminary, Experimental or Standard specification, it will be reclassified as
Obsolete. [Note: An earlier draft of this document used the term Draft
for this specification status. The term Draft should no longer be used. Instead,
a draft refers to any specification in the course of writing or revision, without
regard to its status in the FIPA specification process.]
An Experimental specification represents material which FIPA believes is suitable
for experimental implementation and interoperability testing. An Experimental
specification may be published by any FIPA Technical Committee with the
approval of the FIPA Architecture Board. By default, if after two years an
Experimental specification has not been superseded by another Experimental or
Standard specification, it will be reclassified as Obsolete.
- A Standard specification represents material which FIPA believes is stable,
mature, well-understood and ready for commercial implementation and deployment.
Commercial and government agencies should be able to cite compliance with
FIPA Standard specifications in Requests for Proposals (RFPs). A Standard
specification may be published by any FIPA Technical Committee upon approval by
of the FIPA membership and the final approval
of the FIPA Architecture Board. Standard specification do not have an
A Standard specification may be superseded by another Standard specification, but this in itself will
not cause the original specification to become Deprecated. (This is because
existing products may still be reliant upon it.) A FIPA Standard specification may be
reclassified as Deprecated by a vote of the FIPA membership and the unanimous
approval of the FIPA Architecture Board.
- A Deprecated specification is a FIPA
specification which is scheduled for reclassification
as Obsolete. When a FIPA specification is to be retired, it is reclassified
as Deprecated and an expiration date
is recorded in the specification's header. When that date arrives, the
specification is automatically reclassified as Obsolete. A specification which has been classified as
Deprecated may be reclassified with its original status subject to the
"Specification Approval" process described below.
- An Obsolete specification represents material which previously had some other
classification but which is no longer valid. The specification remains in the
FIPA repository indefinitely. There is no provision for reclassifying
an Obsolete specification; if this is desired, a new Preliminary should be published
and moved through the specification life cycle as appropriate.
Every FIPA specification has a identifier with the following format:
One of "P", "X", "S", "D" or "O", indicating a Preliminary,
Experimental, Standard, Deprecated and Obsolete specification.
One of "C" and "P", indicating a Component or Profile specification.
A five digit decimal number, with leading zero fill. Numbers are assigned
sequentially for all specifications. Numbers are assigned by the FIPA
Architecture Board, or electronically by a mechanism approved by the Architecture
The same specification may be published in a number of formats. Each file
name consists of the identifier followed by a dot (".") and a file type.
(HTML specifications should use the type ".html".) File type and status
codes and letter suffices must be upper-case. File types will normally
be in lower case, but may follow the convention established for specifications
of that type.
An optional letter suffix, indicating a revised draft of a specification.
An initial component Preliminary specification would be assigned a number
(e.g. "00123") and receive the identifier "PC00123". If any new drafts
are published, they would be identified as "PC00123A", "PC00123B", and
so forth. When the material is deemed fit for publication as an experimental
specification, the file will be identified as "XC00123". In the event that
it becomes a standard, the new identifier would be "SC00123".
When a document becomes Obsolete, it retains its identifier, so that
existing references continue to work correctly.
However, when a FIPA specification is to be referenced
in other documents, including FIPA specifications, the specification is given an
"official" identifier. This consists of the prefix "FIPA"
followed by the five digit decimal number which has been assigned to the
specification. For example, "PC00023" is specification 00023's
internal reference, but "FIPA00023" is its official, external
FIPA specifications should be
referenced in FIPA specifications and other documents in the following manner:
||FIPA Agent Management Specification.
Foundation for Intelligent Physical Agents, 2000.
Specification Structure, Formats and Storage
The structure of a FIPA specification is given in the
sample template in [f-out-00011], available from http://www.fipa.org/docs/output/f-out-00011/.
This format and style must be adhered to. Every FIPA specification must include a
Copyright Notice and Foreword paragraph exactly as
shown in [f-out-00011].
Once a FIPA specification has been published, the document body
not be changed in any way.
If it becomes necessary, the document identifier may be updated and the
resulting document may be stored in the FIPA repository (see below) replacing
the original document. In all such cases, the reason for the change must
be added to the "Change history" field of the specification header. Examples
of reasons for changes are:
When a change occurs to a document, it's version letter
should be incremented in the file name and in "Document number".
The specification has been superseded by a new specification. In this cases, the
"Document status" field would be changed to Obsolete, the "Date of this
status" field would be updated and an explanation would we added to the
"Change history" field.
This Experimental specification has expired and it has not progressed
to Standard status in the period allotted (normally two years). The
status" field would be changed to Obsolete, the "Date of this status"
be updated and an explanation would be added to the "Change history"
Specification Approval and Life Cycle
There are three types of document approval recognized by this process.
A Technical Committee (TC) is a group of FIPA domain experts representing at
least two FIPA member organizations and duly chartered by the FIPA Architecture
Board for the purpose of working on a particular subject.
Each TC is expected to adopt appropriate rules for conducting its
business. The approval of a TC may be expressed by its chair person in a variety of ways: by email to the FIPA
members mailing list, by submitting a resolution to the FIPA board for
inclusion in the resolutions of a FIPA meeting and by other methods approved
by the FIPA Board of Directors.
The approval of the FIPA members is required for the creation of Standard documents, to
make specifications Obsolete and
to re-introduce a Deprecated specification.
Multiple related documents may be approved or obsoleted together.
Approvals of this kind are carried out by balloting the FIPA members
using electronic mail. The ballot is conducted by the chair of the TC (in the case of publishing a
Standard specification) or the chair
of the FIPA Architecture Board (in the case of making a specification Obsolete).
The responsible person ("organizer"), or a duly designated delegate, conducts
the ballot as follows:
Each FIPA member sends to the organizer one email ballot with the following
The organizer makes the specification(s) available through the FIPA repository.
The organizer sends a ballot notice to all FIPA members, using the most
recently available representative contact information. The notice
is also posted in the Members Lounge area of the FIPA web site. The
notice identifies the specifications to be voted on (including the URL for each
specification), describes the desired status for the documents and provides
a brief explanation for the ballot. It requests each FIPA member
organization to submit a vote by email to the organizer by a stated due
date, not less than 21 days after the transmission of the ballot notice.
(The organizer is advised to use the "Return receipt" email mechanism to
verify that all members receive the ballot notice.)
the name of the organization,
the name and email address of the representative,
the references to the documents being voted upon,
a vote, one of Approve, Disapprove, Disapprove with Comments or Abstain,
in the case of a vote of Disapprove with Comments, a description of the
changes to the documents or other actions which could lead to an Approve vote,
an indication as to which parts of the email ballot are to be treated as
private. (Unless otherwise indicated, all ballot information may
be treated as public.)
The ballot concludes on the due date described above. It may be concluded
before that date if either: (1) a valid ballot has been received from every
FIPA member, or (2) if the organizer chooses to cancel the ballot.
A cancellation may be called for any reason; two obvious examples are:
a large number of Disapprove votes have been received and the organizer
believes that the ballot will fail,
one or more Disapprove with Comments votes have been received and the
organizer determines that it is necessary to amend the document to address
the issues raised in these votes.
It is important to recognize that this procedure invoked in only two common cases:
when a FIPA specification is to become a Standard and when a specification is to be retired. The first can occur only when a FIPA
or collection of specifications, is "stable, mature, well-understood, and
ready for commercial implementation and deployment". By establishing
a standard, FIPA is staking its reputation on the fact that the work is
suitable for mission-critical commercial use and that real-world implementations
exist. It seems reasonable to allow the members of FIPA to consult with they colleagues and review material carefully before approving this
step. By the same token, retiring a specification should require even
more careful consideration. The final case is when a "retirement"
is to be rescinded, which is likely to be even more uncommon.
When a ballot is concluded, the organizer will send an email to all FIPA
members giving the results of the ballot. This email will include
the number of votes received in each category and the overall result: Approved or
Disapproved. For publishing a Standard specification, approval requires
that the number of Approved votes is greater than the number of Disapproved votes. For
make a specification Obsolete, approval requires that the number of Approved votes is at least one greater than half of all eligible voting
members of FIPA. The email announcing the results will also be posted
on the FIPA web site.
FIPA Architecture Board Approval
The approval of the FIPA Architecture Board is required for the establishment
of FIPA Technical Committees and Working Groups and for the publication of all documents other
than Preliminary documents. A request for the FIPA Architecture Board
to approve a document is made by sending electronic mail to the mailing
list firstname.lastname@example.org, or as otherwise directed by the FIPA Architecture
Board. The decisions of the FIPA Architecture Board are communicated by
electronic mail to all FIPA members.
See [f-out-00004] for the working policies of the FIPA
The following diagram shows the lifecycle of a FIPA specification:
Component Specification Issues
Profile Specification Issues