Forward

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

• Specification Name Spaces
• Specification Types and Status
• Specification Identifiers
• Internal Referencing
• External Referencing
• Specification Structure, Formats and Storage
• Specification Approval
• Specification Lifecycle
• Component Specification Issues
• Profile Specification Issues
• Library Issues
• Informational Specification Issues
• Archive methodology

Specification Types and Status

Specification Types

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

Specification Status

• 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 expiration date.  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.

Specification Identifiers

Internal Referencing

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

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

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:

• 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 "Document status" field would be changed to Obsolete, the "Date of this status" field would be updated and an explanation would be added to the "Change history" field.

Specification Approval and Life Cycle

• 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:
  
  • 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.)
    
  Each FIPA member sends to the organizer one email ballot with the following information:
  
• 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.
  

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

See [f-out-00004] for the working policies of the FIPA Architecture Board.

Life Cycle

Component Specification Issues

TBD. 

Profile Specification Issues

TBD.

Archival Methodology

TBD.