on 8/24/2003 1:53 AM Rob Austein wrote: > I've used ASN.1 compiler technology for a project that included an > H.323-related frob, and ended up wishing I hadn't. Can you say more > than 2MB just for the ASN.1 PER encoder/decoder on a box with an 8MB > flash chip? (For comparision, the embedded Linux kernel on this same > box was quite a bit less than 1MB.) I knew you could. No doubt we > could have gotten a smaller implementation if we'd been willing to > throw serious money at it, but H.323 wasn't even the main point of the quick-n-dirty = bloat is a universal. I've seen rfc822 parsers that were nearly as large for example. As far as that goes, moving bloat around within a layer doesn't seem to matter much in the end, and ASN.1 parser bloat is just as bad as XML or 822 or [...] parser bloat. The question of where compression should occur is a good one. The usual suspects are the application or the data-link layers, but I'm not sure there are overwhelmingly compelling arguments for either, or that equally compelling arguments couldn't be made for transport or network layer compression for that matter. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/