There seems to be general consensus that checksums on base-64
encoded body parts are a "good thing". I'm curious as to why
checksums on other transport encodings are not? Doesn't anyone
else think that putting a checksum in with a transport encoding
is mixing levels of abstraction?
Jim, I agree with you completely on this. Regardless of whether or not
a checksum is viable for a given message that's encoded in something other than
BASE64, it is definitely viable for some messages encoded in other ways. Thus,
putting a checksum explicitly into the transport stream is not a good idea,
since in general we don't have a way of delineating it from the stream itself.
Nevertheless, a checksum is a transport-level entity parallel with the level
of specification of the transport encoding itself. This, I think, argues for
putting this information in a separate transport-level specification. Since
we use a separate header for the transport encoding, I think the checksum
belongs either in the transport-encoding header or in a separate
content-transport-checksum header. Now all that remains is to specify
what constitutes the data stream that is checksummed for each of the possible
encodings we use and to specify the algorithms we want to support. The former
can simply be stolen (shamelessly) from RFC1113; I see no disadvantages to
the approach used there, and there are many advantages to aligning with the
PEM stuff on this.
The algorithm issues remain, and I for one don't propose to solve them here.
We're in the business of generating a framework here; many of the issues
involving what formats to support and when to support them must be solved with
actual operational experience. If we must reference something, let it be
MD4, which is, I believe, the only digest algorithm that's currently available
as an RFC. (I do know that others are currently in draft, as is a revision to
the MD4 RFC.)
Ned