Okay, so we've got a binary encoding for IPP. And now the suggestion is
on the table to add a type field for each entity.
So with a little shuffling, we could encode things like this:
type-byte
length-byte
value-bytes
And lets decide on some values for the type-byte (throw in a few extra
values besides the character string and integer ones we need right now;
you never know when they might come in handy):
01 boolean
02 integer
03 bit string
04 octet string
05 null
06 object identifier (uh, oh)
09 real
10 enumerated
Let's use a zero byte to indicate the end of the sequence of values.
And because it's a hot day, and I'm feeling feverish, let's just add
these bytes to the front of the whole sequence:
30 80
Know what you've got? BER encoding! (Yes, the sequence is encoded using the
indefinite form (an end-marker), and, yes, the pairs are "flattened" --
they don't have their own sequence wrappers.)
Looking at this, I come up with at least two opposing conclusions: (1)
if you're going to do a binary encoding, go ahead and use a simple BER
subset (the extensibility and "off the shelf" arguments have already
been made), or (2) we've aleady decided not to do BER, and the type
fields are just a home-grown BER without most of the benefit, so stick
with what we agreed to in Nashua. My personal (technical) bias has
always been (1), but I think the answer that respects decisions already
hammered out after much discussion is (2).
:: David Kellerman Northlake Software 503-228-3383
::david_kellerman at nls.com Portland, Oregon fax 503-228-5662