Archive-Name: mail/mime-faq/part3
Version: $Id: mime3,v 3.20 1996/09/09 00:50:39 jsweet Rel $
Posting-Frequency: monthly


--
==========================================================
comp.mail.mime frequently asked questions list (FAQ) (3/3)
==========================================================
Part 3: Advanced Topics
~~~~~~
--

Overview
--------
This is part 3 of a Frequently Asked Questions document about MIME,
the multipurpose and multi-media standard for Internet mail.

Part 1 covers frequently asked questions.

Part 2 is a listing of MIME products.

Part 3 covers advanced topics.
--

3.1) Information
----------------

3.1.1) MIME-relevant RFCs, drafts, and standards

The RFCs mentioned here are mainly relevant to persons building MIME
software.  As an end user, if your mail system is nice to you, you
won't really have to know very much about these things.

RFC and Internet-Drafts are available by anonymous FTP from any decent
archive site.  If you're really stuck, try these URLs:

ftp://ds.internic.net/rfc/
ftp://ds.internic.net/internet-drafts/

Additionally, RFCs may be requested from a mail-based archive server
by sending a message to "mailserv@ds.internic.net".  In the body of
the message, include one of the following commands:

    document-by-name rfcNNNN
    document-by-name rfcNNNN.ps
    document-by-name rfc-index

where NNNN is the number of an RFC to retrieve.  Not all RFCs are
available in PostScript (.ps) format.  Retrieve the rfc-index to
find out what's available.


MIME is primarily defined in these two RFCs:

    RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One:
              Mechanisms for Specifying and Describing the Format of
              Internet Message Bodies

    RFC 1522: MIME (Multipurpose Internet Mail Extensions) Part Two:
              Message Header Extensions for Non-ASCII Text

These two RFCs do not fully define MIME.  For one thing, they are
based on RFC 822 (Standard for the format of ARPA Internet text
messages), as revised by RFC 1123 (Requirements for Internet hosts -
application and support) and must be read in conjunction with these.

For another, the RFCs are extensible.  See section 3.1.2 for a list of
registered subtypes.


Drafts in progress for revisions to the MIME specifications include
these:

  ftp://ds.internic.net/internet-drafts/draft-ietf-822ext-mime-imb-07.txt
    "Multipurpose Internet Mail Extensions (MIME) Part One:  Format of 
    Internet Message Bodies", 07/03/1996.

  ftp://ds.internic.net/internet-drafts/draft-ietf-822ext-mime-imt-05.txt
    "Multipurpose Internet Mail Extensions (MIME) Part Two:  Media 
    Types", 07/03/1996.

  ftp://ds.internic.net/internet-drafts/draft-ietf-822ext-mime-hdrs-00.txt
    "Multipurpose Internet Mail Extensions (MIME) Part Three: Message
    Header Extensions for Non-ASCII Text", 06/03/1996.

  ftp://ds.internic.net/internet-drafts/draft-ietf-822ext-mime-reg-04.txt
    "Multipurpose Internet Mail Extensions (MIME) Part Four:  Registration 
    Procedures", 07/03/1996.

  ftp://ds.internic.net/internet-drafts/draft-ietf-822ext-mime-conf-06.txt
    "Multipurpose Internet Mail Extensions (MIME) Part Five:  Conformance 
    Criteria and Examples", 07/03/1996.

There are many other MIME-related drafts.  For a quick overview of
current Internet drafts, check out this document:

  ftp://ds.internic.net/internet-drafts/1id-index.txt


The MIME RFCs are Internet standards-track protocols.  For the full
implications of this, see RFC 1920 (Internet Official Protocol
Standards).

Many other RFCs deal with e-mail, including these:

IAB standards or standards-track RFCs

    RFC 1985  SMTP Service Extension for Remote Message Queue Starting
    RFC 1939  Post Office Protocol - Version 3
    RFC 1894  An Extensible Message Format for Delivery Status Notifications
    RFC 1893  Enhanced Mail System Status Codes
    RFC 1892  The Multipart/Report Content Type for the Reporting of Mail
              System Administrative Messages
    RFC 1891  SMTP Service Extension for Delivery Status Notifications
    RFC 1870  SMTP Service Extension for Message Size Declaration
    RFC 1869  SMTP Service Extensions
    RFC 1866  Hypertext Markup Language - 2.0
    RFC 1864  The Content-MD5 Header Field
    RFC 1848  MIME Object Security Services
    RFC 1847  Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted
    RFC 1767  MIME Encapsulation of EDI Objects
    RFC 1740  MIME Encapsulation of Macintosh files - MacMIME
    RFC 1734  POP3 AUTHentication command
    RFC 1731  IMAP4 Authentication mechanisms
    RFC 1730  Internet Message Access Protocol - Version 4
    RFC 1700  Assigned Numbers   { Way more than the title implies. }
    RFC 1652  SMTP Service Extension for 8bit-MIMEtransport
    RFC 1502  X.400 Use of Extended Character Sets
    RFC 1496  Rules for Downgrading Messages from X.400(88) to X.400(84)
              when MIME Content-Types are Present in the Messages
    RFC 1495  Mapping between X.400 and RFC-822 Message Bodies
    RFC 1494  Equivalences between 1988 X.400 and RFC-922 Message Bodies
    RFC 1424  Privacy Enhancement for Internet Electronic Mail: Part IV
    RFC 1423  Privacy Enhancement for Internet Electronic Mail: Part III
    RFC 1422  Privacy Enhancement for Internet Electronic Mail: Part II
    RFC 1421  Privacy Enhancement for Internet Electronic Mail: Part I
    RFC 1327  Mapping between X.400(1988)/ISO 10021 and RFC 822
    RFC 1314  File format for the exchange of images in the Internet

