2. 定義、規約、および一般的なBNF文法 (Definitions, Conventions, and Generic BNF Grammar)
MIMEメカニズムはこの文書セット全体を通じて散文で指定されていますが、多くはRFC 822の拡張BNF記法 (Augmented BNF Notation) を使用して正式に記述されています。実装者がこの文書セットを理解するためには、この記法に精通している必要があり、拡張BNF記法の完全な説明についてはRFC 822を参照してください。
この文書セット内の拡張BNFの一部は、RFC 822で定義された構文規則への名前付き参照を行います。したがって、完全な正式文法 (Formal Grammar) は、この文書セットの各文書から収集された文法付録をRFC 822の文法と組み合わせ、さらにRFC 1123で定義されたRFC 822への修正(特に return、date、および mailbox の構文を変更)を加えることによって得られます。
この文書セット内のすべての数値およびオクテット値は10進表記で示されます。定義されたすべてのメディアタイプ値、サブタイプ値、およびパラメータ名は大文字と小文字を区別しません (Case-insensitive)。ただし、パラメータ値は、特定のパラメータに対して別途指定されない限り、大文字と小文字を区別します (Case-sensitive)。
形式上の注記 (FORMAT NOTE): このような注記は、読者が本質的なものを見逃すことなくスキップできる追加の非本質的な情報を提供します。これらの非本質的な注記の主な目的は、この文書セットの根拠に関する情報を伝えること、またはこれらの文書を適切な歴史的または進化的文脈に位置づけることです。特に、そのような情報は、準拠実装の構築に専念している人々によってスキップされる可能性がありますが、特定の設計選択がなされた理由を理解したい人々には有用である可能性があります。
2.1. CRLF
この文書セットにおける用語 CRLF は、2つのUS-ASCII文字 CR (10進値13) および LF (10進値10) に対応するオクテットのシーケンスを指し、この順序で一緒に取得された場合、RFC 822メールにおける改行 (Line Break) を示します。
2.2. 文字セット (Character Set)
用語「文字セット (Character Set)」は、MIMEでは、オクテットのシーケンスを文字のシーケンスに変換する方法を指すために使用されます。すべての文字が特定の文字セットで表現可能であるとは限らず、また文字セットが特定の文字シーケンスを表現するために複数のオクテットシーケンスを提供する可能性があるため、他の方向への無条件かつ曖昧さのない変換は要求されないことに注意してください。
この定義は、US-ASCIIのような単純な単一テーブルマッピングから、ISO 2022の技術を使用するような複雑なテーブル切り替え方式まで、様々な種類の文字エンコーディングを許可することを意図しています。ただし、MIME文字セット名に関連付けられた定義は、実行されるマッピングを完全に指定しなければなりません (MUST)。特に、正確なマッピングを決定するための外部プロファイリング情報 (External Profiling Information) の使用は許可されません。
注記 (NOTE): 用語「文字セット (Character Set)」は、もともとUS-ASCIIやISO-8859-1のような、少数の文字のセットと単一オクテットから単一文字への単純な1対1マッピングで構成されるものを説明するために使用されました。マルチオクテット符号化文字セット (Multi-octet Coded Character Sets) と切り替え技術により、状況はより複雑になっています。例えば、一部のコミュニティでは、MIMEが「文字セット (Character Set)」と呼ぶものを「文字エンコーディング (Character Encoding)」という用語で表現し、整数(オクテットではなく)から文字への抽象的なマッピングを示すために「符号化文字セット (Coded Character Set)」というフレーズを使用しています。
2.3. メッセージ (Message)
用語「メッセージ (Message)」は、さらに限定されない場合、ネットワーク上で転送されている(完全または「トップレベル」の)メッセージ、または "message/rfc822" または "message/partial" タイプの本文にカプセル化されたメッセージを意味します。
2.4. エンティティ (Entity)
用語「エンティティ (Entity)」は、メッセージまたはマルチパート本文内のパートのいずれかの、MIME定義のヘッダーフィールドと内容を具体的に指します。そのようなエンティティの仕様がMIMEの本質です。エンティティの内容はしばしば「本文 (Body)」と呼ばれるため、エンティティの本文について話すことは理にかなっています。エンティティのヘッダーには任意の種類のフィールドが存在する可能性がありますが、名前が "content-" で始まるフィールドのみが実際にMIME関連の意味を持ちます。これは、それらがまったく意味を持たないという意味ではないことに注意してください。メッセージでもあるエンティティには、RFC 822によって意味が定義された非MIMEヘッダーフィールドがあります。
2.5. 本文パート (Body Part)
用語「本文パート (Body Part)」は、マルチパートエンティティ内のエンティティを指します。
2.6. 本文 (Body)
用語「本文 (Body)」は、さらに限定されない場合、エンティティの本文、つまりメッセージまたは本文パートのいずれかの本文を意味します。
注記 (NOTE): 前述の4つの定義は明らかに循環的です。MIMEメッセージの全体的な構造は確かに再帰的であるため、これは避けられません。
2.7. 7ビットデータ (7bit Data)
「7ビットデータ (7bit Data)」は、CRLF行区切りシーケンス間に998オクテット以下の比較的短い行として表現されるすべてのデータを指します [RFC-821]。10進値127より大きいオクテットは許可されず、NUL(10進値0のオクテット)も許可されません。CR(10進値13)およびLF(10進値10)のオクテットは、CRLF行区切りシーケンスの一部としてのみ発生します。
2.8. 8ビットデータ (8bit Data)
「8ビットデータ (8bit Data)」は、CRLF行区切りシーケンス間に998オクテット以下の比較的短い行として表現されるすべてのデータを指しますが [RFC-821]、10進値127より大きいオクテットが使用される場合があります。「7ビットデータ」と同様に、CRおよびLFオクテットはCRLF行区切りシーケンスの一部としてのみ発生し、NULは許可されません。
2.9. バイナリデータ (Binary Data)
「バイナリデータ (Binary Data)」は、任意のオクテットシーケンスが許可されるデータを指します。
2.10. 行 (Lines)
「行 (Lines)」は、CRLFシーケンスによって区切られたオクテットのシーケンスとして定義されます。これは、RFC 821およびRFC 822の両方と一致しています。「行」は、メッセージ内のデータの単位のみを指し、ユーザエージェント (User Agent) によって実際に表示されるものに対応する場合としない場合があります。
用語のまとめ (Terminology Summary):
| 用語 | 説明 |
|---|---|
| 文字セット (Character Set) | オクテットシーケンスを文字シーケンスに変換する方法 |
| メッセージ (Message) | RFC 822メッセージまたはカプセル化されたメッセージ |
| エンティティ (Entity) | MIMEヘッダーフィールドと内容 |
| 本文パート (Body Part) | マルチパートエンティティ内のエンティティ |
| 本文 (Body) | エンティティの内容 |
| 7ビットデータ (7bit Data) | US-ASCIIのみ、高ビットオクテットなし、短い行 |
| 8ビットデータ (8bit Data) | 高ビットオクテット許可、短い行 |
| バイナリデータ (Binary Data) | 任意のオクテットシーケンス許可 |
| 行 (Lines) | CRLF区切りのオクテットシーケンス |
主要概念 (Key Concepts):
- MIME構造は再帰的です(エンティティはエンティティを含むことができます)
- パラメータ名は大文字小文字を区別しませんが、値は通常区別します
- CRLFは行区切り文字の唯一の形式です
- データは7ビット、8ビット、およびバイナリタイプに分類されます