ietf-822
[Top] [All Lists]

Re: checksums (was: content-charset & checksums)

1991-10-28 11:43:27
        In another matter, Alain Fontaine has convinced me that a checksum
        would be a good idea.  I'm inclined to do this via a separate (and
        optional/ignorable, for those who so desire) Content-checksum
        header.  Does anyone object to this?  Is it necessary to include
        this as part of the RFC, or can we allow it to be added by a later
        RFC?

I agree that a checksum is a good idea.  However, I do not think a checksum
header is the right solution.

It has been suggested there needs to be a way "to verify the correctness of
any body part".  I could break ground on a rat hole and ask what is meant by
"verify the correctness", but I will resist in this message.  For now I will
assume we all know what that means.

I agree with suggestion.  It has also been suggested that each application
should provide its own "builtin" checksum.  I, as do many others, disagree
with suggestion.

Further, I observe that the inclusion of a checksum header does not solve
the real problem of providing a single, interoperable mechanism for
computing and verifying a checksum.  Consider that you will have to agree on
an appropriate checksum algorithm.  Todays technology suggests using a hash
algorithm, rather than a CRC.  If you think the character set choice is
hard, try choosing a hash algorithm.  SNMP Security did, but the choice is
"charged".  The reality is it is never really chosen until the documents are
published, which SNMP Security is not, yet, but should be in November.

Leaving the choice open to bilateral agreement does not solve the problem.
If you do that you have to allow the option of ignoring the checksum header.
But if you can ignore it, why have it in the first place!

I assert that an alternative is to allow for the specification of an
application that only does checksumming.  This allows the issue to be set
aside with respect to this RFC proposal.  Further, the inclusion or
non-inclusion of a checksum header is also set aside.

This is completely consistent with the current proposal.  You simply nest
whatever body needs a checksum in a body that checksums it.  This allows the
checksum application to apply to all body types, a big win over just
providing a checksum for binary body parts.

Let me also give you a peak at the future.  Privacy Enhanced Mail has one
option relevant to this discussion, that is to provide both authentication
and integrity.  If you have body part that needs its integrity guaranteed,
PEM it.  This alternative will be available sooner rather than later.  I am
involved in Alpha testing one implementation of RFC-XXXX.  A principal
reason for this is to explore the integration of PEM.

Jim

<Prev in Thread] Current Thread [Next in Thread>