All predefined types and subtypes, as defined in Internet RFC 1521 (Multipurpose Internet Mail Extension), will be handled by Ishmail. The image, audio, video, and application types will not be displayed directly by Ishmail. Rather, Ishmail will rely on the availability of other applications to do this. If defined in a mail capabilities file (mailcap), Ishmail will launch the specified application when it comes across one of these types.
Also, two methods of data encoding will be directly supported by Ishmail; quoted-printable, and base64 (as defined in RFC 1521). Briefly, quoted-printable is for character sets that are a superset of US-ASCII, and encodes any 8-bit characters into a string of 7-bit characters. Base64 is used for parts that are largely (or completely) 8 bit. This is superior to uuencode, because it guarantees that the encoded data will only be 1/3 larger than the original. Another advantage is that Base64 does not rely on the ASCII character set, therefore will decode correctly on a system using, for example, EBCDIC character encoding. However, if a user insists on using uuencode, it is possible to define this through the mailcap file.
Following is an excerpt from the RFC, defining data types:
Text - Textual information. The primary subtype, "plain", indicates plain unformatted text. No special software is required to get the full meaning of the text, aside from support for the indicated character set. Subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes thus include any readable word processor format. A very simple and portable subtype, rich text, is the other predefined subtype. The supported character sets will be US-ASCII and the ISO-8859-* set.
Multipart - Data consisting of multiple parts of independent data types. Four initial subtypes are defined; the primary "mixed" subtype, "alternative" for representing the same data in multiple formats, "parallel" for parts intended to be viewed simultaneously, and "digest" for multipart entities in which each part is of type "message".
Message - An encapsulated message. A body of Content-Type "message" is itself a fully formatted RFC 822 conforming message which may contain its own different Content-Type header field. The primary subtype is "rfc822". The "partial" subtype is defined for partial messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through mail transport facilities. Another subtype, "External-body", is defined for specifying large bodies by reference to an external data source (e.g. the MUA might use anon-ftp to get the data for you).
Image - This format requires a display device (such as a graphical display, a printer, or a FAX machine) to view the information. Initial subtypes are defined for two widely-used image formats, jpeg and gif. The viewer, xloadimage, may be used for gif. The viewer, xv, can display jpeg, but this is not available for resale. It may only be distributed as contributed software.
Audio - With initial subtype "basic". Audio requires an audio output device (such as a speaker or a telephone) to "display" the contents. The "basic" subtype is 8-bit ISDN u-law (PCM), and assumes a 8k Hz sample rate on one channel. This will be the standard audio device provided by HAL (same as Sun).
Video - This format requires the capability to display moving images typically including specialized hardware and software. The initial subtype is "mpeg". A public domain viewer called "mpeg_play" is available for SunOS.
Application - Some other kind of data, typically either un-interpreted binary data or information to be processed by a mail-based application. The primary subtype, "octet-stream", is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. Two additional subtypes, "ODA" and "PostScript", are defined for transporting ODA and PostScript documents in bodies. At this time, and ODA viewer is not defined. Ghostscript is expected to be used as the PostScript viewer. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) e-mail.