[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ASCII versus binary
Gentlefolk, I do not agree that we should use ASCII canonical forms.
Indeed, after all the dust had settled, I had thought that we had agreed
that all the escaping problems were not worth the effort.
Folks went off and coded parsers for both ASCII and binary. Binary was
shown to be simpler and faster.
Yet, somehow, without consultation of the working group, ASCII was
chosen in the latest draft.
For one thing, the size of the S-expression lists is not available until
we reach the end of the list. I was pretty sure that was a _design_
_requirement_ of this WG that such sizes be specified.
The only rationale given is buried in 4.1.4: "Some concessions were made
to those developers who might want to examine a canonical S-expression
in an ASCII editor like emacs...."
Now, wait just a minute there. What are we carrying in the
certificates? Well, it looks a lot like binary data: hashes, moduli,
exponents, et alia. With some "tags" that are now byte strings.
Whenever binary (non-ASCII) data is carried, the _entire_ object is
base64 encoded. This is good. This is email compatible.
But the structure of the object is _not_ visible in an ASCII text editor.
While this format is much better on many issues than some of the ASCII
formats that were proposed to the list, it just doesn't float my boat.
I wanna, I wanna, I wanna my LR(0) parser.... I can even live with
recursive descent. :-)
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: