[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

	(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.


#1c:funny-character-{x6}-just given

which might be useful.  Also, (b) allows you to use the base64 coding
for fragmentation:


because line-breaks are ignored inside the braces.  But with (a), you
need a different mechanism for fragmentation, if you want to support 

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.)


	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



	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

Version: 2.6.2


|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        |