ase connection X" in any suitable language used in layer element A. Its TCAP agent translates the order to information in a TCAP message. On the SSP side, the TCAP agent interprets the received message and translates it to a report to its SSP actor that says "SCP in A tells you to release the connection X," using any suitable lan- 11 "Transaction capabilities application part". TCAP has evolved from the ACSE, ROSE, and ASN. 1 standards of the OSI application layer. TCAP relies on SCCP for connectivity. SCCP is a kind of transport layer in SS7. 2.3 Agents and Actors guage in B. The scenario also indicates some of the parameters that must be included in the TCAP message for this scenario to succeed: an operation name, relevant operation parameters, a primitive type parameter, a detecting actor address and possibly a generating actor address (we also say that an operation name concatenated with a primitive type is a primitive name). The actor-agent separation principles offers an alternative to how to specify protocols: The method applied in most existing standards is to produce a single protocol specification that describes how an observer who stands in between the layer elements would interpret the messages, and which conclusions he would draw about what the actors do. Such protocol specifications always tend to be very voluminous and complex, and therefore difficult to interpret. The actor-agent separation principle can be applied for all protocols. It sepa- rates a conventional control protocol specification into one part that describes the communication between actors, one part that describes the communication between agents, and one (language-dependent) part that describes how the events in an actor-agent interface are mapped on messages. For example, the communication between actors in the above scenario says simply "release con- nection X." We regard such an expression as an event in the abstract protocol between actors. The corresponding TCAP message (part of the TCAP message protocol) is obviously consider