Transfer Syntax Notation One (TSN.1) is a formal notation for the definition of data types. A data type is a class of information, for example, a message in a communication protocol.
TSN.1 is different from Abstract Syntax Notation One (ASN.1) [1] in the following way: TSN.1 defines the data directly in terms of its binary representation (transfer syntax), thus capturing both the information bits and the encoding bits of a message in a single notation.
In ASN.1, a message is first defined using abstract types such as Integer and Boolean, or type constructs such as Sequence or Set. The base notation does not specify how the message is encoded. To map the abstract definition into concrete bits (transfer syntax), user chooses from one of the standard ASN.1 encoding rules, for example, the Basic Encoding Rule (BER) [2]. Each ASN.1 encoding rule translates the ASN.1 types and type constructs in a standard and uniform way, giving user no control over the final encoding of the data.
ASN.1 does not work for legacy protocols for which the users must retain their existing binary representations. ASN.1 also does not work if users wish to have precise control over the binary representation of their messages, perhaps to save bits in a bandwidth constrained systems such as wireless networks or for some internal data that require proprietary encoding. Although the Encoding Control Notation (ECN) [3] has been added to the ASN.1 standard to alleviate some of these problems, it remains highly impractical to use ASN.1 for this type of data. In some instances, the complexity of applying ECN defeats the purpose of using a formal notation. In other instances, ECN is simply not expressive enough to handle the encoding requirements.
TSN.1 is designed specifically to describe messages that require flexible and custom encodings. It allows users to describe both the information bits and the encoding bits of a message in one notation. Because a message is defined directly in binary, no separate encoding rules is needed.
In terms of expressiveness, it is important to note that all ASN.1 data types can be described in TSN.1 after applying one of the ASN.1 encoding rules. However, it is not always possible to find an equivalent representation in ASN.1 for a TSN.1 data type.
TSN.1 is different from Abstract Syntax Notation One (ASN.1) [1] in the following way: TSN.1 defines the data directly in terms of its binary representation (transfer syntax), thus capturing both the information bits and the encoding bits of a message in a single notation.
In ASN.1, a message is first defined using abstract types such as Integer and Boolean, or type constructs such as Sequence or Set. The base notation does not specify how the message is encoded. To map the abstract definition into concrete bits (transfer syntax), user chooses from one of the standard ASN.1 encoding rules, for example, the Basic Encoding Rule (BER) [2]. Each ASN.1 encoding rule translates the ASN.1 types and type constructs in a standard and uniform way, giving user no control over the final encoding of the data.
ASN.1 does not work for legacy protocols for which the users must retain their existing binary representations. ASN.1 also does not work if users wish to have precise control over the binary representation of their messages, perhaps to save bits in a bandwidth constrained systems such as wireless networks or for some internal data that require proprietary encoding. Although the Encoding Control Notation (ECN) [3] has been added to the ASN.1 standard to alleviate some of these problems, it remains highly impractical to use ASN.1 for this type of data. In some instances, the complexity of applying ECN defeats the purpose of using a formal notation. In other instances, ECN is simply not expressive enough to handle the encoding requirements.
TSN.1 is designed specifically to describe messages that require flexible and custom encodings. It allows users to describe both the information bits and the encoding bits of a message in one notation. Because a message is defined directly in binary, no separate encoding rules is needed.
In terms of expressiveness, it is important to note that all ASN.1 data types can be described in TSN.1 after applying one of the ASN.1 encoding rules. However, it is not always possible to find an equivalent representation in ASN.1 for a TSN.1 data type.
转载于:https://blog.51cto.com/beterse/275029