序文

この標準情報(TR)は，1996年11月にInternat Engineering Task Force (IETF)から公表されたRFC 2046 "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples"を翻訳し，技術的内容を変更することなく作成した標準情報(TR)である。

1. 導入

1.1 適用範囲

インターネット公式プロトコル規定STD 11であるRFC 822では，US-ASCIIメッセージヘッダについて多くの詳細を規定したメッセージ表現プロトコルを定義しているが，メッセージ内容又はメッセージ本体については構造のないUS-ASCIIテキストのままにしている。この一連の文書は，多目的インターネットメール拡張又はMIMEと総称され，次のことを可能とするために，メッセージのフォーマットを再定義している。

1. US-ASCII以外の文字集合でのテキストのメッセージ本体
2. 非テキストのメッセージ本体のための，種々のフォーマットの拡張集合
3. マルチパートメッセージ本体
4. US-ASCII以外の文字集合でのテキストのヘッダ情報

MIMEを規定する一連の標準情報(TR)は，RFC 934，STD 11及びRFC 1049に文書化されている初期の成果に基づくが，それらを拡張及び改訂する。RFC 822では，メッセージ本体についてはごくわずかに示しているだけなので，これらの標準情報(TR)の大部分は，RFC 822の改訂というよりは，RFC 822を補うものである。

これら一連の標準情報(TR)の最初であって，RFC 2045を原規定とするTR X 0069では，MIMEメッセージの構造を記述するために使用される多くのヘッダを規定する。2番目のRFC 2046を原規定とするTR X 0070では，MIMEメディア型付けシステムの一般的構造を定義し，メディア型の初期集合を定義する。3番目のRFC 2047を原規定とするTR X 0071では，非US-ASCIIでのインターネットメールヘッダフィールドの中で非US-ASCIIデータを可能にするためのRFC 822の拡張について記述する。4番目のRFC 2048を原規定とする標準情報(TR)では，MIME関連機能のための多くのIANA登録手続きについて規定する。最後の5番目のRFC 2049を原規定とするこの標準情報(TR)では，MIME適合基準について記述し，それと共に，幾つかのMIMEメッセージフォーマットの例示，謝辞及び参考文献を提供する。

RFC 2045, RFC 2046, RFC 2047, RFC 2048及びRFC 2049は，RFC 1521, RFC 1522及びRFC 1590の改訂であって，RFC 1521, RFC 1522及びRFC 1590はRFC 1341及びRFC 1342の改訂であった。附属書Bに，過去の版との違い及び変更を示す。

1.2 概要

MIME関連の一連の規定のうち、１番目のTR X 0069及び２番目のTR X 0070は、MIMEヘッダフィールド及びMIMEメディア型の初期の集合を定義する。３番目のTR X 0071は、US-ASCII以外の文字集合を許容するために、RFC 822フォーマットの拡張について規定する。この規定は、MIME適合実装がサポートしなければならない事項を規定する。また、近代のメッセージングシステムのたくさんの落とし穴、及び、MIMEが基づいている正準符号化モデルについても記述する。

2. MIME適合性

MIME関連の規定で記述される機構は，拡張可能である。 全ての実装が全ての可能なメディア型をサポートすることも，それらが同じ拡張を有することも，全く期待されない。 しかし，相互運用性を推進するため，US-ASCIIテキストと異なる内容でのメッセージの有用な交換を許容する、実装の一定水準を定義するものである"MIME適合性"の概念を定義することは有用である。 この箇条では，これらの適合性のための要求を規定する。

MIMEに適合するメール利用者エージェントは，次を満たさなければならない。

1. 作成する全てのメッセージにいつでも"MIME-Version: 1.0"ヘッダフィールドを生成する。
(1) Always generate a "MIME-Version: 1.0" header field in any message it creates.
2. Content-Transfer-Encodingヘッダフィールドを認識し，quoted-printable実装又はbase64実装により符号化された全ての受信データを復号する。 7ビット，8ビット及び2値の同一変換を認識しなければならない。 (2) Recognize the Content-Transfer-Encoding header field and decode all received data encoded by either quoted- printable or base64 implementations. The identity transformations 7bit, 8bit, and binary must also be recognized.
   符号化せずに送られたすべての非7ビットデータは、8ビット又は2値のcontent-transfer-encodingとして適切にラベル付けされなければならない。 下にある転送が、8ビット又は2値をサポートしない場合（例えばSMTP [RFC-821]はサポートしない）、送信者は、quoted-printable又はbase64などの適切な内容転送符号化を用いて、符号化及びラベル付けの両方を行うことが要求される。
