序文

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

1. 導入

1.1 適用範囲

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

1. a) US-ASCII以外の文字集合でのテキストのメッセージ本体
2. b) 非テキストのメッセージ本体のための異なるフォーマットの拡張集合
3. c) マルチパートのメッセージ本体
4. d) US-ASCII以外の文字集合でのテキストのヘッダ情報

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

これらの一連の標準仕様書(TS)の最初であって，RFC 2045を原規定とするTS X 0069は，MIMEメッセージの構造を記述するために使用される多くのヘッダを規定する。2番目のRFC 2046を原規定とするTS X 0070は，MIMEメディア型付けシステムの一般的構造を定義し，メディア型の初期集合を定義する。3番目のRFC 2047を原規定とするTS X 0071は，非US-ASCIIでのインターネットメールヘッダフィールドの中で非US-ASCIIデータを可能にするためのRFC 822の拡張を規定する。4番目のRFC 2048を原規定とするTS X 0106は，MIME関連機能のための多くのIANA登録手続を規定する。最後の5番目のRFC 2049を原規定とするこの標準仕様書(TS)は，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関連の一連の規定のうち，1番目のTS X 0069及び2番目のTS X 0070は，MIMEヘッダフィールド及びMIMEメディア型の初期集合を定義する。3番目のTS X 0071は，US-ASCII以外の文字集合を可能とするために，RFC 822フォーマットの拡張について規定する。この標準仕様書(TS)は，MIMEのどの部分が適合するMIME実装によってサポートされなければならないかを規定する。また，この標準仕様書(TS)は，現代のメッセージングシステムの多くの落とし穴を示し，MIMEが基づいている正準符号化モデルをも規定する。

2. MIME適合性

MIME関連規定で示される機構は，拡張に対応している。すべての実装がすべての可能なメディア型をサポートすることも，それらが同じ拡張を共有することも，全く期待されない。しかし相互運用性を推進するため，実装のある水準を定義する“MIME適合性”の概念を定義することは有用であり，これは，US-ASCIIテキストと異なる内容をもつメッセージの有用な交換を可能にする。 2.は，この適合性のための要件を規定する。

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

1. a) それが作成するすべてのメッセージに, 常に“MIME-Version: 1.0”ヘッダフィールドを生成しなければならない。 (1) Always generate a "MIME-Version: 1.0" header field in any message it creates.

2. b) 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値の内容転送符号化で適切にラベル付けされなければならない。下層にある転送機構が，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. c) 認識できないどのような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. d) 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. e) 名前を認識できない内容型パラメタは無視しなければならない。 (5) Ignore any content type parameters whose names they do not recognize.

6. f) 次のメディア型値を，少なくとも次の程度まで明示的に処理しなければならない。 (6) Explicitly handle the following media type values, to at least the following extents:
   text:
   • 文字集合“US-ASCII”をもつ“text”メールを認識し, 表示しなければならない。
   • 他の文字集合を, 少なくとも，メッセージが使っている文字集合が何であるかについて利用者に知らせることができる程度まで, 認識しなければならない。
   • 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:
   • TS X 0069で定義される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のメールの冗長な部分を利用者に見せることを避けなければならない。
   • “multipart/digest”下位型を認識しなければならない。特に，“multipart/digest”実体内部の本体部分のデフォルトのメディア型として，“text/plain”ではなく“message/rfc822”を使わなければならない。
   • すべての認識できない下位型を“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. g) 認識できない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. h) 適合利用者エージェントが, 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. i) 適合利用者エージェントは，“=?”で始まり“?=”で終わる“*text”又は“*ctext”の中にある非空白で印字可能なUS-ASCII文字のどの文字列も, 妥当な符号化語(valid encoded-word)であることを保証しなければならない。ここで, “始まる”は，フィールド本体の先頭又は線形空白(linear-white-space)の直後を意味し，“終わる”は，フィールド本体の末尾又は線形空白の直前を意味する。さらに，“=?”で始まり“?=”で終わる“phrase”の中にあるどんな“word”も，妥当な符号化語でなければならない。 (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. j) 適合利用者エージェントは，符号化語がメッセージヘッダ中の適切な位置に現れたらいつでも，4.に規定する規則に従って, 符号化語を“text”，“ctext”又は“word”から区別できなければならない。それは, それがサポートするどの文字集合に対しても，“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値として扱うことができ，疑わない利用者の画面上にそれをまき散らすことはないことによる。

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

3. 電子メールデータ送信の指針

インターネットメールは，完全で一様なシステムではない。メールは，最終目的地に行く途中の多くの段階で，壊れてしまうことがある。特に，インターネットを通って送られた電子メールは，多くのネットワーク技術を通過し得る。多くのネットワーク技術及びメール技術は，SMTP転送環境で可能な全機能をサポートするわけではない。これらのシステムを通過するメールは，それが転送され得るように，変更され易い。

インターネットには, 多くの非適合MTAがある。これらのMTAは，SMTPプロトコルで交信する際に, それが実装されているホストの内部データ構造を利用して動作中にメッセージを改変するか，又ははっきりと壊される。

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

