At 1:41 PM 21/9/95, Carl Ellison wrote:
From: Bancroft Scott <75613(_dot_)602(_at_)compuserve(_dot_)com>
Among the reasons for using ASN.1 are:
1. It cleanly divorces the description of data types from any particular
language, so you can readily use such types in C, C++, Pascal, etc.,
all from a single data type description.
2. It gives the implementor the freedom to choose the C (or whatever
language) representation that is most suitable for their
implementation.
It is therefore not something to create interoperability (for lack of
standard encoding) and uniformity (for lack of standard memory
representation) -- rather something to allow a standards writer to specify
something unbound. Since I'm dealing with this at the binding stage (as an
implementor) and not at the standards writing stage, it does nothing for
me.
This is useless unless one includes the mapping rules from ASN.1 to each of
those languages as part of the spec. Ditto the encoding rules for transfer
from machine to machine.
I would say that this divorce between "abstract description" and
"programming language" is one of the reason for not using ASN.1 in
classical "RPC" applications. The large distance between ASN.1 and, say, C,
implies that ASN.1 compilers to choose how the ASN.1 construct is
represented in C. Such as, is your INTEGER an int, a long, a long long, or
1024 bits? Or, is your SET OF a fixed dimension array, a variable length
dynamically allocated array, a chained list? We could point out other
"small details", e.g. the difference in name scopes rules between ASN.1 and
C, that obliges compilers to invent names.
The net result is the API nightmare. The same ASN.1 specification results
is translated in different header files by different compilers, resulting
in different API. Organisations like X-Open felt the need to specify C
mappings in complement to the ASN.1 versions of X.400 or X.500.
If the language had been close to C, e.g. like XDR, these mapping problems
would not have existed. But then, the look and feel of X.409 would not have
been compatible with S.62...
Christian Huitema