Usenet 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / answers / mail / mime-faq / part3 < prev next >

Wrap

Internet Message Format | 1993-12-02 | 15.5 KB

Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nic.hookup.net!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!pipex!not-for-mail From: tim@pipex.net (Tim Goodwin) Newsgroups: comp.mail.mime,comp.answers,news.answers Subject: comp.mail.mime frequently asked questions list (FAQ) (3/3) Supersedes: <mime-faq3_751830002@pipex.net> Followup-To: comp.mail.mime Date: 30 Nov 1993 18:38:45 -0000 Organization: Pipex Ltd., 216 Science Park, Cambridge CB4 4WA, England Lines: 341 Approved: news-answers-request@MIT.Edu Expires: 23 Jan 1994 18:38:28 GMT Message-ID: <mime-faq3_754684708@pipex.net> References: <mime-faq1_754684708@pipex.net> NNTP-Posting-Host: tank.pipex.net 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. Xref: senator-bedfellow.mit.edu comp.mail.mime:2260 comp.answers:2852 news.answers:15203 Archive-Name: mail/mime-faq/part3 Last-modified: 1993/11/30 Version: 3.2 comp.mail.mime frequently asked questions list (FAQ) (3/3) Part III -- Advanced Topics This is part III of a Frequently Asked Questions document about MIME, the multipurpose and multi-media standard for Internet mail. Part I covers frequently asked questions. Part II is a listing of MIME products. Part III covers advanced topics. 10 Information 10.1 MIME-relevant RFCs and other standards The RFCs mentioned here are mainly relevant to people 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 FTP: ds.internic.net:rfc/* FTP: ds.internic.net:internet-drafts/* 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 1540 (IAB Official Protocol Standards). Here is their current status. 1521: Draft Elective Standard 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 complete list of registered subtypes. There are a whole lot of other RFCs that deal with email, including these. IAB standards-track RFCs 1502 X.400 Use of Extended Character Sets 1496 Rules for Downgrading Messages from X.400(88) to X.400(84) when MIME Content-Types are Present in the Messages 1495 Mapping between X.400 and RFC-822 Message Bodies 1494 Equivalences between 1988 X.400 and RFC-922 Message Bodies 1427 SMTP Service Extension for Message Size Declaration. 1426 SMTP Service Extension for 8bit-MIMEtransport. 1425 SMTP Service Extensions. 1424 Privacy Enhancement for Internet Electronic Mail: Part IV. 1423 Privacy Enhancement for Internet Electronic Mail: Part III. 1422 Privacy Enhancement for Internet Electronic Mail: Part II. 1421 Privacy Enhancement for Internet Electronic Mail: Part I. 1327 Mapping between X.400(1988)/ISO 10021 and RFC 822. 1314 File format for the exchange of images in the Internet. Other RFCs (Informational, Experimental, or Historical) 1489 Registration of a Cyrillic Character Set. 1468 Japanese Character Encoding for Internet Messages. 1456 Conventions for Encoding the Vietnamese Language. 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME. 1357 Format for emailing bibliographic records. 1345 Character Mnemonics & Character Sets. 1344 Implications of MIME for Internet mail gateways. 1343 User agent configuration mechanism for multimedia mail format information. 1339 Remote mail checking protocol. 1321 MD5 Message-Digest algorithm. 1225 Post Office Protocol: Version 3. 1211 Problems with the maintenance of large mailing lists. 1176 Interactive Mail Access Protocol: Version 2. 1197 Using ODA for translating multimedia information. 1154 Encoding header field for internet messages. 1153 Digest message format. 1049 Content-type header field for Internet messages. 1036 Standard for interchange of USENET messages. 934 Proposed standard for message encapsulation. 807 Multimedia mail meeting notes. 10.2 List of registered MIME types A list of registered MIME types is available from FTP: isi.edu:in-notes/mime/mime-types This is the latest version. Type Subtype Description Reference ---- ------- ----------- --------- text plain [169,NSB] richtext [169,NSB] tab-separated-values [Paul Lindner] multipart mixed [169,NSB] alternative [169,NSB] digest [169,NSB] parallel [169,NSB] appledouble [MacMime,Patrik Faltstrom] header-set [Dave Crocker] message rfc822 [169,NSB] partial [169,NSB] external-body [169,NSB] news [RFC 1036, Henry Spencer] application octet-stream [169,NSB] postscript [169,NSB] oda [169,NSB] atomicmail [atomicmail,NSB] andrew-inset [andrew-inset,NSB] slate [slate,terry crowley] wita [Wang Info Transfer,Larry Campbell] dec-dx [Digital Doc Trans, Larry Campbell] dca-rft [IBM Doc Content Arch, Larry Campbell] activemessage [Ehud Shapiro] rtf [Paul Lindner] applefile [MacMime,Patrik Faltstrom] mac-binhex40 [MacMime,Patrik Faltstrom] news-message-id [RFC 1036, Henry Spencer] news-transmission [RFC 1036, Henry Spencer] wordperfect5.1 [Paul Lindner] pdf [Paul Lindner] zip [Paul Lindner] macwriteii [Paul Lindner] msword [Paul Lindner] remote-printing [RFC1486,MTR] image jpeg [169,NSB] gif [169,NSB] ief Image Exchange Format [RFC-1314] tiff Tag Image File Format [MTR] audio basic [169,NSB] video mpeg [169,NSB] quicktime [Paul Lindner] Each <type> has a directory FTP: isi.edu:in-notes/mime/<type> containing the definitions of its subtypes. 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 (see 3.4). Work is underway to align PEM and MIME which will provide real security to MIME email. 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 1521. 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 1425) is open-ended; so far two extensions have been defined. Message size declaration (RFC 1427) 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 1426) 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? FTP: thumper.bellcore.com:pub/nsb/samples/* 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 people, 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. 12 Acknowledgements Many people have contributed to this document. They include: 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 Collier-Brown, David Miller, Ed Anselmo, Edward Vielmetti, Erik van der Poel, Harald Alvestrand, Ian Hoyle, James Ford, Jason Beyer, Jay Weber, Jerry Sweet, Joe Ilacqua, Joergen Haegg, John Gardiner Myers, John Martin, John Romine, Joyce Reynolds, Keith Moore, Larry Salomon Jr, Lars-Gunnar Olsson, Luc Rooijakkers, Marc VanHeyningen, Mark Crispin, Mark Grand, Marshall Rose, Martin Wendel, Masanobu Umeda, Michael Parson, Michael Urban, Nathaniel Borenstein, Ned Freed, Paul Eggert, Quentin Smart, Ran Atkinson, Ray Langford, Rich Ragan, Rick Troth, Ron Barak, Steve Dorner, Steve Hole, Stuart Lynne, Susan Straub, Syd Weinstein, Tommy Wallo, Yehavi Bourvine. If I've left your name off, please accept my apologies. Drop me a note and I'll include it for next time. Thanks also to Jonathan Kamens, for coordinating the *.answers groups, and for his post_faq program which brought you this FAQ. End of Part III -- Tim Goodwin | "Alvestrand's equality: gateways = pain" PIPEX Ltd | -- Harald T Alvestrand.