[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
In message <199704091826.AA28089@swan.lcs.mit.edu>, Ron Rivest writes:
>I don't have any idea what you mean by "pre-scanning". Do you mean
Essentially yes. You've argued (in another message) that 16 bits
length (counting in bytes) would be too short for some arguments.
Parsing that same argument in an S-expression (without a length
prefix) would be...interesting. Keep free-ing and allocating ever
increasing chunks of memory, copying the whole thing over and over.
>The idea that you should just take a bunch of bytes as your input
>object, and accept it without further checking (leaving the errors to
>fall where they may later on), is not a good one. (That is not to say
>that you can always do all the necessary checking initially.) But
>"parsing" (telling where lists and byte-strings begin an end), or
>"pre-scanning" as you call it, is a very minor part of this whole
>business. I'm actually suprised that we're talking about this sort of
>minor thing when there are other much more major design issues (e.g.
>*-rules for tags) in terms of affecting overall size of the
Parsing is a necessary step. I don't feel that parsing a series of
ascii strings is convinient or easy enough for everyone to implement
correctly (handling all possible problems). And certainly, ease of
implementation is very important to this group.
>Here we are talking (I think) about the difference between just passing
>a pointer and a length field to the hash algorithm, or writing a small
>recursive routine that runs over the object, passing parens and byte
>strings to the hash routine). Probably 10-20 lines of code. I don't
>see why this is so important that we should give up on readable
Because an implementation would have to be aware of *all* possible
mangling a transmission or storage medium could possibly do to an
ASCII bytestring. Whereas, binary is binary is binary everywhere
(well, quantum computers might differ :)
>Having an ASCII readable format for our data structures is, I believe,
>an important design goal. Look at the success of Postscript. Having to
>pull out a special tool to examine data structures during implementation,
>instead of just using a text editor, is a BIG negative.
Um. I suspect there might be quite a few people on this mailing list
that actually write in raw Postscript (you know who you are). These
are *NOT* the majority of people who use Postscript. Your typical Joe
user probably has never ever bothered looking into a Postscript file;
he just prints it. If there's something wrong, he fires up ghostview
or ghostscript and sees where the error is (not that he can fix it
>If you are into counting lines of code, you should perhaps count the lines of
>code that you need to build your special tools, instead of focussing on the
>few ones needed to do canonicalization, etc...
Yes, but you'll need the exact same tools to do the same things with
certificates in either format (create, sign, verify). The difference
is that you'll have to use them even when you want just to view a
certificate (for whatever reason).