Message Transport Model 2

Model 2 describes a TCP-like exchange of KQML-like messages. This model is derived from three primary sources of information.

[Bellman, 96a] (Attachment A) is Kirstie Bellman's March 20 slide that introduced the CAETI minimal architecture.
[Harbison, 96a] (Attachment B) is Karan Harbison's April 14 email elaboration of that slide.
[CAT, 96a] is the CAETI Architecture Team's May 8 draft document that describes the "CAETI minimal architecture (CMA)" in greater detail.

This model primarily attempts to follow the CAETI Architecture Team's draft [CAT, 96a]. However, where the three sources of information are inconsistent, consistency is maintained with [Bellman, 96a] and [Harbison, 96b]. (Thus, Model 2 more closely resembles Model 1 [Good, 96b] which was derived from just those two documents.) Model 2 also contains some recommended deviations from [CAT, 96a]. These deviations make the transport aspects of CMA more closely resemble TCP transmission than what is described in [CAT, 96a]. The rationale for this deviation is i) to make the message transmission part of the CMA more strongly resemble a well established data transmission protocol (TCP), and ii) to make a stronger separation of the concerns of message transmission and message content.

This section gives an English description of Model 2. It is intended to be simply a precise description of the CMA. The rationale for deriving this model from the source documents is given in the Derivation section, and the mathematical statement of the model is given in Mathematics section. The Issues Raised section summarized the various issues raised by this derivation and mathematical formulation.

CMA Purpose.

The purpose of the CMA is to enable CAETI applications to exchange messages.

Set of Processes.

The CAETI system is of a set of interacting processes. CAETI applications are processes.

Process Interaction.

CAETI processes are required to interact only by exchanging CMA messages.

TCP-Like Message Transport.

CAETI processes are required to exchange CMA messages only over connections that can be supported by TCP/IP. This does not rule out other means of interprocess communication.

Interprocess Connections.

A connection is a logical communication path that is identified by a pair of CAETI addresses.

CAETI Addresses.

There is a CAETI address space that identifies the end points of connections. Every element of the address space is unique.

Message Elements.

Every CMA message is composed of a sequence of ASCII characters. Messages are of variable length and potentially large.

KQML Message Syntax.

Every CMA message has the following syntax:

 <performative> ::= (<word> { <whitespace> :<word> <whitespace> <expression> }*)
 <expression> ::= <word> | <quotation> | <string> | (<word> { <whitespace> <expression> }*)
 <word> ::= <character><character>*
 <character> ::= <alphabetic> | <numeric> | <special>
 <special> ::= < | > | = | + | - | * | / | & | ^ | ~ | - | @ | $ | % | : | . | ! | ?
 <quotation> ::= '<expression> | `<comma-expression>
 <comma-expression> ::= <word> | <quotation> | <string> | ,<comma-expression> 
 				| (<word> { <whitespace> <comma-expression> }*)
 <string> ::= "<stringchar>*" | #<digit><digit>*"<ascii>*
 <stringchar> ::= \<ascii> | <ascii>-\-"

Note that the second form of <string> has an additional restriction: The number named by the <digit>s is how many <ascii> characters must follow. e.g. #5"abcde

Messages Types.

CAETI processes are required only to receive and respond to the following types of messages: tell, ask, do, subscribe, sorry. The type of the message is identified by the first <word> in the <performative>.

Message Parameters.

Message parameters are identified by the :<word> parts of a <performative>. Every CMA message must have both a sender and a receiver parameter, and it may contain some or all of the following parameters:

Parameter Description Default Examples

sender where the message is from none pa.caeti.org:2010

receiver where the message is to none sa@dodea.edu, http://foo.net/agent

language how the content is encoded text MIME, KIF, TOE

ontology the name of the ontology used in the content something appropriate for the language Student Academic Record

content the encoded representation of data to be passed none "math score = 98%"

reply-with whether a reply is expected, and if so, a label for the reply nil "bob's math score"

in-reply-to the expected label none "bob's math score"

Messages may contain any additional parameters, the meaning of which should be agreed upon by both sender and receiver. Parameters may appear in any order. Refer to the KQML specification for more detailed definitions of the syntax and semantics of these parameters.

Message Addressing.

There is a mapping from the sender and receiver parameters of messages into CAETI addresses (which are the end points of connections).

Message Delivery.

The sender parameter of every CMA message maps into the CAETI address from which the message was sent. If a CMA message is delivered, it is delivered to the CAETI address that is mapped from the receiver parameter in the message. This does not require that every CMA message be delivered nor that CMA messages be delivered in the order in which they were sent.

Parameter	Description	Default	Examples
sender	where the message is from	none	pa.caeti.org:2010
receiver	where the message is to	none	sa@dodea.edu, http://foo.net/agent
language	how the content is encoded	text	MIME, KIF, TOE
ontology	the name of the ontology used in the content	something appropriate for the language	Student Academic Record
content	the encoded representation of data to be passed	none	"math score = 98%"
reply-with	whether a reply is expected, and if so, a label for the reply	nil	"bob's math score"
in-reply-to	the expected label	none	"bob's math score"