Any non-7bit data that is sent without encoding must be properly labelled with a content-transfer-encoding of 8bit or binary, as appropriate. If the underlying transport does not support 8bit or binary (as SMTP [RFC-821] does not), the sender is required to both encode and label data using an appropriate Content- Transfer-Encoding such as quoted-printable or base64.
3. 認識できないContent-Transfer-Encodingは、実際のContent-Typeが認識されるかどうかにはかかわらず、すべて"application/octet-stream"のContent-Typeだったものとして扱わなくてはならない。
(3) Must treat any unrecognized Content-Transfer-Encoding as if it had a Content-Type of "application/octet- stream", regardless of whether or not the actual Content-Type is recognized.
4. Content-Typeヘッダフィールドを認識及び解釈しなければならず、text以外のContent-Typeフィールドの生データを利用者に見せてはならない。 実装は、少なくともtext/plainメッセージを、それがUS-ASCIIでない場合にはcharsetパラメタで指定する文字集合で、送ることができなくてはならい。
(4) Recognize and interpret the Content-Type header field, and avoid showing users raw data with a Content-Type field other than text. Implementations must be able to send at least text/plain messages, with the character set specified with the charset parameter if it is not US-ASCII.
5. 認識できない名前の内容型パラメタは無視する。
(5) Ignore any content type parameters whose names they do not recognize.
6. 次のメディア型値を、少なくとも次の範囲で、明示的に扱う。 (6) Explicitly handle the following media type values, to at least the following extents:
   Text:
   • "text"のメールを文字集合"US-ASCII"と認識し表示する。
   • メッセージが使う文字集合が何であるかについて利用者に知らせることが可能な範囲へ、少なくとも他の文字集合を認識する。
   • ISO-8859-*及びUS-ASCIIに共通の文字を表示できる範囲、特にオクテット値1から127までで表現される全ての文字において、"ISO-8859-*"文字集合を認識する。
   • 既知の文字集合の認識できない下位型のため、正準形式から局所形式に内容を変換した後の" 生"の版を利用者に見せるか又は見せることを申し出る。
   • 未知の文字集合の素材を"application/octet-stream"であるかのように扱う。
   Text: -- Recognize and display "text" mail with the character set "US-ASCII." -- Recognize other character sets at least to the extent of being able to inform the user about what character set the message uses. -- Recognize the "ISO-8859-*" character sets to the extent of being able to display those characters that are common to ISO-8859-* and US-ASCII, namely all characters represented by octet values 1-127. -- For unrecognized subtypes in a known character set, show or offer to show the user the "raw" version of the data after conversion of the content from canonical form to local form. -- Treat material in an unknown character set as if it were "application/octet-stream".
   Image，audio及びvideo:
   • 最低限、全ての認識できない下位型を"application/octet-stream"であるかのように扱う機能を提供すること。
   Image, audio, and video: -- At a minumum provide facilities to treat any unrecognized subtypes as if they were "application/octet-stream".
   Application:
   • この規定で定義されるquoted-printable符号化又はbase64符号化が、使われるか又は結果の情報が利用者のファイルに置かれる場合、それを取り除く能力を提示する。
   Application: -- Offer the ability to remove either of the quoted- printable or base64 encodings defined in this document if they were used and put the resulting information in a user file.
   Multipart:
   • 複数が混在した下位型を認識する。 メッセージレベル及び本体部分ヘッダレベルの全ての関連する情報を表示し、そして、それぞれの本体部分を独立に見せるか又は見せることを申し出る。
   • "alternative"下位型を認識し、multipart/alternativeのメールの冗長な部分を利用者に見せることを避ける。
   • 特に、"umultipart/digest"実体の内部の本体部分のデフォルトのメディア型として、"text/plain"ではなく"message/rfc822"を使って、"multipart/digest"下位型を認識する。
   • 全ての認識できない下位型を"mixed"であるかのように扱う。
   Multipart: -- Recognize the mixed subtype. Display all relevant information on the message level and the body part header level and then display or offer to display each of the body parts individually. -- Recognize the "alternative" subtype, and avoid showing the user redundant parts of multipart/alternative mail. -- Recognize the "multipart/digest" subtype, specifically using "message/rfc822" rather than "text/plain" as the default media type for body parts inside "multipart/digest" entities. -- Treat any unrecognized subtypes as if they were "mixed".
   Message:
   • 少なくともRFC 822メッセージカプセル化（message/rfc822)を、すべての再帰構造を保持している方法で認識し表示する。すなわち、このメディア型に従うデータを、表示するか又は表示することを申し出る。
   • どんな認識できない下位型も"application/octet-stream"であるかのように扱う。
   Message: -- Recognize and display at least the RFC822 message encapsulation (message/rfc822) in such a way as to preserve any recursive structure, that is, displaying or offering to display the encapsulated data in accordance with its media type. -- Treat any unrecognized subtypes as if they were "application/octet-stream".
