Date: Mon, 11 Sep 1995 02:08:12 -0400
From: Benjamin Pivnic <pivnic(_at_)norden1(_dot_)com>
[...] job of the encoding rules, such as BER, DER, PER, etc. For example,
though the following is specified in ASN.1
MyInt ::= INTEGER (123456789 .. 123456792)
ix MyInt ::= 123456789
the value ix is encoded using DER in 6 bytes, while in PER it is
encoded in 2 bits (yes, bits). The point is that ASN.1 has nothing to
do with how data is encoded or space usage, it is strictly used to
describe the fields in messages in a way that allows interoperability
regardless of the machine, OS or programming language in use.
And this was from a defender of ASN.1 !! This construct is a wonderful
sample of the perversion which ASN.1 encourages. Thank you for the
addition to my list.
Can you spell out in greater detail what you propose as an alternate to
ASN.1 and its encoding rules, other than that standards should say "put
this byte here and that one there"?
There are several alternatives but I'm still building my list and inviting
more.
The leading contender to me, so far, is a cleaned-up version of the
intersection between C and PASCAL structure declarations (cleaned up by
removal of the union construct, among a few other things).
The question is why one would use ASN.1 in the first place.
I, for one, don't wish to describe abstract syntax. I want a mechanism
in which I can compactly specify data structures and from which there
can be easily generated (ie., compiled):
1. data structure definitions in the dominant computer languages (C
and PASCAL and probably no others)
2. code to pack and unpack those structures to/from byte strings for
communication between dissimilar machines.
I especially *do not want* to specify objects which can not be represented
directly by C or PASCAL data structures. I do not want to be seduced into
writing well-nested definitions (ala BNF), the way ASN.1 does, because that
structure nesting is not what a C or PASCAL programmer would do (because it
leads to variable names with too many fields). I do not want to be able to
specify bit strings as different from byte strings. I do not want a
language which won't let me specify "unsigned char" without adding some
wart that requires runtime checking to an INTEGER specification. I do not
want "DEFAULT" values. I do not want unlimited size INTEGERs as my only
choice. My list is much longer, but I'm still gathering it.
It is becoming clear to me.
ASN.1 might be an interesting exercise for people who believe LISP is the
only real language or who really like to play with abstract syntax or who
like to write specs while ignoring implementations (ie., write standards).
It's *really* easy to write structure declarations in ASN.1 -- as long as
you don't try to implement from them.
However, as one who wants computer programs to be written efficiently and
legibly (with small, easy to handle names, allowing complete statements to
be expressed in a small space) and to have these programs communicate
between machines with different byte ordering -- and almost nothing else --
I find ASN.1 is the *wrong* tool.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme(_at_)tis(_dot_)com
http://www.clark.net/pub/cme/home.html|
|Trusted Information Systems, Inc. http://www.tis.com/ |
|3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 |
+--------------------------------------------------------------------------+