ate this discussion to requirements on a methodology for protocol design, it should comprise the following features: Support for abstract protocol design, General message formats, Offer a choice between three ways of encoding: BER encoding of ASN.1 data types, AML encoding of AML data types and user-defined encoding of private data types (like MIN in EIA533). 5.7 Protocol Specification Methods These options are discussed in the following sections. Section 5.7.2 briefly dis- cusses abstract protocol design. Section 5.7.3 exemplifies the method that is most attractive for designers of distributed applications. This method requires no support other than a compiler that can link designer's code to library units. Section 5.7.4 discusses the functions of an intelligent message format generator (based on AML types) that can support compact encoding. In Sect. 5.7.5 are some comments on how support can be provided for private data types. 5.7.2 Abstract Protocol Design An abstract protocol defines the rules for communication between abstract units that are called abstract machines. An abstract machine can provide access to one or more service objects. An abstract protocol specification describes the behaviour between two abstract machines, preferably as a state machine for each side of the protocol. The protocol is based on a number of operations, where each operation defines a number of ASPs. Communication events between abstract machines are instances of ASPs. An abstract protocol is not constrained to any particular distri- bution solution or message handling. We can therefore leave the details of abstract protocol design to Sect. 7.7. Of interest to message protocol design is, however, how the ASPs are mapped on the message format that is handled by the FOH and the ENC. Three possibilities exist: 1. An abstract interface can exist between physical nodes. In that case, the abstract protocol must be mapped on messages that are carried by some CSP that exists in the network. 2. An abstract interface can also exist inside 