OK, I'm convinced: checksums belong in base64. (This also makes me
feel better about a concern nobody but me seemed to be worrying about,
which is pipe-oriented encoders, which wouldn't be able to write a
checksum in the header but only at the end of the data.)
I am far from convinced that they belong in BASE64 only. I for one want them
available in 7bit and 8bit as well, and certainly in quoted-printable.
This also demonstrates a strong 7bit bias, something I had hoped to avoid.
If you want to checksum your data, you have to encode it to get the
checksum. This is stupid if you have a binary pipe available to use. Thus, in
the case of a true binary transport where BASE64 is entirely superfluous, it
becomes required to get a checksum! I don't like this at all.
If we're going to give up completely on any future non-7bit transports, let's
do it explicitly. No, I don't want to abandon 7bit transports either. I just
think that there can be and will be other things in the future.
Any objections to an optional checksum at the end of base64-encoded
data? Personally, I feel rather strongly that it should be optional,
but then I'm more confident than many people about the potential
robustness of base64-encoded mail.
I object because it is not orthogonal to the other encodings we support and
cannot possibly be made so.
A checksum is an artefact of the transport encoding process. It is not part of
the encoding itself, largely because not all encodings have a place to put
this sort of thing, nor can space be made for it in them. Thus, I feel it
should be grouped with transport-encoding but should not be part of encoded
data.
Various types and subtypes (especially application) may well want to have their
own checksumming mechanisms that end up as parameters on the content-type
line. A digital signature is an obvious example of a type of checksum that
should not be grouped with the transport mechanism.
Ned