1 <!doctype sinfo system>
2 <!-- $Id: tm-en.sgml,v 1.1.1.1 1998-01-14 06:27:58 steve Exp $ -->
4 <title>tm 7.100 Manual (English Version)
5 <author>MORIOKA Tomohiko <mail>morioka@jaist.ac.jp</mail>
15 This file documents tm, a MIME package for GNU Emacs.
21 The tm package is a set of modules to enjoy MIME on GNU Emacs. Using
25 <li> playback or view the MIME messages using tm-view
26 <li> compose MIME message using tm-edit
27 <li> use the enhanced MIME features with mh-e, GNUS, Gnus, RMAIL and VM
33 Please read following about each topics:
36 <li><a file="gnus-mime-en">tm-MUA for Gnus</a>
37 <li><a file="tm-gnus-en">tm-MUA for GNUS</a>
38 <li><a file="tm-mh-e-en">tm-MUA for mh-e</a>
39 <li><a file="tm-vm-en">tm-MUA for VM</a>
40 <li><a file="tm-view-en">mime/viewer-mode</a>
41 <li><a file="tm-edit-en">mime/editor-mode</a>
51 <concept>7bit</concept> means any integer between 0 .. 127.
53 Any data represented by 7bit integers is called <concept>7bit
56 Textual string consisted of Control characters between 0 .. 31 and
57 127, and space represented by 32, and graphic characters between 33
58 .. 236 are called <concept>7bit (textual) string</concept>.
60 Traditional Internet <a node="MTA">MTA</a> can translate 7bit data, so
61 it is no need to translate by <a
62 node="Quoted-Printable">Quoted-Printable</a> or <a
63 node="Base64">Base64</a> for 7bit data.
65 However if there are too long lines, it can not translate by 7bit MTA
66 even if it is 7bit data. <dref>RFC 821</dref> and <dref>RFC
67 2045</dref> require lines in 7bit data must be less than 998 bytes.
68 So if a ``7bit data'' has a line more than 999 bytes, it is regarded
69 as <dref>binary</dref>. For example, Postscript file should be
70 encoded by Quoted-Printable.
76 <concept>8bit</concept> means any integer between 0 .. 255.
78 Any data represented by 8bit integers is called <concept>8bit
81 Textual string consisted of Control characters between 0 .. 31, 127,
82 and 128 .. 159, and space represented by 32, and graphic characters
83 between 33 .. 236 and 160 .. 255 are called <concept>8bit (textual)
86 For example, <dref>iso-8859-1</dref> or <dref>euc-kr</dref> are
87 coded-character-set represented by 8bit textual string.
89 Traditional Internet <a node="MTA">MTA</a> can translate only
90 <dref>7bit</dref> data, so if a 8bit data will be translated such MTA,
91 it must be encoded by <dref>Quoted-Printable</dref> or
94 However 8bit MTA are increasing today.
96 However if there are too long lines, it can not translate by 8bit MTA
97 even if it is 8bit data. <dref>RFC 2045</dref> require lines in 8bit
98 data must be less than 998 bytes. So if a ``8bit data'' has a line
99 more than 999 bytes, it is regarded as <dref>binary</dref>, so it must
100 be encoded by Base64 or Quoted-Printable.
103 <h3> 94-character set
104 <node> 94-character set
106 <concept>94-character set</concept> is a kind of 1 byte <dref>graphic
107 character set</dref>, each characters are in positions 02/01 (33) to
108 07/14 (126) or 10/01 (161) to 15/14 (254). (ex. <dref>ASCII</dref>,
112 <h3> 96-character set
113 <node> 96-character set
115 <concept>96-character set</concept> is a kind of 1 byte <dref>graphic
116 character set</dref>, each characters are in positions 02/00 (32) to
117 07/15 (126) or 10/00 (160) to 15/15 (255). (ex. ISO 8859)
120 <h3> 94x94-character set
121 <node> 94x94-character set
123 <concept>94x94-character set</concept> is a kind of 2 byte
124 <dref>graphic character set</dref>, each bytes are in positions 02/01
125 (33) to 07/14 (126) or 10/01 (161) to 15/14 (254). (ex. <dref>JIS
126 X0208</dref>, <dref>GB 2312</dref>)
132 <concept>ASCII</concept> is a <dref>94-character set</dref> contains
133 primary latin characters (A-Z, a-z), numbers and some characters. It
134 is a standard of the United States of America. It is a variant of <a
135 node="ISO 646">ISO 646</a>.
137 <standard abbrev="ASCII" title-en="Coded Character Set -- 7-Bit
138 American Standard Code for Information Interchange"
139 number="ANSI X3.4" year="1986">
145 <concept>Base64</concept> is a transfer encoding method of
146 <dref>MIME</dref> defined in <dref>RFC 2045</dref>.
148 The encoding process represents 24-bit groups of input bits as output
149 strings of 4 encoded characters. Encoded characters represent integer
150 0 .. 63 or <concept>pad</concept>. Base64 data must be 4 * n bytes,
151 so pad is used to adjust size.
153 These 65 characters are subset of all versions of ISO 646, including
154 US-ASCII, and all versions of EBCDIC. So it is safe even if it is
155 translated by non-Internet gateways.
161 Any byte stream is called <concept>binary</concept>.
163 It does not require structureof lines. It differs from from <a
164 node="8bit">8bit</a>.
166 In addition, if line structured data contain too long line (more than
167 998 bytes), it is regarded as binary.
173 A <a node="MIME charset">MIME charset</a> for simplified Chinese
174 mainly used in the Chinese mainland.
176 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
177 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
178 <dref>GB 2312</dref>.
180 It is defined in <a node="RFC 1922">RFC 1922</a>.
186 A <a node="MIME charset">MIME charset</a> for traditional Chinese
187 mainly used in Taiwan and Hon Kong.
189 It is a <dref>8bit</dref> <dref>coded character set</dref> not based
190 on <dref>ISO 2022</dref>. It is a de-fact standard.
192 It is defined in <a node="RFC 1922">RFC 1922</a>.
194 cf. <report abbrev="BIG5" author="Institute for Information Industry"
195 title-en="Chinese Coded Character Set in Computer"
198 It corresponds to <dref>CNS 11643</dref>.
204 <a node="graphic character set">Graphic character sets</a> for Chinese
205 mainly written by traditional Chinese mainly used in Taiwan and Hong
206 Kong. It is a standard of Taiwan. Currently there are seven
207 <dref>94x94-character set</dref>.
209 Final byte of <dref>ISO 2022</dref> are following:
212 <dt>plane 1<dd>04/07 (`G')
213 <dt>plane 2<dd>04/08 (`H')
214 <dt>plane 3<dd>04/09 (`I')
215 <dt>plane 4<dd>04/10 (`J')
216 <dt>plane 5<dd>04/11 (`K')
217 <dt>plane 6<dd>04/12 (`L')
218 <dt>plane 7<dd>04/13 (`M')
221 <standard abbrev="CNS 11643-1992" title-en="Standard Interchange Code
222 for Generally-Used Chinese Characters" number="CNS
226 <h3> Coded character set, Character code
227 <node> coded character set
229 A set of unambiguous rules that establishes a character set and the
230 one-to-one relationship between the characters of the set and their
235 <node> code extension
237 The techniques for the encoding of characters that are not included in
238 the character set of a given code. (ex. <dref>ISO 2022</dref>)
241 <h3> Content-Disposition field
242 <node> Content-Disposition
244 A field to specify presentation of entity or file name. It is an
245 extension for <dref>MIME</dref>.
247 <rfc number="1806" type="Experimental" author="E R. Troost and
248 S. Dorner" title="Communicating Presentation Information
249 in Internet Messages: The Content-Disposition Header"
253 <h3> Content-Type field
254 <node> Content-Type field
256 Header field to represent information about body, such as <dref>media
257 type</dref>, <dref>MIME charset</dref>. It is defined in <dref>RFC
262 Historically, Content-Type field was proposed in RFC 1049. In it,
263 Content-Type did not distinguish type and subtype. However MIME
264 parser may be able to accept RFC 1049 based Content-Type as unknown
269 Content-Type field is defined as following:
272 ``Content-Type'' ``:'' <concept>type</concept> ``/''
273 <concept>subtype</concept> *( ``;'' <concept>parameter</concept> )
281 Content-Type: image/jpeg
287 Content-Type: text/plain; charset=iso-2022-jp
293 A part does not have content-type field is regarded as
297 Content-Type: text/plain; charset=us-ascii
304 And a part has unknown type/subtype is regarded as
308 Content-Type: application/octet-stream
318 In this document, `Emacs' means GNU Emacs released by FSF, and `emacs'
319 means any variants of GNU Emacs.
325 Representation non <dref>ASCII</dref> characters in header. It
326 is defined in <concept>RFC 2047</concept>.
328 <rfc number="2047" type="Standards Track" author="K. Moore"
329 title="MIME (Multipurpose Internet Mail Extensions) Part
330 Three: Message Header Extensions for Non-ASCII Text"
331 date="November 1996" obsolete="1521,1522,1590">
337 Method to insert whole <a node="RFC 822">Internet message</a> into
338 another Internet message.
340 For example, it is used to forward a message.
342 <cf node="message/rfc822">
348 Header fields and contents of a message or one of the parts in the
349 body of a <dref>multipart</dref> entity.
353 In this document, `entity' might be called ``part''.
360 A <dref>MIME charset</dref> for Korean.
362 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
363 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
364 <dref>KS C5601</dref>.
366 It is defined in <dref>RFC 1557</dref>.
368 cf. <standard abbrev="euc-kr" org="Korea Industrial Standards
369 Association" title-en="Hangul Unix Environment"
370 number="KS C 5861" year="1992">
375 <rfc name="FTP" number="959" type="STD 9" author="Postel, J. and
376 J. Reynolds" title="File Transfer Protocol"
383 A <dref>94x94-character set</dref> for Chinese mainly written by
384 simplified Chinese mainly used in the Chinese mainland. It is a
387 Final byte of <dref>ISO 2022</dref> is 04/01 (`A').
389 <standard abbrev="GB 2312"
390 title-en="Code of Chinese Graphic Character Set for
391 Information Interchange - Primary Set" number="GB 2312"
398 A <dref>94x94-character set</dref> for Chinese as supplement to
399 <dref>GB 2312</dref>. It is a standard of China.
401 <standard abbrev="GB 8565.2" title-en="Information Processing - Coded
402 Character Sets for Text Communication - Part 2: Graphic
403 Characters used with Primary Set" number="GB 8565.2"
407 <h3> Graphic Character Set
408 <node> graphic character set
410 <a node="coded character set">Coded character set</a> for graphic
417 A <a node="MIME charset">MIME charset</a> for simplified Chinese
418 mainly used in the Chinese mainland.
420 It extends <dref>ASCII</dref> to combine <dref>GB 2312</dref>, its
421 technique is like <dref>iso-2022-jp</dref>, but it is designed to be
422 ASCII printable to use special form for ESC sequence to designate GB
425 It is defined in RFC 1842 and 1843.
427 <rfc number="1842" type="Informational" author="Y. Wei, Y. Zhang,
428 J. Li, J. Ding and Y. Jiang" title="ASCII Printable
429 Characters-Based Chinese Character Encoding for Internet
430 Messages" date="August 1995">
431 <rfc number="1843" type="Informational" author="F. Lee" title="HZ - A
432 Data Format for Exchanging Files of Arbitrarily Mixed
433 Chinese and ASCII characters" date="August 1995">
439 It is a standard for character code structure and <dref>code
440 extension</dref> technique.
442 <standard abbrev="ISO 2022" org="International Organization for
443 Standardization (ISO)" title-en="Information Processing:
444 ISO 7-bit and 8-bit coded character sets: Code extension
445 techniques" number="ISO/IEC 2022" year="1994">
451 A <dref>MIME charset</dref> for Chinese.
453 It is a <dref>7bit</dref> <dref>coded character set</dref> based on
454 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
455 <dref>GB 2312</dref> and/or <a node="CNS 11643">CNS 11643 plain 1,
458 It is defined in <dref>RFC 1922</dref>.
462 <node> iso-2022-cn-ext
464 A <dref>MIME charset</dref> for Chinese.
466 It is a <dref>7bit</dref> <dref>coded character set</dref> based on
467 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
468 <dref>GB 2312</dref>, <a node="CNS 11643">CNS 11643 plain 1 .. 7</a>,
469 <dref>ISO-IR-165</dref> and other Chinese graphic character sets.
471 It is defined in <dref>RFC 1922</dref>.
474 MULE 2.3 and current XEmacs/mule can not use it correctly.
476 Emacs/mule can use it.
483 A <dref>MIME charset</dref> for Japanese.
485 It is a <dref>7bit</dref> <dref>coded character set</dref> based on
486 old <dref>ISO 2022</dref>. It switches <dref>ASCII</dref>, JIS
487 X0201-Latin, <a node="JIS C6226">JIS X0208-1978</a> and <a node="JIS
488 X0208">JIS X0208-1983</a>.
490 It is defined in RFC 1468.
493 JIS X0208-1997? will define it in annex as non-<dref>ISO 2022</dref>
497 <rfc name="iso-2022-jp" number="1468" author="Murai J., M. Crispin,
498 and E. van der Poel" title="Japanese Character Encoding
499 for Internet Messages" date="June 1993">
505 A <dref>MIME charset</dref>, which is a multilingual extension of
506 <dref>iso-2022-jp</dref>.
508 It is defined in RFC 1554.
510 <rfc name="iso-2022-jp-2" number="1554" type="Informational"
511 author="Ohta M. and Handa K." title="ISO-2022-JP-2:
512 Multilingual Extension of ISO-2022-JP" date="December
519 A <a node="MIME charset">MIME charset</a> for Korean language (Hangul
522 It is based on <dref>ISO 2022</dref> <dref>code extension</dref>
523 technique to extend <dref>ASCII</dref> to use <dref>KS C5601</dref> as
524 <dref>7bit</dref> text.
526 It is defined in <dref>RFC 1557</dref>.
532 <standard abbrev="ISO 646" org="International Organization for
533 Standardization (ISO)" title-en="Information technology:
534 ISO 7-bit coded character set for information
535 interchange" number="ISO/IEC 646" year="1991">
541 <standard abbrev="ISO 8859-1" org="International Organization for
542 Standardization (ISO)" title-en="Information Processing
543 -- 8-bit Single-Byte Coded Graphic Character Sets --
544 Part 1: Latin Alphabet No.1" number="ISO 8859-1"
551 <concept>iso-8859-1</concept> is a <dref>MIME charset</dref> for
552 west-European languages written by Latin script.
554 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
555 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
556 <dref>ISO 8859-1</dref>.
558 It is defined in <dref>RFC 2046</dref>.
564 <standard abbrev="ISO 8859-2" org="International Organization for
565 Standardization (ISO)" title-en="Information Processing
566 -- 8-bit Single-Byte Coded Graphic Character Sets --
567 Part 2: Latin alphabet No.2" number="ISO 8859-2"
574 <concept>iso-8859-2</concept> is a <dref>MIME charset</dref> for
575 east-European languages written by Latin script.
577 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
578 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
579 <dref>ISO 8859-2</dref>.
581 It is defined in <dref>RFC 2046</dref>.
587 <standard abbrev="ISO 8859-3" org="International Organization for
588 Standardization (ISO)" title-en="Information
589 Processing -- 8-bit Single-Byte Coded Graphic
590 Character Sets -- Part 3: Latin alphabet No.3"
591 number="ISO 8859-3" year="1988">
597 <standard abbrev="ISO 8859-4" org="International Organization for
598 Standardization (ISO)" title-en="Information
599 Processing -- 8-bit Single-Byte Coded Graphic
600 Character Sets -- Part 4: Latin alphabet No.4"
601 number="ISO 8859-4" year="1988">
607 <standard abbrev="ISO 8859-5" org="International Organization for
608 Standardization (ISO)" title-en="Information Processing
609 -- 8-bit Single-Byte Coded Graphic Character Sets --
610 Part 5: Latin/Cyrillic alphabet" number="ISO 8859-5"
617 <concept>iso-8859-5</concept> is a <dref>MIME charset</dref> for
620 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
621 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
622 <dref>ISO 8859-5</dref>.
624 It is defined in <dref>RFC 2046</dref>.
630 <standard abbrev="ISO 8859-6" org="International Organization for
631 Standardization (ISO)" title-en="Information
632 Processing -- 8-bit Single-Byte Coded Graphic
633 Character Sets -- Part 6: Latin/Arabic alphabet"
634 number="ISO 8859-6" year="1987">
640 <standard abbrev="ISO 8859-7" org="International Organization for
641 Standardization (ISO)" title-en="Information Processing
642 -- 8-bit Single-Byte Coded Graphic Character Sets --
643 Part 7: Latin/Greek alphabet" number="ISO 8859-7"
650 <concept>iso-8859-7</concept> is a <dref>MIME charset</dref> for
653 It is a <dref>8bit</dref> <dref>coded character set</dref> based on
654 <dref>ISO 2022</dref>. It extends <dref>ASCII</dref> to combine
655 <dref>ISO 8859-7</dref>.
657 It is defined in RFC 1947.
659 <rfc name="iso-8859-7" number="1947" type="Informational"
660 author="D. Spinellis" title="Greek Character Encoding
661 for Electronic Mail Messages" date="May 1996">
667 <standard abbrev="ISO 8859-8" org="International Organization for
668 Standardization (ISO)" title-en="Information
669 Processing -- 8-bit Single-Byte Coded Graphic
670 Character Sets -- Part 8: Latin/Hebrew alphabet"
671 number="ISO 8859-8" year="1988">
677 <standard abbrev="ISO 8859-9" org="International Organization for
678 Standardization (ISO)" title-en="Information
679 Processing -- 8-bit Single-Byte Coded Graphic
680 Character Sets -- Part 9: Latin alphabet No.5"
681 number="ISO 8859-9" year="1990">
684 <h3> ISO-IR-165, CCITT Extended GB <node> ISO-IR-165
686 A <dref>94x94-character set</dref> for Chinese mainly written by
687 simplified Chinese mainly used in the Chinese mainland registered by
690 It consists of <dref>GB 2312</dref>, <dref>GB 8565.2</dref> and
691 additional 150 characters.
693 Final byte of <dref>ISO 2022</dref> is 04/05 (`E').
699 It defines two <dref>94-character set</dref>, for Latin script (a
700 variant of <dref>ISO 646</dref>) and Katakana script, and 7bit and
701 8bit <dref>coded character set</dref>s.
703 It was renamed from <concept>JIS C6220-1976</concept>.
705 <standard abbrev="JIS X0201-1976" org="Japanese Standards Association"
706 title-en="Code for Information Interchange" number="JIS
709 In addition, revised version will be published in 1997.
711 <standard abbrev="JIS X0201-1997?" org="Japanese Standards
712 Association" title-en="7-bit and 8-bit coded character
713 sets for information interchange" number="JIS X 0201"
720 A <dref>94x94-character set</dref> for Japanese. It was renamed to
723 <cf node="JIS X0208">
729 A <dref>94x94-character set</dref> for Japanese. Japanese standard.
730 It was published in 1978, and revised in 1983 and 1990. In the
731 Internet message, 1983 edition is major.
733 JIS X0208 contains some symbols, numbers, primary Latin script,
734 Hiragana script, Katakana script, Greek script, Cyrillic script, box
735 drawing parts, Kanji (Ideographic characters used in Japanese).
736 Notice that some symbols and box drawing parts were added in 1983 and
737 some Kanjis were changed or swapped code points. So 1978 edition and
738 1983 edition are regarded as different graphic character set.
740 1990 edition added some characters, so designation of 1990 edition
741 requires `identify revised registration' sequence, ESC 02/06 4/0 as
742 prefix of designation sequence.
744 <standard abbrev="JIS X0208-1978" org="Japanese Standards Association"
745 title-en="Code of the Japanese graphic character set for
746 information interchange" number="JIS C6226" year="1978">
747 <standard abbrev="JIS X0208-1983,1990" org="Japanese Standards
748 Association" title-en="Code of the Japanese graphic
749 character set for information interchange" number="JIS
750 X0208" year="1983,1990">
753 In addition, revised version will be published in 1997. (It does not
754 change graphic character set)
756 <standard abbrev="JIS X0208-1997?" org="Japanese Standards
757 Association" title-en="7-bit and 8-bit double byte coded
758 Kanji sets for information interchange" number="JIS X
759 0208" year="1997? draft">
765 A <dref>94x94-character set</dref> for Japanese as supplement to
766 <dref>JIS X0208</dref>. It is a standard of Japan.
768 Final byte of <dref>ISO 2022</dref> is 04/04 (`D').
774 A <dref>MIME charset</dref> for Cyrillic script for Russian or other
777 It is a 1 byte <dref>8bit</dref> <dref>coded character set</dref>, not
778 based on <dref>ISO 2022</dref>. It is a de-fact standard.
780 It is defined in RFC 1489.
782 <rfc number="1489" author="A. Chernov" title="Registration of a
783 Cyrillic Character Set" date="July 1993">
789 A <dref>94x94-character set</dref> for Korean language (Hangul
790 script). Korean Standard. Final byte of <dref>ISO 2022</dref> is
793 <standard abbrev="KS C5601" org="Korea Industrial Standards
794 Association" title-en="Code for Information Interchange
795 (Hangul and Hanja)" number="KS C 5601" year="1987">
801 <concept>media type</concept> specifies the nature of the data in the
802 body of <dref>MIME</dref> <dref>entity</dref>. It consists of
803 <concept>type</concept> and <concept>subtype</concept>. It is defined
804 in <dref>RFC 2046</dref>.
806 Currently there are following types:
809 <li><concept>text</concept>
811 <li><concept>image</concept>
813 <li><concept>audio</concept>
815 <li><concept>video</concept>
817 <li><concept>application</concept>
819 <li><a node="multipart"><concept>multipart</concept></a>
821 <li><concept>message</concept>
825 And there are various subtypes, for example, application/octet-stream,
826 audio/basic, image/jpeg, <dref>multipart/mixed</dref>,
827 <dref>text/plain</dref>, video/mpeg...
829 You can refer registered media types at <a
830 href="ftp://ftp.isi.edu/in-notes/iana/assignments/media-types">MEDIA
833 In addition, you can use private type or subtype using
834 <concept>x-token</concept>, which as the prefix `x-'. However you can
835 not use them in public.
837 <cf node="Content-Type field">
843 In this document, it means mail defined in <dref>RFC 822</dref> and
844 news message defined in <dref>RFC 1036</dref>.
848 <node> message/rfc822
850 <concept>message/rfc822</concept> indicates that the body contains an
851 encapsulated message, with the syntax of an <dref>RFC 822</dref>
852 message. It is the replacement of traditional <dref>RFC 934</dref>
853 encapsulation. It is defined in <dref>RFC 2046</dref>.
859 Application program of tm-view to process for specified <dref>media
860 type</dref> when user plays an entity.
862 There are two kinds of methods, <concept>internal method</concept> and
863 <concept>external method</concept>. Internal method is written by
864 Emacs Lisp. External method is written by C or script languages and
865 called by asynchronous process call.
867 <cf file="tm-view-en" node="method">
873 MIME stands for <concept>Multipurpose Internet Mail
874 Extensions</concept>, it is an extension for <dref>RFC 822</dref>.
876 According to RFC 2045:
878 STD 11, RFC 822, defines a message representation protocol specifying
879 considerable detail about US-ASCII message headers, and leaves the
880 message content, or message body, as flat US-ASCII text. This set of
881 documents, collectively called the Multipurpose Internet Mail
882 Extensions, or MIME, redefines the format of messages to allow for
885 <li>textual message bodies in character sets other than US-ASCII,
887 <li>an extensible set of different formats for non-textual message
890 <li>multi-part message bodies, and
892 <li>textual header information in character sets other than US-ASCII.
896 It is defined in <dref>RFC 2045</dref>, <dref>RFC 2046</dref>, <a
897 node="encoded-word">RFC 2047</a>, <dref>RFC 2048</dref> and <dref>RFC
904 <a node="coded character set">Coded character set</a> used in
905 <dref>Content-Type field</dref> or charset parameter of <a
906 node="encoded-word">encoded-word</a>.
908 It is defined in <dref>RFC 2045</dref>.
910 <dref>iso-2022-jp</dref> or <dref>euc-kr</dref> are kinds of it. (In
911 this document, MIME charsets are written by small letters to
912 distinguish <dref>graphic character set</dref>. For example, ISO
913 8859-1 is a graphic character set, and iso-8859-1 is a MIME charset)
919 <concept>Message Transfer Agent</concept>. It means mail transfer
920 programs (ex. sendmail) and news servers.
928 <concept>Message User Agent</concept>. It means mail readers and news
937 Multilingual extension of GNU <dref>Emacs</dref> by HANDA Ken'ichi et
940 <inproc abbrev="MULE" author="Nishikimi M., Handa K. and Tomura S."
941 title-en="Mule: MULtilingual Enhancement to GNU Emacs"
942 book-en="Proc. of INET'93" date="August, 1993">
944 Now, FSF and HANDA Ken'ichi et al. are working to merge MULE feature
945 into Emacs, there is <a
946 href="ftp://etlport.etl.go.jp/pub/mule/mule-19.33-delta.taz">alpha
947 version of mule merged emacs</a>.
949 In addition, there is XEmacs with mule feature.
951 So now, there are 3 kinds of mule variants.
953 In this document, <concept>mule</concept> means any mule variants,
954 <concept>MULE</concept> means original MULE (..2.3),
955 <concept>Emacs/mule</concept> means mule merged Emacs,
956 <concept>XEmacs/mule</concept> means XEmacs with mule feature.
962 <concept>multipart</concept> means <dref>media type</dref> to insert
963 multiple <a node="entity">entities</a> in a single body. Or it also
964 indicates a message consists of multiple entities.
966 There are following subtypes registered in <dref>RFC 2046</dref>:
969 <li><dref>multipart/mixed</dref>
970 <li><dref>multipart/alternative</dref>
971 <li><dref>multipart/digest</dref>
972 <li><dref>multipart/parallel</dref>
976 and registered in <a node="Security multipart">RFC 1847</a>:
979 <li><dref>multipart/signed</dref>
980 <li><dref>multipart/encrypted</dref>
984 <h3> multipart/alternative
985 <node> multipart/alternative
987 <concept>multipart/digest</concept> is one of <dref>multipart</dref>
988 media types. This type is syntactically identical to
989 <dref>multipart/mixed</dref>, but the semantics are different. In
990 particular, each of the body parts is an ``alternative'' version of
991 the same information.
996 <h3> multipart/digest
997 <node> multipart/digest
999 <concept>multipart/digest</concept> is one of <dref>multipart</dref>
1000 media types. This type is syntactically identical to
1001 <dref>multipart/mixed</dref>, but the semantics are different. In
1002 particular, in a digest, the default Content-Type value for a body
1003 part is changed from <dref>text/plain</dref> to
1004 <dref>message/rfc822</dref>.
1006 This is the replacement of traditional <dref>RFC 1153</dref> based
1007 <dref>encapsulation</dref>.
1009 <cf node="RFC 2046">
1012 <h3> multipart/encrypted
1013 <node> multipart/encrypted
1015 It is a <dref>Security multipart</dref> defined in
1016 RFC 1847, used to represent encrypted message.
1018 <cf node="PGP/MIME">
1021 <h3> multipart/mixed
1022 <node> multipart/mixed
1024 Primary and default subtype of <dref>multipart</dref>, it is used when
1025 the body parts are independent and need to be bundled in a particular
1028 <cf node="RFC 2046">
1031 <h3> multipart/parallel
1032 <node> multipart/parallel
1034 <concept>multipart/parallel</concept> is a subtype of
1035 <dref>multipart</dref>. This type is syntactically identical to
1036 <dref>multipart/mixed</dref>, but the semantics are different. In
1037 particular, in a parallel entity, the order of body parts is not
1040 <cf node="RFC 2046">
1043 <h3> multipart/signed
1044 <node> multipart/signed
1046 It is a <dref>Security multipart</dref> defined in
1047 RFC 1847, used to represent signed message.
1049 <cf node="PGP/MIME">
1055 A public key encryption program by Phil Zimmermann. It provides
1056 encryption and signature for <dref>message</dref>. PGP stands for
1057 <concept>Pretty Good Privacy</concept>.
1059 Traditional PGP uses <dref>RFC 934</dref> <dref>encapsulation</dref>.
1060 It is conflict with <dref>MIME</dref>. So <dref>PGP/MIME</dref> is
1061 defined. On the other hand, <dref>PGP-kazu</dref> was proposed to use
1062 PGP encapsulation in MIME. But it is obsoleted.
1064 <rfc name="PGP" number="1991" type="Informational" author="D. Atkins,
1065 W. Stallings and P. Zimmermann" title="PGP Message
1066 Exchange Formats" date="August 1996">
1073 In this document, <concept>PGP-kazu</concept> means a method to use
1074 traditional PGP encapsulation in <dref>MIME</dref>, proposed by
1077 PGP-kazu defines a <dref>media type</dref>,
1078 <concept>application/pgp</concept>.
1080 In application/pgp entity, PGP <dref>encapsulation</dref> is used.
1081 PGP encapsulation conflicts with MIME, so it requires PGP-processing
1082 to read as MIME message.
1084 It was obsoleted, so you should use <dref>PGP/MIME</dref>. However if
1085 you want to use traditional PGP message, it might be available.
1091 <dref>PGP</dref> and <dref>MIME</dref> integration proposed by Michael
1094 It is based on <a node="Security multipart">RFC 1847</a>, so it is
1095 harmonious with MIME, but it is not compatible with traditional PGP
1096 encapsulation. However MIME MUA can read PGP/MIME signed message even
1097 if it does not support PGP/MIME.
1099 <dref>PGP/MIME</dref> will be standard of PGP message.
1101 <rfc name="PGP/MIME" number="2015" type="Standards Track"
1102 author="M. Elkins" title="MIME Security with Pretty Good
1103 Privacy (PGP)" date="October 1996">
1106 <h3> Quoted-Printable
1107 <node> Quoted-Printable
1109 <concept>Quoted-Printable</concept> is a transfer encoding method of
1110 <dref>MIME</dref> defined in <dref>RFC 2045</dref>.
1112 If the data being encoded are mostly US-ASCII text, the encoded form
1113 of the data remains largely recognizable by humans.
1121 <rfc name="SMTP" number="821" type="STD 10" author="J. Postel"
1122 title="Simple Mail Transfer Protocol" date="August
1129 A RFC defines format of Internet mail message, mainly <concept>message
1134 news message is based on RFC 822, so <concept>Internet
1135 message</concept> may be more suitable than <concept>Internet
1139 <rfc number="822" type="STD 11" author="D. Crocker" title="Standard
1140 for the Format of ARPA Internet Text Messages"
1147 A RFC defines an <a node="encapsulation">
1148 <concept>encapsulation</concept></a> method for <a node="RFC
1149 822">Internet mail</a>.
1151 It conflicts with <dref>MIME</dref>, so you should use
1152 <dref>message/rfc822</dref>.
1154 <rfc number="934" author="Marshall T. Rose and Einar A. Stefferud"
1155 title="Proposed Standard for Message Encapsulation"
1156 date="January 1985">
1162 A RFC defines format of USENET message. It is a subset of <dref>RFC
1163 822</dref>. It is not Internet standard, but a lot of netnews
1164 excepting Usenet uses it.
1166 <rfc name="USENET" number="1036" author="M. Horton and R. Adams"
1167 title="Standard for Interchange of USENET Messages"
1168 date="December 1987" obsolete="850">
1174 <rfc number="1153" author="F. Wancho" title="Digest Message Format"
1181 A RFC defines <dref>MIME charset</dref>s for Korean,
1182 <dref>euc-kr</dref> and <dref>iso-2022-kr</dref>.
1184 <rfc number="1557" type="Informational" author="U. Choi, K. Chon and
1185 H. Park" title="Korean Character Encoding for Internet
1186 Messages" date="December 1993">
1192 A RFC defines <dref>MIME charset</dref>s for Chinese,
1193 <dref>iso-2022-cn</dref>, <dref>iso-2022-cn-ext</dref>,
1194 <dref>cn-gb</dref>, <dref>cn-big5</dref>, etc.
1196 In addition, it defines additional parameters of <dref>Content-Type
1197 field</dref> field, <concept>charset-edition</concept> and
1198 <concept>charset-extension</concept>.
1200 <rfc number="1922" type="Informational" author="Zhu, HF., Hu, DY.,
1201 Wang, ZG., Kao, TC., Chang, WCH. and Crispin, M."
1202 title="Chinese Character Encoding for Internet Messages"
1209 <rfc number="2045" type="Standards Track" author="N. Freed and
1210 N. Borenstein" title="Multipurpose Internet Mail
1211 Extensions (MIME) Part One: Format of Internet Message
1212 Bodies" date="November 1996" obsolete="1521, 1522,
1219 <rfc number="2046" type="Standards Track" author="N. Freed and
1220 N. Borenstein" title="Multipurpose Internet Mail
1221 Extensions (MIME) Part Two: Media Types"
1222 date="November 1996" obsolete="1521, 1522, 1590">
1228 <rfc number="2048" type="Standards Track" author="N. Freed, J. Klensin
1229 and J. Postel" title="Multipurpose Internet Mail
1230 Extensions (MIME) Part Four: Registration Procedures"
1231 date="November 1996" obsolete="1521, 1522, 1590">
1237 <rfc number="2049" type="Standards Track" author="N. Freed and
1238 N. Borenstein" title="Multipurpose Internet Mail
1239 Extensions (MIME) Part Five: Conformance Criteria and
1240 Examples" date="November 1996" obsolete="1521, 1522,
1247 A textual data represented by only <dref>coded character set</dref>.
1248 It does not have information about font or typesetting.
1249 <cf node="text/plain">
1252 <h3> Security multipart
1253 <node> Security multipart
1255 A format to represent signed/encrypted message in <dref>MIME</dref>.
1257 It defines two multipart media types, <a
1258 node="multipart/signed"><concept>multipart/signed</concept></a> and <a
1259 node="multipart/encrypted"><concept>multipart/encrypted</concept></a>.
1261 MOSS and <dref>PGP/MIME</dref> are based on it.
1263 <rfc name="Security multipart" number="1847" type="Standards Track"
1264 author="James Galvin, Gale Murphy, Steve Crocker and Ned
1265 Freed" title="Security Multiparts for MIME:
1266 Multipart/Signed and Multipart/Encrypted" date="October
1271 <node> text/enriched
1273 <rfc name="text/enriched" number="1896" author="P. Resnick and
1274 A. Walker" title="The text/enriched MIME Content-type"
1275 date="February 1996" obsolete="1563">
1281 <concept>text/plain</concept> is a <dref>media type</dref> for
1282 <dref>plain text</dref>, defined in <dref>RFC 2046</dref>.
1284 The default media type of ``text/plain; charset=us-ascii'' for
1285 Internet mail describes existing Internet practice. That is, it is
1286 the type of body defined by <dref>RFC 822</dref>.
1288 <cf node="MIME charset"><cf node="us-ascii">
1294 A libraries to provide user interface about <dref>MIME</dref> for
1295 emacs. tm stands for `tools for MIME'.
1297 <memo title="Unimportant notice(^-^;">
1300 <li> tm may not stand for ``tiny-mime''(^-^;
1301 <li> tm may not stand for initial of an author (^-^;
1302 <li> ``Tools for MIME'' may be strained (^-^;
1310 <dref>MUA</dref> or MUA extender using <a node="tm-kernel">tm</a>.
1312 <concept>tm oomori package</concept> has following extenders:
1315 <li><a file="tm-mh-e-en"><concept>tm-mh-e</concept></a>
1316 for <a file="mh-e">mh-e</a>
1317 <li><a file="tm-gnus_en"><concept>tm-gnus</concept></a> for GNUS
1318 <li><a file="gnus-mime-en"><concept>gnus-mime</concept></a> for Gnus
1319 <li><a file="tm-vm-en"><concept>tm-vm</concept></a> for VM
1320 <li><concept>tm-rmail</concept> for RMAIL
1327 A <a node="MIME charset">MIME charset</a> for primary Latin script
1328 mainly written by English or other languages.
1330 It is a 7bit <dref>coded character set</dref> based on <dref>ISO
1331 2022</dref>, it contains only
1332 <dref>ASCII</dref> and <dref>code extension</dref> is not allowed.
1334 It is standard coded character set of Internet mail. If MIME charset
1335 is not specified, <concept>us-ascii</concept> is used as default.
1337 In addition, <concept>ASCII</concept> of <dref>RFC 822</dref> should
1338 be interpreted as us-ascii.
1344 In the tm package, two files, <file>mime-setup.el</file> and
1345 <file>tm-setup.el</file>, are provided to ease the setup.
1347 The <file>mime-setup.el</file> is used for the whole MIME related
1348 setup including MIME encoding using <file>tm-edit.el</file>, while
1349 <file>tm-setup.el</file> is used to set up tm-MUA only.
1355 If you want normal setting, please use <concept>mime-setup</concept>.
1356 For example, please insert following into <file>~/.emacs</file>:
1363 As <file>mime-setup.el</file> loads <file>tm-setup.el</file>, you
1364 don't need to load <file>tm-setup.el</file> when you use
1365 <file>mime-setup.el</file> (Description of old version of Gnus FAQ is
1372 You can set up the <concept>automatic signature selection
1373 tool</concept> using <file>mime-setup</file>. If you want to
1374 automatically select the signature file depending on how the message
1375 headers show, add lines like shown below to your .emacs (Refer to the
1376 reference manual of <file>signature.el</file> for more details).
1379 (setq signature-file-alist
1380 '((("Newsgroups" . "jokes") . "~/.signature-jokes")
1381 (("Newsgroups" . ("zxr" "nzr")) . "~/.signature-sun")
1382 (("To" . ("ishimaru" "z-suzuki")) . "~/.signature-sun")
1383 (("To" . "tea") . "~/.signature-jokes")
1384 (("To" . ("sim" "oku" "takuo")) . "~/.signature-formal")
1389 <defvar name="mime-setup-use-signature">
1391 If it is not <code>nil</code>, <file>mime-setup.el</file> sets up for
1392 <file>signature.el</file>. Its default value is <code>t</code>.
1396 <defvar name="mime-setup-signature-key-alist">
1398 It defines key to bind signature inserting command for each
1399 major-mode. Its default value is following:
1402 ((mail-mode . "\C-c\C-w"))
1406 If you want to change, please rewrite it. For example:
1409 (set-alist 'mime-setup-signature-key-alist
1410 'news-reply-mode "\C-c\C-w")
1416 <defvar name="mime-setup-default-signature-key">
1418 If key to bind signature inserting command for a major-mode is not
1419 found from <code>mime-setup-signature-key-alist</code>, its value is
1420 used as key. Its default value is <code>"\C-c\C-s"</code>.
1424 <h3> Notices for GNUS
1425 <node> Notice about GNUS
1427 When <file>mime-setup.el</file> sets up for <file>signature.el</file>,
1428 it sets variable <code>gnus-signature-file</code> to <code>nil</code>.
1429 Therefore GNUS does not insert signature automatically when it is
1430 sending a message. Reason of this setting is following:
1432 GNUS inserts signature after <file>tm-edit.el</file> composed as MIME
1433 message. Therefore signature inserted by GNUS is not processed as a
1434 valid MIME part. In particular, for multipart message, signature
1435 places in outside of MIME part. So MIME MUA might not display it.
1437 Other notice is key bind. In historical reason, key bind to insert
1438 signature is <kbd>C-c C-s</kbd> (like <a file="mh-e">mh-e</a>) instead
1439 of <kbd>C-c C-w</kbd>. If you change to GNUS's default, please set
1443 (set-alist 'mime-setup-signature-key-alist 'news-reply-mode "\C-c\C-w")
1447 <h2> Setting not to use tm-edit
1450 <concept>tm-setup</concept> only sets up <a node="tm-MUA">tm-MUA</a>s.
1451 In other words, it is a setting to avoid to use tm-edit. If you don't
1452 want to compose MIME message or want to use other MIME composer,
1453 please use it instead of <file>mime-setup.el</file>.
1455 For example, please insert following into <file>~/.emacs</file>:
1465 If you use <file>mime-setup.el</file>, you you don't need to load
1466 <file>tm-setup.el</file>.
1471 <node> setting for VM
1473 If you use <concept>vm</concept>, please insert following in
1481 <memo title="Notice">
1483 If you use <concept>BBDB</concept>, please insert <code>(require
1484 'tm-vm)</code> <bf>after</bf> <code>(bbdb-insinuate-vm)</code>.
1488 <h2> Setting up without loading provided setup files
1489 <node> manual setting
1491 You may find the valuable hints in <file>mime-setup.el</file> or
1492 <file>tm-setup.el</file> if you want to set up MIME environment
1493 without loading the tm-provided setup files.
1497 Current tm provides some convenient features to expect tm-edit, and
1498 they can not use if <file>mime-setup.el</file> is not used. If you
1499 want to set up original setting to use tm-edit, please declare
1503 (provide 'mime-setup)
1509 <h1> How to report bug and about mailing list of tm
1512 If you write bug-reports and/or suggestions for improvement, please
1513 send them to the tm Mailing List:
1516 <li> Japanese <mail>bug-tm-ja@chamonix.jaist.ac.jp</mail>
1517 <li> English <mail>bug-tm-en@chamonix.jaist.ac.jp</mail>
1521 Notice that, we does not welcome bug reports about too old version.
1522 Bugs in old version might be fixed. So please try latest version at
1525 You should write <concept>good bug report</concept>. If you write
1526 only ``tm does not work'', we can not find such situations. At least,
1527 you should write name, type, variants and version of OS, emacs, tm and
1528 MUA, and setting. In addition, if error occurs, to send backtrace is
1529 very important. <cf file="emacs" node="Bugs">
1531 Bug may not appear only your environment, but also in a lot of
1532 environment (otherwise it might not bug). Therefor if you send mail
1533 to author directly, we must write a lot of mails. So please send mail
1534 to address for tm bugs instead of author.
1536 Via the tm ML, you can report tm bugs, obtain the latest release of
1537 tm, and discuss future enhancements to tm. To join the tm ML, send
1541 <li> Japanese <mail>tm-ja-admin@chamonix.jaist.ac.jp</mail>
1542 <li> English <mail>tm-en-admin@chamonix.jaist.ac.jp</mail>
1546 Since the user registration is done manually, please write the mail
1547 body in human-recognizable language (^_^).
1550 <h1> Acknowledgments
1551 <node> Acknowledgments
1553 I thank MASUTANI Yasuhiro. He requested me a lot of important
1554 features and gave me a lot of suggestions when tm-view was born.
1555 tm-view is based on his influence.
1557 I thank ENAMI Tsugutomo for work of <file>mime.el</file>, which is an
1558 origin of <file>tm-ew-d.el</file> and <file>mel-b.el</file>, and
1559 permission to rewrite for tm.
1561 I thank OKABE Yasuo for work of internal method for LaTeX and
1562 automatic assembling method for message/partial. I thank UENO
1563 Hiroshi for work of internal method for tar archive.
1565 I thank UMEDA Masanobu for his work of <file>mime.el</file>, which is
1566 the origin of tm-edit, and permission to rewrite his work as tm-edit.
1568 I thank KOBAYASHI Shuhei for his work as a tm maintainer. In
1569 addition, he often points out or suggests about conformity with RFCs.
1571 I thank Oscar Figueiredo for his work as the maintainer of tm-vm. He
1572 improves tm-vm and wrote a good manual of tm-vm.
1574 Last of all, I thank members of two tm mailing lists, Japanese and
1579 <node> Concept Index
1585 <node> Variable Index