[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

encoding rules versus DDLs versus ASN.1

At 09:04 2/28/96, FreedmanJ wrote:

BTW, your clock must be off.  The message you replied to was written on
13:42 EST


>   I have no problem with any of this - I only support ASN1 because I don't
>like reinventing the wheel but, I'd do it for a good enough reason- my
>thoughts are to have a modified, "fixed" asn1 along with understandable,
>implementable, distinguished and canonical encoding rules. By that I mean a
>set of encoding rules that have the property that DER is supposed to have - a
>encodable structure would have only one encoding. If the language is modified
>PASCAL, and if the encoding has 16 bit length fields, then so be it as long as
>the encoding is "distinguished". At this level of discussion those are details

There's a difference between ASN.1's encoding rules, which are designed
for transport from one machine to another, and a Data Definition Language [DDL]
for generating structure definitions in some programming language.

ASN.1 is used for both -- in fact, for 3 purposes:

1.      chalk-talk:  letting people talk about what ought to be in a
        structure, without getting bogged down in implementation details

2.      encoding:  transfer of data between machines, especially dissimilar
        ones

3.      DDL:  generation of data structures in a programming language

Formally, ASN.1 is only #1.  #2 is a product of the encoding rules
which have been added over the years and which can always be augmented
but which aren't formally a part of ASN.1.

#3 is a product of whatever ASN.1 compiler you happen to use.

Many of my complaints about ASN.1 have to do with #2 and #3, rather than
#1.  In that sense, my complaints aren't fair.  However, my gripes about
#3 happened even with my own compiler, because ASN.1 itself forces the
compiler to be able to handle indefinite length integers or sets or
sequences -- nice stuff to the mathematician at a chalk board but needless
generality for the programmer and a source of much pain in the parsing,
packing and use of generated structures [#3] as well as inefficiency
in the encoding [#2].

For a specific example of that, the X.509 Distinguished Name is a
SEQUENCE OF a SET OF a SEQUENCE containing [attribute,value] pairs.
On paper [in bits] this looks pretty enough to give the author a slight
thrill of having written something elegant and powerful.  ASN.1 itself
thereby applauds use of such constructs.  As a structure in C or PASCAL, the
construct is horrible.  Everyone I know who deals with DNs [with one 
exception] treats it as an unparsed byte string rather than set up the
C structures capable of representing this internal structure.

Note also that although ASN.1 and the encoding rules are standardized, the
compilers aren't.  Therefore, if you have code written to use structures
generated by ASN.1 compiler A, it is not guaranteed to work with structures
generated by ASN.1 compiler B.  Therefore, ASN.1 works against code
portability.



Thus my preference:  define your structures in a true DDL -- one with a
standard mapping to the popular computer languages and one in which a programmer
applies his skill in choosing definitions which will make for efficient
use of the structures.  Then define an encoding mechanism for those
structures, to allow them to be transferred from one computer to a dissimilar
one.  In this preferred world of mine, the mathematician at the
chalk-board is left dangling in the wind {and I'm a mathematician by
training, so it's not anti-math sentiment here}.  If your implementation
language is LISP, ASN.1 might be the right DDL.  If your language is
C or PASCAL, it isn't.

 - Carl
From ???@??? Wed Feb 28 17:27:00 1996
To: ben@algroup.co.uk
From: cme@cybercash.com (Carl Ellison)
Subject: Re: Specification Languages
Cc: SPKI <spki@c2.org>
Bcc: 
X-Attachments: 
Message-Id: <v02140b12ad5a857dd1e1@[204.254.34.231]>

At 13:26 2/28/96, Ben Laurie wrote:
>10. Some other already defined specification language.
>
>Would anyone care to add to this list? Or give some instances of 10?

I don't remember its name now, but there was a DDL designed and implemented
at Stratus [more details as I dredge them up] which took one
data structure definition and generated C, PASCAL, PL/I and maybe a couple
of others.

That language looked C-like [ugh -- I'd rather it looked PASCAL-like] but
it did the job.  It defined data structures so that code in different
languages could manipulate the same structured binary files.  You couldn't
do everything in this language that you could in each of the target
languages, but you could do enough for system programming.

This language also had the advantage of looking like a programming language
with none of the ASN.1isms [SEQUENCE OF, SET OF, BIT STRING, ...] so that
you were encouraged to think about efficiency of internal representation
and use while you were defining the structure.

Once you have a data structure defined such a way, encoding it for transport
between machines is no big deal.  A processor to write pack/parse code
for a given structure is really easy.

 - Carl