tm 7.90 Manual (English Version)

tm 7.90 Manual (English Version)
********************************

This file documents tm, a MIME package for GNU Emacs.

What is tm?
***********

The tm package is a set of modules to enjoy MIME on GNU Emacs.  Using tm, you can

  * playback or view the MIME messages using tm-view

  * compose MIME message using tm-edit

  * use the enhanced MIME features with mh-e, GNUS, Gnus, RMAIL and VM

and more.

Please read following about each topics:

  * tm-MUA for Gnus ((gnus-mime-en))

  * tm-MUA for GNUS ((tm-gnus-en))

  * tm-MUA for mh-e ((tm-mh-e-en))

  * mime/viewer-mode ((tm-view-en))

  * mime/editor-mode ((tm-edit-en))

Glossary
========

7bit
----

7bit means any integer between 0 .. 127.

Any data represented by 7bit integers is called 7bit data.

Textual string consisted of Control characters between 0 .. 31 and 127, and space represented by 32, and graphic characters between 33 .. 236 are called 7bit (textual) string.

Traditional Internet MTA (MTA) can translate 7bit data, so it is no need to translate by Quoted-Printable (Quoted-Printable) or Base64 (Base64) for 7bit data.

However if there are too long lines, it can not translate by 7bit MTA even if it is 7bit data.  RFC 821 (RFC 821) and RFC 2045 (RFC 2045) require lines in 7bit data must be less than 998 bytes.  So if a ``7bit data'' has a line more than 999 bytes, it is regarded as binary (binary).  For example, Postscript file should be encoded by Quoted-Printable.

8bit
----

8bit means any integer between 0 .. 255.

Any data represented by 8bit integers is called 8bit data.

Textual string consisted of Control characters between 0 .. 31, 127, and 128 .. 159, and space represented by 32, and graphic characters between 33 .. 236 and 160 .. 255 are called 8bit (textual) string.

For example, iso-8859-1 (iso-8859-1) or euc-kr (euc-kr) are coded-character-set represented by 8bit textual string.

Traditional Internet MTA (MTA) can translate only 7bit (7bit) data, so if a 8bit data will be translated such MTA, it must be encoded by Quoted-Printable (Quoted-Printable) or Base64 (Base64).

However 8bit MTA are increasing today.

However if there are too long lines, it can not translate by 8bit MTA even if it is 8bit data.  RFC 2045 (RFC 2045) require lines in 8bit data must be less than 998 bytes.  So if a ``8bit data'' has a line more than 999 bytes, it is regarded as binary (binary), so it must be encoded by Base64 or Quoted-Printable.

94-character set
----------------

94-character set is a kind of 1 byte graphic character set (graphic character set), each characters are in positions 02/01 (33) to 07/14 (126) or 10/01 (161) to 15/14 (254). (ex. ASCII (ASCII), JIS X0201-Latin)

96-character set
----------------

96-character set is a kind of 1 byte graphic character set (graphic character set), each characters are in positions 02/00 (32) to 07/15 (126) or 10/00 (160) to 15/15 (255). (ex. ISO 8859)

94x94-character set
-------------------

94x94-character set is a kind of 2 byte graphic character set (graphic character set), each bytes are in positions 02/01 (33) to 07/14 (126) or 10/01 (161) to 15/14 (254). (ex. JIS X0208 (JIS X0208), GB 2312 (GB 2312))

ASCII
-----

アメリカ連邦で使われる文字を符号化した 94-character set (94-character set).  A-Z, a-z の Latin 文字と数字、幾つかの記号からなる。ISO 646 (ISO 646) の一つ。

[ASCII]

     ``Coded Character Set -- 7-Bit American Standard Code for Information Interchange'', ANSI X3.4:1986.

Base64
------

Base64 is a transfer encoding method of MIME (MIME) defined in RFC 2045 (RFC 2045).

The encoding process represents 24-bit groups of input bits as output strings of 4 encoded characters.  Encoded characters represent integer 0 .. 63 or pad.  Base64 data must be 4 * n bytes, so pad is used to adjust size.

These 65 characters are subset of all versions of ISO 646, including US-ASCII, and all versions of EBCDIC.  So it is safe even if it is translated by non-Internet gateways.

binary
------

任意の byte 列を binary と呼ぶことにします。

8bit (8bit) と異なるのは data に行の構造を仮定しないことです。

また、行の構造があっても、999 byte 以上からなる行がある場合も binaryと呼ぶことにします。

ちなみに、7bit (7bit) や 8bit で表現できる data は binary でも表現できます。よって、binary data と言った場合、任意の data を指すことがあります。

Graphic Character Set
---------------------

Coded character set (Coded character set) for graphic characters.

cn-gb, gb2312
-------------

中国大陸でられている簡体字で表記される中国語を表現するための MIME charset (MIME charset) の１つ。

