ages used in design- ing different parts of a network. It is more important to realize that one single set of encoding algorithms cannot satisfy all requirements. Sometimes BER is just what is needed. In other cases, more compact forms of encoding must be used. This is especially when the whole or parts of a message are length-constrained, i.e. the maximum number of values of a message parameter is known. The definition of AML types serves the latter situation. One can also foresee cases where designers want to design their own encoding algorithms. A few such cases exists in EIA553, e.g. encoding of the identity of an MS (the mobile identification number, MIN). SM&AML and the OSI RM have different approaches to message handling, as regards the relation between data types and encoding. In OSI RM, the encoding method is not associated with the data type. Instead, an application can request one of a number of encoding methods. for each abstract syntax. As we saw in Sect. 5.4.4, the OSI presentation layer defines a presentation context for each abstract syntax that associates a data type to an encoding algorithm. However, this requires a negotiation procedure, which is the only reason for the existence of a presentation layer protocol. In SM&AML a more effective, but less open method has been selected. A data type is uniquely associated with a specific encoding algorithm. To support encod- ing flexibility, AML instead allows three sets of data types to be used and mixed in the same message format. 1. ASN.1 defined data types. Such data are always encoded according to BER. 2. AML defined data types. The first character in such a type is always $. Such data are encoded according to AML-defined algorithms, which try to avoid including type and length information in the message. 3. Private data types. The first character in such a type is always #. The data are encoded according to encoding algorithms that must be provided by the designer. Typing and encoding in AML is described in more detail in Appendix 2. If we transl