of type Confirm or Refuse was expected, it could send the other agent an error message without bothering its own actor/user. This is however not SO. A ROSE agent delivers any LSM event it gets in messages which is syntac- tically correct to its actor/user, which must perform such validity checks itself. That is also why ROSE defines the additional operation RO-REJECT-U to be used by an actor/user to inform its partner about formal LSM event errors (in an AMLn actor 6.2 OSI Upper-Layer Architecture layer represented by the generic abstract primitive generalFaultReport (defined by AMLs). The last ROSE primitive, RO-REJECT-Pindication, has no correspondence in AMLn. It is used by a ROSE agent to inform its actor/user if it cannot recognize which LSM event is referred to in a received ROSE message. In AMLn we assume a) that the sending agent has already checked the validity before sending, and b) that used connectivity service is reliable. If there still are problems of this kind, the agents should first try to solve it mutually, and, if they cannot, inform the associa- tion element that the association no longer works. The association elements will then give notice to their actor/users by the agRelRep (see Fig. 2.33). Thus, there is no need for an RO-REJECT-P operation in AMLn. The operation class system defined in ROSE is different to the one defined by AMLs. The rationale for the AMLs operation class system is described in Muth (2001), which also comments on some strange features in the ROSE operation class system. We will therefore not repeat these arguments here. Note, however, that the AMLn invokes (see Appendix B) are not bound to use the AMLs. operation class system. They can serve any operation class system, as long as it defines the syntax of abstract primitives as consisting of an operation identifier, a primitive type, and a sequence of parameters, which includes the way operations and primi- tives are specified in the ROSE specification technique. Another difference between ROSE and AMLn is that neither 