7. 認識できないどんなContent-Typeフィールドに遭遇したときでも、 実装は、パラメタなしの"application/octet-stream"のメディア型であるかのように扱わなければならない。 このようなデータをどう処理するかは実装にゆだねられるが、このような認識できないデータを処理する適当な選択肢は、メール転送フォーマットから復号してファイルに書き込むことを利用者に提供するか、又は、復号データを入力として渡すプログラムの名前を利用者が指定することを申し出ることを含む
(7) Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of "application/octet-stream" with no parameter sub-arguments. How such data are handled is up to an implementation, but likely options for handling such unrecognized data include offering the user to write it into a file (decoded from its mail transport format) or offering the user to name a program to which the decoded data should be passed as input.
8. US-ASCII以外の文字集合を用いる非MIMEメッセージに対して非標準のサポートを提供する場合、 受け取ったメッセージにだけそのようにすることが、適合する利用者エージェントに要求される。 適合する利用者エージェントは、US-ASCIIテキスト以外を含む非MIMEメッセージを送ってはならない。
(8) Conformant user agents are required, if they provide non-standard support for non-MIME messages employing character sets other than US-ASCII, to do so on received messages only. Conforming user agents must not send non-MIME messages containing anything other than US-ASCII text.
特に、MIME-Versionフィールドなしのメールメッセージにおける非US-ASCIIテキストの使用は、異なるローカリゼーション変換の領域間でメッセージを送るときに相互運用性をじゃまするので、強く非推奨とする。 適合する利用者エージェントは、US-ASCII文字集合中、プレーンテキスト以外を送るとき、正しいMIMEラベル付けを含まなくてはならない。 In particular, the use of non-US-ASCII text in mail messages without a MIME-Version field is strongly discouraged as it impedes interoperability when sending messages between regions with different localization conventions. Conforming user agents MUST include proper MIME labelling when sending anything other than plain text in the US-ASCII character set.
さらに、非MIME利用者エージェントは、MIME中の何もサポートしないとしても、送ったメッセージ中適当なMIMEヘッダ情報を含むことが全て可能なように更新されたほうがよい。 この更新は、ほんの少しであり、もしあれば、非MIME受信者に影響すること及びこのようなメッセージを正しく表示するMIMEを援助する。 これは、他のMIME機能を結局採用することへの滑らかな移行も提供する。 In addition, non-MIME user agents should be upgraded if at all possible to include appropriate MIME header information in the messages they send even if nothing else in MIME is supported. This upgrade will have little, if any, effect on non-MIME recipients and will aid MIME in correctly displaying such messages. It also provides a smooth transition path to eventual adoption of other MIME capabilities.
9. 適合する利用者エージェントは、"=?"で始まり"?="で終わる"*text"又は"*ctext"中の非空白の印字可能なUS-ASCII文字の列が正当な符号語であることを保証しなければならない。 ことで"始まる"とは、フィールド本体の始まりか又は線形空白の直後を意味し、"終わる"とは、フィールド本体の終わりか又は線形空白の直前を意味する。 さらに、"=?"で始まり"?="で終わる"phrase"中の任意の"waord"は、正当な符号語でなければならない。
(9) Conforming user agents must ensure that any string of non-white-space printable US-ASCII characters within a "*text" or "*ctext" that begins with "=?" and ends with "?=" be a valid encoded-word. ("begins" means: At the start of the field-body or immediately following linear-white-space; "ends" means: At the end of the field-body or immediately preceding linear-white- space.) In addition, any "word" within a "phrase" that begins with "=?" and ends with "?=" must be a valid encoded-word.
10. 適合する利用者エージェントは、"text"、"ctext"又は"word"から符号語を、それらがメッセージヘッダ中の正しい位置に現れたならばいつでも、4.に規定する規則に従って区別できなければならない。 サポートする全ての文字集合に対して、"B"符号化及び"Q"符号化の両方をサポートしなければならない。 プログラムは、文字集合が"US-ASCII"ならば復号される敵外を表示できなければならない。 ISO-8859-*文字集合に対しては、メール読みプログラムは、US-ASCII集合にも含まれる文字は、少なくとも表示できなくてはならない。
(10) Conforming user agents must be able to distinguish encoded-words from "text", "ctext", or "word"s, according to the rules in section 4, anytime they appear in appropriate places in message headers. It must support both the "B" and "Q" encodings for any character set which it supports. The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the US-ASCII set.

