🚀 go-pugleaf

In article <5560029@hpindda.HP.COM> kmont@hpindda.HP.COM (Kevin Montgomery) writes:

   / hpindda:comp.protocols.iso / auerbach@CSL.SRI.COM (Karl Auerbach) /  8:06 am  Jun 12, 1989 /
   > What I am wondering is whether any of you out there have any
   > practical measures of the distribution of octet and bit string sizes

   nothing practical, just an okay guess  :-) ....  I believe octet
   and bit string segmentation can begin occurring at 512 byte boundaries,
   so if one was segmenting (or interoperating with someone that did)
   one would like to avoid this costly segmentation business as much 
   as possible.  So I'd place my bet on a max of 512 bytes or at least
   a multiple thereof.  (how about looking at the protocols you want
   to pass?)

Actually, the use of a constructed octet or bit string can happen at
any time in ASN.1.  For instance, I can send the octet string `FOO' as
a primitive string, a constructed string containing the primitive
string `FOO', a constructed string containing three constructed
strings, one containing `F' and two containing `O', etc.

In an implementation of MMS we handled this problem as follows.  If a
routine which was expecting an octet or bit string received a
constructed string, it would invoke another routine which muddled
through the constructed string, building a primitive string which it
returned to its caller.  This prevented everyone from having to deal
with the possibilities of obscene peers sending constructed strings of
constructed strings of constructed strings of...

As for any hints of the `typical' distribution, I don't have enough
experience to comment.
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...uunet!abvax!sgtech!adnan