Re: API (was: "FORWARD" module)

[Nick Mathewson <nickm@alum.mit.edu>]

On Wed, 2002-03-27 at 10:15, Zooko wrote:
 [...]
> In particular, I suggest that the mix core spec has only a few types: FORWARD, 
> DROP, APPLICATION, and perhaps INFO and PING and that there is a separate layer 
> which encodes arbitrary-length strings as "extension type".  The primary value 
> of this approach is that the Mix Core stuff which can affect privacy and which 
> application programmers touch is separate in specification and in implementation 
> from the extensible part.  (Although I fully agree that v1.0 must specify and 
> implement SMTP and other extensions!)

I agree, mostly.  I only worry about "separate in specification": I
believe our spec, even from the first version, should include these
extensions as an appendix.  If we're all okay on this, I'd be mostly
fine....

        (BIG QUESTION)
...but I'm still worried about the problem that got us onto this track:
How can SURBs work with fragments?  If anybody can explain this, I'd be
happy.  (For that matter, how do you specify your email address in a
SURB?)
 
        (LITTLE QUESTION)
[BTW, does anybody mind the potential for homophonic confusion between
SURBs and Serbian people?  If so, we should pick a new name or
abbreviation ASAP.]

 [...good api...]
> Hm.  In fact, now that I think about it I would like for the standard extension 
> types (MULTIPART, GZIP, SMTP) to be MIME.  The MIME design isn't exactly how 
> I would have designed it, but it is a standard and it is widely understood and 
> implemented.

[By "MULTIPART", I meant "FRAGMENT" or "PARTIAL", not the MIME notion of
multipart.  (We should change the name.)  Does MIME even have a notion
of message-split-into-many-fragments?  How much overhead does it add?]

I think using MIME would introduce more problems than it solved.

First, MIME is kinda big.  For instance, there is no reason I can tell
to process multipart messages in the MIME sense; or to allow different
character sets.  Also, it is an unthinkably large security hole to ever
use the environment/OS's underlying MIME handlers.  Therefore, if we use
MIME, we would probably only want a subset of it.  In other words, every
payload could be a MIME message, without every MIME message being a
payload.

**But the _major_ problem with MIME is that there's more than one way to
spell it.**  For example, if your client writes 'charset=us-ascii' and
mine writes 'charset="us-ascii"', our clients are now distinguishable.  
If we use MIME, we'll need to constrain the spelling as much as we can. 
You know RFCs 2045-2049 better than I, I'd bet.  What would MIME buy us
other than conformance to a standard?  (Keep in mind that the standard
wouldn't allow us to use existing MIME code unmodified, since we'd need
to make sure it confirmed to the single-spelling subset we allowed.)

Yrs,
-- 
Nick