Other RFCs (Informational, Experimental, or Historical)

    RFC 1991  PGP Message Exchange Formats
    RFC 1945  Hypertext Transfer Protocol -- HTTP/1.0
    RFC 1922  Chinese Character Encoding for Internet Messages
    RFC 1911  Voice Profile for Internet Mail
    RFC 1896  The text/enriched MIME Content-type
    RFC 1895  The Application/CALS-1840 Content Type
    RFC 1874  SGML Media Types
    RFC 1873  Message/External-Body Content-ID Access Type
    RFC 1872  The MIME Multipart/Related Content-type
    RFC 1867  Form-based File Upload in HTML
    RFC 1844  Multimedia E-mail (MIME) User Agent checklist
    RFC 1838  Use of the X.500 Directory to support mapping between
              X.400 and RFC 822 Addresses
    RFC 1830  SMTP Service Extensions for Transmission of Large
              and Binary MIME Messages
    RFC 1815  Character Sets ISO-10646 and ISO-10646-J-1
    RFC 1806  Communicating Presentation Information in
              Internet Messages: The Content-Disposition Header
    RFC 1741  MIME Content Type for BinHex Encoded Files
    RFC 1733  Distributed Electronic Mail Models in IMAP4
    RFC 1732  IMAP4 Compatibility With IMAP2 and IMAP2bis
    RFC 1641  Using Unicode with MIME
    RFC 1590  Media Type Registration Procedure
    RFC 1557  Korean Character Encoding for Internet Messages
    RFC 1556  Handling of Bi-directional Texts in MIME
    RFC 1555  Hebrew Character Encoding for Internet Messages
    RFC 1524  A User Agent Configuration Mechanism For Multimedia 
              Mail Format Information
    RFC 1506  A tutorial on gatewaying between X.400 and Internet mail
    RFC 1505  Encoding Header Field for Internet Messages
    RFC 1489  Registration of a Cyrillic Character Set
    RFC 1468  Japanese Character Encoding for Internet Messages
    RFC 1456  Conventions for Encoding the Vietnamese Language
    RFC 1428  Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
    RFC 1357  Format for emailing bibliographic records
    RFC 1345  Character Mnemonics & Character Sets
    RFC 1344  Implications of MIME for Internet mail gateways
    RFC 1339  Remote mail checking protocol
    RFC 1321  MD5 Message-Digest algorithm
    RFC 1211  Problems with the maintenance of large mailing lists
    RFC 1197  Using ODA for translating multimedia information
    RFC 1176  Interactive Mail Access Protocol: Version 2
    RFC 1153  Digest message format
    RFC 1036  Standard for interchange of USENET messages
    RFC 0934  Proposed standard for message encapsulation
    RFC 0822  Standard for the format of ARPA Internet text messages
    RFC 0821  Simple Mail Transfer Protocol
    RFC 0807  Multimedia mail meeting notes

Overtly Silly RFCs

    RFC 1927  Suggested Additional MIME Types for Associating Documents
    RFC 1437  The Extension of MIME Content-Types to a New Medium

--------------------------------

3.1.2) MIME types

There are registered and unregistered MIME types.  Unregistered MIME
types begin with an "x-" and their meanings generally depend on
private agreements between senders and receivers.  This section lists
registered types and some known unregistered types.

--------------------------------

3.1.2.1) List of registered MIME types

The latest list of registered MIME types is available from the ISI
media-types file at this URL:

ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types

The media-types file also lists character sets registered for use with
MIME, access types for external-body contents, content-transfer-encodings,
and MIME/X.400 mapping tables.

The list of media types below is taken from the June, 1996 version of
the aforementioned ISI media-types file.  The list isn't guaranteed to
be up-to-the-minute.

Some types, although described in RFCs, are either not officially
registered, or may never have been submitted for registration.  If
such types are not listed in the ISI media-types file, they are not
included here with the registered types, and may instead be listed in
section 3.1.2.2, the list of unregistered MIME types.

