FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS

 
Document title FIPA Specifications Policy
Document number f-out-00003A Document source FIPA Board of Directors
Document status Preliminary Date of this status 2000/08/10
Change history
2000/01/27 Complete rework
2000/08/10 FAB consistency and editorial

 

Forward

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

Introduction

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.

Contents

This document is divided into the following sections:

Specification Types and Status

Specification Types

There are two types of FIPA specification:

Specification Status

Every FIPA specification has a status. The possible values for status are Preliminary, Experimental, Standard, Deprecated and Obsolete.

Specification Identifiers

Internal Referencing

Every FIPA specification has a identifier with the following format:

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

External Referencing

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

FIPA specifications should be referenced in FIPA specifications and other documents in the following manner:

 
[FIPA00023] FIPA Agent Management Specification. Foundation for Intelligent Physical Agents, 2000.
http://www.fipa.org/specs/fipa000023/

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 may 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".

Specification Approval and Life Cycle

There are three types of document approval recognized by this process.

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:

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.

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

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 fab@fipa.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 Architecture Board.

Life Cycle

The following diagram shows the lifecycle of a FIPA specification:

Component Specification Issues

TBD. 

Profile Specification Issues

TBD.

Archival Methodology

TBD.