and "aborts" his previous offer. Obviously the "offer", the "accept" and the "abort" events all belong to the same operation on the called user side (which is to connect him to the calling user). Even when the ITU-T remote operation standard (ROSE) was issued in 1984, a first effort was made to identify such general patterns of communication events, in order to facilitate the specification of applications and the implementation of generic functions. ROSE talked about operation class as a way to identify such pat- terns. The ROSE operation classification system is based on the following criteria: if a result is provided or not, if the result is either positive or negative (or just one of those possibilities) and if the operation is synchronous or asynchronous (an operation is synchronous if no other operations can be invoked on the same object before the previous one has been performed). From a process control system point of view, the ROSE classification system is not sufficient, primarily due to: There is no operation class for operations that are spontaneously executed. These are very frequent in all process control systems, specially in services pro- vided by resource controllers. No operation class for sequences of three events is defined. These are frequent in process control systems for telecom systems and in distributed database sys- items. ROSE defines operation classes that give a response only if the activity failed, or only if it succeeded. Such classes are of value in concrete languages, but do not support protocol specification, where time delays play an important role. For example, assume that we use the ROSE operation class that gives a response only if the activity fails. If the user who requested the operation does not get a response in a reasonable time, he will assume that the operation succeeded. However, occasionally, the long delay was caused by congestion at the provider side. If the activity then fails, the user will get a response when he has already taken a number of other actions, based