Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!MIRSA.INRIA.FR!Christian.Huitema
From: Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema)
Newsgroups: comp.protocols.iso
Subject: Re: cost of ASN-1 (was: Null Protocol Layers Question)
Message-ID: <8906300739.AA06207@jerry.inria.fr>
Date: 30 Jun 89 07:39:25 GMT
References: <29-Jun-89.115441@192.41.214.2>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26

Both Amanda Walker and J. Zweig mention that production system should
not encode the ASN-1 in real time, but should use "canned encodings",
e.g. tables of pre encoded commands, on the basis that ASN.1 is nothing
but a complex "way of specifying packet formats". This may be true for
some other protocols, e.g. XDR, but is hardly a solution in the case of
ASN-1/BER for the following reasons:

* ASN-1/BER encodings are variable in length. Suppose you use it in
X-Window to address a pixel: you will use the INTEGER model. Then,
pixel number 127 will be referred to by the ASN1/BER value "02017f";
pixel number 128 will be referred to as "02010080". Just explain me how
you build up your table...

* ASN-1/BER encodings are not unique: one can choose primitive or
structured encoding for strings, the order of the components in a SET
is variable, there are many ways to encode a floating point number. As
a consequence, some on line decoding cannot be avoided.

Canned encodings have a value in some circumstances, one of the best
example being that of a file server: if the file are stored on the disk
in ASN-1/BER encoding, then the server will not have to encode/decode
them during connections. Which boils down to saying that canned
incoding is good for canned information... and probably inadequate for
randomly generated values.

Christian Huitema