From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6cc2d0131145e263 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-10 06:55:04 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen From: Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) Newsgroups: comp.lang.ada Subject: Re: Question about Date: 10 Aug 2001 08:54:55 -0500 Organization: LJK Software Message-ID: References: <3B72C23E.62F7B3D2@san.rr.com> <871ymk480x.fsf@deneb.enyo.de> NNTP-Posting-Host: eisner.encompasserve.org X-Trace: grandcanyon.binc.net 997451196 11926 192.135.80.34 (10 Aug 2001 13:46:36 GMT) X-Complaints-To: abuse@binc.net NNTP-Posting-Date: Fri, 10 Aug 2001 13:46:36 +0000 (UTC) Xref: archiver1.google.com comp.lang.ada:11757 Date: 2001-08-10T08:54:55-05:00 List-Id: In article , Ted Dennison writes: > In article , Larry Kilgallen says... >> >>I have not worked with streams, but was wondering if anyone had tried >>using ASN.1 to achieve interoperability. It solves endian problems >>and the DER representation is rather firm about "only one way to express >>something". > > Is it? For instance, data can be encoded with lengths, or with an > "End-of-Contents" octet. > The copy I have here is about 16 years old, and I don't have a "DER", just a > BER. My memory from when I did it was that there were indeed multiple ways to > encode most anything, but again that was many moons ago. That is the basic difference between BER (Basic Encoding Rules) and DER (Distinguished Encoding Rules). Something which is valid DER is also valid BER, but under DER there is only a single way to represent something. > I'd think the big problems with ASN.1 streams would be: > > o ASN.1 is too damn complicated. ASN.1 is quite susceptible to being compiled. Thus it is regular, if not particularly human-friendly. I believe a compiler could handle the job neatly -- no human hands need be involved. > o The encoding data structures are too flexible to map directly into Ada. > o Some ASN.1 types have no direct Ada analog. > o Some Ada types have multipe possible ASN.1 analogs. My point is not that a general ASN.1 message would be acceptable as a stream, but that a stream would be encoded as in ASN.1. This gives a great opportunity for the sending and receiving Ada implementations to check whether the stream is in the proper format. > o Since its type-based, you couldn't just do the job with a custom stream. > You'd also have to recode every type to output ASN.1 from its stream attributes. I believe that could be built into the compiler, with as much congruence as appropriate -- for instance, requiring that the names of elements be the same on the sending and receiving systems (if that is desired). > The last is a bit of a problem for *any* custom stream in Ada. If you care about > the internal data types or things like record boundries, then you end up having > to rewrite all the type stream attributes. This is a lot of work. It also > prevents people from using just any type with your stream, and it prevents > anyone from using those types with any other streams that you may have lying > around. I was under the impression that the program reading a stream was supposed to "match" the program that wrote it, at least with respect to the type declarations. To me it seems those type declarations are enough to make a definitive ASN.1 DER encoding.