ietf-822
[Top] [All Lists]

Re: Content-transfer-encoding: x-uue

1992-02-14 03:14:05
Now, the main reason I'm answering you is the CRC issue:  We all agreed
that a CRC for base64 would be a good thing, but we were unable to agree
on one.  It is, however, the kind of thing that can be phased in later
without much pain, which is why decided to defer it.  (Imagine a
"Content-CRC:" header, for example.)

I don't think that would be a too good way to do it, I'd prefer to see it
a part of base64.  That way you could "sprinkle" the checksums into the
encoded material as tight or as loose as you want.

This may be true, but there are other advantages of a header. In
particular, it becomes possible to check integrity of all messages, not
only encoded ones. This means in particular that an image encoded
using base64 (or x-uue) and subsequently split in several
message/partial messages can have both its parts and the total
checksummed. 

Note that "a header" does not necessarily mean a *separate* header; you
could use a x-crc=n parameter to the content-type. If a real header is
used, careful attention should be paid to what happens with message
splitting and joining (using message/partial).

When applied to an unencoded message the checksum should be insensitive
to trailing spaces. It should be sensitive to all bytes when applied to
a to-be-encoded (quoted-printable or base64) message. Satisfying these
conflicting goals are to be satisfied may be an interesting exercise.

--
Luc Rooijakkers                                 Internet: 
lwj(_at_)cs(_dot_)kun(_dot_)nl
Faculty of Mathematics and Computer Science     UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands         tel. +3180652271