上記の条件に合致する利用者エージェントは、MIME適合といえるものとする。 この句の意味は、このようなメールシステムの利用者が、適切に印付けされたどんな種類のデータも実質的に"安全に"送ることができることを想定する。なぜならば、このようなシステムは、少なくともデータを識別されない2値として扱うことができ、疑わない利用者の画面に単に出してしまわないからである。

RFC 821及びRFC 822に適合するどんな既知のシステムによっても、そのようなデータを壊さない又は壊されないという、MIME適合のフォーマットでデータを送ることができるもう一つの"安全"がある。 MIME適合の利用者エージェントは、利用者がテキストとして見られることを決して想定しないデータを見せられないという、追加の保証をもつ。

3. 電子メールデータ送信のガイドライン

インターネットメールは、完全で一様なシステムではない。 メールは、最終目的地へ伝送の途中、多くの段階で、壊れてしまう場合がある。 特に、インターネットを通って送られた電子メールは、多くのネットワーク技術を伝わっていく場合がある。 多くのネットワーク及びメール技術は、SMTP転送環境において可能なすべての機能は、サポートしない。 これらのシステムでのメールの横断は、転送を可能にするために、修正されそうである。

インターネットには多くの非適合MTAが配置されている。 これらのSMTPプロトコルを話すMTAは、それが実装されているホストの内部データ構造に有利なようにメッセージを改変するか、または、単に壊れている。

次の指針は、広範なネットワーク技術及び既知の壊れたMTAで無傷で生き残れることを想定したデータフォーマット（メディア型）を工夫する人に有用かもしれない。 base64符号化により符号化されたものは、これらの規則を満たすが、特にUNIXのuuencode機能のようなよく知られた機能は満たさないことに注意すること。 Quoted-Printable符号化で符号化されたものは、大部分のゲートウェイで生き残るが、EBCDIC文字集合を使うシステムへのいくつかのゲートウェイではだめな可能性がある。

