which the author is sure of that very few designers have ever understood and applied. Another important difference is the way that the unique part of an application protocol is defined. In AMLn we isolate this part in terms of an LSM and its abstract protocols, which we specify (using AMLs techniques) independent of the LPM that will be used. In the OSI RM, the correspondence to an actor is one of a number of "application service elements" (ASE) that exist in an "application entity" (AE), that in turn exist in an "application process" (AP, a typical software concept). Sometimes such unique ASEs are called "user elements," but when spec- ifying an "application protocol" all ASEs are treated alike. The OSI application protocol defines the communication between AEs. It is a specification that comprises not just a "user element" ASE, but all other ASEs as well (primary ROSE and ACSE ASEs). The specification technique is based on an extension of basic ASN.1, where an ASE is described by an ASN. 1 macro that is an aggregate of other ASN.1 macro that specify operations. An application protocol is then specified as an aggregate of ASE macron, as an application context macro. To further complicate the matter, an AE may handle alternative application contexts (which necessarily requires additional negotiation procedures in association han- dling). This complex architecture can only be understood if we know the purpose with it, which is to facilitate code generation and management of interface specifica- tions, based on the particular specification technique that is represented by ASN.1 macro for operations, ASEs, AEs, and application contexts. Another stated purpose is to support OO software implementation of applications (the ASE being close to 6.2 OSI Upper-Layer Architecture the specification of a software object type). For example, in the ROSE standard (see ITU-TX.219) you find the statement: "The notation is based on established object- oriented programming principles." The standard does not define which these princip