ISO 2022 (ISO 2022) に基いて ASCII (ASCII) に GB 2312 (GB 2312) を 8bit (8bit) で符号拡張 (Code extension)している。

RFC 1922 (RFC 1922) で定義されている。

cn-big5, big5
-------------

台湾や香港で用いられている主に繁体字で表記される中国語を表現するための MIME charset (MIME charset) の１つ。

ISO 2022 (ISO 2022) に基かない 8bit (8bit) のcoded character set (coded character set)で de-fact standard である。RFC 1922 (RFC 1922) で定義されている。

cf.

[BIG5]

     Institute for Information Industry, ``Chinese Coded Character Set in Computer'', March 1984.

CNS 11643-1986 (CNS) と対応関係がある。

CNS 11643-1992
--------------

台湾や香港で用いられている主に繁体字で表記される中国語を表現するための文字集合(Character set)。台湾の標準。現在、94×94 (94x94 character set) の面が第１面から第７面まである。

ISO 2022 (ISO 2022) での終端文字は、第１面が `G', 第２面が `H', 第３面が `I', 第４面が `J', 第５面が `K', 第６面が `L', 第７面が `M' である。

[CNS 11643-1992]

     ``Standard Interchange Code for Generally-Used Chinese Characters'', CNS 11643:1992.

Coded character set, Character code
-----------------------------------

A set of unambiguous rules that establishes a character set and the one-to-one relationship between the characters of the set and their bit combinations.

Code extension
--------------

The techniques for the encoding of characters that are not included in the character set of a given code. (ex. ISO 2022 (ISO 2022))

Content-Disposition field
-------------------------

Content の表示の仕方や file 名を表現するための field. MIME (MIME) の拡張の１つ。

[RFC 1806]

     E R. Troost and S. Dorner, ``Communicating Presentation Information in Internet Messages: The Content-Disposition Header'', June 1995, Experimental.

media type
----------

media type specifies the nature of the data in the body of MIME (MIME) entity (entity).  It consists of type and subtype.  It is defined in RFC 2046 (RFC 2046).

Currently there are following types:

  * text

  * image

  * audio

  * video

  * application

  * multipart (multipart)

  * message

And there are various subtypes, for example, application/octet-stream, audio/basic, image/jpeg, multipart/mixed (multipart/mixed), text/plain (text/plain), video/mpeg...

You can refer registered media types at MEDIA TYPES (ftp://ftp.isi.edu/in-notes/iana/assignments/media-types).

In addition, you can use private type or subtype using x-token, which as the prefix `x-'.  However you can not use them in public.

(cf. Content-Type field)

Content-Type field
------------------

Header field to represent information about body, such as media type (media type), MIME charset (MIME charset).  It is defined in RFC 2045 (RFC 2045).

[Memo]

     Historically, Content-Type field was proposed in RFC 1049.  In it, Content-Type did not distinguish type and subtype.  However MIME parser may be able to accept RFC 1049 based Content-Type as unknown type.

Content-Type field is defined as following:

     ``Content-Type'' ``:'' type ``/'' subtype *( ``;'' parameter )

For example:

          Content-Type: image/jpeg

          Content-Type: text/plain; charset=iso-2022-jp

[Memo]

     A part does not have content-type field is regarded as

               Content-Type: text/plain; charset=us-ascii

     (cf. us-ascii)

     And a part has unknown type/subtype is regarded as

               Content-Type: application/octet-stream

Emacs
-----

ここでは `Emacs' で FSF が配布している GNU Emacs を指し、`emacs' で GNU Emacs の変種の総称とする。

encoded-word
------------

Representation non ASCII (ASCII) characters in header.  It is defined in RFC 2047.

[RFC 2047]

     K. Moore, ``MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text'', November 1996, Standards Track (obsolete RFC 1521,1522,1590).

encapsulation
-------------

Internet mail (RFC 822) を他の記事にまるごと入れる方法。

例えば、記事を転送したりするのに用いる。

(cf. message/rfc822)

euc-kr
------

韓国語を表現するための MIME charset (MIME charset) の１つ。

ISO 2022 (ISO 2022) に基いて ASCII (ASCII) にKS C5601 (KS C5601) を 8bit (8bit) で符号拡張 (Code extension) している。

RFC 1557 (RFC 1557) で定義されている。

cf.

[euc-kr]

     Korea Industrial Standards Association, ``Hangul Unix Environment'', KS C 5861:1992.

FTP
---

Internet で file を転送するための protocol の１つ。RFC 959 で定義されている。

[FTP: RFC 959]

     Postel, J. and J. Reynolds, ``File Transfer Protocol'', October 1985, STD 9.

GB 2312-1980
------------