Subtypes exist whose names begin with "vnd.".  The "vnd"  prefix,
which stands for "vendor", is part of a hierarchical name space
proposed in this draft document:

  ftp://ftp.isi.edu/internet-drafts/draft-ietf-822ext-mime-reg-04.txt

As noted in RFC 1590, "The registration of a data type does not imply
endorsement, approval, or recommendation by IANA or IETF or even
certification that the specification is adequate."  Accordingly, the
descriptions of some registered types listed in the ISI media-types
files may refer to materials available only from off-line commercial
sources, or refer to individuals rather than documents.  In such
cases, a little more digging, or even reverse-engineering, may be
required to obtain details on the media-types of interest.
You may find that some of the ISI media-types files are somewhat 
outdated, particularly if they still refer to RFC 1341 (obs.).

{ If you know of an especially useful or definitive URL for any
particular registered or unregistered type, please drop a note to the
MIME FAQ maintainers. }

{ Also, if you know of a bit of software, commercial or otherwise,
that decodes or displays a given type, please drop a note to the MIME
FAQ maintainers.  URLs that are known to work for the public are
especially appreciated. }


3.1.2.1.1) Application types

type: application/activemessage
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/activemessage

type: application/andrew-inset
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/andrew-inset

type: application/applefile
see: RFC 1740
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/applefile

type: application/atomicmail
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/atomicmail

type: application/cals-1840
see: RFC 1895
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/cals-1840

type: application/commonground
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/commonground

type: application/cybercash
see: RFC 1898
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/cybercash

type: application/dec-dx
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/dec-dx

type: application/dca-rft
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/dca-rft

type: application/eshop
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/eshop

type: application/iges
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/iges

type: application/mac-binhex40
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/mac-binhex40

type: application/macwriteii
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/macwriteii

type: application/mathematica
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/mathematica

type: application/msword
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/msword

type: application/news-message-id
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/news-message-id

type: application/news-transmission
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/news-transmission

type: application/octet-stream
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/octet-stream

type: application/oda
see: RFC 1494
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/oda

type: application/pdf
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/pdf

type: application/postscript
see: RFC 1521
see: news:comp.lang.postscript
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/postscript

type: application/remote-printing
see: RFC 1528
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/remote-printing

type: application/riscos
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/riscos

type: application/rtf
see: ftp://indri.primate.wisc.edu/pub/RTF/RTF-Spec.rtf
see: ftp://indri.primate.wisc.edu/pub/RTF/RTF-Spec.hqx 
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/rtf

type: application/sgml
see: RFC 1874
comment: no corresponding media-types file at ISI.

type: application/slate
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/slate

type: application/vnd.framemaker
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.framemaker

type: application/vnd.koan
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.koan

type: application/vnd.mif
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.mif

type: application/vnd.ms-artgalry
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.ms-artgalry

type: application/vnd.ms-excel
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.ms-excel

type: application/vnd.ms-powerpoint
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.ms-powerpoint

type: application/vnd.ms-project
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.ms-project

type: application/vnd.ms-tnef
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.ms-tnef
comment: 

    [ Carl S. Gutekunst <csg@clavinova.eng.sun.com> 14-Mar-1996 ]

    TNEF (Transport Neutral Encapsulation Format) contains a serialization
    of an entire Microsoft MAPI message.  It is not an encoding format
    like uuencode is.
    
    Usually the TNEF part doesn't have anything in it that would be of
    interest to a MIME client, e.g., Microsoft's own rich text markup.
    The exception is when the sender does a drag-and-drop from an OLE
    application into a message; the dragged object is carried only in the
    TNEF part.

    [ Carl S. Gutekunst <csg@clavinova.eng.sun.com> 18-Jun-1996 ]

    There is enough information in the Microsoft TNEF SDK
    documentation to at least partially clone TNEF for use in
    non-Microsoft mail clients.

    [ Mark Horton <mark@clipper.cb.lucent.com> 12-Jul-1996 ]

    TNEF has extra info that would otherwise be discarded by translation
    into RFC 822 - things like the fonts, pointsizes, and alignment of any
    rich text in the message.  Microsoft puts it there so a receiving
    Exchange can re-establish richtext on the incoming message.
    
    Sort of like how color TV in the US is just B/W TV with extra info on
    the side for the color info, thus permitting existing B/W TV sets to
    keep working.
    
    I would not bother trying to translate TNEF.  There's no useful
    information in it.  Unless you're trying to translate the entire
    message into HTML.


type: application/vnd.truedoc
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.truedoc

type: application/vnd.ms-works
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.ms-works

type: application/vnd.music-niff
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.music-niff

type: application/vnd.svd
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/vnd.svd

type: application/wita
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/wita

type: application/wordperfect5.1
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/wordperfect5.1

type: application/x400-bp
see: RFC 1494
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/x400-bp

type: application/zip                 
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/zip                 


