[Prev][Next][Index][Thread]
comp.mail.mime FAQ, part 3 of 3 (frequently asked questions list)
-
Subject: comp.mail.mime FAQ, part 3 of 3 (frequently asked questions list)
-
From: mime-faq@ics.uci.edu (MIME FAQ maintainer)
-
Date: Mon, 8 Jan 1996 07:28:27 GMT
-
Approved: news-answers-request@MIT.Edu
-
Expires: Sat, 2 Mar 1996 07:30:02 GMT
-
Followup-To: comp.mail.mime
-
Newsgroups: comp.mail.mime, comp.answers, news.answers
-
Organization: Irvine Compiler Corp., Irvine, California, USA
-
References: <mime-faq1_821086202@irvine.com>
-
Reply-To: mime-faq@ics.uci.edu (MIME FAQ maintainer)
-
Sender: usenet@irvine.com (News Administration)
-
Summary: This posting contains answers to some of the Frequently Asked Questions about MIME (Multipurpose Internet Mail Extensions). Please read it before posting a question to comp.mail.mime.
-
Supersedes: <mime-faq3_818407801@irvine.com>
-
Xref: ci.pwr.wroc.pl comp.mail.mime:4731 comp.answers:11946 news.answers:41676
Archive-Name: mail/mime-faq/part3
Version: $Id: mime3,v 3.15 1996/01/02 00:00:25 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.
--
10) Information
---------------
10.1) MIME-relevant RFCs and other 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 defined in RFC 1521 (MIME Mechanisms for Specifying and
Describing the Format of Internet Message Bodies) and RFC 1522
(Representation of Non-ASCII Text in Internet Message Headers).
These are Internet standards-track protocols. For the full
implications of this, see RFC 1780 (Internet Official Protocol
Standards). Here is their current status.
RFC 1521: Draft Elective Standard
RFC 1522: Draft Elective Standard
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, they are extensible. See 10.2 for a list of registered
subtypes.
Many other RFCs deal with e-mail, including these:
IAB standards or standards-track RFCs
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 1725 Post Office Protocol - Version 3
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 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 1563 The text/enriched MIME Content-type
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
--------------------------------
10.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.
--------------------------------
10.2.1) List of registered MIME types
The latest list of registered MIME types is available from this file:
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.
A list of URLs follows for documents relevant to various media types.
The media types are taken from the December, 1995 version of the
aforementioned media-types file, but the URLs below aren't necessarily
representative of the latest list of registered types. In general,
each <type> has a directory whose name has this form:
media-types/<type>/<subtype>
The <type> directory contains the definitions of the subtypes of the
given <type>/<subtype>.
Application types:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/activemessage
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/andrew-inset
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/applefile
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/atomicmail
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/commonground
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/cybercash
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/dec-dx
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/dca-rft
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/eshop
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/iges
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/mac-binhex40
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/macwriteii
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/mathematica
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/msword
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/news-message-id
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/news-transmission
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/octet-stream
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/oda
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/pdf
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/postscript
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/remote-printing
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/riscos
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/rtf
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/sgml
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/slate
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/wita
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/wordperfect5.1
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/x400-bp
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/zip
Audio types:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/audio/basic
Image types:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/cgm
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/jpeg
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/g3fax
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/gif
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/ief
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/naplps
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/tiff
Message types:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/external-body
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/partial
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/rfc822
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/news
Multipart types:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/alternative
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/appledouble
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/digest
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/form-data
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/header-set
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/mixed
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/parallel
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/related
Text types:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/enriched
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/plain
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/richtext
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/sgml
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/tab-separated-values
Video types:
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/mpeg
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/quicktime
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:
ISO-8859-1 see ISO_8859-1:1987
ISO-8859-2 see ISO_8859-2:1987
ISO-8859-3 see ISO_8859-3:1988
ISO-8859-4 see ISO_8859-4:1988
ISO-8859-5 see ISO_8859-5:1988
ISO-8859-6 see ISO_8859-6:1987
ISO-8859-7 see ISO_8859-7:1987
ISO-8859-8 see ISO_8859-8:1988
ISO-8859-9 see ISO_8859-9:1989
US-ASCII see ANSI_X3.4-1968
Access types for external contents:
AFS CMU Andrew File System (Transarc Corp., Pittsburgh, PA, USA)
ANON-FTP anonymous FTP (RFC 1635, RFC 959)
FTP non-anonymous FTP (RFC 959)
LOCAL-FILE directly retrievable file
MAIL-SERVER request to a mail-based archive server
TFTP trivial file transfer protocol (RFC 1350)
content-id Message/External-Body Content-ID Access Type (RFC 1873)
Content transfer encodings:
7BIT BINARY
8BIT QUOTED-PRINTABLE
BASE64
--------------------------------
10.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 10.2.1 and 11.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. For example, FrameMaker or FrameReader might be run
to handle a content type of application/x-framemaker. (In the case of
Frame documents, there are several ways to handle this---see Frame
Technical Note 1359 or consult the comp.text.frame FAQ.) 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 such
non-standard types 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. }
Application types:
application/pgp PGP
application/x-aiff Z-Mail: AIFF audio data
application/x-bcpio MHonArc: bcpio data
application/x-bitmap Z-Mail: X11 bitmaps
application/x-cpio MHonArc: cpio archives
application/x-csh MHonArc: csh scripts
application/x-dvi MHonArc: TeX DVI data
application/x-framemaker Z-Mail: FrameMaker documents
application/x-gtar MHonArc: GNU tar archives
application/x-hdf MHonArc: hdf data
application/x-inventor Z-Mail: for Inventor files
application/x-island-draw Z-Mail: IslandDraw files
application/x-island-paint Z-Mail: IslandPaint files
application/x-island-write Z-Mail: IslandWrite files
application/x-jot Z-Mail: Jot documents
application/x-latex MHonArc: LaTeX documents
application/x-macbinhex40 TCP/Connect II: Mac BinHex 4.0
application/x-metamail-patch metamail: patches to metamail
application/x-mif MHonArc: Frame MIF documents
application/x-movie Z-Mail: MoviePlayer documents
application/x-ms-tnef Worldtalk: proprietary "tunneling" type for MS Exchange
application/x-netcdf MHonArc: netcdf data
application/x-sgi Z-Mail: SGI ImageWorks documents
application/x-sh MHonArc: sh scripts
application/x-shar MHonArc: shell archives
application/x-showcase Z-Mail: Showcase documents
application/x-sv4cpio MHonArc: SVR4 cpio archives
application/x-sv4crc MHonArc: SVR4 crc data
application/x-tar MHonArc: tar archives
application/x-tcl MHonArc: tcl programs
application/x-tex MHonArc: TeX documents
application/x-texinfo MHonArc: GNU texinfo documents
application/x-troff MHonArc: plain troff documents
application/x-troff-man MHonArc: troff -man documents
application/x-troff-me MHonArc: troff -me documents
application/x-troff-ms MHonArc: troff -ms documents
application/x-ustar MHonArc: ustar data
application/x-wais-source MHonArc: WAIS sources
application/x-wingz Z-Mail: Wingz documents
application/x-xpm1 Z-Mail: OL pixmap files
application/x-wt-stf Worldtalk: proprietary "tunneling" type for Worldtalk
application/x-zm-fax Z-Mail: Z-Fax documents
Audio types:
audio/x-aiff MHonArc: AIFF audio data
audio/x-wav MHonArc: WAV audio data
audio/x-macaudio Iride: NOT sampled Macintosh audio
audio/x-next MH 6.8: self-describing audio data
see ftp://ftp.ics.uci.edu/mh/contrib/multimedia/mhn-tutorial.ps
Image types:
image/x-cmu-raster MHonArc: CMU raster data
image/x-fits FITS files (see part 2 for an xv patch)
image/x-macpict TCP/Connect II, Iride: Macintosh PICT
image/x-pbm MHonArc: portable bit map data
image/x-pgm MHonArc: PGM data
image/x-pict MHonArc: Mactinosh PICT data
image/x-pnm MHonArc
image/x-portable-anymap MHonArc
image/x-portable-bitmap MHonArc
image/x-portable-graymap MHonArc
image/x-portable-pixmap MHonArc
image/x-ppm MHonArc
image/x-rgb MHonArc
image/x-xbitmap MHonArc: in-lines into the HTML
image/x-xbm MHonArc: in-lines into the HTML
image/x-xpixmap MHonArc
image/x-xpm MHonArc
image/x-xwd MHonArc
image/x-xwindowdump MHonArc: X window dump
Multipart types:
multipart/report SendMail v8.7
Text types:
text/html MHonArc: WWW HTML (See also RFC 1866)
text/unknown Worldtalk
text/x-html MHonArc: WWW HTML
text/x-setext MHonArc: setext
text/x-usenet-faq Ohio State WWW FAQ document format
Video types:
video/x-msvideo MHonArc: Microsoft video data
video/x-sgi-movie MHonArc: SGI movie data
Other types:
x-be2 old Andrew format
x-sun-attachment Sun MicroSystems mailtool
x-zm-multipart old Z-Mail format
Content transfer encodings:
uue uuencoded data
uuencode uuencoded data
x-uue uuencoded data
x-uuencode uuencoded data
Character sets:
charset=x-unknown MH 6.8.3: for untagged charsets
Miscellaneous parameters:
application/octet-stream
type=tar; x-conversions=compress
MH 6.8.x viamail: See also tar(1) and compress(1).
--------------------------------
10.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.
--
11) Developers' FAQs
--------------------
11.1) How can I register a new MIME type?
The procedures for registering new content types, character set
values, access types, and conversions 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/mimestuff/media-types.html
The Web version includes hyperlinks to the relevant IANA archives
and RFCs.
--------------------------------
11.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 1651) is open-ended; so far two
extensions have been defined.
Message size declaration (RFC 1653) 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.
--------------------------------
11.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.
--------------------------------
11.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.
--------------------------------
11.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.
--------------------------------
11.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.
--------------------------------
11.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, written by
Steve Dorner and Rens Troost.
--
12) Acknowledgements
--------------------
In addition to those named elsewhere in this document, contributors
have included:
Alan Robiette, Alec Henderson, Axel Boldt, Carlyn Lowery, Chris
Pepper, Christophe Wolfhugel, Christopher Davis, Craig Huckabee,
Daniel Fandrich, Daniel Glazman, Dave Curry, Dave Lacey, David Barr,
David Collier-Brown, David Eaves, David Miller, Douglas Boyce, Ed
Anselmo, Ed Greshko, Edward Vielmetti, Erik van der Poel, Gisle
Hannemyr, Harald Alvestrand, Ian Hoyle, James Ford, Jason Beyer, Jay
Weber, Jerry Peek, Jerry Sweet, Joe Ilacqua, Joergen Haegg, John
Gardiner Myers, John Martin, John R MacMillan, John Romine, Joyce
Reynolds, Keith Moore, Larry Salomon Jr, Larry W. Virden, Lars-Gunnar
Olsson, Luc Rooijakkers, Marc VanHeyningen, Mark Crispin, Mark Grand,
Marshall Rose, Martin Wendel, Masanobu Umeda, Michael Parson, Michael
Shields, Michael Urban, Nathaniel Borenstein, Ned Freed, Niklas Agren,
Olle Jarnefors, Pat Farrell, Paul Eggert, Piero Serini, Quentin Smart,
Rahmat M. Samik-Ibrahim, Ran Atkinson, Ray Langford, Rich Ragan, Rick
Troth, Roman Czyborra, Ron Barak, Sascha Wildner, Steve Dorner, Steve
Hole, Stuart Lynne, Susan Straub, Syd Weinstein, Tim Goodwin, Tim
Kehres, Tommy Wallo, Yehavi Bourvine.
If we've left your name off, please accept our apologies. Drop us a
note and we'll include it for next time.
Thanks also to the University of California, Irvine, Department of
Information and Computer Science, Einar Stefferud, and Irvine Compiler
Corp., for providing the resources for maintaining this FAQ; and to
Jonathan Kamens, for coordinating the *.answers groups, and for his
post_faq program which brought you this FAQ.
13) 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
*************
--
References: