[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cme@cybercash.com: Re: Base-64 proposal]
Carl --
I am agreeable with your idea that base-64 be limited. I see two
possibilities:
(a) a base-64 region can encode exactly one s-expression
(byte-string or list)
(b) a byte-64 region should not include any parentheses
that are unmatched within the base-64 region.
I can implement (b) easily just by checking, when seeing a closing ")",
that either both parens are not in a base-64 region, or both parens are
in the same base-64 region. I have an prototype implementation that does
that easily, by recording when it sees a left paren, how many base-64
regions have begun since the beginning of time.
(b) also gives you the ability to encode part of a string, e.g.
#1:{ew}
or
#1c:funny-character-{x6}-just given
which might be useful. Also, (b) allows you to use the base64 coding
for fragmentation:
#ff:67fTajfGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGggg{
}XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxx{
}ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
because line-breaks are ignored inside the braces. But with (a), you
need a different mechanism for fragmentation, if you want to support
that.
With both (a) and (b), if you see a printout you know that there is no
"funny parenthesis business" going on underneath the base-64 coding.
With (a), you know that there is exactly one object underneath. (With
(b), there could be two successive byte strings, for example.)
Comments?
Ron Rivest
==============================================================================
Return-Path: <cme@cybercash.com>
X-Sender: cme@cybercash.com
Date: Thu, 17 Apr 1997 16:17:14 -0400
To: rivest@theory.lcs.mit.edu (Ron Rivest)
From: Carl Ellison <cme@cybercash.com>
Subject: Re: Base-64 proposal
Cc: spki@c2.net, ggm@connect.com.au
In-Reply-To: <199704161212.AA02104@swan.lcs.mit.edu>
Mime-Version: 1.0
-----BEGIN PGP SIGNED MESSAGE-----
Ron,
I understand how to do the 6-bit channel, but don't believe
it's easy the way you have defined it. In particular, if you have a
verbatim string with {} inside, the {} are clearly meant to be there
and we don't get the 6-bit channel.
There is also the problem that base64 might contain unbalanced
()s and confuse a reader. The argument we had earlier in a small
group about whether base64 should be just for the whole certificate
(or communication) or for pieces of an object (e.g., modulus of a
public key), resolved to the latter based on the notion that a human
might want to examine the object. If the base64 can contain
unbalanced ()s then the human can not examine it meaningfully.
Therefore, I vote for having base64 be for complete objects
(strings or S-expressions) only -- and possibly even limiting it to
the outer object.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBM1aFRFQXJENzYr45AQHqpwP/VlStgWxg0G7DVjqV8yO1y5a8m3ZFIB2j
1k9NQw+eh+uFpwPoj+15FTK9M39HfaIMdf7gqyv4Zxs12iHgEYe4Y4ptOf+WXZbQ
+oM1bGZQiNHs5JIx/RZjKlTwsEGZcxdVsydI4eMCUWHBhVSbBEMWZqy2eQonuDFe
dt/31MGfxTk=
=0dll
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|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: