[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 |
+------------------------------------------------------------------+
Follow-Ups: