FLIM は Internet Message の表現や符号化に関する基礎的な機能を提供する ための library です。
FLIM の提供する MIME 機能を使うためには
(require 'mime)
を評価してください。
RFC 2045 (section RFC 2045) によれば、「Entity という語は、message, もしく は、multipart entity の body 中の１つの部分の、MIME で定義された header field と内容を指す」となっています。ここでは、MIME で定義された header field 以外の全ての header と body を指す語として entityを用いる ことにします。
RFC 2045 の定義は、MIME message が entity を単位とする木構造であることを 示しています。message は下図で示すような木となり、entity はこの木におけ る節となります。つまり、MIME は message を木構造に拡張した訳です。
FLIM は entity の情報を表現するためにmime-entity 構造体を用いま す。以下では単に mime-entity と呼ぶことにします。
前述のように、message 中の各 entity は木の節に当たりますが、この木には 深さと同じ深さの中の順番に従って番号が付けることができます。即ち、
┌───┐
│ nil │
└─┬─┘
┌─────────┼─────────┐
┌┴┐ ┌┴┐ ┌┴┐
│０│ │１│ │２│
└┬┘ └┬┘ └┬┘
│ ┌────┼────┐ │
┌─┴─┐┌─┴─┐┌─┴─┐┌─┴─┐┌─┴─┐
│ ０.０││ １.０││ １.１││ １.２││ ２.０│
└───┘└───┘└───┘└───┘└───┘
のように深さ n の節には長さ n の整数列の節番号が振れます。これ
を entity-number と呼びます。entity-number は S 式と
しては (1 2 3) のような整数のリストとして表現されます。
mime-entity では、これと同様の node-id を用います。node-id はちょ
うど entity-number を逆にしたリストで、entity-number 1.2.3 に対応する
node-id は (3 2 1) です。
前述のように、MIME message は entity を単位とした木構造になっているので、
この根である message 全体も mime-entity で表現することができ、buffer
local 変数 mime-message-structure に格納することにします。
そして、entity-number や node-id を用いることで
mime-message-structure における entity の相対的な位置関係を
扱うことができます。
Function: mime-open-entity &optional type location
Open an entity and return it.
type is representation-type. (cf. section Entity の表現と実現)
location is location of entity. Specification of it is depended on representation-type.
Function: mime-parse-buffer &optional buffer type
buffer を message として構文解析し、その結果の mime-entity を
buffer のmime-message-structure に格納する。
buffer が省略された場合、現在の buffer を構文解析する。
type が指定された場合、その値を生成される mime-entity の表象型とし て用いる。省略された場合は buffer となる。(cf. section Entity の表現と実現)
Variable: mime-message-structure
現在の buffer における message 全体の mime-entity 構造体を格納するbuffer local 変数。
Function: mime-entity-children entity
entity に含まれる entity の list を返す。
Function: mime-entity-parent entity &optional message
entity の親の entity を返す。
message が指定された場合、これを根と見倣す。
Function: mime-root-entity-p entity
entity が根（即ち、message 全体）である場合に、非-nil を返
す。
Function: mime-entity-node-id entity
entity の node-id を返す。
Function: mime-entity-number entity
entity の entity-number を返す。
Function: mime-find-entity-from-number entity-number &optional message
Return entity from entity-number in message.
If message is not specified, mime-message-structure is
used.
Function: mime-find-entity-from-node-id entity-node-id &optional message
Return entity from entity-node-id in message.
If message is not specified, mime-message-structure is
used.
Function: mime-entity-content-type entity
entity の content-type を返す。(cf. section mime-content-type 構造体)
Function: mime-entity-content-disposition entity
entity の content-disposition を返す。 (cf. section mime-content-disposition 構造体)
Function: mime-entity-filename entity
entity の file 名を返す。
Function: mime-entity-encoding entity &optional default-encoding
entity の content-transfer-encoding を返す。 (cf. section 符号化法)
もし、entity に Content-Transfer-Encoding 欄が存在しない場合は、
default-encoding を返す。これが指定されない場合は、"7bit"
を用いる。
Function: mime-entity-cooked-p entity
Return non-nil if contents of entity has been already code-converted.
Function: mime-fetch-field field-name &optional entity
entity の header 中の field-name 欄の body を返す。
結果の文字列は network 表現のままである。
entity が省略された場合は、mime-message-structure の値を用
いる。
field-name 欄が存在しない場合は nil を返す。
Function: mime-read-field field-name &optional entity
entity の header 中の field-name 欄を構文解析した結果を返す。
結果の形式は欄毎に異なる。非構造化欄の場合は文字列を返し、構造化欄の場合 はその形式に従った list を返す。
結果中の文字列は Emacs の内部表現に変換される。
entity が省略された場合は、mime-message-structure の値を用
いる。
field-name 欄が存在しない場合は nil を返す。
Function: mime-insert-decoded-header entity &optional invisible-fields visible-fields
現在位置に entity の復号した header を挿入する。
invisible-fields と visible-fields は正規表現のlist で、それ ぞれ、表示したくない field 名と表示したい欄名を表現したものである。
invisible-fields の要素のどれかに match し、かつ、 visible-fields の要素のどれにも match しない欄は表示されない。
Function: mime-entity-content entity
entity の内容の byte 列を返す。
Function: mime-write-entity-content entity filename
Write content of entity into filename.
Function: mime-write-entity entity filename
Write representation of entity into filename.
Function: mime-write-entity-body entity filename
Write body of entity into filename.
Function: mime-entity-buffer entity
entity が存在する buffer を返す。
Function: mime-entity-point-min entity
entity が存在する buffer における、entity が占める領域の先頭 位置を返す。
Function: mime-entity-point-max entity
entity が存在する buffer における、entity が占める領域の末尾 位置を返す。
Function: mime-entity-header-start entity
entity が存在する buffer における、header が占める領域の先頭位置を 返す。
Function: mime-entity-header-end entity
entity が存在する buffer における、header が占める領域の末尾位置を 返す。
Function: mime-entity-body-start entity
entity が存在する buffer における、body が占める領域の先頭位置を返 す。
Function: mime-entity-body-end entity
entity が存在する buffer における、body が占める領域の末尾位置を返 す。
Entity は抽象化されたデータ表現で、実際のデータ表現としては用途に応じて さまざまなものが利用できるように設計されています。
ここで、entity がどういう種類の表現を行っているかを示すのが representation-type で、entity を生成する時にはこれを指定します。 (cf. @xref{Entity Creation})
前節までに述べて来た entity に対する処理は、entity に対してその処理を依 頼することによって実現されています。Entity は自分の representation-type を知っており、その representation-type に応じて実際の処理を行う関数を呼 び出します。このような関数を entity 処理method と呼びます。また、 representation-type 毎にこのような関数をまとめたものを mm-backend と呼びます。
mm-backend は representation-type の名前の先頭に mm という
接頭辞を付けた関数名からなる module で、その module 名は同様に
representation-type の名前の先頭に mm を付けたものになって
います。この module は representation-type の entity が最初に生成される
時に自動的に require されます。
Function: mime-entity-send entity message &rest args
entity に message を送る。
args は message の引数である。
（すみません。そのうち書きます (^_^;）
（とりあえず、mm*.el を参考にしてください）
Content-Type 欄 は media-type (section media-type) や MIME charset といった entity (@xref{entity}) の内容の種類や表現形式などを記述 するためのもので、RFC 2045 (section RFC 2045) で定義されています。
[Memo]
歴史的には RFC 1049 で Content-Type 欄が提案されている。但し、MIME の media-type のような type と subtype の区別はなく、MIME charset のような 文字符号の種類を表現することもできない。
FLIM は Content-Type 欄を構文解析する関数と Content-Type 欄の解析結果を 格納する構造体 mime-content-type を提供します。
Content-Type 欄の形式は以下のように定義されています：
"Content-Type" ":" type "/" subtype *( ";" parameter )
例えば、
Content-Type: image/jpeg
や
Content-Type: text/plain; charset=iso-2022-jp
などのように用いられます。
ここで、`type' と `subtype' は entity の形式を示すもので、両者を総称し て、`media-type' と呼ぶことにします。上記の例における `image/jpeg' や `text/plain' は media-type の１つです。
[Memo]
Content-Type 欄のない entity は
Content-Type: text/plain; charset=us-asciiとして解釈される。(cf. section us-ascii)
@deffn{Structure}: mime-content-type
Content-Type 欄の情報を格納するための構造体。
この構造体を参照するには mime-content-type-要素名 という名前の参
照関数を用いる。
この構造体の要素は以下の通りである：
Function: make-mime-content-type type subtype
&optional parameters
content-type の生成子。
Function: mime-content-type-parameter content-type parameter
content-type の parameter の値を返す。
Function: mime-parse-Content-Type string
string を content-type として解析した結果を返す。
Function: mime-read-Content-Type
現在の buffer の Content-Type 欄を読み取り、解析した結果を返す。
Content-Type 欄が存在しない場合は nil を返す。
Function: mime-type/subtype-string type &optional subtype
type と subtype から type/subtype 形式の文字列を返す。
Content-Disposition 欄 は entity の表示や file 名など の属性になどに関する情報を記述するためのものです。
[RFC 2183]
S. Dorner, K. Moore and R. Troost, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", August 1997, Standards Track.
FLIM は Content-Disposition 欄を構文解析する関数と Content-Disposition 欄の解析結果を格納する構造体 mime-content-disposition を提供します。
@deffn{Structure}: mime-content-disposition
Content-Disposition 欄の解析結果を収めるための構造体。
この構造体を参照するには mime-content-disposition-要素名 という名
前の参照関数を用いる。
この構造体の要素は以下の通りである：
Function: mime-content-disposition-parameter content-disposition parameter
content-disposition の parameter の値を返す。
Function: mime-content-disposition-filename content-disposition
content-disposition の filename の値を返す。
Function: mime-parse-Content-Disposition string
string を content-disposition として解析した結果を返す。
Function: mime-read-Content-Disposition
現在の buffer の Content-Disposition 欄を読み取り、解析した結果を返す。
Content-Disposition 欄が存在しない場合は nil を返す。
Content-Transfer-Encoding 欄 は entity の符号化法を記述するため のものです。
FLIM では Content-Transfer-Encoding 欄を構文解析する関数を提供します。こ れらの関数は Content-Transfer-Encoding 欄の情報は文字列で表現します。
また、Content-Transfer-Encoding に基づいて符号化・復号化を行う関数も提 供されます。
Function: mime-parse-Content-Transfer-Encoding string
string を content-transfer-encoding として解析した結果を返す。
Function: mime-read-Content-Transfer-Encoding &optional default-encoding
現在の buffer の Content-Transfer-Encoding 欄を読み取り、解析した結果を 返す。
Content-Transfer-Encoding 欄が存在しない場合はdefault-encoding を 返す。
Function: mime-encode-region start end encoding
Encode region start to end of current buffer using encoding.
Function: mime-decode-region start end encoding
Decode region start to end of current buffer using encoding.
Variable: mime-encoding-method-alist
Alist of encoding vs. corresponding method to encode region.
Each element looks like (STRING . FUNCTION) or (STRING
. nil). string is content-transfer-encoding. function is
region encoder and nil means not to encode.
Variable: mime-decoding-method-alist
Alist of encoding vs. corresponding method to decode region.
Each element looks like (STRING . FUNCTION) or (STRING
. nil). string is content-transfer-encoding. function is
region decoder and nil means not to decode.
Function: mime-decode-string string encoding
string を encoding として復号した結果を返します。
Variable: mime-string-decoding-method-alist
Alist of encoding vs. corresponding method to decode string.
Each element looks like (STRING . FUNCTION). STRING is
content-transfer-encoding. FUNCTION is string decoder.
Function: mime-insert-encoded-file filename encoding
Insert file FILENAME encoded by ENCODING format.
Function: mime-write-decoded-region start end filename encoding
Decode and write current region encoded by encoding into filename.
start and end are buffer positions.
Variable: mime-file-encoding-method-alist
Alist of encoding vs. corresponding method to insert encoded file.
Each element looks like (STRING . FUNCTION). STRING is
content-transfer-encoding. FUNCTION is function to insert encoded file.
Variable: mime-file-decoding-method-alist
Alist of encoding vs. corresponding method to write decoded region to file.
Each element looks like (STRING . FUNCTION). STRING is
content-transfer-encoding. FUNCTION is function to write decoded region
to file.
encoded-word は header で非 ASCII (section ASCII) 文字を表現するための形式 で、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).
また、行儀の悪いことだと言えますが、encoded-word を用いずに非 ASCII (section ASCII) 文字を header に入れた記事も存在します。
FLIM はこれらを符号化・復号化する機能を提供します。
Function: eword-encode-header &optional code-conversion separator
Decode MIME encoded-words in header fields.
If code-conversion is nil, it decodes only encoded-words.
If it is mime-charset, it decodes non-ASCII bit patterns as the
mime-charset. Otherwise it decodes non-ASCII bit patterns as the
default-mime-charset.
If separator is not nil, it is used as header separator.
Function: eword-encode-header &optional code-conversion
Encode header fields to network representation, such as MIME encoded-word.
It refer variable eword-field-encoding-method-alist.
MIME 関連機能に関する group.
mail と news に属する。
Variable: default-mime-charset
適切な MIME charset (section MIME charset) が見つからなかった場合に用いら れるMIME charset.
本来は APEL の変数である。
MIME 機能に関する実装が一時的に使用する file を作成する directory.
環境変数 MIME_TMP_DIR, TM_TMP_DIR, TMPDIR,
TMP もしくは TEMP が設定されていた場合、それを初期値として
用いる。何も設定されていない場合、"/tmp/" を用いる。
ここでは 0 から 127 の整数を指す。
0 から 127 の整数の列で表現できるような data を "7bit の data" と呼ぶ。
また、0 から 31 および 127 で表現される制御文字と 32 で表現される空白と 33 から 126 で表現される図形文字からなる文字列のことを "7bit の文字列" と呼ぶ（これは ISO 2022 (@xref{ISO 2022}) の「7 単位系」と同様）。
伝統的な Internet の MTA (section MTA) は 7bit の data を転送できるので、 7bit の data は Quoted-Printable (section Quoted-Printable) や Base64 (section Base64) といった変換を行わなくてもそのまま転送できる。
しかし、7bit であればどんな data でも良いとはいえない。なぜなら、１行の 長さがあまりに長いと、MTA はその message を転送することができないからで ある。ちなみに、RFC 821 (@xref{RFC 821}) は１行は改行文字を除いて 998 byte 以内であることを求めている。よって、これ以上の行が含まれる可能性の ある data, 例えば、Postscript の data などは Quoted-Printable 等で encodeする必用がある。
ここでは 0 から 255 の整数を指す。
0 から 255 の整数の列で表現できるような data を "8bit の data" と呼ぶ。
また、0 から 31, 127 および 128 から 159 で表現される制御文字と 32 で表 現される空白と 33 から 126 と 160 から 255 で表現される図形文字からなる 文字列のことを "8bit の文字列" と呼ぶ（これは ISO 2022 (@xref{ISO 2022}) の「8 単位系」と同様）。
iso-8859-1 (@xref{iso-8859-1}) や euc-kr (@xref{euc-kr}) といった符号化文 字集合は 8bit の文字列である。
伝統的な Internet の MTA (section MTA) は 7bit (section 7bit) の data しか転 送できないので、そうした MTA を経由する場合、Quoted-Printable (section Quoted-Printable) や Base64 (section Base64) といった変換を行わなく てはならない。
しかし、最近では 8bit の文字列をそのまま通すことができる MTA も登場して きたので、そのまま送ることができる場合も増えてきた。
しかし、8bit であればどんな data でも良いとはいえない。なぜなら、１行の 長さがあまりに長いと、MTA はその message を転送することができないからで ある。ちなみに、RFC 821 (@xref{RFC 821}) は１行は改行文字を除いて 998 byte 以内であることを求めている。よって、これ以上の行が含まれる可能性の ある data, 例えば、Postscript の data などは Quoted-Printable 等で encodeする必用がある。
また、こうした理由から、１行が 999 byte 以上の行が存在する可能性のある data は binary (section binary) と呼ぶことにする。
ちなみに、7bit で表現できる data は 8bit でも表現できる。よって、 "8bit" と言った場合、１行が 998 byte 以下の任意の data を指すことが ある。
アメリカ連邦で使われる文字を符号化した符号化文字集合 (@xref{符号化文字集 合})。A-Z, a-z の Latin 文字と数字、幾つかの記号からなる。ISO 646 の一つ で、現在は国際基準版 (IRV) になっている。
[ASCII]
"Coded Character Set -- 7-Bit American Standard Code for Information Interchange", ANSI X3.4:1986.
RFC 2045 (section RFC 2045) で定義されている MIME (section MIME) における binary data (section binary) の network での変換法の１つ。
『64 進数』という意味で、3 byte の data を 0 から 63 の数を表す ASCII (section ASCII) 4 文字に変換する方法。（もし、4 文字にならなければ pad と呼ばれる詰め物をして長さを調整する）
この 65 種類の文字は ASCII と EBCDIC の共通部分から選ばれており、 Internet 以外の network を経由する場合でも安全に転送できるように設計さ れている。
任意の byte 列を binary と呼ぶ。
8bit (section 8bit) と異なるのは data に行の構造を仮定しないことである。
また、行の構造があっても、999 byte 以上からなる行がある場合も binary と 呼ぶことにする。
ちなみに、7bit (section 7bit) や 8bit で表現できる data は binary でも表現 できる。よって、binary data と言った場合、任意の data を指すこ とがある。
文字と byte 列と１対１に対応付ける曖昧でない規則の集合。
MIME (section MIME) における entity (@xref{entity}) の種類。 primary-type と subtype からなる。RFC 2046 (section RFC 2046) で定義されている。
primary-type は標準では
が定義され、それぞれには application/octet-stream, audio/basic, image/jpeg, multipart/mixed (@xref{multipart/mixed}), text/plain (@xref{text/plain}), video/mpeg などのさまざまな subtype が定義されている。
[注意]
ここでは、text/plain などの type/subtype の組をしばしば primary-type/subtype と書く。
media-type は、RFC 2046 で定義されているものに加えて、登録することもでき る。現在、登録されているものは MEDIA TYPES (ftp://ftp.isi.edu/in-notes/iana/assignments/media-types) で参照できる。
また、type もしくは subtype に、前に `x-' を付けた x-token を用 いることにより、登録されていないものを私的に用いることもできる。しかし、 当然のことながら、こうした私的な media-type は諒解を得た者の間でしか解釈 できないので利用には注意すること。
(cf. section Content-Type 欄の情報)
ここでは mail と news 記事の総称として用いる。
Multipurpose Internet Mail Extensions の略で、Internet の mail や news で us-ascii plain text (section us-ascii) 以外の文字を使うための RFC 822 (section RFC 822) に対する拡張。
RFC 2045 は冒頭で次のように述べている：
STD 11, RFC 822 は、US-ASCII message header に関して非常に詳細に規定し た message 表現 protocol を定義している。しかし、それは単に flat な US-ASCII text のみに留まり、message の内容や message body に関する規定 はなされていない。Multipurpose Internet Mail Extensions, あるいは MIME と総称される、この一連の文書は、以下の事を可能とするために message の 形式を再定義した：
RFC 2045 (section RFC 2045), RFC 2046 (section RFC 2046), RFC 2047 (section Header の network 表現), RFC 2048 (section RFC 2048), RFC 2049 (section RFC 2049) で定義されている。
Content-Type (section Content-Type 欄の情報) 欄や encoded-word (section Header の network 表現) の charset parameter で用いられる登録された符号化文字集合(section Coded character set（符号化文字集合）, Character code（文字符号）)。
RFC 2045 (section RFC 2045) で定義されている。
iso-2022-jp や euc-kr はその１つ。
Message Transfer Agent の略で、qmail や sendmail などの mail 配 送 program と inn などの news server の総称。
(cf. section MUA)
Message User Agent の略で、mail reader と news reader の総称。
(cf. section MTA)
RFC 2045 (section RFC 2045) で定義されている MIME (section MIME) における binary data (@xref{binary data}) の network での変換法の１つ。
`=' や制御文字や 128 以上の文字などは `=AF' のように `=' の後に続く 16 進数で表現する。このため、ASCII (section ASCII) 文字中心の data では Base64 (section Base64) に比べると可読性が高くなる可能性がある。
しかしながら、EBCDIC には存在しない文字を利用する場合、EBCDIC を利用し ている network では安全に転送することができず、Base64 に比べて安全性は 低い。
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.
USENET での message の形式を定めた RFC. RFC 822 (section 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 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]
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]
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]
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).
書体や組版に関する情報を持たない文字符号(section Coded character set（符号化文字集合）, Character code（文字符号）)のみ で表現される text 情報。(cf. @xref{text/plain})
アメリカ連邦などで使われる英語などを表現するための MIME charset (section MIME charset) の１つ。
ASCII (section ASCII) のみからなり ISO 2022 による符号拡張は許されない。
Internet message における標準の符号化文字集合(section Coded character set（符号化文字集合）, Character code（文字符号）) であり、明示的に MIME charset が示されない場合は原則として us-ascii が使われる。
また、RFC 822 (section RFC 822) における ASCII は us-ascii である。
FLIM のバグを見つけたら、以下の address に mail を送ってください：
但し、あまりにも古い版に関する報告は歓迎されません。古い版の bug は、新 しい版では治っているかもしれません。まず、最新版で確認してみましょう。
それから、適切な報告をしましょう。単に「うまく動かない」と言われてもどう いう状況なのかはさっぱり判りません。最低限、OS, emacs, APEL, FLIM, SEMI, 使っている MUA の種類および版、設定を書く必要があります。また、error が 起っている場合は backtrace を送ることも重要です。(cf. @xref{(emacs)Bugs})
また、bug は大抵複数の人が遭遇するものです（そうでなければ、bug ではな い可能性があります）。だから、作者に直接 mail を送ると作者は同じ mail を何通も書く羽目になります。だから、必ず bug 報告は上記の address に送っ てください。
tm ML では FLIM のバグ情報の交換や最新版の配布、FLIM の改良に関する議 論を行なっています。tm ML に参加したい方は
に空の mail を送って下さい。
FLIM の file は CVS を使って管理されています。このため、以下の方法で最 新の FLIM を入手することができます：
(0) cvs login
% cvs -d :pserver:anonymous@chamonix.jaist.ac.jp:/hare/cvs/root \
login
CVS password: [CR] # NULL string
(1) checkout
% cvs -d :pserver:anonymous@chamonix.jaist.ac.jp:/hare/cvs/root \
checkout [-r TAG] flim
CVS を用いた開発に参加したい方は
まで、account 名と UNIX の passwd と同じ形式の crypt 化された password を沿えて御連絡ください。
FLIM の code の最古の部分は 榎並 嗣智 氏が書いた `mime.el'に起源し ます。この小さな program は Nemacs で動作する iso-2022-jp の B-encoding 専用の encoded-word の復号化プログラムでした。
その後、守岡 知彦 は `mime.el' を元に`tiny-mime.el' というプロ グラムを書きます。これは、Nemacs と Mule で動作する encoded-word の符号 化・復号化プログラムでした。`tiny-mime.el' は B-encoding だけでなく Q-encoding もsupport し、また、MULE で扱うことができるさまざまな MIME charset (section MIME charset) を同時に使うことができました。この時、 Nemacs と Mule の双方を support するために用いられたテクニックは後に emu package にまとめられます。
この頃、守岡 知彦 は `tiny-mime.el' をさまざまな MUA で使うための設 定集も配布していましたが、それらは後に`tiny-mime.el' とともに１つの package にまとめられ、tm という名前で配布されます。
守岡 知彦 はやがて、MIME message を閲覧するためのプログラムである `tm-body.el' を書きます。これは、すぐに`tm-view.el' という名前 に変わりましたが、やがて、これが`tiny-mime.el' に代わって、tm の中 核となります。
`tm-view.el' は当然、Content-Transfer-Encoding を扱う必要があります。 この目的のために、MEL が整備されはじめました。Base64 に関しては `tiny-mime.el' の code が移され、また、新たにQuoted-Printable の code が追加されました。これらが`mel-b.el' と `mel-q.el' になり ました。
また、後に、守岡 知彦 によって uuencode 用の `mel-u.el' が追加され、 その後に、小林 修平 氏によって x-gzip64 用の`mel-g.el' が追加されま した。
tm では後に、守岡 知彦 によって `tiny-mime.el' の再実装が行われ、こ の過程で、STD 11 の parser が書かれました。これは、現在の `std11.el' に当たります。また、この過程で `tiny-mime.el' は復 号化を行う `tm-ew-d.el' と符号化を行う `tm-ew-e.el' に分けられ ました。この両者が現在の `eword-decode.el' と `eword-encode.el' の先祖に当たります。
後に、守岡 知彦 らによって tm の全面書き換え作業が行われ、この過程で、tm は APEL, MEL, SEMI, EMH, RMAIL-MIME, Gnus-MIME などに分けられました。こ のうちの MEL が FLIM の直接の先祖に当たります。
後に、APEL から `std11.el' が移され、また、`mailcap.el', `eword-decode.el' および `eword-encode.el' が SEMI から移され、 package の名前が FLIMとなります。
この直前から田中 哲 氏がより RFC に忠実な実装を書き始め、これは、現在、 FLIM の枝である "FLIM-FLAM" となっています。