1. いくつかの状況では、通常のゲートウェイの一部か又は利用者エージェント操作として、データに使われる符号化を変更してよい。 特に、base64からquted-printableへの変換、又はその逆の変換が必要であるかもしれない。 これは、テキスト本体中の行区切りでCRLF列の混乱がおきるかもしれない。 このようにして、改行以外の何かとしての、CRLFの永続性は信頼してはならない。
(1) Under some circumstances the encoding used for data may change as part of normal gateway or user agent operation. In particular, conversion from base64 to quoted-printable and vice versa may be necessary. This may result in the confusion of CRLF sequences with line breaks in text bodies. As such, the persistence of CRLF as something other than a line break must not be relied on.
2. 多くのシステムは、ローカルな改行変換を使って、テキストデータを表示し、保存することを選択してよい。 CRだけ、LFだけ、CRLF、又は数えたレコードを使うことが知られるローカルな改行変換は、RFC822 CRLF規約には一致しないかもしれない。 孤立したCR文字及びLF文字は一般には許されない結果となる。 それらは、あるシステムでは、失われるか又は区切り子に変換されるかもしれないので信頼してはならない。
(2) Many systems may elect to represent and store text data using local newline conventions. Local newline conventions may not match the RFC822 CRLF convention -- systems are known that use plain CR, plain LF, CRLF, or counted records. The result is that isolated CR and LF characters are not well tolerated in general; they may be lost or converted to delimiters on some systems, and hence must not be relied on.
3. NUL（US-ASCII値の0）の転送は、インターネットメールでは問題である。 これは、プログラム言語Cの多くの標準ランタイムライブラリルーチンにより、NULが終端文字として使われていることの結果によるところが大きい。 終端文字としてのNULの使用の実践では、いまや侵害されるので、メッセージが保持されることを信じてはならない。
(3) The transmission of NULs (US-ASCII value 0) is problematic in Internet mail. (This is largely the result of NULs being used as a termination character by many of the standard runtime library routines in the C programming language.) The practice of using NULs as termination characters is so entrenched now that messages should not rely on them being preserved.
4. TAB（HT）文字は、誤って解釈されうるか、又は、異なる数のスペースへ自動的に変換されるかもしれない。 これは、いくつかの環境では、特にUS-ASCIIに基づかない場合、避けられない。 このような変換は、強く非推奨とするが、もしそれがおこったならば、メールフォーマットはTAB(HT)文字の保持性に依存してはならない。
(4) TAB (HT) characters may be misinterpreted or may be automatically converted to variable numbers of spaces. This is unavoidable in some environments, notably those not based on the US-ASCII character set. Such conversion is STRONGLY DISCOURAGED, but it may occur, and mail formats must not rely on the persistence of TAB (HT) characters.
5. 76文字より長い行は、いくつかの環境では、折り返されるか又は切られる。 メール転送で行われる行折り返し又は行切りは、強く非推奨とするが、いくつかの場合には避けられない。 長い行を要求するアプリケーションは、ソフト又はハード改行の間で差別化しなければならない。 これを行う簡単は方法は、quoted-printable符号化を使うことである。
(5) Lines longer than 76 characters may be wrapped or truncated in some environments. Line wrapping or line truncation imposed by mail transports is STRONGLY DISCOURAGED, but unavoidable in some cases. Applications which require long lines must somehow differentiate between soft and hard line breaks. (A simple way to do this is to use the quoted-printable encoding.)
6. 行の末尾の"空白"文字（SPACE、TAB(HT)）は、いくつかの転送エージェントで捨てられるかもしれない。他の転送エージェントではこれらの文字を埋めて、メールファイル中の全ての行を同じ長さにする場合もある。 末尾の空白の保持性をあてにしてはならない。
(6) Trailing "white space" characters (SPACE, TAB (HT)) on a line may be discarded by some transport agents, while other transport agents may pad lines with these characters so that all lines in a mail file are of equal length. The persistence of trailing white space, therefore, must not be relied on.
7. 多くのメール領域は、US-ASCII文字集合での多様なものを使うか、又はUS-ASCIIの文字の多くを含むが全ては含んでいないEBCDICのような文字集合を使う。 普遍の集合に含まれない文字の正しい翻訳は、文字変換ゲートウェイに依存されることはできない。 例えば、この状況は、uuencodeだれた情報を、EBCDICシステムであるBITNETに送る場合に問題である。 多くのインターネットのホストは、内部ではUS-ASCII以外の文字集合をつかっているので、類似の問題は、ゲートウェイを通さない場合にも起る。 X.400におけるPrintable String（印字可能文字列）の定義は、特定の場合において、さらに制限を加えている。 特に、全てのゲートウェイを通して整合すると知られている文字は73文字だけであり、それらは、大文字及び小文字のAからZまで及びaからzまで、0から9までの10数字、並びに、次の11の特別な文字である。
   (7) Many mail domains use variations on the US-ASCII character set, or use character sets such as EBCDIC which contain most but not all of the US-ASCII characters. The correct translation of characters not in the "invariant" set cannot be depended on across character converting gateways. For example, this situation is a problem when sending uuencoded information across BITNET, an EBCDIC system. Similar problems can occur without crossing a gateway, since many Internet hosts use character sets other than US- ASCII internally. The definition of Printable Strings in X.400 adds further restrictions in certain special cases. In particular, the only characters that are known to be consistent across all gateways are the 73 characters that correspond to the upper and lower case letters A-Z and a-z, the 10 digits 0-9, and the following eleven special characters:

               "'"  (US-ASCII decimal value 39)
               "("  (US-ASCII decimal value 40)
               ")"  (US-ASCII decimal value 41)
               "+"  (US-ASCII decimal value 43)
               ","  (US-ASCII decimal value 44)
               "-"  (US-ASCII decimal value 45)
               "."  (US-ASCII decimal value 46)
               "/"  (US-ASCII decimal value 47)
               ":"  (US-ASCII decimal value 58)
               "="  (US-ASCII decimal value 61)
               "?"  (US-ASCII decimal value 63)
   

   "'" (US-ASCII decimal value 39) "(" (US-ASCII decimal value 40) ")" (US-ASCII decimal value 41) "+" (US-ASCII decimal value 43) "," (US-ASCII decimal value 44) "-" (US-ASCII decimal value 45) "." (US-ASCII decimal value 46) "/" (US-ASCII decimal value 47) ":" (US-ASCII decimal value 58) "=" (US-ASCII decimal value 61) "?" (US-ASCII decimal value 63)

   最大限可搬性のあるメール表現は、73文字のこの集合からの意味のある文字だけを使った比較的短い行に限ることであろう。 base64符号化はこの規則に従っている。

   A maximally portable mail representation will confine itself to relatively short lines of text in which the only meaningful characters are taken from this set of 73 characters. The base64 encoding follows this rule.
