[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: encodings: do we need binary at all? -Reply

At 02:06 PM 2/25/96 -0500, Ed_Reed@novell.com (Ed Reed) wrote:
>I'd like to distinguish between representing things in binary, which I think
>is a generally good thing for the purposes of on-the-wire efficiency and
>server parsing performance, and the use of ASN.1, which is really just a
>formal description of data structures, and BER, which is a particular
>mechanism for encoding data.

That's an important distinction.  I think of this stuff in three layers:
- an object layer (e.g. ASN.1) which describes entities and relationships
- a mapping layer that translates objects into a bit or byte stream
- an exchange layer, that translates the bit stream into an I/O format
(e.g. bits on a wire or calls to an API).  The layers can overlap.
Issues like "Can you do Unicode?" are object questions - you _can_ do
Unicode, but your exchange layer may use uuencode or MIME radix-64
to represent it, or might use MIME quoted-printable if it's usually mostly
ASCII.

Perry's example for keys uses a simple, fixed set of object types,
and a simple mapping from those objects into a bit stream which
fits into ASCII; numbers are mapped using ASCII decimal (or hex etc.).
It's reminiscent of the nice clean MOSS formats.  I don't remember if he 
addressed non-ASCII name fields.  (Quoted-printable is cheating, but it's 
good enough for most applications and no loss for people with 
non-ASCII-character names that need to be squashed into ASCII for transmission.)
For hashes, it probably makes sense to use the "real" form rather than
the quoted-printable representation.

ASN.1 uses a very general abstract framework for objects, but the BER/DER
are a horrendous bit-twiddle that looks like its first priority is
minimizing the number of bits in the output format, at the cost of
excessive CPU decision-making and almost as many output bits as it saves.
Either raw or mm/uuencoded, its exchange format isn't human-readable.

The big benefit of ASN.1 is the extensibility; BER/DER has minimal redeeming
social value.  I've heard that PER is far more tolerable.
A big drawback is that you _have_ to use ASN.1 parsing tools,
rather than your favorite ASCII editors and databases.

There are three main drawbacks to Perry's approach - size expansion,
fixed contents, and the need for special-case code (as opposed to reusable
ASN.1).
Size expansion is pretty minor for most applications - at most 100% (for hex),
and you can do better if you represent the key in base-64 or base-85.
If you use a similar format for signatures, you still don't expand much,
because you're signing hashes.  And you start smaller because you're
not spending lots of bits representing ASN.1 generality, which is pretty big.
While the parsing code is single-purpose, rather than highly general like ASN.1,
it's pretty simple, and you may be able to win by reusing non-ASN.1 tools.
Having a fixed set of concrete things you can represent isn't that much worse
than having a fixed set of objects that your standards committee has gotten
around to defining; the big catch is what happens if you want to add fields
to support new applications; in an ASN.1 world you may be able to expand better.


#--
#                               Thanks;  Bill
# Bill Stewart, stewarts@ix.netcom.com / billstewart@attmail.com +1-415-442-2215
# http://www.idiom.com/~wcs     Pager +1-408-787-1281
Follow-Ups: