IPP> PRO proposed tweak to protocol

IPP> PRO proposed tweak to protocol

IPP> PRO proposed tweak to protocol

David_Kellerman at nls.com David_Kellerman at nls.com
Tue Jul 15 17:50:15 EDT 1997


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



More information about the Ipp mailing list