A few thoughts about content-checksum.
I oppose the use of a new header for checksums. It brings up all the
generic questions about when to have it, and how it should be used.
My preference it to add a checksum to base64 and be done. This way it
is always done if base64 is selected. Base 64 was written to be
reliable across flaky networks, and adding data integrity seems a
reasonable extensions. However, adding this for plain text seems to
be extreme. If you want data to get there unaltered, send it base 64.
content charset applied to non-encoded data is much less clear. To
some extent we accept small changes to textual data if we send it
unencoded. Conversion occure, such as conversion of tabs to spaces
and padding of lines and whatnot. Yes, this is impure, unclean, but a
reality which is discussed and considered in RFCXXXX. If this were to
happen with a content-checksum, the checksum would fail.....whatever
that means! It does not mean the data was bad, just that the receiver
now needs to guess whether the sender really needed the data to be
intact (Executable binaries) , or whether the sender just sends
everything with the "optional" header conputed.
If it has to get there unmodified, use base 64 with it's hopefully
soon to be built in checksum. If it is text, and it is free to be
poked and proded as needed by a friendly neigborhood gateway, (as most
of our mail is) then please don't put a checksum there! Spare me some
confusion.
BTW, The Privacy Enhansed Mail WG has really has addressed many of
these issues and I'd hate to rehash what many good people have been
doing for years. If we get really serious about this stuff, I would
just as soon punt and get the PEM stuff integrated into the RFCXXXX
framework.
Greg V.