as textual data, e.g. over SMTP relays, or through copy/paste buffers. Example This is an example ASN.1 module defining the messages (data structures) of a fictitious Foo Protocol: FooProtocol DEFINITIONS ::= BEGIN FooQuestion ::= SEQUENCE { trackingNumber INTEGER, question IA5String } FooAnswer ::= SEQUENCE { questionNumber INTEGER, answer BOOLEAN } END 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: myQuestion FooQuestion ::= { trackingNumber 5, question "Anybody there?" } ASN.1 supports constraints on values and sizes, and extensibility. The above specification can be changed to 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 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 bytes using one of the 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