中国大陸で用いられている簡体字で表記される中国語を表すための 94x94-character set (94x94-character set)。中国の国家標準。ISO 2022 (ISO 2022) での終端文字は `A'.

これは GB における基本集である。

[GB 2312]

     『信息交換用漢字編碼字符集 -- 基本集』, ``Code of Chinese Graphic Character Set for Information Interchange - Primary Set'', GB 2312:1980.

GB 8565.2-1988
--------------

中国語のための補助文字集合(Character set)。中国の国家標準。GB 2312 (GB 2312) の空き部分に補充するように定義されたらしい。

[GB 8565.2]

     ``Information Processing - Coded Character Sets for Text Communication - Part 2: Graphic Characters used with Primary Set'', GB 8565.2:1988.

hz-gb2312
---------

中国大陸で用いられている簡体字で表記される中国語を表現するための MIME charset (MIME charset) の１つ。

ASCII (ASCII) に GB 2312 (GB 2312) を 7bit で符号拡張 (Code extension)したものを ASCII printable になるように工夫している。

RFC 1842, 1843 で定義されている。

[RFC 1842]

     Y. Wei, Y. Zhang, J. Li, J. Ding and Y. Jiang, ``ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages'', August 1995, Informational.

[RFC 1843]

     F. Lee, ``HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters'', August 1995, Informational.

ISO 2022
--------

符号拡張(Code extension)のための国際標準。

これを用いて複数の文字集合(Character set)を組合せて 7bit (7bit) ないし 8bit (8bit) の 符号化文字集合(Coded character set) を作ることができる。

[ISO 2022]

     International Organization for Standardization (ISO), ``Information Processing: ISO 7-bit and 8-bit coded character sets: Code extension techniques'', ISO/IEC 2022:1994.

iso-2022-cn
-----------

中国語を表現するための MIME charset (MIME charset) の１つ。

ISO 2022 (ISO 2022) に基いて ASCII (ASCII) に GB 2312 (GB 2312), CNS 11643 plain 1, plain 2 (CNS) を 7bit (7bit) で符号拡張 (Code extension)している。

RFC 1922 (RFC 1922) で定義されている。

iso-2022-cn-ext
---------------

中国語を表現するための MIME charset (MIME charset) の１つ。

ISO 2022 (ISO 2022) に基いて ASCII (ASCII) に GB 2312 (GB 2312), CNS 11643 plain 1 .. 7 (CNS), ISO-IR-165 (ISO-IR-165) 等を 7bit (7bit) で符号拡張 (Code extension)している。

RFC 1922 (RFC 1922) で定義されている。

[Memo]

     MULE 2.3 および、現在の XEmacs/mule では正しく扱うことはできない。

     Emacs/mule では利用可能である。

iso-2022-jp
-----------

日本語を表現するための MIME charset (MIME charset) の一つ。

古い ISO 2022 (ISO 2022) に基いて ASCII (ASCII), JIS X0201-Latin, JIS X0208-1978 (JIS C6226-1978), JIS X0208-1983 (JIS X0208) を切り替える 7bit (7bit) 文字符号。

RFC 1468 で定義されている。

[Memo]

     JIS X0208-1996? では ISO 2022 (ISO 2022) と独立に定義される予定。

[iso-2022-jp: RFC 1468]

     Murai J., M. Crispin, and E. van der Poel, ``Japanese Character Encoding for Internet Messages'', June 1993.

iso-2022-jp-2
-------------

A MIME charset (MIME charset), which is a multilingual extension of iso-2022-jp (iso-2022-jp).

It is defined in RFC 1554.

[iso-2022-jp-2: RFC 1554]

     Ohta M. and Handa K., ``ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP'', December 1993, Informational.

iso-2022-kr
-----------

A MIME charset (MIME charset) for Korean language (Hangul script).

It is based on ISO 2022 (ISO 2022) code extension (code extension) technique to extends ASCII (ASCII) to use KS C5601 (KS C5601) as 7bit (7bit) text.

It is defined in RFC 1557 (RFC 1557).

ISO 646
-------

各国で共通に使える最小限度の文字集合(Character set)を定めたもの。 94 文字集合 (94 character set)の１つ。ISO 646 IRV（国際基準版）を元に幾つかの文字は各国で違う文字を割当ることを許していて、幾つかの変種が存在する。ASCII (ASCII) や JIS X0201-Latin はその一種。

[ISO 646]

     International Organization for Standardization (ISO), ``Information technology: ISO 7-bit coded character set for information interchange'', ISO/IEC 646:1991.

ISO 8859-1
----------

[ISO 8859-1]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No.1'', ISO 8859-1:1987.

iso-8859-1
----------

iso-8859-1 is a MIME charset (MIME charset) for west-European languages written by Latin script.

ISO 2022 (ISO 2022) に基いて、ASCII (ASCII) に ISO 8859-1 (ISO 8859-1) を 8bit (8bit) で符号拡張 (Code extension)している。

It is defined in RFC 2046 (RFC 2046).

ISO 8859-2
----------

[ISO 8859-2]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 2: Latin alphabet No.2'', ISO 8859-2:1987.

iso-8859-2
----------

iso-8859-2 is a MIME charset (MIME charset) for east-European languages written by Latin script.

ISO 2022 (ISO 2022) に基いて、ASCII (ASCII) に ISO 8859-2 (ISO 8859-2) を 8bit (8bit) で符号拡張 (Code extension)している。

It is defined in RFC 2046 (RFC 2046).

ISO 8859-3
----------

[ISO 8859-3]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 3: Latin alphabet No.3'', ISO 8859-3:1988.

ISO 8859-4
----------

[ISO 8859-4]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 4: Latin alphabet No.4'', ISO 8859-4:1988.

ISO 8859-5
----------

[ISO 8859-5]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 5: Latin/Cyrillic alphabet'', ISO 8859-5:1988.

iso-8859-5
----------

iso-8859-5 is a MIME charset (MIME charset) for Cyrillic script.

ISO 2022 (ISO 2022) に基いて、ASCII (ASCII) に ISO 8859-5 (ISO 8859-5) を 8bit (8bit) で符号拡張 (Code extension)している。

It is defined in RFC 2046 (RFC 2046).

ISO 8859-6
----------

[ISO 8859-6]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 6: Latin/Arabic alphabet'', ISO 8859-6:1987.

ISO 8859-7
----------

[ISO 8859-7]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 7: Latin/Greek alphabet'', ISO 8859-7:1987.

iso-8859-7
----------

iso-8859-7 is a MIME charset (MIME charset) for Greek script.

ISO 2022 (ISO 2022) に基いて、ASCII (ASCII) に ISO 8859-7 (ISO 8859-7) を 8bit (8bit) で符号拡張 (Code extension)している。

It is defined in RFC 1947.

[iso-8859-7: RFC 1947]

     D. Spinellis, ``Greek Character Encoding for Electronic Mail Messages'', May 1996, Informational.

ISO 8859-8
----------

[ISO 8859-8]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 8: Latin/Hebrew alphabet'', ISO 8859-8:1988.

ISO 8859-9
----------

[ISO 8859-9]

     International Organization for Standardization (ISO), ``Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 9: Latin alphabet No.5'', ISO 8859-9:1990.

ISO-IR-165, CCITT Extended GB
-----------------------------

CCITT が登録した、中国大陸で用いられている簡体字で表記される中国語を表現するための 94x94-character set (94x94-character set)。

GB 2312 (GB 2312) と GB 8565 表２ (GB 8865.2) に 150 文字ほどを追加したものらしい。

ISO 2022 (ISO 2022) での終端文字は `E' である。

