ame for all operations within 5.4 Message Handling an abstract protocol. Therefore, operation specifications need not define types for these parameters. These definitions are instead made part of the message specifica- tion for FOH messages, as shown in Fig. 5.26. Tunad aparating Tuned operation Typed operation gevOrd(locInvId, Opld, PrimType, parSet) specification devRepCnf(locinvid, Opld, PrimType, parSet) FOHmessage reference Message local values and global type information specification GlobInvId ::= INTEGER (0..63) OPid #: INTEGER (0..63) PrimType ::= ENUMERATED{request(0) confirm(1), refuse(2), order(3), offer(4), reject(5), invite(6), rep(7), repCnf(8), repFail(9)} ASPid ::= SEQUENCE(Opid, PrimType} FOHmessage ::= CHOICE{[0]ASPmess, [1]ErrorMess} AspMess::=SEQUENCE{Globlnvld asp ASPid, parSet ANY DEFINED BY asp} ErrorMess :: SEQUENCE {GlobInvId, cause ENUMERATED { duplInv(0), primType(1), OpNotAvail(3), format(4), dataType(5), length(6),...}} Fig. 5.26 A message specification The set of primitive types is the same for all abstract protocols that are based on AML. The values that exist in the chAddr operation are Request, Confirm and Refuse. In all, ten different primitive type values exist. Each operation must have a unique value within the abstract protocol, unless the protocol defines several service objects (in that case, the operation identifier must only be unique per each object). The message format in Fig. 5.26 supports only one service object per abstract protocol (a more general message format is discussed in Sect. 5.7.3). From the FOH point of view, the OPid value identifies a particular operation specification. An additional parameter, the global invocation identifier (GlobInvId), is also defined in the message specification. It uniquely identifies an instance of an opera- tion call and allows an initiator to initiate multiple invocations of the same opera- tion. The parameter supports dialogue control within an operation. Dialogue control may comprise three aspects: Control of duplicated invoca