8. いくつかのメール転送エージェントは、特定の文字列を含むデータを壊す。 特に、ピリオド（"."）だけの行は、いくつかの正しくないSMTP実装によって壊れることが知られており、"From "の5文字（最後の文字はSPACE）で始まる行は同様に通常壊れる。 注意深い作成エージェントは、これらのデータを符号化することによって破壊を防ぐことができる。 例えば、quoted-printable符号化で行の先頭にある"Fromの場所に"=46rom "を使い、"."だけの行の場所には"=2E"を使う。

4. 正準符号化モデル

MIME規定の初期の版では，電子メールデータが正準形式に変換し符号化されるとき、特にこの過程がどのように、システムごとに大きく異なる改行の表現が与えられる、CRLFの振る舞いに影響するか、混乱があった。 この理由により、符号化の正準モデルを次に示す。

MIME実体を作成する過程は、いくつかの段階で行われるものとしてモデル化できる。 これらの段階は、大雑把に言って、PEM [RFC-1421]で使われる段階と似ていて、それぞれの最も内側のレベルの本体に対して実行される。

1. ローカル形式の作成
   システムの固有フォーマットで、転送する本体を作成する。 固有の文字就業を使い、適切であれば、同様にローカルな行の終端の変換が行われる。 本体は、UNIXスタイルのテキストファイル、Sunのラスタ画像、VMSのインデックス付きファイル、メモリ内にだけ保存される形式のシステム依存の音声データ、又は、情報のある形式の表現ためのローカルなモデルに対応するその他のものであってもよい。 基本的に、データは、メディア型で指定される型に対応する"固有の"形式で作成される。
(1) Creation of local form. The body to be transmitted is created in the system's native format. The native character set is used and, where appropriate, local end of line conventions are used as well. The body may be a UNIX-style text file, or a Sun raster image, or a VMS indexed file, or audio data in a system-dependent format stored only in memory, or anything else that corresponds to the local model for the representation of some form of information. Fundamentally, the data is created in the "native" form that corresponds to the type specified by the media type.
2. 正準形式への変換
   レコード長及び可能なファイル属性情報などの"out-of-band"情報を含む全ての本体は、ユニバーサル正準形式に変換される。 本体の特定のメディア型及び関連する属性は、使われる正準形式の性質を指令する。 正しい正準形式への変換は、文字集合の変換、音声データの変換、圧縮、又は、多くのメディア型に特有の多くの他の操作を伴ってよい。 文字集合の変換を伴う場合、どんな文字集合の変換にも強く係わり合いをもつであろう、メディア型のセマンティクスを理解する注意が払われなければならない。 例えば、"plain"以外のテキスト下位型の構文上意味のある文字などに注意を払わなければならない。 (2) Conversion to canonical form. The entire body, including "out-of-band" information such as record lengths and possibly file attribute information, is converted to a universal canonical form. The specific media type of the body as well as its associated attributes dictate the nature of the canonical form that is used. Conversion to the proper canonical form may involve character set conversion, transformation of audio data, compression, or various other operations specific to the various media types. If character set conversion is involved, however, care must be taken to understand the semantics of the media type, which may have strong implications for any character set conversion, e.g. with regard to syntactically meaningful characters in a text subtype other than "plain".
   例えば、text/plainデータの場合、テキストはサポートされる文字集合に変換されなければならず、RFC 822に従ってCRLF区切り子で行を区切らなくてはならない。 次の段階でquoted-printable符号化又はbase64符号化を用いるならば、RFC 822に規定される行の長さの制限はなくなる。
For example, in the case of text/plain data, the text must be converted to a supported character set and lines must be delimited with CRLF delimiters in accordance with RFC 822. Note that the restriction on line lengths implied by RFC 822 is eliminated if the next step employs either quoted-printable or base64 encoding.
3. 転送符号化の適用
   この本体に適切なContent-Transfer-Encodingを適用する。 メディア型と転送符号化との間には固定的な関係はないことに注意すること。 特に、本体の与えられた実体に特有の文字頻度数におけるbase64又はquoted-printableに基づくことがてきとうであってよい。
(3) Apply transfer encoding. A Content-Transfer-Encoding appropriate for this body is applied. Note that there is no fixed relationship between the media type and the transfer encoding. In particular, it may be appropriate to base the choice of base64 or quoted-printable on character frequency counts which are specific to a given instance of a body.
4. 実体への挿入
   符号化された本体は、MIME実体に適切なヘッダとともに挿入される。 そして、実体は、必要に応じて、より高いレベルの実体（メッセージ又はマルチパート）に挿入される。

実体形式からローカル形式への変換は、これらの段階を逆にすることによって達成される。 もとのローカル形式と最終的なローカル形式が同じである保証はないので、これらの段階の逆は異なる結果を生成するかもしれないことに注意すること。

これらの段階はモデルにすぎないことに注意することは重要である。 これらは、特に実際のシステムがどのように構築されるかの青写真ではない。 特に、モデルは、2つの普通の設計でうまくいかない。

1. 多くの場合、符号化に先立つ正準形式への変換は、ローカルなフォーマットを直接理解できる、符号化器そのもに含まれる。 例えば、テキスト本体のローカルな改行の変換は、フォーマットが何であるか知識にそって、符号化器そのものを通して、行われ得る。
(1) In many cases the conversion to a canonical form prior to encoding will be subsumed into the encoder itself, which understands local formats directly. For example, the local newline convention for text bodies might be carried through to the encoder itself along with knowledge of what that format is.
2. 符号化器の出力は、メッセージとして転送される前に、一つ又はそれ以上の追加の段階を通るかもしれない。 このようにして、符号化器の出力は、RFC 822に規定されるフォーマットに適合しないかもしれない。特に、変換器の出力が、標準のRFC 822のCRLF区切り死を使うのではなく、ローカルな改行の変換を使って表現されることが適切であるかもしれない。

他の実装上の多様性も同様に想像できる。 この議論における大事な点は、要求される段階が崩れるか又は追加の処理が挿入される最適化に代わっても、結果のメッセージはここで記述されたモデルにより生成されたものと整合していなければならないということである。 例えば、次のヘッダーファイルをもつメッセージは、はじめにtext/foo形式で表現され、そして、必要であれば、"bar"文字集合により表現され、そして最後に、base64アルゴリズムによって、メール安全形式へと変換されなければならない。

     Content-type: text/foo; charset=bar
     Content-Transfer-Encoding: base64

備考  RFC 822のCRLF変換と異なるローカルな改行変換を使うフォーマットのメッセージをあらわすシステムにより、いくらかの混乱が起っている。 これらのフォーマットは正準なRFC822/MIMEではないことに注意することは重要である。 これらのフォーマットは、メッセージの正準な表現におけるCRLF列を符号化する、RFC 822における*encodings*ではなく、ローカルな改行の変換である。 CRLF列を符号化するフォーマットは、例えば、LFのオクテットをCRLF行区切り列の一部ではなく含む2値データを含むMIMEメッセージを表現する機能をLFはもたない。

5. 要約

