Path: utzoo!attcan!uunet!husc6!rutgers!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: Size distribution of ASN.1 octet and bit strings
Message-ID: <8906141456.AA28060@jerry.inria.fr>
Date: 14 Jun 89 14:56:31 GMT
References: <8906121506.AA24480@Hercules.csl.sri.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 22

Both Octets and Bit Strings have two differents uses -- neither ``uncommon''.

Bit Strings will either:
* include a limited set of named configuration flags -- could be in
most cases mapped to (some of) the 32 bits of an Integer by a typical C program;
* be used to carry a bitmap: anything from a smallish icone to a full
screen, not excluding fac-simile images.

Octet Strings have much of the same split. They can either encode:
* some attribute, like name or password, which usually fits on a single line;
* a full ``file'', or ``document'', or whatever. That not only for
X.400, but also for FTAM + all document related applications.

The other problem is the split between ``primitive'' and ``structured''
encodings. As far as I can tell, you find anything, the key being the
ability of the sender to predict the size of the string; when it is
predictable (e.g. binary file), the primitive encoding is often
preferred. Several systems code text files in the structured format,
for you have to do a lot of clean up at the end of lines => the final
length is hard to predict.

Christian Huitema