3.1.2.1.2) Audio types

type: audio/basic
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/audio/basic

type: audio/32kadpcm
see: RFC 1911
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/audio/32kadpcm


3.1.2.1.3) Image types

type: image/cgm
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/cgm

type: image/g3fax
see: RFC 1494
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/g3fax

type: image/gif
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/gif

type: image/ief
see: RFC 1314
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/ief

type: image/jpeg
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/jpeg

type: image/naplps
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/naplps

type: image/tiff
see: RFC 1314
see: RFC 1528
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/tiff

type: image/vnd.dwg
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/vnd.dwg

type: image/vnd.dxf
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/vnd.dxf

type: image/vnd.svf
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/vnd.svf


3.1.2.1.4) Message types

type: message/external-body
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/external-body

type: message/http
see: RFC 1945

type: message/news
see: RFC 1036
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/news

type: message/partial
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/partial

type: message/rfc822
see: RFC 1521
see: RFC 822
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/rfc822


3.1.2.1.5) Multipart types

type: multipart/alternative
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/alternative

type: multipart/appledouble
see: RFC 1740
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/appledouble

type: multipart/digest
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/digest

type: multipart/form-data
see: RFC 1867
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/form-data

type: multipart/header-set
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/header-set

type: multipart/mixed
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/mixed

type: multipart/parallel
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/parallel

type: multipart/related
see: RFC 1872

type: multipart/report
see: RFC 1892
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/report

type: multipart/voice-message
see: RFC 1911
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/voice-message


3.1.2.1.6) Text types

type: text/enriched
see: RFC 1896
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/enriched

type: text/html
see: RFC 1866
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/html

type: text/plain
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/plain

type: text/richtext
see: RFC 1341 (obs.)
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/richtext
comments: obsolete - see text/enriched instead

type: text/sgml
see: RFC 1874
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/sgml

type: text/tab-separated-values
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/tab-separated-values


3.1.2.1.7) Video types

type: video/mpeg
see: RFC 1521
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/mpeg

type: video/quicktime
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/quicktime

type: video/vnd.vivo
see: ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/vnd.vivo


3.1.2.1.8) Character sets

See RFC 1700 for the latest list of registered character sets.
These character sets are known to be registered at the time of
this writing:

what: charset=ISO-8859-1
see: ISO_8859-1:1987

what: charset=ISO-8859-2
see: ISO_8859-2:1987

what: charset=ISO-8859-3
see: ISO_8859-3:1988

what: charset=ISO-8859-4
see: ISO_8859-4:1988

what: charset=ISO-8859-5
see: ISO_8859-5:1988

what: charset=ISO-8859-6
see: ISO_8859-6:1987

what: charset=ISO-8859-7
see: ISO_8859-7:1987

what: charset=ISO-8859-8
see: ISO_8859-8:1988

what: charset=ISO-8859-9
see: ISO_8859-9:1989

what: charset=US-ASCII
see: ANSI_X3.4-1968


3.1.2.1.9) Access types for external contents

what: access-type=AFS
for: CMU Andrew File System
see: http://www.transarc.com/afs/transarc.com/public/www/Product/AFS/FAQ/faq.html

what: access-type=ANON-FTP
for: anonymous FTP
see: RFC 1635
see: RFC 959

what: access-type=content-id
for: Message/External-Body Content-ID Access Type
see: RFC 1873

what: access-type=FTP
for: non-anonymous FTP
see: RFC 959

what: access-type=LOCAL-FILE
for: directly retrievable file
see: RFC 1521

what: access-type=MAIL-SERVER
for: request to a mail-based archive server
see: RFC 1521

what: access-type=TFTP
for: trivial file transfer protocol
see: RFC 1350


3.1.2.1.10) Content transfer encodings

cte: 7BIT
see: RFC 1521

cte: 8BIT
see: RFC 1521

cte: BASE64
see: RFC 1521

cte: BINARY
see: RFC 1521

cte: QUOTED-PRINTABLE
see: RFC 1521

--------------------------------

3.1.2.2) List of known unregistered MIME types

Here is a list of some known x-types, x-subtypes, and x-parameters.

The enumeration of these x-types here does not imply any kind of
standardization or open specification.  The meanings of x-types depend
on private agreements between senders and receivers.  Some x-types may
eventually become registered types; see sections 3.1.2.1 and 3.2.1.

Just because an x-type is generated by a proprietary mail user agent
doesn't necessarily mean that only that MUA can handle the x-type.
Metamail and MH, for example, permit you to set up your own mechanisms
to handle various standard and non-standard content types.  In
particular, it may simply be a matter of invoking some commercial
application (aka invoking an "external viewer") to view data used by
that application.

The Metamail source distribution comes with pre-defined mailcap
entries for handling some x-types; these may offer clues about how to
configure your own mail user agent.

