🚀 go-pugleaf

jpalme@dsv.SU.SE (Jacob Palme DSV) writes:

>I have a question about the SET construct in ASN.1.

>I know that the SET construct allows the agent which encodes in ASN.1
>to put the elements in arbitrary order.
>My question is: Does this mean that the order of the element
>is totally insignificant, and that the construct might be unpacked
>and packet with a different order of the elements during
>transmission?

There is no *semantic* significance placed on the order of the
components of the SET.  You can think of this as meaning that the
creator of an ASN.1 specification uses a SET to convey the notion that
the ordering of the components of the SET is arbitrary as far as the
application program is concerned, and that there is no significance to
the ordering, from an abstract point of view.

However, when it comes to encoding/decoding the SET, the various
encoding rules of ASN.1 (BER, PER, CER, DER) place differing
requirements on the order in which components of a SET are encoded.
BER imposes no restrictions at all, so the order of the encoded
components is entirely unpredictable ... a testament to the
flexability of BER.  All the other encoding rules of ASN.1 impose
requirements on the order in which components of a SET are encoded,
independent of the order in which they were defined in the ASN.1
specification.

>Or can one assume that the order in which the elements were coded
>by the encoding agent will be preserved when the deconding agent
>unpacks the ASN.1 structure?

In the case of all ASN.1 encoding rules other than BER, you are
guaranteed that the order in which the elements are encoded is the
same when decoded, since those encoding rules mandate a single way in
in which the components can be encoded.  However, in the case of BER
it is possible for you to encode data in one order, and due to the PDU
passing through a relaying application (which may decode and re-encode
it), the order in which the components were originally encoded differs
upon receipt.

To summarize, your application should never make any assumptions about
the order in which components of a SET are encoded.

=====================================|========================================
Bancroft Scott			     |		Open Systems Solutions, Inc.
609-987-9073			     |		Princeton, N.J.
=====================================|========================================