1. a) いくつかの状況下では，通常のゲートウェイの一部又は利用者エージェント操作として，データに使われる符号化を変更してよい。特に，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. b) 多くのシステムは，局所的な改行変換を使って，テキストデータを表示し，保存することを選択してよい。局所的な改行変換は，RFC 822のCRLF規約, つまり, CRだけ，LFだけ，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. c) 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. d) 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. e) 76文字より長い行は，ある環境では，折り返されるか又は切り取られる。メール転送で行われる行の折返し又は切取りは，強く非推奨とするが，いくつかの場合には避けられない。長い行を要求するアプリケーションは，無指定(soft)行区切りと指定(hard)行区切りとを何とかして区別しなければならない。これを行う簡単な方法に，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. f) 行の末尾の“空白”文字(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. g) 多くのメールドメインは，US-ASCII文字集合での変種を使うか，又はUS-ASCIIの文字の多くを含むがすべては含んでいないEBCDICなどの文字集合を使う。 “不変の”集合にない文字の正しい翻訳は，文字変換ゲートウェイに頼ることはできない。例えば，この状況は，uuencodeされた情報を，EBCDICシステムであるBITNETを通して送る場合に問題となる。多くのインターネットのホストは，内部ではUS-ASCII以外の文字集合を使うので，類似の問題は，ゲートウェイを通さない場合にも起る。 X.400におけるPrintable String(印字可能文字列)の定義は，ある特定の場合に更に制限を加えている。特に，すべてのゲートウェイを通して一貫性があると知られている文字は, 大文字のAからZまで, 小文字のaからzまで，0から9までの10数字，及び次の11の特別な文字である73文字だけである。
   (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の10進値で39)
               “(”  (US-ASCIIの10進値で40)
               “)”  (US-ASCIIの10進値で41)
               “+”  (US-ASCIIの10進値で43)
               “,”  (US-ASCIIの10進値で44)
               “-”  (US-ASCIIの10進値で45)
               “.”  (US-ASCIIの10進値で46)
               “/”  (US-ASCIIの10進値で47)
               “:”  (US-ASCIIの10進値で58)
               “=”  (US-ASCIIの10進値で61)
               “?”  (US-ASCIIの10進値で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. h) いくつかのメール転送エージェントは，ある文字列を含むデータを壊す。特に，ピリオド(“.”)だけの行は，いくつかの(正しくない)SMTP実装によって壊されることが知られており，“From ”の5文字(最後の文字はSPACE)で始まる行も通常壊される。注意深い作成エージェントは，そのデータを符号化することによって破壊を防ぐことができる。例えば，quoted-printable符号化において行の先頭にある“From ”の場所に“=46rom ”を使い，行の“.”だけの場所には“=2E”を使う。

上述の一覧は，MTAに関する推奨される実行の一覧ではないことに注意されたい。 RFC 821のMTAは，空白の文字を変更すること又は長い行を折り返すことを禁止している。これらの悪い不正な実行は，設置されたネットワークで起ることが知られていて，実装は，それらが引き起こし得る悪い影響を扱う際に頑健であることが望ましい。

4. 正準符号化モデル

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

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

1. a) 局所形式の作成
   システムの固有フォーマットで，転送する本体を生成する。固有の文字集合が使われ，適切であれば，同様に局所的な行の終端の変換が行われる。本体は，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. b) 正準形式への変換
   レコード長, 可能なファイル属性情報などの“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. c) 転送符号化の適用
   この本体に適切な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. d) 実体への挿入
   符号化された本体は，MIME実体に適切なヘッダとともに挿入される。それから実体は，必要に応じてもっと高いレベルの実体(メッセージ又はマルチパート)に挿入される。

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

これらの段階はモデルにすぎないことに注意することは重要である。これらは，実際のシステムがどのように構築されるかの青写真では決してない。特にモデルは，次の二つの共通設計を説明できない。

1. a) 多くの場合，符号化に先立つ正準形式への変換は，局所フォーマットを直接理解できる符号化器そのものに含まれる。例えば，テキスト本体の局所的な改行の変換は，そのフォーマットが何であるかの知識に基づいて, 符号化器そのものを通して実行されるであろう。 (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. b) 符号化器の出力は，メッセージとして転送される前に，一つ以上の追加の段階を通らなければならないかもしれない。したがって，符号化器の出力は，RFC 822に規定されるフォーマットに適合しないかもしれない。特に，変換器の出力が，標準的なRFC 822のCRLF区切り子を使うのではなく，局所的な改行変換を使って表現されることが再び適切であるかもしれない。

他の実装上の多様性も同様に考えられる。この議論の重要な点は，要求される段階を崩したり追加処理を挿入したりする最適化にかかわらず，結果のメッセージはここに示されたモデルによって生成されたものと整合していなければならないことである。例えば，次のヘッダーファイルをもつメッセージは，はじめにtext/foo形式で表現され，それから必要に応じて，“bar”文字集合によって表現され，最後にbase64アルゴリズムによってmail-safe形式に変換されなければならない。

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

備考  RFC 822のCRLF変換と異なる局所的な改行変換を使うフォーマットでメッセージを表現するシステムによって，ある混乱が起きていた。これらのフォーマットが正準なRFC822/MIMEではないことに注意することは, 重要である。これらのフォーマットは，メッセージの正準表現におけるCRLF列が局所的な改行変換として符号化される，RFC 822の代理“符号化”である。例えば，CRLF行分離列の部分でないLFオクテットを含む2値データを含むMIMEメッセージを表現できないことに注意。

5. 要約

この標準仕様書(TS)は，MIME適合が何を意味するかを定義した。それは, インターネットの電子メールシステムに存在することが知られている様々な問題, 及びこれらを克服するためにMIMEをどのように使うかをも詳述した。最後に，MIMEの正準符号化モデルを示した。

6. セキュリティへの考慮

セキュリティについては，MIME関連の2番目の規定であるTS X 0070に示されている。

7. 原規定の著者の連絡先（参考）

さらに詳細な情報を得るには, 次に示す原規定(RFC 2049)の著者にインターネットメールで連絡をとるのがよい。

   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

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