plies that there is often no one-to-one relation between an ASP and a message type. Optimizations of message types that are commonly applied in mes- sage protocols include: The information elements of an ASP (object identifier, operation identifier, primitive type, etc.) are given a fixed position in the sequence of message parameters that carries them. The order of position is not bound to the syntax of the ASP, but optimized for processing efficiency. Another typical optimization is: the designer of an ASP does not really care in which order parameters of an ASP are defined in messages, which in the used data typing language may be declared by defining the parameter field as a SET and naming or "tagging" each parameter individually. The corresponding mes- sage type may change this and define a fixed order (a SEQUENCE) and remove tags if possible. A generator of events may want to generate a whole series of events, addressed to the same detector at the same time. Provided that the underlying connectivity stratum offers unlimited size of data, the message protocol may define a mes- sage format that concatenates information elements of several events. TCAP has a function called "component handling" that does that. With the exception of some older transport protocols that define separate ACK and NACK messages for the primitive types Confirm and Refuse, respectively, most protocols define a single message type (or parameter) for all types of responses. Control protocols that rely on narrow bandwidth (typical for older cellular net- works), may use the same message parameter for different ASP elements, depending on the state of the control procedure. This kind of "smart coding" may serve a bit or two in transmission, but is also very confusing, especially if the corresponding ASPs and their mapping on messages is not defined. Most protocols that carry ASPs define a single message parameter called "mes- sage type" that in fact often corresponds to the combination of an operation identifier and a message type identifie