メインコンテンツまでスキップ

1. はじめに (Introduction)

1982年の公開以来、RFC 822はインターネット上のテキストメールメッセージの標準形式を定義してきました。その成功は、RFC 822形式がインターネットの枠を超え、RFC 821で定義されたインターネットSMTPトランスポートの範囲を大きく超えて、全体的または部分的に採用されるほどでした。この形式が広く採用されるにつれて、多くの制限がユーザーコミュニティにとってますます制約的であることが証明されました。

RFC 822はテキストメッセージの形式を指定することを意図していました。そのため、オーディオや画像を含む可能性のあるマルチメディアメッセージなどの非テキストメッセージについては、単に言及されていません。しかし、テキストの場合でさえ、RFC 822は、US-ASCIIよりも豊富な文字セットの使用を必要とする言語を使用するメールユーザーのニーズには不十分です。RFC 822は、オーディオ、ビデオ、アジア言語のテキスト、またはほとんどのヨーロッパ言語のテキストを含むメールのメカニズムを指定していないため、追加の仕様が必要です。

基本的なRFC 821/822メールシステムの注目すべき制限の1つは、電子メールメッセージの内容を7ビットUS-ASCIIの比較的短い行（例：1000文字以下 [RFC-821]）に制限することです。これにより、ユーザーは、送信したい非テキストデータを、ローカルメールUA（User Agent、ユーザーエージェント、人間のユーザーがメールを送受信するプログラム）を呼び出す前に、印刷可能なUS-ASCII文字として表現可能な7ビットバイトに変換することを余儀なくされます。現在インターネットで使用されているそのようなエンコーディングの例には、純粋な16進数、uuencode、RFC 1421で指定された3-in-4 base 64スキーム、Andrew Toolkit Representation [ATK]、その他多数が含まれます。

RFC 822メール形式の制限は、RFC 822ホストとX.400ホスト間でメールメッセージを交換できるようにゲートウェイが設計されるにつれて、さらに明らかになります。X.400 [X400]は、電子メールメッセージ内に非テキスト素材を含めるためのメカニズムを指定しています。X.400メッセージをRFC 822メッセージにマッピングするための現在の標準では、X.400の非テキスト素材はIA5Text形式に変換（エンコードではない）されるか、破棄され、RFC 822ユーザーに破棄が発生したことを通知する必要があります (must)。これは明らかに望ましくありません。ユーザーが受信したい情報が失われるからです。ユーザーエージェントに非テキスト素材を処理する機能がない場合でも、ユーザーは素材から有用な情報を抽出できるUAの外部のメカニズムを持っている可能性があります。さらに、メッセージが最終的にX.400メッセージ処理システムにゲートウェイバックされる可能性（つまり、X.400メッセージがインターネットメールを「トンネリング」する）があり、その場合、非テキスト情報は確実に再び有用になります。

このドキュメントは、既存のRFC 822メールの世界との深刻な非互換性を導入することなく、これらの問題のほとんどを解決するために組み合わせるいくつかのメカニズムについて説明します。特に、以下について説明します：

  1. MIME-Versionヘッダーフィールド：バージョン番号を使用してメッセージがMIMEに準拠していることを宣言し、メール処理エージェントがそのようなメッセージと、そのようなフィールドを欠いていると推定される古いまたは非準拠のソフトウェアによって生成されたメッセージを区別できるようにします。

  2. Content-Typeヘッダーフィールド：RFC 1049から一般化され、メッセージの本文内のデータのメディアタイプとサブタイプを指定し、そのようなデータのネイティブ表現（正規形式）を完全に指定するために使用できます。

  3. Content-Transfer-Encodingヘッダーフィールド：本文に適用されたエンコーディング変換と結果のドメインの両方を指定するために使用できます。アイデンティティ変換以外のエンコーディング変換は、通常、データまたは文字セットの制限がある可能性のあるメールトランスポートメカニズムを通過できるようにするためにデータに適用されます。

  4. 2つの追加のヘッダーフィールド：Content-IDとContent-Descriptionは、本文内のデータをさらに説明するために使用できます。

このドキュメントで定義されているすべてのヘッダーフィールドは、RFC 822で指定されているヘッダーフィールドの一般的な構文規則の対象となります。特に、Content-Dispositionを除くこれらのヘッダーフィールドはすべて、セマンティックコンテンツを持たず、MIME処理中に無視されるべき (should) RFC 822コメントを含めることができます。

最後に、相互運用性を指定および促進するために、RFC 2049は、現在のドキュメントの最小限の「準拠」レベルを定義する上記のメカニズムのサブセットの基本的な適用性ステートメントを提供します。

歴史的注記：このドキュメントセットで説明されているメカニズムのいくつかは、最初に読むと少し奇妙に見えたり、バロック的に見えたりすることがあります。このドキュメントセットを開発したワーキンググループの最高の優先事項の2つは、既存の標準との互換性と既存の実践全体の堅牢性であったことに注意することが重要です。特に、互換性は常に優雅さよりも優先されました。

このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」の最新版を参照してください。RFC 822とSTD 3、RFC 1123もMIMEにとって重要な背景を提供します。準拠するMIME実装はこれらに違反することはできないためです。さらに、他のいくつかの情報提供RFCドキュメントもMIME実装者にとって価値があります。特に、RFC 1344、RFC 1345、およびRFC 1524です。

用語 (Terminology)：

  • User Agent (UA) (ユーザーエージェント)：人間のユーザーがメールを送受信するプログラム
  • MIME：Multipurpose Internet Mail Extensions（多目的インターネットメール拡張）
  • canonical form (正規形式)：データのネイティブ表現
  • media type (メディアタイプ)：データの一般的なタイプ
  • subtype (サブタイプ)：メディアタイプ内の特定の形式
  • encoding transformation (エンコーディング変換)：送信のためにデータに適用される変換

主要概念 (Key Concepts)：

  • RFC 822の制限：7ビットUS-ASCIIテキストのみをサポート
  • MIMEの目的：マルチメディア、複数の文字セット、非テキストコンテンツのサポート
  • 互換性優先：MIME設計はRFC 822との下位互換性を維持
に最終更新