CAP standard Q.771 that: TCAP is in partial alignment with ACSE." To the author it seems that TCAP has substituted ACSE association handling with something rather different, called "dialogue handling." The only thing TCAP and ACSE have in common is that they both rely on application context identifiers (referring ASN.1 macro, according to the ROSE specification technique). This identifier is used between TCAP users to check that they can both operate according to the same "application protocol." 6 Applying AMLn the inventors of TCAP also managed to violate the OSI RM transparency require- ments by dividing TCAP in two "sublayers," which did not simplify things. Figure 6.4 shows how TCAP's layer structure is defined in the standard. Dialogue Component TC user handling: handling: TC operations TC-UNI TC-INVOKE see ITU-T Q.771 TC-BEGIN TC-RESULT-L Transaction TC-CONTINUE TC-RESULT-NL handling: Component TC-END TC-U-ERROR TR-UNI sublayer & TC-U-ABORT TC-L-CANCEL TR-BEGIN TR user TR-CONTINUE TR-operations, TC-P-ABORT TC-U-CANCEL TC-NOTICE TC-L-REJECT TR-END see ITU-T Q.771 TC-R-REJECT TR-U-ABORT Transaction TCAP messages, TC-U-REJECT TR-P-ABORT sublayer (TR) see ITU-T Q.773 TC-TIMER-RESET TR-NOTICE Fig. 6.4 TCAP's layer structure as described in ITU-T Q.771 "Transaction capability" (TC) is the correspondence to an AMLn agent layer (i.e., TC is equivalent to the TCAP layer). An immediate observation, looking at the operations in the interface between the sublayers, is that this interface is not a connectivity service point ...SP); in that case the only operations that would be needed would have been TR-send and TR-receive). It looks more like a control point (...CP). However, since most of the TR operations include LSM event data to be sent between TC user, it is also not a service control point. The standard also shows that none of the component handling operations (TC-INVOKE, etc.) result in any TCAP messages being sent or received (contrary to how the OSI application layer and the AMLn common agent layer work). Thus