JIS X0201
---------

ISO 646 (ISO 646) の変種の１つである Latin 文字集合と 1 byte のカタカナ文字集合からなる。

元は JIS C6220-1976 と言ったが JIS X0201 に番号が変更された。

[JIS X0201-1976]

     日本規格協会 (Japanese Standards Association),『情報交換用符号』, ``Code for Information Interchange'', JIS X 0201-1976:.

また、1996 年に改定版が出る予定。

[JIS X0201-1996?]

     日本規格協会 (Japanese Standards Association),『７ビット及び８ビットの情報交換用符号化文字集合』, ``7-bit and 8-bit coded character sets for information interchange'', JIS X 0201:1996?  draft.

JIS C6226-1978
--------------

日本語を表すために作られた 94x94-character set (94x94-character set)。日本の国家標準。JIS X0208-1978 ともいう。

(cf. JIS X0208)

JIS X0208
---------

日本語を表すために作られた 94x94-character set (94x94-character set)。日本の国家標準。1978 年版、1983 年版、1990 年版があるが、Internet では 1983 年版がもっとも良く使われている。

JIS X0208 は記号、数字、ローマ字、ひらがな、カタカナ、ギリシャ文字、キリル文字、罫線素、第１水準、第２水準の漢字が含まれる。但し、1983 年版の一部の記号と罫線素は 1978 年版にはない。また、一部の漢字の字形が 1983 年版では変更され、また、第１水準と第２水準が入れ替わっていたりする。このため、 1978 年版と 1983 年版は異なる文字集合として扱われる。

1990 年の改定では 1983 年版に対する追加が行われた。このため、1990 年版を指示する場合は前に更新シーケンスを用いる。

[JIS X0208-1978]

     日本規格協会 (Japanese Standards Association),『情報交換用漢字符号系』, ``Code of the Japanese graphic character set for information interchange'', JIS C6226:1978.

[JIS X0208-1983,1990]

     日本規格協会 (Japanese Standards Association),『情報交換用漢字符号系』, ``Code of the Japanese graphic character set for information interchange'', JIS X0208:1983,1990.

また、1996 年に改定版が出版される予定。（字形の変更は行われないので文字集合としては 1990 年版と同一である）

[JIS X0208-1996?]

     日本規格協会 (Japanese Standards Association),『７ビット及び８ビットの２バイト情報交換用符号化漢字集合』, ``7-bit and 8-bit double byte coded Kanji sets for information interchange'', JIS X 0208:1996? draft.