この標準情報(TR）は、MIME適合が何を意味するかを定義した。 また、インターネットの電子メールシステムに存在する多くの既知の問題及びこれらを克服するためにMIMEをどう使えばよいかを詳説した。最後に、MIMEの正準符号化モデルについて記述した。

6. セキュリティの考慮

セキュリティについては、MIME関連の2番目の標準情報(TR）TR X 0070に記述されている。

7. 原規定の著者の連絡先

さらに情報を得るために、原規定の著者に連絡をとる場合には、インターネットメールを使うとよい。

   Ned Freed
   Innosoft International, Inc.
   1050 East Garvey Avenue South
   West Covina, CA 91790
   USA

   Phone: +1 818 919 3600
   Fax:   +1 818 919 3614
   EMail: ned@innosoft.com

   Nathaniel S. Borenstein
   First Virtual Holdings
   25 Washington Avenue
   Morristown, NJ 07960
   USA

   Phone: +1 201 540 8967
   Fax:   +1 201 993 3032
   EMail: nsb@nsb.fv.com

MIMEは、Internet Engineering Task Force (IETF)のRFC 822拡張に関する作業グループの作業の結果である。作業グループの議長Greg Vaudreuilの連絡先を示す。

   Gregory M. Vaudreuil
   Octel Network Services
   17080 Dallas Parkway
   Dallas, TX 75248-1905
   USA

   EMail: Greg.Vaudreuil@Octel.Com

8. 貢献者

原規定（RFC 2049）は，IETF-SMTP及びIETF-822のメーリングリスト及びその他の場所での，多くのIETF会議での多くの人々の集積した効果の結果である。 どんな列挙にもひどい抜けはあるであろうが、次の列挙は、この成果への多くの貢献者の中の一覧である。

     Harald Tveit Alvestrand       Marc Andreessen
     Randall Atkinson              Bob Braden
     Philippe Brandon              Brian Capouch
     Kevin Carosso                 Uhhyung Choi
     Peter Clitherow               Dave Collier-Brown
     Cristian Constantinof         John Coonrod
     Mark Crispin                  Dave Crocker
     Stephen Crocker               Terry Crowley
     Walt Daniels                  Jim Davis
     Frank Dawson                  Axel Deininger
     Hitoshi Doi                   Kevin Donnelly
     Steve Dorner                  Keith Edwards
     Chris Eich                    Dana S. Emery
     Johnny Eriksson               Craig Everhart
     Patrik Faltstrom              Erik E. Fair
     Roger Fajman                  Alain Fontaine
     Martin Forssen                James M. Galvin
     Stephen Gildea                Philip Gladstone
     Thomas Gordon                 Keld Simonsen
     Terry Gray                    Phill Gross
     James Hamilton                David Herron
     Mark Horton                   Bruce Howard
     Bill Janssen                  Olle Jarnefors
     Risto Kankkunen               Phil Karn
     Alan Katz                     Tim Kehres
     Neil Katin                    Steve Kille
     Kyuho Kim                     Anders Klemets
     John Klensin                  Valdis Kletniek
     Jim Knowles                   Stev Knowles
     Bob Kummerfeld                Pekka Kytolaakso
     Stellan Lagerstrom            Vincent Lau
     Timo Lehtinen                 Donald Lindsay
     Warner Losh                   Carlyn Lowery
     Laurence Lundblade            Charles Lynn
     John R. MacMillan             Larry Masinter
     Rick McGowan                  Michael J. McInerny
     Leo Mclaughlin                Goli Montaser-Kohsari
     Tom Moore                     John Gardiner Myers
     Erik Naggum                   Mark Needleman
     Chris Newman                  John Noerenberg
     Mats Ohrman                   Julian Onions
     Michael Patton                David J. Pepper
     Erik van der Poel             Blake C. Ramsdell
     Christer Romson               Luc Rooijakkers
     Marshall T. Rose              Jonathan Rosenberg
     Guido van Rossum              Jan Rynning
     Harri Salminen                Michael Sanderson
     Yutaka Sato                   Markku Savela
     Richard Alan Schafer          Masahiro Sekiguchi
     Mark Sherman                  Bob Smart
     Peter Speck                   Henry Spencer
     Einar Stefferud               Michael Stein
     Klaus Steinberger             Peter Svanberg
     James Thompson                Steve Uhler
     Stuart Vance                  Peter Vanderbilt
     Greg Vaudreuil                Ed Vielmetti
     Larry W. Virden               Ryan Waldron
     Rhys Weatherly                Jay Weber
     Dave Wecker                   Wally Wedel
     Sven-Ove Westberg             Brian Wideen
     John Wobus                    Glenn Wright
     Rayan Zachariassen            David Zimmerman

原規定の著者は、この一覧から抜けている人に謝罪する。意図的に抜かしたのでは断じてない。