o consider, since a communication event is not a datum. There are no communication interrupts to consider, since data transfer prob- lems are dealt with by general functions of the corresponding protocol network or by lower-level logical networks. Since the initiated and the corresponding detected events are identical (except maybe for the service relation prefix), no misunderstanding of the meaning of the event is possible between the two parties. Since communication events are not data, there is no size restriction to the datum that represents a parameter value. For example, the file name X of the event Mahatma-sendFileRequest({fileId) x}, {to Nelson}) may refer to a file of 100 Mbit, while the connectivity service that is used supports a maximum SDU size of 1 kbit. This is of no concern to the modeller of a service network. Communication events occur only in concrete systems and in simulations of service networks. In service networks, abstract service primitives (ASP) are speci- fied. An ASP defines an operation name, a primitive type and a parameter set. For each parameter, the possible set of values is defined (this makes communication events instances of ASPs). Abstract service primitives can be specified in either of two forms: symbolic form or typed form, where the latter is a specification refine- ment of the former. Figure 7.25 shows an example of the symbolic form of ASPs for the operation "calendar information", callnfo, that is provided by an object as part of a "calendar service", CAS. The key words used to specify ASPs in symbolic form are the same as those used for property specification in resource models, i.e. the ASN.1 words SET, SET OF, CHOICE, OPTIONAL and DEFAULT. Values are also specified according to ASN.1, see Appendix 2. As long as communication between service objects is not over a message protocol, the symbolic form of ASPs can be used for implementing the service objects in some concrete language. 7.4 Elements of Interactions The service network: Operations in CAS are: calinfo, setDat