So far so good, but here are some questions that should be addressed:
There probably should be an explicit subtype of TEXT that describes the former
TEXT type as opposed to the former TEXT-PLUS type. This would be the default,
but I think it's important to have a subtype value for that as well. I
suggest `PLAIN', but I'm not particular.
Other questions of defaulting need to be settled. Hopefully most of this
should be non-controversial. We should pick a default cookie for MULTIPART,
if feasible it could be compatible with the old Content-Type RFC's. MTR's
audio proposal needs to be checked for this too; what does `Content-Type:
AUDIO' with no other information mean? I don't really care if it's U-LAW or
sound-file or what, as long as it's defined.
Checksums are a great idea, and I'm all for them. Surprisingly, I'm less in
objection to a Content-Checksum header than I was to a Content-Charset header,
because I have an idea of what Content-Checksum means in the global case!
However, checksumming is something that I feel must be done right the first
time. What is the checksum algorithm? Can we have an explicit specification
of it, including C code, to make damn sure people get it right? What do we
checksum? I would hope that a BASE64 or QUOTED-PRINTABLE segment would
checksum the resulting BINARY/8-TEXT file and not the encoded version. How
meaningful are checksums (other than advisory), for plain-text?
Interestingly, the checksum can reasonably go in the Content-Type header as a
parameter, in the Content-Transfer-Encoding header(!), or in a separate header
such as Content-Checksum. An argument for putting it in transfer-encoding is
that this really is a transfer-encoding issue; an argument against is that it
makes the syntax more complicated since there is no expansion space in that
header (as opposed to Content-Type or a new header). I don't care (for once).
Let's just make sure we get the details outlined above for checksum done
property.