On Thu, 4 Dec 1997, Paul Long wrote:
Paul Long wrote:
4. As I understand it, for some strange reason, because the order of the members of a SET OF is intended to be un-important the compiler takes it upon itself to sort the values entered into some form of order!!! This seems a waste of time and is a step best avoided by using SEQUENCE OF.
I've never heard of this before. I'll check with Bancroft. Sounds like a bug in the OSS compiler, which by the way we don't use for reasons like this.
[Bancroft's response follows. Apparently there is no reason _not_ to use SET OF, because H.245, and H.225.0, and presumably H.450 use BASIC PER, not CANONICAL PER, so there is no sorting.]
This is true in the case of DER, which mandates this behavior. DER encoders does not take it upon themselves to do this; it is required in order to produce a valid DER encoding. This is also true in the case of CER and the canonical variants of PER. It is not true for the non-canonical variants of PER or for BER.
As far as the OSS ASN.1 Tools go, DER is supported, so here SET OF's are sorted as required. The OSS ASN.1 Tools at this time does not support the canonical variants of PER, so no such sorting occurs for PER. Since all the sorting algorithms are in place for DER, it is easy to provide canonical PER support if it is required.
I rarely recommend use of SET OF, for I can never tell when an existing standard is going to be used in the future for the base of another standard that happens to use DER, CER or canonical PER. Sticking to a semantically pure choice (i.e., SET OF) at this point can thus later result in either redefinition of the standard you are creating or in the future standard taking the CPU hit. On the other hand, if one is creating a standard that they *know* makes sense only using DER, CER or canonical PER (e.g., X.509), then a SET OF is actually a good thing for types whose values for some reason should be sorted in ascending order. In these cases SET OF is a good idea because based on the toolkit you are using the sort will be performed for you without your having to write added code. What I say here also applies to SET, which requires no sort of any kind in PER, but which can have unnecessary CPU and coding overhead for DER encoders which are required to sort it, and for BER decoders which have unnecessary CPU and coding overhead because the SET components can appear in any order. Most folks don't think that their ASN.1 specs will see life beyond their immediate application, but in practice the more successfully specs get used over and over again, often in ways that the authors never imagined. To allow such reuse is the reason I don't suggest use of SET, ever, and of SET OF only after serious thought. -------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos@oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636