Not all of the x-types listed here begin with "x-".  Although x-types
without the "x-" prefix may contravene the MIME specification, the
fact remains that someone out there is generating them.  Listing such
types here is not intended to enshrine such types.

{ NOTE: some of the meanings of these x-types are GUESSES by the FAQ
  maintainer.  Please let us know about incorrect guesses, and, if
  possible, supply a URL pointing to information about the x-type.
 
  And please feel free to let us know about whatever wacko or not-so-wacko
  x-types that your UAs may unleash on an unsuspecting world.  If you
  have a URL for a document that describes the format, so much the
  better.  Please at least let us know what applications are generating
  the x-types in question.  }


3.1.2.2.1) Application types

type: application/green-commerce
for: commercial transactions
see: http://www.fv.com/pubdocs/agc-spec.txt

type: application/ms-tnef
from: Microsoft
see: application/vnd.ms-tnef

type: application/pgp
from: PGP
for: Pretty Good Privacy
see: section 1.3.3

type: application/safe-tcl      
for: enabled-mail
comment: see multipart/enabled-mail, below

type: application/x-aiff
from: Z-Mail
for: AIFF audio data

type: application/x-bcpio
from: MHonArc
for: bcpio data

type: application/x-bitmap
from: Z-Mail
for: X11 bitmaps

type: application/x-cpio
from: MHonArc
for: cpio archives

type: application/x-csh
from: MHonArc
for: csh scripts

type: application/x-dvi
from: MHonArc
for: TeX DVI data

type: application/x-framemaker
from: Z-Mail
for: FrameMaker documents

type: application/x-gtar
from: MHonArc
for: GNU tar archives

type: application/x-hdf
from: MHonArc
for: hdf data

type: application/x-inventor
from: Z-Mail
for: Inventor files

type: application/x-island-draw
from: Z-Mail
for: IslandDraw files

type: application/x-island-paint
from: Z-Mail
for: IslandPaint files

type: application/x-island-write
from: Z-Mail
for: IslandWrite files

type: application/x-jot
from: Z-Mail
for: Jot documents

type: application/x-latex
from: MHonArc
for: LaTeX documents

type: application/x-lotus-notes
from: Lotus Notes
comment: may use unregistered cte "uue" (uuencode)

type: application/x-macbinhex40
from: TCP/Connect II
for: Mac BinHex 4.0
comment: see application/macbinhex40

type: application/x-metamail-patch
from: metamail
for: patches to metamail

type: application/x-mif
from: MHonArc
for: Frame MIF documents

type: application/x-movie
from: Z-Mail
for: MoviePlayer documents

type: application/x-ms-tnef
from: Worldtalk
for: proprietary "tunneling" type for MS Exchange

type: application/x-netcdf
from: MHonArc
for: netcdf data

type: application/x-patch
from: { unknown }
for: miscellaneous source code patches
see: patch(1)

type: application/x-sgi
from: Z-Mail
for: SGI ImageWorks documents

type: application/x-sh
from: MHonArc
for: sh scripts
comments: obvious security problem

type: application/x-shar
from: MHonArc
for: shell archives
comments: obvious security problem

type: application/x-showcase
from: Z-Mail
for: Showcase documents

type: application/x-sv4cpio
from: MHonArc
for: SVR4 cpio archives

type: application/x-sv4crc
from: MHonArc
for: SVR4 crc data

type: application/x-tar
from: MHonArc
for: tar archives

type: application/x-tcl
from: MHonArc
for: tcl programs
comments: obvious security problem

type: application/x-tex
from: MHonArc
for: TeX documents

type: application/x-texinfo
from: MHonArc
for: GNU texinfo documents

type: application/x-troff
from: MHonArc
for: plain troff documents

type: application/x-troff-man
from: MHonArc
for: troff -man documents

type: application/x-troff-me
from: MHonArc
for: troff -me documents

type: application/x-troff-ms
from: MHonArc
for: troff -ms documents

type: application/x-ustar
from: MHonArc
for: ustar data

type: application/x-wais-source
from: MHonArc
for: WAIS sources

type: application/x-wingz
from: Z-Mail
for: Wingz documents

type: application/x-xpm1
from: Z-Mail
for: OL pixmap files

type: application/x-wt-stf
from: Worldtalk
for: proprietary "tunneling" type for Worldtalk

type: application/x-zm-fax
from: Z-Mail
for: Z-Fax documents


3.1.2.2.2) Audio types

type: audio/x-aiff
from: MHonArc
for: AIFF audio data

type: audio/x-wav 
from: MHonArc
for: WAV audio data

type: audio/x-macaudio
from: Iride
for: NOT sampled Macintosh audio

type: audio/x-next
from: MH 6.8
for: self-describing SunOS/NeXT audio data
see: ftp://ftp.ics.uci.edu/pub/mh/contrib/multimedia/mhn-tutorial.ps
comment: suggested by MH 6.8 docs