JIS X0212-1990
--------------

JIS X0208 (JIS X0208) になかった文字を集めた 94x94-character set (94x94-character set)。「補助漢字」とも呼ばれる。日本の国家標準。 ISO 2022 (ISO 2022) での終端文字は `D'.

koi8-r
------

A MIME charset (MIME charset) for Cyrillic script for Russian or other languages.

It is a 1 byte 8bit (8bit) coded character set (coded character set), not based on ISO 2022 (ISO 2022).  It is a de-fact standard.

It is defined in RFC 1489.

[RFC 1489]

     A. Chernov, ``Registration of a Cyrillic Character Set'', July 1993.

KS C5601-1987
-------------

A 94x94-character set (94x94-character set) for Korean language (Hangul script).  Korean Standard.  Final byte of ISO 2022 (ISO 2022) is `C'.

[KS C5601]

     Korea Industrial Standards Association, ``Code for Information Interchange (Hangul and Hanja)'', KS C 5601:1987.

message
-------

ここでは RFC 822 (RFC 822) で定義される mail と RFC 1036 (RFC 1036) で定義される news 記事の総称として用いる。

message/rfc822
--------------

message/rfc822 indicates that the body contains an encapsulated message, with the syntax of an RFC 822 (RFC 822) message.  It is the replacement of traditional RFC 934 (RFC 934) encapsulation.  It is defined in RFC 2046 (RFC 2046).

method
------

tm で特定の種類の data を再生したとき実際にその処理を行なう program. Emacs Lisp で書かれた internal method と C や script 言語などで書かれた external method がある。

(cf. (tm-view-en)method)

MIME
----

MIME stands for Multipurpose Internet Mail Extensions, it is an extension for RFC 822 (RFC 822).

According to RFC 2045:

STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text.  This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for

 1. textual message bodies in character sets other than US-ASCII,

 2. an extensible set of different formats for non-textual message bodies,

 3. multi-part message bodies, and

 4. textual header information in character sets other than US-ASCII.

It is defined in RFC 2045 (RFC 2045), RFC 2046 (RFC 2046), RFC 2047 (encoded-word), RFC 2048 (RFC 2048) and RFC 2049 (RFC 2049).

MIME charset
------------

Coded character set (Coded character set) used in Content-Type field (Content-Type field) or charset parameter of encoded-word (encoded-word).

It is defined in RFC 2045 (RFC 2045).

iso-2022-jp (iso-2022-jp) や euc-kr (euc-kr) はその１つ。（ここでは、MIME charset は文字集合 (Character set)と区別して小文字で書いている）

MTA
---

Message Transfer Agent の略で、 sendmail などの mail 配送 program と news server の総称。

(cf. MUA)

MUA
---

Message User Agent の略で、mail reader と news reader の総称。

(cf. MTA)

MULE
----

半田 剣一氏らが作った、多言語された Emacs (Emacs).

[MULE] Nishikimi M., Handa K. and Tomura S., ``Mule: MULtilingual Enhancement to GNU Emacs'', Proc. of INET'93, August, 1993.

