ASN.1 Basic Encoding Rules implementation. Only the BER are implemented. This is not an implementation of ASN.1, such as an ASN.1 compiler or runtime. It could be used as the core of an ASN.1 runtime.

Work to do

  1. Only the following built-in types are implemented: BOOLEAN, INTEGER, OCTET STRING, NULL, ENUMERATED, and SEQUENCE. Notably absent are: BIT STRING, REAL, and SET. (There is an abandoned start at implementing BIT STRING.)
  2. Tag numbers, lengths, and INTEGER values are limited to 32 bits. It should be reasonably easy to extend tag numbers to 53 bits, lengths to 64 bits, and INTEGER values to arbitrary sizes (e.g., using BigInteger)
  3. Indefinite length encodings are not supported. This should also be straightforward. The end-of-contents marker is partially implemented. The natural use would be to implement encoding constructors for BerOctetString and BerSequence that take an InputStream or Reader and an Enumeration (of BerObjects), respectively.

Stream classes

I strongly considered introducing BER streams for reading and writing rather than using methods (BerObject.writeTo and BerModule.readFrom) that take streams as arguments. The pros of having specialized BER streams are that they would be more natural for Java programmers, and they allow multiple character encodings to be used for a given module. The cons are that client code would need to pass around BER streams rather than passing around more generic Java streams, the added complexity (the BER stream classes wouldn't replace any existing classes) and the question of what kind of streams they should be. The obvious choices for input are to extend InputStream or to implement DataInput or ObjectInput, with the corresponding choices for output.

I think that in the end only InputStream makes sense. What we would want from readBoolean is that it read a BER-encoded BOOLEAN, not a Java boolean. We couldn't implement the implicit contract of DataInput, though we may be able to implement its method signatures.

As it happens, one of our uses of the BER classes reads from sockets that have been wrapped in a BufferedInputStream. From that it reads both Java primitives and BER-encoded objects using a DataInputStream. This shared DataInputStream implementation would not be possible with BER streams, though any implementation of BER streams should, in my opinion, be usable in cases where some bytes may be read from the stream using other encodings, such as those of DataInput, via other stream wrapper objects wrapping the same underlying stream.

If BER streams are introduced, the basic changes would be as follows:

Note that it would certainly be possible to introduce the BER streams on top of the existing implementation, without interferring with existing client code.

BerTypes

The constants of BerTypes may more properly belong in BerIdentifier. Perhaps BerIdentifier should implement BerTypes and the latter be deprecated for use from outside the package.

Copyright

Copyright 1999 Vizdom Software, Inc. All Rights Reserved.

This program is free software; you can redistribute it and/or modify it under the same terms as the Perl Kit, namely, under the terms of either:

  1. the GNU General Public License as published by the Free Software Foundation; either version 1 of the License, or (at your option) any later version, or
  2. the "Artistic License" that comes with the Perl Kit.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See either the GNU General Public License or the Artistic License for more details.