I've been following the ASN.1 debate for some time. While I sympathize
with Carl to some extent, let me share my major experience with ASN.1.
It converted me for good anyway.
Several years ago (the statute of limitations on talking about it expired
some time ago :-), I consulted to MCI on their new network management
system (NM-II). This is a 3-tier system, and I was involved with the
top and middle layers. For good or bad, the decision to use ASN.1 for
communications (i.e. ENCODING RULES) had been made. I developed a
rather substantial data model in ASN.1 (i.e. ABSTRACT SYNTAX) as part
of the high-level design. IMHO, ASN.1 is exactly the right level of
abstraction for such high-level design (but I think we all agree that
it's fine for that purpose). Of particular use (vs. Carl's proposal
to use Pascal, which language I like a great deal, or C), were the CHOICE
construct (no need for record elements indicating which CHOICE is used)
and OPTIONAL (no need to make up rules on representation of absent
elements). Some of the 1993 extensions (e.g. information objects) are
also very useful. I can't agree that defining concrete structure (in a
high level design) is correct; one really wants to define an abstract
syntax, which ASN.1 does well.
Carl wants to work from the wire representation backward, to ensure
efficiency, etc. This is a noble goal. Indeed, much of the ASN.1
I've been involved with recently (e.g. the X.509 v3 extensions) is
heavily influenced by efficiency concerns (e.g. an extension value is
an OCTET STRING, likely containing an embedded BER encoding, rather
than an EMBEDDED PDV, which Bancroft and about 10 other people understand
(I'm not sure if I understand it, myself). But premature concerns with
efficiency may lead to a design that doesn't meet basic requirements.
At least one standards commitee (ANSI X9F) of which I am a member has
adopted ASN.1 to eliminate the ambiguities in their current methods of
specification. (Of course, this includes X9.17, so ANY formal notation
would be an improvement :-)
Carl suggests (I think) that it is important to think about the wire
representation of a message during high level design. I disagree. During
subsequent parts of the design, an appropriate, efficient encoding must
be defined. Perhaps we are really arguing about (as Bancroft suggests)
encoding rules. Of course, if one can't write the encoding rules given
the "abstract syntax", we're in trouble. But the current sets of ASN.1
encoding rules (BER, DER, and PER) seem satisfactory.
Carl also (I think) assumes everyone uses C or Pascal, or a variant
thereof. Consider IBM mainframe applications written in COBOL. The
specification language has to be abstract enough to map to COBOL, as
well as C or PASCAL. Most versions of COBOL that I know cannot understand
the difference between CHAR, SHORT, LONG, etc. (in a vendor-independent
way).
I'm beginning to think that the problem is actually in the encoding rules.
I'm eagerly awaiting Carl posting his proposal; one might be able to
translate ASN.1 to it (as "encoding rules"), or translate it to ASN.1
(as an "abstract syntax").
Always fun to contribute to the debate...,
Rich