Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!cs.utexas.edu!uunet!mrmarx!abvax!sgtech!adnan From: adnan@sgtech.UUCP (Adnan Yaqub) Newsgroups: comp.protocols.iso Subject: Re: Size distribution of ASN.1 octet and bit strings Message-ID: Date: 15 Jun 89 10:33:25 GMT References: <8906121506.AA24480@Hercules.csl.sri.com> <5560029@hpindda.HP.COM> Sender: adnan@sgtech.UUCP Organization: Star Gate Technologies, Inc. Lines: 34 In-reply-to: kmont@hpindda.HP.COM's message of 13 Jun 89 03:14:09 GMT 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