Re: Question about

[Kilgallen@eisner.decus.org.nospam (Larry Kilgallen)]

In article <C7Rc7.5082$NJ6.23233@www.newsranger.com>, Ted Dennison<dennison@telepath.com> writes:
> In article <dsGwyS7sA3+2@eisner.encompasserve.org>, 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.