6.2 that is represented by two primitives in AMLs: acAssConfirm (positive outcome) and acAssRefuse (negative outcome). The OSI operation classes are defined in ROSE (see Sect. 6.2.3). The similarities between ACSE and AMLn end here however, due to the differ- ence in architectural models. A minor difference to AMLn is that ACSE does not define an association identifier (ASi). A major difference is how element identifica- tion is done when associations are established and used. In AMLn we need two parameters: an actor layer identifier (ALi, for common agent layers only) and an actor suffix (As), and possibly an association identifier (ASi) when an association exists. This is reflected by the tables in the model to the left in Fig. 6.1. 6.2 OSI Upper-Layer Architecture The model to the right in Fig. 6.1 indicates which types of identifiers are needed in creating ACSE associations: since an association is established between two AEs, and an AE is contained in an application process, AP (which is the element that must translate application layer identifiers to presentation layer addresses), both an "application process title" (APtitle) and an "application entity qualifier" (AEqualifier) must be given in ACSE messages. Since no ASi is used, all applica- tion protocol messages must include these parameters both for the "calling" and "responding" parties. The APtitle is the closest we get to the AMLn actor layer identifier. Note however that ACSE does not know which APs belong to the same application. This implies that every AP that is called by another AP must check if it is an illegal call or not, by checking the calling APtitle against stored information about which APs belong to its own application. We still have not covered all identification needs in the OSI architecture, how- ever. As Fig. 6.1, shows, multiple instances of application processes is also sup- ported, which requires an additional set of identifiers: "AP invocation identifier" and "AE invocation identifier". The author was lost at this point when rea