 an association for an invocation (and have to release it afterwards). This had to be considered when defining the specified agent interface (SAG) of TCAP. 2. Since TCAP was developed for supporting call handling in public networks, i.e., not any applications on an "open system," it was felt unnecessary to use the identifying parameters of ACSE (AP title, AE qualifier, etc. which we discussed in Sect. 6.2.2). Actor identification in TCAP therefore relies on SCCP address- ing methods. 3. TCAP also assumed that two communicating actors would benefit from running concurrent threads of invocations, called "dialogues". The standard does not explain why. A qualified guess is that two call-handling actors can use this facil- ity to relate each ongoing call to a single dialogue. For example, an ISDN call- handling layer element in a local exchange uses the parameter CallRef in the DSS1 L3 protocol to identify a call. If this element starts using TCAP, it can define a separate dialogue identifier value in TCAP to relate to the CallRef value. Remember that, if AMLn invokes had been used, the TCAP dialogue identifier would be regarded as an association identifier (ASi). 4. TCAP had an ambition to support the sending of several LSM events (called "components") in the same invocation. As is the case in most standards, no explanation is given to why and in which situations this would be beneficial. Furthermore, the solution to this facility was to define two "sublayers" within the TCAP agent layer: the "component sublayer" and the "transaction sublayer", of which only the latter is a layer whether you use the OSI RM or the AMLn definition of what a layer is. The TCAP standard is a good example of how one can complicate a rather sim- ple network function by aligning it to a less suitable architecture (i.e. the OSI RM) and specification method (i.e. ASN. 1 macron, defined the ROSE way). In addition, Considering the fact that neither ACSE association procedures nor ACSE identifiers are used, it is rather puzzling to read in the T