FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS
FIPA
Agent Message Transport Protocol
for HTTP Specification
|
Document title |
FIPA Agent Message Transport Protocol for HTTP Specification |
||
|
Document number |
XC00084C |
Document source |
FIPA Agent Management |
|
Document status |
Experimental |
Date of this status |
2000/08/24 |
|
Supersedes |
None |
||
|
Contact |
fab@fipa.org |
||
|
Change history |
|||
|
2000/08/24 |
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 Message
Transport Protocol for HTTP
3 Informative
Annex A — Example
This document is part of the FIPA
specifications and deals with message transportation between inter-operating
agents. This document also forms part of the FIPA Agent Management
Specification [FIPA00023] and contains specifications for:
·
The transportation of
messages between agents using the Hypertext Transfer Protocol (HTTP - see
[RFC2616]).
This MTP is based on the transfer of data representing the entire agent message including the message envelope in a HTTP request. The HTTP data transfer is a two-step process: the sender makes a HTTP request and after receiving the data the receiver sends a HTTP response. The receiver then parses the message envelope and the message is handled according to the instructions and information given in the message envelope.
The name assigned to this
component is:
fipa.mts.mtp.http.std
A HTTP request comprises:
·
Request Line
- The request method type that must be POST.
- The request resource identification that must be a full URI (see [RFC1630]).
- The request version that must be HTTP/1.1.
·
Request Headers
- The mandatory parameter Content-Type: that must be "multipart/mixed" and must have a boundary parameter enclosed by double quotes. It should be anticipated that the boundary parameter may be “folded” as described in [RFC822] – hence parsers must be able to handle this type of encoding.
- The mandatory parameter Host: that must be in the form hostname or hostname:portnumber.
- The mandatory parameter Cache-Control: that must have the value no-cache.
- The mandatory parameter MIME-Version: that must have the value 1.0.
- The optional parameter Content-Length: that contains the size of the request body[1].
·
Request Body
The request body contains the agent message. The agent message has two components (separated as defined in [RFC2046] for multipart/mixed MIME content): a FIPA message envelope and a FIPA message body (the payload).
The encoded body must therefore contain at least two parts, the first part containing the FIPA message envelope, the second part containing the FIPA Message being sent. Each of the two parts must specify an encoding-level ContentType field which may be any MIME type (Implementations must assume that some parts of the multipart encoded content may contain raw binary data). Each of the two parts may contain other headers such as, for example, Content-Transfer-Encoding but the processing of these fields is not mandatory.
The charset used in headers and the boundary delimiter of the multipart encoding must be plain ASCII.
Where applicable the charset encoding of the FIPA Message must be specified as a charset parameter of the ContentType header. This charset parameter value must have the same value as the value of the envelope payload-encoding field.
The parts encoded in the multipart message body are enclosed between boundary delimiters. The boundary delimiter is formed from the boundary value specified as parameter for the ContentType header. The boundary value must be a sequence of maximum 70 ASCII chars. Each MIME part is to be considered enclosed between two occurrences of the sequence "CRLF--boundary value". The last boundary delimiter must be a boundary delimiter ending line and is formed from the usual boundary delimiter followed by the sequence "--", that is, "CRLF--boundary value--".
The envelope body encoding must therefore have the following structure:
- MIME headers (at least a MIME-Version header and a ContentType header that contains the boundary value).