s, one must associate an encoding mechanism with each type that, when applied to a value of the type, cre- ates a bit-representation of the value that every function can understand. ASN.1 is designed to be used together with an encoding system that provides "type/length/ value"-coding. ASN.1 is often also associated with BER (Basic Encoding Rules, Appendix 2: Naming and Data Typing in AML see ITU-T recommendation X.209), which is such an encoding method. Other methods would do as well. However, in many protocol applications the overhead bits created in messages, when using this technique, is not acceptable. This is espe- cially true for protocols below the "application level". ASN.1 is therefore rarely used in contexts other than for OSI, TCAP and TMN applications. Since AML is intended to support any type of protocol (even narrowband protocols, where each bit is costly), AML cannot just inherit ASN.1 as it is. The AML solution to this problem is: To use the ASN.1 syntax for defining names, data types and macro definitions. To associate encoding methods directly with basic data type names and allow for three different sets of types (types of all three sets can be mixed in the same specification): - ASN.1 types. An ASN.1 type is (in AML) always encoded according to BER. Naming rules follow the ASN.1 standard. - AML types. The initial character of an AML built-in type reference is a $. The encoding principles are: length information is included only for variable length data. Type information is never included in the encoded bitstring. If type infor- mation is needed, the user must instead provide such information as part of another type, in which the actual type is a structural element. - Private types. The initial character of a private type reference is a #. These are types for which the user must also define its encoding. Type and value notations in ASN.1 The ASN.1 notation for defining types and values is basically a BNF (Bachus- Naur Form). The definition of a type is called a type assignment. A simple user- d