Resources
The ASN.1 SET type is similar to the SEQUENCE type. The key difference is that the elements in each value of a SEQUENCE type must appear in the order shown in the definition. The elements of a SET type value may appear in any order, regardless of how they are listed in the SET's definition, unless the encoding rule requires otherwise (for example, DER and PER). Note that defining a SET containing some elements of the same base type without element names can lead to ambiguity in the value notation.
Using SET types can sometimes make implementation of encoding/decoding software more difficult; therefore it is recommended to use the SEQUENCE type whenever possible.
The following example defines a value for the type Building. The address element is expressed in hex (it's an OCTET STRING), and occupied is set to TRUE. Omitting the element names address and occupied would not have resulted in ambiguity, since the SET's elements are of different types.
Building ::= SET {address OCTET STRING, occupied BOOLEAN} headquarters Building ::= { address '31343430204E6F7274686C616E64'H, occupied TRUE }
In the following example, the elements location and age are encoded in reverse order from that specified in the type definition.
PersonnelRecord ::= SET { name OCTET STRING, location INTEGER { homeOffice(0), fieldOffice(1), roving(2) }, age INTEGER OPTIONAL } rockStar3 PersonnelRecord ::= { name '44617679204A6F6E6573'H, location homeOffice, age 44 }
In BER, the SET type values defined above are encoded as follows:
31 12 80 0A 44617679204A6F6E6573 81 01 00 82 01 2C
The SET type can be constrained by a single value, by type inclusion, and by constraints on its components (inner subtyping).