[1135] in Release_7.7_team
Initial Connect-The-Dots proposal
daemon@ATHENA.MIT.EDU (Larry Stone)
Wed Oct 22 01:53:39 1997
Date: Wed, 22 Oct 97 1:53:30 EDT
From: Larry Stone <lcs@MIT.EDU>
To: wdc@MIT.EDU, mbarker@MIT.EDU, fuzzballs@MIT.EDU, cwis-dev@MIT.EDU,
release-team@MIT.EDU
Here is my first cut at a proposal for rationalizing the treatment
of multimedia mail in the Athena environment. It's probably full of
holes and misconceptions, being the first project I've planned since
starting here scant weeks ago, so please send me comments, corrections,
and suggestions. Some parts of this, at least, will probably be
implemented and released in the near future.
-- Larry
------------
Proposal: Connect - The - Dots Project
Multimedia support in Athena mail utilities.
Larry Stone 10-Oct-97
----------------------------------------------------------------------------
Connect-the-dots is a project to bring together the latent capabilities
in mail and multimedia software we already have available to provide
seamless support for sending and receiving multimedia mail in the Athena
environment. The vehicle is the standard MIME (Multipurpose Internet
Mail Extensions) format, which is already used on our existing mail
transport infrastructure.
The actual project is mainly concerned with specifying what kinds of
multi-media support we offer and configuring existing software. Only
a few new pieces of code and data have to be added.
I. Utilities to send / receive MIME mail
A. mhn
This is included in MH 6.8.3, already part of the Athena release.
It needs a new global profile (/usr/athena/etc/mhn_defaults)
which can be automatically derived from the "mailcap" file used
to configure metamail. Mhn is more immediately useful than metamail
since it is part of the MH system.
B. mpack - in graphics locker
Sends a file via MIME, using base64 encoding.
It works fine already, needs no more configuration.
C. mimencode / mmencode
Part of Andrew system, isn't it already in Athena release? (in
/usr/andrew/bin) It is only used to encode (decode) entities within
a MIME message, so it does not read or supply headers. users would
be better off with mpack to completely encapsulate an object in a
MIME message.
D. XMH
Although MHN (above) is integrated smoothly into the command-line MH
environment, the XMH GUI does not use it either for
composing or displaying mail. I haven't investigated too thoroughly
yet, but there does not seem to be any simple way to integrate NMH
into XMH. It could undoubtedly be done if enough demand develops,
since we have the source.
E. METAMAIL
Metamail is available now as part of the Andrew system and there
is no reason to discontinue it, but MHN serves its function in the
MH suite. We should provide a default mailcap file that supports
all of the media types covered by the MHN configuration, however,
so users of other mailers can make use of metamail.
F. Eudora on PC & Mac
Eudora can already send and receive some kinds of multimedia
attachments. It has some unfortunate defaults (i.e. using binhex
encoding by default on a Mac) which ought to be fixed by
providing custom defaults, if we can.
II. Media content-types to be supported:
Each of the following sections describes a type of multi-media data,
identified by its MIME content-type keyword. It is followed by a
description of the type and the reasons for supporting it, and what
program is used by "mhn -show" (or metamail). The "store" action shows
the format of the filename created by "mhn -store".
text/plain
This is the default content type. The "text" type means it is
character data, and "plain" implies that there is no formatting
aside from the usual line breaks. It is presented in an
ordinary text terminal emulator (or in a tty session).
There can also be a "charset" parameter in the content-type.
This identifies the character set in which the text is encoded.
The default is US-ASCII, the 7-bit subset of ASCII adopted by ANSI.
Another common character set is ISO-8859-1, an 8-bit superset of
ASCII that includes characters from some European languages.
Other ISO-8859 character sets may also be used, since they are all
supersets of ASCII and allow the CR, LF, and FF control characters
required by this content-type.
We do not make any special provisions for character sets other than
US-ASCII. Since most common X Window System fonts implement the
ISO-8859-1 character set, a message part in that encoding will probably
display correctly in the typical Athena session. To see other
encodings, the user must set up an xterm with that font, e.g.
"-etl-fixed-medium-r-normal--*-170-*-*-c-*-iso8859-8" for Hebrew.
Also note that MHN does not have provisions to act on the
charset parameter in its configuration file; we would have to
add some simple software to handle different character sets.
This is a hole in the configuration that could be addressed if there
is sufficient demand.
text/html
HTML is, thanks to the WWW, a very popular format for structured
text. Other formats and word-processor products are easily
translated to HTML. Some web browsers and personal-computer mailers
seem to be agressive about sending HTML; I've seen entire messages
consisting of a single text/html entity, with no plain text.
show: htmlview
compose: n/a
print/store: <file>.html
image/*
image/tiff
image/jpeg
image/gif
Images are one of the top-level media types defined by RFC2046,
so they should be expected in MIME messages. Since image data usually
includes a unique header that identifies its format, a single versatile
viewer such as xv(1) can display many kinds of image. It is easy
to add image support, so the only reason not to do it is if we are
worried about how it might be used. For example, large images consume
space and email bandwidth.
Hopefully the most common reason for enclosing an image will be to
add a mug shot (i.e. the usenix facesaver) to the signature of a
message, or similar kinds of annotation.
show: imgview for some types on SGI, xv for image/* and on Sun.
compose: n/a
store: <file>.<subtype>
video/mpeg
video/*
Video is also one of the top-level media types defined by RFC2046.
Most Athena workstations, especially SGIs, have the means to produce
and display video clips. It follows that users may want to share
movies via mail.
Since video data is almost inevitably bulky (on the order of megabytes)
we should NOT encourage anyone to use it. It may be safest not to mention
it at all, or quietly include support but leave it undocumented.
show: movieplayer on sgi, mpeg_play everywhere?
compose: no automated composition, due to bugs in capture when running
under mhn.
store: <file>.<subtype>
audio/basic
audio/*
Audio is even more easily produced on Athena workstations since both
Sparc and SGI machines have microphones and speakers/headphones.
It's not outrageously bulky (though on the order of hundreds of Kb).
Supporting it gives users a way to exploit and experiment with the
multimedia capabilities of Sparc4/5 and Indy workstations.
One risk is that audio must not be played through loudspeakers in
Athena clusters, since it disturbs other users. The MUA must prompt
the user before playing audio and perhaps should include a message
reminding them to use headphones.
show: showaudio, or sfplay on sgi.
store: <file>.<subtype>
? audio/x-pn-realaudio
How prevalent is this media type outside of Web sites?
It may be significant, but I recommend leaving it out for now.
The web browser is configured to handle it but email does not
need to be.
application/postscript
This is a popular output format for word processors and is sometimes
the only format in which a document is available. Users often
send and receive resumes by enclosing a postscript file in mail.
show: ghostview
store: file.ps
application/octet-stream
This is the default media type for random unknown applications. The
MIME spec (rfc2046) demands that a conforming MUA support it. Since
the nature of the data is unknown, the only reasonable course of
action for the MUA is to save the enclosure in a file. The user
should know what to do with it from there.
show: n/a
store: <file>.octet-stream
application/pdf
Like the other Adobe-spawned standard, PostScript, this is yet
another common neutral format for sharing structured text (and
graphics) documents. It is oriented more to present the precise
image of a document than to show the structure. Users can be
expected to receive and exchange PDF documents by email.
show: /afs/athena/software/acro_v3.0/bin/acroread
store: <file>.pdf
print: /afs/athena/software/acro_v3.0/bin/acroread -toPostScript
application/mac-binhex40
It is bogus to use this as a content-type, since BinHex 4.0 is really a
transfer encoding, and the type of the content it encodes is thus
unknown. Unfortunately, the popular Eudora MUA attaches documents
this way (with no transfer-encoding header), at least by default.
Since Athena users receive many messages like this we should
handle them automatically.
The original content-type is lost when the file is encoded this way, so
the most straightforward way to handle an entity of this type is
to decode the Macintosh file and save the data fork verbatim as a Unix
file, discarding the rest of it (Finder info and resource fork).
This lets the recipient of a Word5 document figure out what to do with
it from context, e.g. load it into FrameMaker if there was a helpful
plaintext document identifying it as a MS Word document.
show: unbinhex (new script wrapped around the consult xbin)
store: | unbinhex > <file>.data
application/x-dvi
DVI is the output of TeX, one of the supported document production
systems on Athena, so we can expect users to have it around and want
to exchange it. Displaying it is trivial:
show: /usr/athena/bin/xdvi
store: <name>.dvi
application/x-ez
Likewise, since EZ is a supported Athena application we can expect
users to exchange EZ documents. The ezv viewer makes it trivial
to support this document type.
show: /usr/andrew/bin/ezv
store: name.ez
application/x-framemaker
And finally, FrameMaker is a supported Athena application so we can expect
users to exchange Frame documents too.
to support this document type.
show: /usr/andrew/bin/ezv
store: name.doc
III. New or newly-used tools & files
a. new: mailcap files for sun, sgi platforms. Others needed?
b. new: mailcap2mh filter to translate mailcap to mh_profile
new: auto-generated mh profiles for sun & sgi. /usr/athena/etc/mhn_defaults
c. new: unbinhex filter wrapper, use old xbin program (currently in
consult locker)
d. xv, from graphics locker
e. htmlview from infoagents locker.
f. acroread from acro_v3.0 locker.
g. reader, fmclient (FrameMaker), from frame_v51 locker.
IV. Unresolved Issues.
A. S/MIME and Encryption/Authentication
The forthcoming Secure MIME standard adds "authentication,
message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using
encryption)."
I believe these features could all be useful in an academic
environment, although the specification is still an Internet
Draft. There are tools and commercial products supporting
it already: e.g. the free "premail" package, see
http://www.c2.net/~raph/premail.html, and a bunch
of commercial products for Windows NT/95.
See http://www.rsa.com/smime/html/products.html
S/MIME is not the only answer. There are other contenders for email
security standards, see: http://www.c2.net/~raph/comparison.html for
a concise, critical, survey of alternatives.
B. Media types explicitly ignored.
I am explicitly ignoring some content-types until it is shown
that they are in demand or would be used enough to make some
development effort worthwhile:
text/richtext, text/enriched: These are structured subtypes of text
containing some formatting information. They do not seem to be used
much and the same purpose is served more easily by attaching a
word-processor document file (e.g. FrameMaker, Ez) or HTML to the
message.
text/plain with an exotic charset parameter. We need more information
about what users need since there are many possible character sets
and fonts.
video: I expect the volume of data required by any video clip longer
than a few seconds would be too large for the Athena infrastructure
to support. A single message could easily contain several megabytes
of encoded data. Although Athena workstations can handle this
easily, the mail infrastructure and users' disk quotas cannot.
audio/x-pn-realaudio: Unknown if there is any demand for this format
in email (as opposed to WWW browsers) so wait for demand before
considering any support.
C. Uuencode transfer encoding.
Most MIME-emitting software on Unix (mpack, mmencode, mhn)
sends only the supported content-transfer-encodings (e.g. base64,
quoted-printable). Only Netscape and other MUAs on Mac and PC
platforms seems to produce the somewhat bogus 'x-uuencode'
content-transfer-encoding.
If this is the case, than our users should rarely see uuencoded data
in a MIME message. It can show up outside of a MIME envelope or in
UseNet messages, so they would have to use the uudecode(1) program
outside of the mail reader in any case.
There is still the possibility that well-meaning Mac and PC users send
uuencoded MIME data to Unix users, thinking it is more native than binhex.
If that happens frequently enough, we can modify mhn(1) to decode
it, but that is non-trivial.
