The various IM2000 protocols have a common structure and common transport layer requirements.
The IM2000 protocols are client-driven, authenticated, protocols that permit multiple non-overlapping transactions within a single session. The identity of the client and the server vary according to the protocol. Transactions are non-overlapping in that only one transaction may be outstanding in a session at any given time.
The protocols operate as follows:
A client establishes a transport-layer connection to a message store to establish a session. Initially, the session is in the unauthenticated state.
The client performs zero or more transactions.
Some types of transactions may be permitted only when the session is in the authenticated state. To switch to that state, the client attempts an authentication transaction, specific to the protocol. If the server allows the authentication transaction to succeed the session enters the authenticated state, otherwise it enters the unauthenticated state.
To terminate the session cleanly, the client terminates the transport-layer connection at the end of a transaction. (Termination of the transport-layer connection in the middle of a transaction is an unclean session termination. Servers must abort the transaction that is in progress if this occurs.)
Transactions comprise a sequence of one or more non-overlapping command and response pairs.
A transaction comprises either
Each command and response is a single Protocol Data Unit, transmitted via the transport layer.
All response PDUs comprise some common elements:
Clients must only use the transaction abort flag in a response PDU to determine whether a transaction is being aborted. They must not use the status code to determine this. An error response may, depending from the type of transaction, be permitted to occur within a transaction that comprises a sequence of multiple commands and responses, without aborting the transaction.
IM2000 protocols require a transport layer that is capable of reliable, sequenced, bidirectional, half-duplex, transmission of PDUs. The protocols can be layered over either stream-based or message-based protocols.
The protocols can thus be transported via TCP (for general Internet use), or via an operating system's local stream-based or message-based interprocess communication facility (such as, for example, named pipes).
For stream-based transport protocols, each PDU is transmitted across the transport layer as a stream of octets preceded by a 4-octet word (in "big-endian" network order) denoting the length (not including that word itself) in octets of the PDU.
For message-based transport protocols, the length of each PDU is encapsulated in the message itself, and is not otherwise explicitly transmitted.
Clients, servers, and transport protocols must support PDUs up to 64KiB long, and must be capable of skipping PDUs that are too long for them to handle without affecting either the status of the session or the correct handling of further PDUs.
Transport protocols that fragment PDUs must do so transparently. As far as clients and servers are concerned, PDUs are transported en bloc.
Sessions begin with a command PDU sent from the client to the server. This permits transport protocols such as TCP to perform the optimization of sending the completion of the connection handshake and the command PDU together in a single network layer datagram.
Transport layer security for the IM2000 protocols is provided by encrypting the octet streams in both directions. As far as the protocols are concerned, this is done entirely transparently. The protocols have no "home grown" encryption mechanisms.
When the transport layer is TCP (for general Internet use), an IM2000 service has three transport-level security options:
The protocol is transported in cleartext form.
This is suitable for use where the communications path between the client and the server is trusted, e.g. the entirety of the path is either under the control of the client's owner or of the server's owner.
The protocol is transported via an SSH tunnel.
This is suitable for use where the communications path between the client and the server is not trusted, e.g. parts of the path are not under the control of the owners of either end, and there is a prior relationship between both ends (such as between recipients and the owners of their recipient notification agents or between originators and the owners of the message stores). It is not used for transport of protocols where two entities that have no prior relationship communicate.
Mechanisms are not provided for the negotiation or advertisement of such services. Server owners are expected to inform client owners of the availability of SSH tunnelling as part of making the private service arragements between them.
The protocol is transported using SSL.
This is suitable for use where the communications path between the client and the server is not trusted, e.g. parts of the path are not under the control of the owners of either end, and there is no prior relationship between both ends (such as between recipients and message stores and between message stores and recipient notification agents).
Mechanisms are provided for the providers of services to signal that they are provided over SSL as well as in cleartext form. Clients should use the SSL alternative where available in such cases.