I'm not a checksum expert, and have largely stayed out of the debate.
But I really like the *flavor* of Alain's proposal. Here's why:
I think people are greatly exaggerating the importance of checksums for
mail. Sure, they're useful to tell you if you're data is corrupted.
But they're not like checksums in a lower-level protocol like TCP, where
if your data is corrupted you can retransmit & fix things and the user
never needs to know. If mail is corrupted, it's gone. If you want
SERIOUS data integrity, hop over to the ietf-smtp list and work on
adding checksums to SMTP. Seriously -- that's where they belong. All
we can do in the XXXX world is -- SOMETIMES -- tell people if their data
is corrupted. No more, and sometimes it will be very hard to do that.
(Try defining "corrupted" for text mail that has crossed an ASCII-EBCDIC
gateway. Probably can be done, but not trivial.)
All of this suggests to me that IF we're going to add checksums to XXXX
-- and frankly, I'd be just as happy if we didn't, because I see the
utility as rather limited -- we ought to add it in a way that is
EXTREMELY simple and limited, reflecting the near-impossibility of the
general case and the fact that this is not the appropriate layer for
seriously worrying about data integrity.
To my mind, that means checksums should be for base64 only, and a very
simple scheme there. None of this is a showstopper for me, but I think
people should step back and consider what they're trying to accomplish
with all the storm and fury. -- Nathaniel