3.1.2.2.3) Image types

type: image/x-cmu-raster
from: MHonArc
for: CMU raster data

type: image/x-fits
for: FITS files

type: image/x-macpict
from: TCP/Connect II
from: Iride
for: Macintosh PICT

type: image/x-pbm
from: MHonArc
for: portable bit map data

type: image/x-pgm
from: MHonArc
for: PGM data

type: image/x-pict
from: MHonArc
for: Macintosh PICT data

type: image/x-pnm
from: MHonArc

type: image/x-portable-anymap
from: MHonArc

type: image/x-portable-bitmap
from: MHonArc

type: image/x-portable-graymap
from: MHonArc

type: image/x-portable-pixmap
from: MHonArc

type: image/x-ppm
from: MHonArc

type: image/x-rgb
from: MHonArc

type: image/x-xbitmap
from: MHonArc
for: in-lines into the HTML

type: image/x-xbm
from: MHonArc
for: in-lines into the HTML

type: image/x-xpixmap
from: MHonArc

type: image/x-xpm
from: MHonArc

type: image/x-xwd
from: MHonArc

type: image/x-xwindowdump
from: MHonArc
for: X window dump


3.1.2.2.4) Multipart types

type: multipart/enabled-mail
see: section 2.1 of the MIME FAQ - "Safe-TCL (Enabled Mail)"
see: ftp://ftp.bellcore.com/pub/nsb/st/em-model.txt
see: ftp://ftp.bellcore.com/pub/nsb/st/safe-tcl.txt

type: multipart/encrypted
see: RFC 1847

type: multipart/signed
see: RFC 1847


3.1.2.2.5) Text types

type: text/unknown
from: Worldtalk

type: text/x-html
from: MHonArc
comment: see type text/html

type: text/x-setext
from: MHonArc
for: setext

type: text/x-usenet-faq
for: Ohio State WWW FAQ documents


3.1.2.2.6) Video types

type: video/x-msvideo
from: MHonArc: Microsoft video data

type: video/x-qtc
from: Apple Computer
for: QuickTime TV conference calls

type: video/x-qtv
from: Apple Computer
for: QuickTime TV video/audio broadcasts

type: video/x-sgi-movie
from: MHonArc: SGI movie data


3.1.2.2.7) Other top-level types

type: x-be2
from: Andrew
comment: old

type: x-sun-attachment
from: Sun MicroSystems mailtool

type: x-zm-multipart
from: Z-Mail
comment: old


3.1.2.2.8) Content transfer encodings

cte: uue
for: uuencoded data

cte: uuencode
for: uuencoded data

cte: x-uue
for: uuencoded data

cte: x-uuencode
for: uuencoded data


3.1.2.2.9) Miscellaneous x-parameters

what: charset=x-unknown
in: text/plain
from: MH 6.8.3
for: untagged charsets

what: x-conversions=compress
in: application/octet-stream; type=tar
from: MH 6.8 "viamail"
see: tar(1)
see: compress(1)


--------------------------------

3.1.3) Internet Engineering Task Force (IETF) working groups

The IETF working group on Privacy-Enhanced Mail (PEM) has developed
extensions that permit confidentiality, authentication, and integrity
to be provided in a manner backwards compatible with RFC 821 and
RFC 822.  Work is underway to align PEM and MIME which will provide
real security to MIME e-mail.

The IETF MIME working group is not actively considering significant
changes to the specifications.  However the WG still exists as a forum
for MIME developers, as a home for interpretation questions, and to
handle any problems or ambiguities that might arise in MIME.

See also: part 1.

--

3.2) Developers' FAQs
---------------------

3.2.1) How can I register a new MIME type?

The procedures for registering new content types, character set
values, access types, and conversion parameters with IANA (the
Internet Assigned Numbers Authority) are documented in RFC 1590.

    [ "Harald T. Alvestrand" <Harald.T.Alvestrand@uninett.no> 27-Oct-94 ]

    I put up a few words on how I understand the current MIME body
    part registration procedures on
    
    http://domen.uninett.no/~hta/ietf/media-types.html
    
    The Web version includes hyperlinks to the relevant IANA archives
    and RFCs.

RFC 1590 makes mention of a discussion list for type registration,
"ietf-types".  The current subscription request address for the
ietf-types list is this:

        ietf-types-request@uninett.no

Harald T. Alvestrand's aforementioned web page on MIME body part
registration procedures also contains a pointer to the list's message
archive, amongst other useful information.

Proposed new type naming conventions, some of which appear to have
been adopted already, are discussed in this draft document:

ftp://ftp.isi.edu/internet-drafts/draft-ietf-822ext-mime-reg-03.txt

--------------------------------

3.2.2) What's ESMTP, and how does it affect MIME?

ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism by which
extensions to "traditional" (RFC 821) SMTP can be negotiated by client
and server.  The mechanism (RFC 1869) is open-ended; so far two
extensions have been defined.

