Date: Fri, 25 Oct 91 10:25:55 +0100
From: "Alain FONTAINE (Postmaster - NAD)"
<fontaine%sri(_dot_)ucl(_dot_)ac(_dot_)be(_at_)UTKVM1(_dot_)UTK(_dot_)EDU>
Subject: Re: Comment on encapsulation BNF in latest RFC-XXXX
To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Cc: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
On Thu, 24 Oct 91 18:04:18 EDT you said:
2. There needs to be a way to verify the correctness of ANY body part
that might contain binary data (be it encoded as quoted-printable,
base64, or binary).
I have said something similar more than once, and have been flamed an
equivalent number of times. I still do *not* repent...
The argument I have been flamed with is : if some application really
needs a checksum, *it* can provide it. I don't believe in this argument.
Well, of course, the application *can* provide a checksum. But we will
be left with applications providing their own checksums, each one defined
in a different way and stored in a different way within the body part.
Many applications already have a more-or-less standard representation
for their data which does not include a checksum. If RFC XXXX defines
a mechanism for computing and storing a checksum, then it's obvious as to
how you store that application's data in an RFC XXXX body part; otherwise,
you have to write a specification first and get it published as an RFC.
Currently, uuencode might be considered superior to base64. Even
though uuencoded data is more likely to get corrupted, the decoder
can at least detect transmission errors.
Keith