Re: Initial comments on draft-ietf-822ext-mime-imb-00

Nathaniel Borenstein <nsb@nsb.fv.com> Mon, 27 June 1994 14:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02914; 27 Jun 94 10:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02910; 27 Jun 94 10:03 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa07669; 27 Jun 94 10:03 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25050; Mon, 27 Jun 94 09:31:03 EDT
Received: from tigger.jvnc.net by dimacs.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25046; Mon, 27 Jun 94 09:31:01 EDT
Received: from nsb.fv.com (guppy.jvnc.net) by tigger.jvnc.net with SMTP id AA12702 (5.65c/IDA-1.4.4 for sdorner@qualcomm.com); Mon, 27 Jun 1994 09:03:03 -0400
Received: by nsb.fv.com (4.1/SMI-4.1) id AA15745; Mon, 27 Jun 94 09:03:07 EDT
Received: from Messages.8.5.N.CUILIB.3.45.SNAP.NOT.LINKED.nsb.fv.com.sun4.41 via MS.5.6.nsb.fv.com.sun4_41; Mon, 27 Jun 1994 09:03:06 -0400 (EDT)
Message-Id: <Ai3gs_L0Eyt5BFdoxA@nsb.fv.com>
Date: Mon, 27 Jun 1994 09:03:06 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Steve Dorner <sdorner@qualcomm.com>
Subject: Re: Initial comments on draft-ietf-822ext-mime-imb-00
Cc: ietf-822@dimacs.rutgers.edu
In-Reply-To: <aa33a43a0402101b8345@[192.17.5.10]>
References: <aa33a43a0402101b8345@[192.17.5.10]>

Excerpts from info-mime: 26-Jun-94 Re: Initial comments on dra.. Steve
Dorner@qualcomm.co (953*) 

> The ONLY (tiny) check on the integrity of base64 is the number of = signs 
> on the end.  If you allow people just to add a bunch of equal signs, you've 
> removed even that.  And I'm not real happy about allowing random characters 
> in the middle of things, either.  Who needs to do that? 

Well, as far as I know this is what the spec has always said. 

> My current procedure is to warn users if these things occur. 

I have no problem with that.  If these things occur, there's almost
certainly a mistake somewhere. 

> content-MD5 is all very well and good, but it assumes the sender is going 
> to make two passes over the data; once to figure out the checksum and once 
> to send the data.  (One of the nice things about the Mac BinHex format is 
> that the checksums come at the end, not the beginning.) 

Yes, it would have been MUCH better to put the checksum at the end of
the base64 encoding.  However, the design of base64 goes back to the
earliest versions of PEM; I'm not sure, but it possibly even pre-dates
MD5! 

It is interesting, however, to put these two threads together.  Since
everything after the = signs is ignored, we could conceivably define a
backwards-compatible extension to base64 in which there *was* a checksum
at the end, where older decoders will just ignore it.....   This idea
intrigues me as an extension & future RFC, but NOT as a last-minute fix
to the final standard version of MIME.  -- Nathaniel