Message size declaration (RFC 1870) offers a graceful way for servers
to limit the size of message they are prepared to accept.  (With SMTP,
the only possibility is for the server to discard the message after it
has been sent in its entirety.  There is no way for the client to know
that it was the size of the message that caused the problem.)

When a message is returned to the user as being too large to deliver,
one possible approach might be to fragment the message using the MIME
Message/Partial mechanism, and resubmit it.

Depending on the exact reason for the "too large" rejection, this may
or may not be a good idea.  For example, the limitation may reflect
the recipient's disk quota, in which case the fragmented message will
not be fully deliverable either.

The possibility of fragmentation should, therefore, be left to the
user's discretion (not performed automatically by the SMTP client).

8bit-MIMEtransport (RFC 1652) opens up the possibility of sending 8bit
data in mail messages, without having to use base64, quoted-printable,
or another encoding, and without the breakage that can result from
sending 8bit data to an unsuspecting RFC 821 SMTP server.  RFC 1428
(Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME)
discusses some of the implications of this.

--------------------------------

3.2.3) Where can I get some sample MIME messages?

Here are two sources:

ftp://ftp.bellcore.com/pub/nsb/samples/
http://www-dsed.llnl.gov/documents/tests/email.html

Here're more sources:

    [ Patrik Faltstrom <paf@bunyip.com> 13-Dec-1994 ]

    At 12:55 AM 12/11/94, Richard Willis wrote:
    >Could someone tell me what the address of the person in Sweden
    >is who kindly provided a set of MIME-conformancy tests via
    >listserver...
    
    My address is paf@bunyip.com, and the address of the listserver
    is mimeback@bunyip.com. Send the command (actually the name of the
    file you want) as the subject in the message. Start with the command
    "HELP".

    [ "Erik Huizer (SURFnet BV)" <Erik.Huizer@surfnet.nl> 20-Jan-1995 ]

    Test messages can be requested in the following way:
    Send mail to <mime-test@relay.surfnet.nl> with a subject field
    containing [ a type/subtype designation, or one of these: ]

    X-local     <to test how your UA deals with undefined content-types>
    nested      <returns a message that contains nested multipart contents>
    iso-8859-1  <returns a message with text/plain charset=iso-8859-1>

    A message containing the requested content-type will be returned to
    the address contained in the from field.

--------------------------------

3.2.4) Wouldn't MIME be better if it did <foo>?

This question is asked for various values of <foo>.  Perhaps the most
common is "multilevel encodings": see the next question.  There are
a couple general points that apply to all <foo>.

1. Please remember that MIME is the result of a lot of work by a lot
of persons, over a long time (look at the Acknowledgements section of
RFC 1521).  A great many ideas, probably including yours, were
considered.  In many cases, there were conflicting goals, such as
simplicity and interoperability on the one hand, and power and
flexibility on the other.

2. If you really think you've got an original idea which would improve
MIME, the correct place to pursue it is not this newsgroup, but the
working group mailing list (having first read the archives, to check
that it really is new).  Yes, this is going to be a lot more work than
posting a news article.

--------------------------------

3.2.5) So what about multilevel encodings?

MIME uses a two-level encoding scheme.  The original object (for
example, a picture, or a text document) is encoded using a well
defined mechanism appropriate to that object (perhaps GIF for the
picture, and text/enriched for the document).  Then a second encoding
is used to ensure that the first encoding can be transmitted intact
(probably base64 for the GIF, and quoted printable for the
text/enriched document). 

Note that there is a very small number of the second encodings (five,
but three of these are simply indications of what kind of data an
unencoded body part contains), and it is not expected that there will
be many more in the foreseeable future.

The multilevel encodings idea is for a more generalized MIME-like
encoding mechanism that could indicate many arbitrary transformations
of the original object.  For example,

    Content-Type: application/tar; conversions="encrypt,compress,uuencode"

might indicate a UNIX tar file that had been encrypted, then
compressed, then uuencoded.  (This is a fictitious example of how MIME
might have worked; it's not legal MIME.  Don't worry if you've never
heard of some of these transformations.)

This may look like an attractive scheme at first, but it has a number
of problems.

1. If you've been brought up on UNIX and command pipelines, the
implementation of such a scheme seems trivial.  Surely any half-decent
machine can do something similar?  Unfortunately, this turns out to be
true only for a very restricted definition of "half-decent".  In
practice, it would be awfully difficult to implement this on a lot of
systems.  Probably even more systems would not allow new
transformations to be just "slotted in", and would require
recompilation or reshipping whenever a new one came along.

2. Each successive transformation reduces the size of the audience who
can successfully decode the message.  Every MIME mailer must be able
to decode base64 and quoted-printable, so it's guaranteed that you can
at least get back to the raw data.  What if, in the above example, I
have tar, decrypt, uudecode, but no uncompressor?

