While I am almost deliriously happy with the overall consensus (and the
"AUTHORS' POSITIONS" on most things), a few things need comments:
Excerpts from ext.ietf-822: 6-Nov-91 PLEASE READ -- Open issues .. Ned
A. 1: Audio formats. There are currently two proposals on the table, and
are actually pretty close -- the key open issue is whether the audio data is
preceded by header data, or whether all non-audio information is included on
the content-type line.
AUTHORS' POSITION: Put it on the content-type line.
1) The proposal *with* header data describes an honest-to-god actual
in-use sound format, while the proposal with some data in the
content-type line, some data in the message body, does not.
2) In addition, the first format can be quite simply transformed into a
file or actual audio output stream by simply streaming the body to a
file, converter, or audio device; the second format requires some part
of the mail tool to know how to build audio headers to prefix the data
So: For these two reasons, the first format (ie, header+binary data in
the body of the message) should be used. Of course, some or all of the
header information can also be present in the Content-type attributes,
for the greater convenience of UAs.
A. 2: Checksums:
While I'm not particularly persuaded by the arguments put forward, I'm
not against them either. Two issues: 1) Putting the checksums in the
header effectively prevents stream checksumming of the body (which may
not be a problem); 2) Note that the computation of the checksum is
based on the character codes used for the characters in the body;
gateways which shift the character codes (EBCDIC-ASCII?) will have to
re-compute the checksums (this has been brought up before, I just
thought it could use emphasis).
B. 14: Trojan horses in mail
AUTHORS' POSTION: We should not define/endorse any content-types that
are known to have Trojan horses. (This is one reason why we removed
troff & tex.) We should add a Security Appendix explaining the dangers
of certain conceivable content-types, but we should ban nothing.
I think this ignores the real world. In particular, there is a real and
heavy demand for sending "shar" files, troff, TeX, and PostScript
documents, all of which present nasty Trojan horse problems. All will
still be used, and the fact that they are dangerous should not excuse us
from defining that use (while at the same time explaining the dangers,
and perhaps deprecating their use).
For that matter, taking your attitude to a meta-level, the "application"
type shouldn't even exist, since many applications will present us with
Trojan horse problems :-)
So: Add/keep definitions for troff, TeX and PostScript.