現在、MULE の機能を Emacs に merge する作業が行われており、alpha 版 (ftp://etlport.etl.go.jp/pub/mule/mule-19.33-gamma.taz) が存在する。

その他、XEmacs に merge したものも存在する。

このため、現在では多言語 Emacs は、元々の MULE を含めて３種類あることになる。

そこで、ここでは、多言語 Emacs の総称を mule, 元々の MULE を MULE, mule 機能を merge した Emacs を Emacs/mule, mule 機能を merge した XEmacs を XEmacs/mule と呼ぶことにする。

Multipart
---------

multipart means media type (media type) to insert multiple entities (entities) in a single body.  Or it also indicates a message consists of multiple entities.

There are following subtypes registered in RFC 2046 (RFC 2046):

  * multipart/mixed (multipart/mixed)

  * multipart/alternative (multipart/alternative)

  * multipart/digest (multipart/digest)

  * multipart/parallel (multipart/parallel)

and registered in RFC 1847 (Security multipart):

  * multipart/signed (multipart/signed)

  * multipart/encrypted (multipart/encrypted)

multipart/alternative
---------------------

multipart/digest is one of multipart (multipart) media types.  This type is syntactically identical to multipart/mixed (multipart/mixed), but the semantics are different.  In particular, each of the body parts is an ``alternative'' version of the same information.

(cf. RFC 2046)

multipart/digest
----------------

multipart/digest is one of multipart (multipart) media types.  This type is syntactically identical to multipart/mixed (multipart/mixed), but the semantics are different.  In particular, in a digest, the default Content-Type value for a body part is changed from text/plain (text/plain) to message/rfc822 (message/rfc822).

This is the replacement of traditional RFC 1153 (RFC 1153) based encapsulation (encapsulation).

(cf. RFC 2046)

multipart/encrypted
-------------------

RFC 1847 で定義された Security multipart (Security multipart) の１つで、暗号化された message を表現するのに用いる。

(cf. PGP/MIME)

multipart/mixed
---------------

Primary and default subtype of multipart (multipart), it is used when the body parts are independent and need to be bundled in a particular order.

(cf. RFC 2046)

multipart/parallel
------------------

multipart/parallel is a subtype of multipart (multipart).  This type is syntactically identical to multipart/mixed (multipart/mixed), but the semantics are different.  In particular, in a parallel entity, the order of body parts is not significant.

(cf. RFC 2046)

multipart/signed
----------------

RFC 1847 で定義された Security multipart (Security multipart) の１つで、電子署名を表現するのに用いる。

(cf. PGP/MIME)

PGP
---

Phil Zimmermann 氏が作成した公開鍵暗号処理系の１つ。message (message) の暗号化や電子署名を行うことができる。Pretty Good Privacy の略。

伝統的な PGP では encapsulation (encapsulation) に RFC 934 (RFC 934)に準じた方法を用いる。これは MIME (MIME) と矛盾するので PGP/MIME (PGP/MIME) が提案されている。一方、MIME において PGP のencapsulation を用いる方法 (cf. PGP-kazu) も利用されてきた。しかし、今後は PGP/MIME に統一していく方が望ましい。

[PGP: RFC 1991]

     D. Atkins, W. Stallings and P. Zimmermann, ``PGP Message Exchange Formats'', August 1996, Informational.

PGP-kazu
--------

山本 和彦 氏が提案した MIME (MIME) で PGP (PGP) を利用するための方法をここでは PGP-kazu と呼ぶことにする。

PGP-kazu は application/pgp という content-type (content-type) を定義する。

application/pgp の part では PGP の encapsulation (encapsulation) が用いられる。PGP の encapsulation (cf. RFC 934) と MIME の encapsulation は矛盾するので、PGP の encapsulation を解かない限り、中に含まれた MIME message を読むことができなくなる。即ち、 PGP-kazu に対応していない MIME に対応した MUA (MUA) はその part が読めなくなる。その代わり、MIME に対応していない PGP 対応の MUA (MUA) でも message を読むことができる。

PGP-kazu では MUA は PGP のと MIME のという２つの encapsulation を知らなければならない。また、application/pgp part を parse するためには、まず、 pgp の処理を行わなければならないので、parse 処理が複雑になる。

また、Internet では今後 PGP/MIME (PGP/MIME) の方向で標準化していこうということで合意が取れている。よって、今後は PGP-kazu は用いないのが望ましい。

[draft-kazu-pgp-mime-00.txt] Yamamoto K., ``PGP MIME Integration'', October, 1995

PGP/MIME
--------

Michael Elkins 氏が提案した MIME (MIME) で PGP (PGP) を利用するための方法。

RFC 1847 (Security multipart) に基き、MIME の multipart による encapsulation (encapsulation) を行う。このため、MIME の自然な拡張になっている。しかし、伝統的な PGPとの互換性が失われている。

PGP/MIME では PGP-kazu (PGP-kazu) と異なり、MIME の encapsulation のみを用いる。また、このため、PGP の処理を行う前に message の parse を行うことができる。

Internet では今後 PGP/MIME (PGP/MIME) の方向で標準化していこうということで合意が取れている。よって、今後は PGP を用いる場合は PGP/MIMEを用いるのが望ましい。

[PGP/MIME: RFC 2015]

     M. Elkins, ``MIME Security with Pretty Good Privacy (PGP)'', October 1996, Standards Track.

Quoted-Printable
----------------

Quoted-Printable is a transfer encoding method of MIME (MIME) defined in RFC 2045 (RFC 2045).

If the data being encoded are mostly US-ASCII text, the encoded form of the data remains largely recognizable by humans.

(cf. Base64)

RFC 821
-------

SMTP と呼ばれる Internet mail の配送法の標準を定めている RFC.

[SMTP: RFC 821]

     J. Postel, ``Simple Mail Transfer Protocol'', August 1982, STD 10.

RFC 822
-------

Internet mail の主に message header に関する形式に関する標準を定めている RFC.

[Memo]

     news message もこれに準じているので、Internet mail と書くよりも、Internet message と書いた方が良いかもしれない。

[RFC 822]

     D. Crocker, ``Standard for the Format of ARPA Internet Text Messages'', August 1982, STD 11.

RFC 934
-------

Internet mail (RFC 822) の encapsulation (encapsulation) の方法を定めた RFC.

MIME (MIME) と矛盾するので、現在では message/rfc822 (message/rfc822) を用いるべきである。

[RFC 934]

     Marshall T. Rose and Einar A. Stefferud, ``Proposed Standard for Message Encapsulation'', January 1985.

RFC 1036
--------

USENET での message の形式を定めた RFC. RFC 822 (RFC 822)の subset になっている。Internet の標準ではないが、USENET 以外の netnews でもこれに準じているものが多い。

[USENET: RFC 1036]

     M. Horton and R. Adams, ``Standard for Interchange of USENET Messages'', December 1987, (obsolete RFC 850).

RFC 1153
--------

複数の Internet mail (RFC 822) を encapsulation (encapsulation) するための方法を定めた RFC. RFC 934 (RFC 934) を用いる。

MIME (MIME) と矛盾するので、現在では message/rfc822 (message/rfc822) を用いた multipart (multipart) を用いるべきである。

(cf. multipart/digest)

[RFC 1153]

     F. Wancho, ``Digest Message Format'', April 1990.

RFC 1557
--------

euc-kr (euc-kr) と iso-2022-kr (iso-2022-kr) という韓国語のための MIME charset (MIME charset) を定義している RFC.

[RFC 1557]

     U. Choi, K. Chon and H. Park, ``Korean Character Encoding for Internet Messages'', December 1993, Informational.

RFC 1922
--------

iso-2022-cn (iso-2022-cn), iso-2022-cn-ext (iso-2022-cn-ext), cn-gb (cn-gb), cn-big5 (cn-big5) といった中国語のための MIME charset (MIME charset) を定義している RFC.

これに加えて、charset-edition と charset-extension という Content-Type field (Content-Type field) の parameter を定義している。

[RFC 1922]

     Zhu, HF., Hu, DY., Wang, ZG., Kao, TC., Chang, WCH. and Crispin, M., ``Chinese Character Encoding for Internet Messages'', March 1996, Informational.

RFC 2045
--------

[RFC 2045]

     N. Freed and N. Borenstein, ``Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies'', November 1996, Standards Track (obsolete RFC 1521, 1522, 1590).

RFC 2046
--------

[RFC 2046]

     N. Freed and N. Borenstein, ``Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types'', November 1996, Standards Track (obsolete RFC 1521, 1522, 1590).

RFC 2048
--------

[RFC 2048]

     N. Freed, J. Klensin and J. Postel, ``Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures'', November 1996, Standards Track (obsolete RFC 1521, 1522, 1590).

RFC 2049
--------

[RFC 2049]

     N. Freed and N. Borenstein, ``Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples'', November 1996, Standards Track (obsolete RFC 1521, 1522, 1590).

plain text
----------

書体や組版に関する情報を持たない 文字符号(Coded character set)のみで表現される text 情報。(cf. text/plain)

Security multipart
------------------

MIME (MIME) で暗号や電子書名を用いるための形式。 multipart/signed (multipart/signed) と multipart/encrypted (multipart/encrypted) という multipart を用いる。MOSS や PGP/MIME (PGP/MIME) はこれに基いている。

[Security multipart: RFC 1847]

     James Galvin, Gale Murphy, Steve Crocker and Ned Freed, ``Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted'', October 1995, Standards Track.

text/enriched
-------------

RFC 1521 で定義された text/richtext に代わって、書体や組版に関する情報を持った textを表現するための media type (media type).

[text/enriched: RFC 1896]

     P. Resnick and A. Walker, ``The text/enriched MIME Content-type'', February 1996, (obsolete RFC 1563).

text/plain
----------

text/plain is a media type (media type) for plain text (plain text), defined in RFC 2046 (RFC 2046).

The default media type of ``text/plain; charset=us-ascii'' for Internet mail describes existing Internet practice.  That is, it is the type of body defined by RFC 822 (RFC 822).

(cf. MIME charset) (cf. us-ascii)

tm-kernel, tm
-------------

Emacs で MIME (MIME) を利用するための user interface を提供する library 群。`tools for MIME' の略。

[どうでも良いこと(^-^;]

       * tm は ``tiny-mime'' の略じゃないらしいぞ (^-^;

       * tm は作者のイニシャルじゃないらしいぞ (^-^;

       * ``Tools for MIME'' の略というのはこじつけらしいぞ (^-^;

tm-MUA
------

tm (tm-kernel) を用いた MUA (MUA) もしくは MUA に対する extender.

tm 大盛り package には

  * mh-e ((mh-e)) 用の tm-mh-e

  * GNUS 用の tm-gnus

  * Gnus 用の gnus-mime ((gnus-mime-en))

  * VM 用の tm-vm

  * RMAIL 用の tm-rmail

が含まれている。

独立した MUA としては cmail ((cmail)) が tm を利用可能である。

us-ascii
--------

アメリカ連邦などで使われる英語などを表現するための MIME charset (MIME charset) の１つ。

ASCII (ASCII) のみからなり ISO 2022 (ISO 2022) による符号拡張 (Code extension)は許されない。

Internet mail における標準の符号化文字集合(Coded character set)であり、明示的に MIME charset が示されない場合は原則として us-ascii が使われる。

また、RFC 822 (RFC 822) における ASCII は us-ascii を指すものと解釈すべきである。

Setting
*******

In the tm package, two files, mime-setup.el and tm-setup.el, are provided to ease the setup.

The mime-setup.el is used for the whole MIME related setup including MIME encoding using tm-edit.el, while tm-setup.el is used to set up tm-MUA only.

Normal setting
==============

If you want normal setting, please use mime-setup. For example, please insert following into ~/.emacs:

     (load "mime-setup")

As mime-setup.el loads tm-setup.el, you don't need to load tm-setup.el when you use mime-setup.el (Description of old version of Gnus FAQ is wrong!)

signature
---------

You can set up the automatic signature selection tool using mime-setup. If you want to automatically select the signature file depending on how the message headers show, add lines like shown below to your .emacs (Refer to the reference manual of signature.el for more details).

     (setq signature-file-alist
           '((("Newsgroups" . "jokes")       . "~/.signature-jokes")
             (("Newsgroups" . ("zxr" "nzr")) . "~/.signature-sun")
             (("To" . ("ishimaru" "z-suzuki")) . "~/.signature-sun")
             (("To" . "tea")                 . "~/.signature-jokes")
             (("To" . ("sim" "oku" "takuo")) . "~/.signature-formal")
             ))

 -- Variable: mime-setup-use-signature

     If it is not nil, mime-setup.el sets up for signature.el.  Its default value is t.

 -- Variable: mime-setup-signature-key-alist

     It defines key to bind signature inserting command for each major-mode.  Its default value is following:

          	((mail-mode . "\C-c\C-w"))

     If you want to change, please rewrite it.  For example:

          (set-alist 'mime-setup-signature-key-alist
          	   'news-reply-mode "\C-c\C-w")

 -- Variable: mime-setup-default-signature-key

     If key to bind signature inserting command for a major-mode is not found from mime-setup-signature-key-alist, its value is used as key. Its default value is "\C-c\C-s".

Notices for GNUS
----------------

When mime-setup.el sets up for signature.el, it sets variable gnus-signature-file to nil.  Therefore GNUS does not insert signature automatically when it is sending a message.  Reason of this setting is following:

GNUS inserts signature after tm-edit.el composed as MIME message. Therefore signature inserted by GNUS is not processed as a valid MIME part.  In particular, for multipart message, signature places in outside of MIME part.  So MIME MUA might not display it.

Other notice is key bind.  In historical reason, key bind to insert signature is C-c C-s (like mh-e ((mh-e))) instead of C-c C-w. If you change to GNUS's default, please set following:

     (set-alist 'mime-setup-signature-key-alist 'news-reply-mode "\C-c\C-w")

Setting not to use tm-edit
==========================

tm-setup only sets up tm-MUA (tm-MUA)s. In other words, it is a setting to avoid to use tm-edit.  If you don't want to compose MIME message or want to use other MIME composer, please use it instead of mime-setup.el.

For example, please insert following into ~/.emacs:

     (load "tm-setup")

[Memo]

     If you use mime-setup.el, you you don't need to load tm-setup.el.

Setting for VM
==============

If you use vm, please insert following in ~/.vm:

     (require 'tm-vm)

[Notice]

     If you use BBDB, please insert (require 'tm-vm) after (bbdb-insinuate-vm).

Setting up without loading provided setup files
===============================================

You may find the valuable hints in mime-setup.el or tm-setup.el if you want to set up MIME environment without loading the tm-provided setup files.

[Memo]

     Current tm provides some convenient features to expect tm-edit, and they can not use if mime-setup.el is not used.  If you want to set up original setting to use tm-edit, please declare following setting:

          (provide 'mime-setup)

How to report bug and about mailing list of tm
**********************************************

If you write bug-reports and/or suggestions for improvement, please send them to the tm Mailing List:

  * Japanese <bug-tm-ja@chamonix.jaist.ac.jp>

  * English <bug-tm-en@chamonix.jaist.ac.jp>

Notice that, we does not welcome bug reports about too old version. Bugs in old version might be fixed.  So please try latest version at first.

You should write good bug report.  If you write only ``tm does not work'', we can not find such situations. At least, you should write name, type, variants and version of OS, emacs, tm and MUA, and setting.  In addition, if error occurs, to send backtrace is very important. (cf. (emacs)Bugs)

Bug may not appear only your environment, but also in a lot of environment (otherwise it might not bug).  Therefor if you send mail to author directly, we must write a lot of mails.  So please send mail to address for tm bugs instead of author.

Via the tm ML, you can report tm bugs, obtain the latest release of tm, and discuss future enhancements to tm.  To join the tm ML, send e-mail to:

  * Japanese <tm-ja-admin@chamonix.jaist.ac.jp>

  * English  <tm-en-admin@chamonix.jaist.ac.jp>

Since the user registration is done manually, please write the mail body in human-recognizable language (^_^).