 message as 5.4 Message Handling an acknowledging response on a previously sent message", instead of characteriz- ing that bit as the value confirm of the data type PrimType. The latter is possible if an abstract syntax notation is not automatically associated with a specific transfer syntax. In Sect. 5.7, we discuss how ASN. 1, as a notation for operations, messages and abstract syntaxes, can be used in combination with different encoding methods. Thus, BER is an encoding technique that, in spite of its widespread use, is not applicable in many instances. Many protocols in process control systems define messages with many parameters but small value-sets. Quite often one bit is enough to represent a message parameter. In such cases, using BER might require 24 octets for a message that could be accommodated in one or a few octets by "smart encod- ing". This is, e.g. what is needed in narrow band channels for service access between mobile systems and cellular networks. An existing protocol of that kind, which use very compact encoding principles, is discussed in Sect. 5.5. 5.4.5 Adaption Handling Transport service adaption handling is a function that might have to be a part of an integrator. In the message handling model, it is modelled as the transport service adaption handler, TAH. The TAH compensates for transport constraints of the con- nectivity service that is used by the logical node. However, including a TAH in an integrator should be avoided. Therefore OSI defined its transport layer (layer 4, see ITU-T X.214 and X.224) as a layer that puts no transport constraints on transport layer users. That is also why the Internet architecture defines TCP (see RFC 793). An example of a case where an adaption-handling protocol is necessary is the Internet Inter-ORB Protocol (IIOP, see CORBA/IIOP 2.3.1, 99-10-07). IIOP runs directly on TCP/IP and adapts to the varying transport properties that exist over different parts of the Internet. Another example where a TAH is valuable is in the CSS architecture. TCAP runs its F