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

encoding: SPKI vs. SDSI

At the December meeting, when I suggested that it might be easier to merge 
with SDSI if we adopt S-expression encoding rather than our current binary 
proposal, I heard objections -- both to ASCII and to S-expressions.

Let me call S-expressions S and the binary LR(0) proposal L.

S has the advantage of being readable and editable in your favorite text 
editor (the PostScript lesson) while L can be processed more easily by 
normal code.

S has the advantage that it is recursive, inherently, while L has the 
advantage that it is not recursive (and therefore more restrictive and 
simpler).  [This last point is based on the observation that one of ASN.1's 
sins is that it puts a burden on the receiver to process all possible 
options.  A spec is best for the receiver if there are no options or 
inconsistencies that the sender could possibly generate so the reciever has 
limited error checking to do.  In a fully constrained spec, anything which 
could be received would be in correct format.]

I'd like to hear suggestions for other comparisons and discussion of
preferences, from the group.

Let me start by stating my only preferences:

L was designed to require no scans over data while certs are read in.  Each 
byte string is proceeded by a count of bytes and each list is preceeded by a 
count of members.  Both can be expressed as arrays which can be allocated as 
the cert arrives before any bytes are put into those arrays or substructures 
are hung off them.  This is why I call it LR(0).  An S-expression, OTOH, was 
designed for LISP where the only thing allocated is a small list element.  
Strings are ended by context and are potentially very long.  Lists are ended 
by a final ")".  Therefore, one either stores everything as lists (which 
need to be stepped over during processing) or one re-formats after data is 
read in, copying bytes to a more friendly internal structure.

OTOH, S is editable by a standard text editor.  We could consider adding 
counts to S, to provide the same LR(0) benefit, but maintaining those counts 
in a text editor would be a nightmare.

S is slightly larger than L (maybe 2x) but I don't think that's a big deal 
for my cert uses.  It might be to some others, however -- especially smart 
card programmers.

 - Carl

|Carl M. Ellison  cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc.                      http://www.cybercash.com/    |
|207 Grindall Street   PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103  T:(410) 727-4288  F:(410)727-4293        |