3. Such a scheme does not increase the scope of the framework defined
by MIME.  If uuencoded, compressed, encrypted tar files are useful
things to sling around, it is entirely possible to define a new MIME
type (presumably a subtype of application) to handle them.

--------------------------------

3.2.6) Why doesn't MIME include a mechanism for compression?

Compression is a difficult area.  It was considered by the working
group, but no consensus was reached.  There is still work going on in
this area: there may someday be a compressed-64 encoding.

Most compression algorithms have one of more of these undesirable
properties: they are covered by patent, they require the ability to
treat the input as a stream of bits, they use a large data space.  The
chances of finding a truly interoperable compression algorithm are
therefore rather slim.

It is worth noting that most or all of the image and video subtypes
(including GIF, JPEG, TIFF, and MPEG) define their own compression
schemes.

--------------------------------

3.2.7) What's this Content-Disposition header?

It's a way to specify what needs to be done with a MIME content, such
as storing it in a file with a particular name, or displaying it.

For information about Content-Disposition, see RFC 1806.

See also RFC 1872 and the following draft document for information
about a complementary content-type, multipart/related.

  ftp://ftp.isi.edu/internet-drafts/draft-ietf-mhtml-related-00.txt

In the draft, interaction between Content-Disposition and
multipart/related is discussed.

--

3.2.8)  What character sets can be used with MIME?

There are several character sets registered for use with MIME.  The
registered character sets are listed in the media-types document; see
section 3.1.2.1.8, above.

    [ Jungshik Shin <jungshik@net161-61.student.yale.edu> 20-Jul-1996 ]

    Chuck Cairns (chuckc@fc.hp.com) wrote:
    > Can someone give me a pointer to the MIME charsets used for Japanese
    > (shift-jis and euc) and Chinese. I've read thru the faq and looked at
    > rfc1700 but it's not clear to me what is usual practice.
    
    See RFC 1468 for Japanese, RFC 1557 for Korean and RFC 1922 for
    Chinese, all available at ftp://ftp.internic.net/rfc and other places.
    Also, you may wish to read Ken Lunde's CJK.inf at
    http://jasper.ora.com/lunde and references therein.

--

3.3) Acknowledgements
---------------------

In addition to those named elsewhere in this document, contributors to
this document have included these persons:

Niklas Agren
Harald Alvestrand
Ed Anselmo
Ran Atkinson
Ron Barak
David Barr
Jason Beyer
Axel Boldt
Nathaniel Borenstein
Yehavi Bourvine
Douglas Boyce
David Collier-Brown
Mark Crispin
Dave Curry
Roman Czyborra
Christopher Davis
Steve Dorner
David Eaves
Paul Eggert
Daniel Fandrich
Pat Farrell
James Ford
Ned Freed
John Gardiner Myers
Daniel Glazman
Tim Goodwin
Mark Grand
Ed Greshko
Joergen Haegg
Gisle Hannemyr
Alec Henderson
Steve Hole
Ian Hoyle
Craig Huckabee
Joe Ilacqua
Olle Jarnefors
Tim Kehres
Brad Knowles
Dave Lacey
Ray Langford
Carlyn Lowery
Stuart Lynne
John Martin
David Miller
Keith Moore
Lars-Gunnar Olsson
Michael Parson
Jerry Peek
Chris Pepper
John R MacMillan
Rich Ragan
Joyce Reynolds
Alan Robiette
John Romine
Luc Rooijakkers
Marshall Rose
Larry Salomon Jr
Rahmat M. Samik-Ibrahim
Piero Serini
Michael Shields
Quentin Smart
Susan Straub
Jerry Sweet
Rick Troth
Masanobu Umeda
Michael Urban
Marc VanHeyningen
Edward Vielmetti
Larry W. Virden
Tommy Wallo
Jay Weber
Syd Weinstein
Martin Wendel
Sascha Wildner
Christophe Wolfhugel
Erik van der Poel

If we've left your name off please accept our apologies.  Drop us a
note and we'll include it for next time.

The following institutions and individuals have provided resources for
maintaining the MIME FAQ:

- The University of California, Irvine; Department of Information and 
    Computer Science
- Einar Stefferud
- Irvine Compiler Corp.

Thanks also go to Jonathan Kamens, for coordinating the *.answers
groups, and for his post_faq program which brought you this FAQ.

3.4) Permissions
----------------

Permission is granted for non-profit redistribution of the unedited
comp.mail.mime FAQ.

For-profit redistribution of the unedited comp.mail.mime FAQ is
presently permitted, but the maintainers request that you notify them.
(For this purpose, commercial USENET newsfeeds, bboards, and other
electronic or physical media distributions that incidentally include
this FAQ as part of a full re-distribution of the newsgroups in which
the FAQ appears, needn't notify us.)

--
End of Part 3
*************
--
