r, which may have corrupted the state of the protocol network. The universal message format should be regarded as a generic format. Any par- ticular application of this format can be modify in two respects: Change the data types of the predefined types INTEGER and ENUMERATE. For example, one may want to use the ASN.1-defined type OBJECT IDENTI- FIER to refer to a standardized object type or operation. All or some parameters of an abstract syntax may be size constrained. Size con- straints may be defined simply to guide the protocol implementor. However, they can also be used by the FOH to check that received values are within range, which protects a receiving service object from having to handle undefined val- 5.7.4 The Intelligent Message Generator Often the flexibility of the universal message format is not needed. Instead one wants to minimize the amount of bits sent for the events of concern. This can be accomplished by specializing the universal format by restricting the range and size of parameters, and by excluding parameters that are not needed. Compact encoding is used, which means not sending type and length information when it can be avoided. This is accomplished by using AML types only (types prefixed by $). From a methodology point of view, it is supposed that an intelligent format-gen- erating tool is available. The designer answers a number of questions concerning which parameters are used on the abstract protocol level, restricted range and size for most parameters, optional occurrence of parameters and default values for parameters. An input to the generator may look as shown in Fig. 5.49. The charac- teristics of this particular protocol are: The protocol comprises, at a maximum, 16 different object types (PSid). There is only one instance of each object type (no SRid is needed). An object can define 64 operations at a maximum. Only two operation classes are needed: REQUEST and ORDER. REQUEST operations are synchronous (which implies that no INVid is needed). Destructive operations do not exist 