Date: 21 Sep 95 12:32:32 EDT
From: Bancroft Scott <75613(_dot_)602(_at_)compuserve(_dot_)com>
Bancroft,
thank you for your defense of ASN.1. Although what I have to say
about ASN.1 is not the most positive, I sincerely appreciate your point of
view and the time you took to respond to my message. I value your
list of ASN.1's benefits.
==============================
I believe you helped make my points. I further believe that's
because we basically agree about what ASN.1 is good for and what it isn't.
In particular, I do not *want* ASN.1. I want to specify structures in a
meta- data-declaration language from which C and PASCAL structures can be
automatically generated. I want the language to be simple. I want the
translation to be direct (so that I could write the C or PASCAL first and
auotmatically translate to the meta language). I want the meta-language to
look very much like PASCAL (or C, if I have to). That means that I don't
want to define Abstract Syntax. I want to define Concrete Structures.
Some of my gripes are about the encoding rules. However, you
point out:
I suspect that your (incorrect) conclusion that the above is a perversion
of ASN.1 is founded in the misconception of what ASN.1 is. ASN.1 is
meant to describe data types, period. Not how they are encoded.
and from that I believe we have agreement. That is, I don't want to define
structures apart from their encoding. I want to define encodings (in the
form of structures in memory, based on my knowledge of what's efficient).
To me, that is the definition of "data type". I do not want the
abstraction. [Notice, this comes from a mathematician by training -- an
INTP by Meyers-Briggs -- someone who abhors the phrase "be practical" --
but also someone with many years of experience in system design and
programming, enough to know pitfalls and to realize that one must be
practical while designing protocols, systems, programs, ....]
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.
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.
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.
3. It allows you to define "extensible" types, so that new fields can
later be added to the type in a wholly non-disruptive manner. For
example, it allows you to define:
Record ::= SEQUENCE {
name IA5String,
age INTEGER,
...
}
Note the "...". This is a very powerful feature of ASN.1:1994, for it
[etc.]
Wow. Yet Another Feature I Haven't Seen Before. This looks cute, like all
the others. It might even be useful. It certainly responds to a known
annoyance in software development. It might be a good response -- or it
might be bogus. I have addressed the same problem other ways and consider
it a non-problem now -- for me. I certainly don't need to modify the
definition of C or PASCAL to achieve it.
To me, this feature is two things:
(a) another wart
(b) the ASN.1 standard committee's acting as if it knew the answer to these
chronic programming problems -- putting forth an untried guess
as a standard
4. It allows you to use the subtype notation to place constraints on the
set of values that a type can have. For example:
Record ::= SEQUENCE {
name IA5String (SIZE(1..100)),
age INTEGER (65..140),
...
}
This was the first wart I referred to. PASCAL allows me to define subrange
types. How those are treated is implementation dependent...and to me that
makes even those a wart on PASCAL (which I consider to be an extremely well
designed language, for the most part).
Have you ever seen PL/I? Do you like it (for its time)? I don't -- even
for its time. It has too many warts like this (from trying to make happy
the FORTRAN, COBOL and ALGOL forces in the same language). It's a
committee effort. ASN.1 strikes me as another one.
5. It allows for the definition of OPTIONAL fields. Since it is often
the case that in a given message not all fields are required (e.g., a
person's name and address may be required, but their car's make and
model may be optional), ASN.1 allows you to define optional fields.
This not only allows you to define messages that reflect real life,
but reduces bandwidth by not encoding fillers for fields that are absent.
This might be useful. There are a number of ways to handle it. All
depends on the encoding rules. But, you said that ASN.1 isn't encoding --
just definition -- so we shouldn't discuss those, right?
6. It frees application and protocol designers to focus on describing
the messages that they wish to exchange between application programs
without having to worry about the bits and bytes details of how such
messages are laid out while in transit between machines. Yet, since
there are encoding rules designed expressly to work with types defined
in ASN.1, interoperability is guaranteed because they (encoding rules)
describe precisely how the data should look while on the wire.
By freeing the specifier of those messages from having to be immediately
aware of the encoding which will result, the specifier is led astray --
encouraged to create messages which are inefficient to transmit, to store,
to pack or to parse (or some combination of the above). This is why I, as
a mathematician, prefer designing with the concrete representation. One
can not add performance after the fact. It must be designed in at the very
beginning.
7. It gives different sectors of industry the freedom to choose from
any of several encoding rules that are designed for use with ASN.1.
In other words, it allows "compliant" implementations not to interoperate.
Yet, I seem to remember someone claiming that ASN.1 has a benefit the
production of applications which interoperate.
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).
If you don't wish to write in this manner, don't. C does not force you
to write using typedefs, nor does ASN.1 force you to write using type
references.
I use typedefs in C all the time. I never use raw structs. However, my
memory representations are efficient in terms of space and access.
The same can not be said for what results from ASN.1.
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 have no idea what you are talking about. In what way do you think
that ASN.1 requires runtime checking of an INTEGER specification, and
what wart having to do with "unsigned char" are you referring to?
I am referring to range constraints. The runtime checking is in the parse
routines.
None
of this is true.
Here we disagree.
ASN.1 does have syntax for constraining values, but
this does not require you to check such constraints [...]
It does if I allocate space for something small and something large comes
in. The encoding permits unlimited size values -- because there's no
basic datatype for BYTE, SHORT, LONG, ....
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.
I have implemented many a structure defined using ASN.1, and with
ease. I find it even easier using an ASN.1 compiler, for it not only
generates the data structures for me, but generates the encoders/decoders
and also ensures that my values are valid.
I'm sure you're quite happy with your ASN.1 experience. I found it
essential (in order to preserve my sanity) to write my own ASN.1 compiler
the last time I had to implement something spec'd in ASN.1. However, it is
not only possible -- it is easy to do significantly better.
ASN.1, to me, is one person's (or small group's) proposed solution to some
real-world problems. It is not a very good one. It is certainly not the
best possible. Therefore, to me, it doesn't deserve to be elevated to the
title "standard" or to be treated with reverence. It is a matter of taste.
You like it -- so use it. I can't stand it.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme(_at_)tis(_dot_)com http://www.clark.net/pub/cme
|
|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 |
+--------------------------------------------------------------------------+