Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
ASN.1
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Example== This is an example ASN.1 module defining the messages (data structures) of a fictitious [[Foo]] Protocol: <syntaxhighlight lang="asn1"> FooProtocol DEFINITIONS ::= BEGIN FooQuestion ::= SEQUENCE { trackingNumber INTEGER, question IA5String } FooAnswer ::= SEQUENCE { questionNumber INTEGER, answer BOOLEAN } END </syntaxhighlight> This could be a specification published by creators of Foo Protocol. Conversation flows, transaction interchanges, and states are not defined in ASN.1, but are left to other notations and textual description of the protocol. Assuming a message that complies with the Foo Protocol and that will be sent to the receiving party, this particular message ([[protocol data unit]] (PDU)) is: <syntaxhighlight lang="asn1"> myQuestion FooQuestion ::= { trackingNumber 5, question "Anybody there?" } </syntaxhighlight> ASN.1 supports constraints on values and sizes, and extensibility. The above specification can be changed to <syntaxhighlight lang="asn1"> FooProtocol DEFINITIONS ::= BEGIN FooQuestion ::= SEQUENCE { trackingNumber INTEGER(0..199), question IA5String } FooAnswer ::= SEQUENCE { questionNumber INTEGER(10..20), answer BOOLEAN } FooHistory ::= SEQUENCE { questions SEQUENCE(SIZE(0..10)) OF FooQuestion, answers SEQUENCE(SIZE(1..10)) OF FooAnswer, anArray SEQUENCE(SIZE(100)) OF INTEGER(0..1000), ... } END </syntaxhighlight> This change constrains trackingNumbers to have a value between 0 and 199 inclusive, and questionNumbers to have a value between 10 and 20 inclusive. The size of the questions array can be between 0 and 10 elements, with the answers array between 1 and 10 elements. The anArray field is a fixed length 100 element array of integers that must be in the range 0 to 1000. The '...' extensibility marker means that the FooHistory message specification may have additional fields in future versions of the specification; systems compliant with one version should be able to receive and transmit transactions from a later version, though able to process only the fields specified in the earlier version. Good ASN.1 compilers will generate (in C, C++, Java, etc.) source code that will automatically check that transactions fall within these constraints. Transactions that violate the constraints should not be accepted from, or presented to, the application. Constraint management in this layer significantly simplifies protocol specification because the applications will be protected from constraint violations, reducing risk and cost. To send the myQuestion message through the network, the message is serialized (encoded) as a series of [[byte]]s using one of the [[Abstract Syntax Notation One#Encodings|encoding rules]]. The Foo protocol specification should explicitly name one set of encoding rules to use, so that users of the Foo protocol know which one they should use and expect. ===Example encoded in DER=== Below is the data structure shown above as myQuestion encoded in [[X.690#DER encoding|DER format]] (all numbers are in hexadecimal): 30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f DER is a [[typeโlengthโvalue]] encoding, so the sequence above can be interpreted, with reference to the standard SEQUENCE, INTEGER, and IA5String types, as follows: 30 โ type tag indicating SEQUENCE 13 โ length in octets of value that follows 02 โ type tag indicating INTEGER 01 โ length in octets of value that follows 05 โ value (5) 16 โ type tag indicating [[IA5String]] (IA5 means the full 7-bit ISO 646 set, including variants, but is generally US-ASCII) 0e โ length in octets of value that follows 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f โ value ("Anybody there?") ===Example encoded in XER=== Alternatively, it is possible to encode the same ASN.1 data structure with [[XML Encoding Rules]] (XER) to achieve greater human readability "over the wire". It would then appear as the following 108 octets, (space count includes the spaces used for indentation): <syntaxhighlight lang="xml"> <FooQuestion> <trackingNumber>5</trackingNumber> <question>Anybody there?</question> </FooQuestion> </syntaxhighlight> ===Example encoded in PER (unaligned)=== Alternatively, if Packed Encoding Rules are employed, the following 122 bits (16 octets amount to 128 bits, but here only 122 bits carry information and the last 6 bits are merely padding) will be produced: 01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0 In this format, type tags for the required elements are not encoded, so it cannot be parsed without knowing the expected schemas used to encode. Additionally, the bytes for the value of the IA5String are packed using 7-bit units instead of 8-bit units, because the encoder knows that encoding an IA5String byte value requires only 7 bits. However the length bytes are still encoded here, even for the first integer tag 01 (but a PER packer could also omit it if it knows that the allowed value range fits on 8 bits, and it could even compact the single value byte 05 with less than 8 bits, if it knows that allowed values can only fit in a smaller range). The last 6 bits in the encoded PER are padded with null bits in the 6 least significant bits of the last byte c0 : these extra bits may not be transmitted or used for encoding something else if this sequence is inserted as a part of a longer unaligned PER sequence. This means that unaligned PER data is essentially an ordered stream of bits, and not an ordered stream of bytes like with aligned PER, and that it will be a bit more complex to decode by software on usual processors because it will require additional contextual bit-shifting and masking and not direct byte addressing (but the same remark would be true with modern processors and memory/storage units whose minimum addressable unit is larger than 1 octet). However modern processors and signal processors include hardware support for fast internal decoding of bit streams with automatic handling of computing units that are crossing the boundaries of addressable storage units (this is needed for efficient processing in data codecs for compression/decompression or with some encryption/decryption algorithms). If alignment on octet boundaries was required, an aligned PER encoder would produce: 01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f (in this case, each octet is padded individually with null bits on their unused most significant bits).
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)