標準仕様書(TS)         TS X 0070:2004

多目的インターネットメール拡張(MIME)

第2部 メディア型

Multipurpose Internet Mail Extensions (MIME)

Part Two: Media Types



序文

この標準仕様書(TS)は,1996年11月にInternat Engineering Task Force (IETF)から公表されたRFC 2046 "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"を翻訳し,技術的内容を変更することなく作成した標準 仕様書(TS)である。

Network Working Group N. Freed Request for Comments: 2046 Innosoft Obsoletes: 1521, 1522, 1590 N. Borenstein Category: Standards Track First Virtual November 1996 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

1. 導入

1.1 適用範囲

Abstract

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

  1. US-ASCII以外の文字集合でのテキストのメッセージ本体。
  2. 非テキストのメッセージ本体のための異なるフォーマットの拡張集合。
  3. マルチパートメッセージ本体。
  4. US-ASCII以外の文字集合でのテキストのヘッダ情報。
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for (1) textual message bodies in character sets other than US-ASCII, (2) an extensible set of different formats for non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII.

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

These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.

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

注1 これらの標準仕様書(TS)は,2004年3月現在,公表されていないが,今後公表されることが期待される。

The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.

RFC 2045, RFC 2046, RFC 2047, RFC 2048及びRFC 2049は,RFC 1521, RFC 1522及びRFC 1590の改訂であって,RFC 1521, RFC 1522及びRFC 1590は,RFC 1341及びRFC1342の改訂であった。RFC 2049を原規定とする標準 仕様書(TS)の附属書に,過去の版との違い及び変更について記述する。

These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions. Table of Contents 1. Introduction ......................................... 3 2. Definition of a Top-Level Media Type ................. 4 3. Overview Of The Initial Top-Level Media Types ........ 4 4. Discrete Media Type Values ........................... 6 4.1 Text Media Type ..................................... 6 4.1.1 Representation of Line Breaks ..................... 7 4.1.2 Charset Parameter ................................. 7 4.1.3 Plain Subtype ..................................... 11 4.1.4 Unrecognized Subtypes ............................. 11 4.2 Image Media Type .................................... 11 4.3 Audio Media Type .................................... 11 4.4 Video Media Type .................................... 12 4.5 Application Media Type .............................. 12 4.5.1 Octet-Stream Subtype .............................. 13 4.5.2 PostScript Subtype ................................ 14 4.5.3 Other Application Subtypes ........................ 17 5. Composite Media Type Values .......................... 17 5.1 Multipart Media Type ................................ 17 5.1.1 Common Syntax ..................................... 19 5.1.2 Handling Nested Messages and Multiparts ........... 24 5.1.3 Mixed Subtype ..................................... 24 5.1.4 Alternative Subtype ............................... 24 5.1.5 Digest Subtype .................................... 26 5.1.6 Parallel Subtype .................................. 27 5.1.7 Other Multipart Subtypes .......................... 28 5.2 Message Media Type .................................. 28 5.2.1 RFC822 Subtype .................................... 28 5.2.2 Partial Subtype ................................... 29 5.2.2.1 Message Fragmentation and Reassembly ............ 30 5.2.2.2 Fragmentation and Reassembly Example ............ 31 5.2.3 External-Body Subtype ............................. 33 5.2.4 Other Message Subtypes ............................ 40 6. Experimental Media Type Values ....................... 40 7. Summary .............................................. 41 8. Security Considerations .............................. 41 9. Authors' Addresses ................................... 42 A. Collected Grammar .................................... 43

1.2 概要

1. Introduction

MIMEを規定する一連の標準仕様書(TS)及び標準情報(TR)の最初であって,RFC 2045を原規定とするTR X 0069は,Content-Typeを含む多くののフィールドを定義している。 Content-Typeフィールドは,メディア型及び下位型の識別子を与えること並びに特定のメディア型で要求してよい外部情報を提供することによって,MIME実体の本体中のデータの性質を指定するために使われる。 メディア型名及び下位型名の後のヘッダフィールドの残りは,単純に,属性/値の記法で指定されるパラメタの組である。 パラメタの順番は区別しない。

The first document in this set, RFC 2045, defines a number of header fields, including Content-Type. The Content-Type field is used to specify the nature of the data in the body of a MIME entity, by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute/value notation. The ordering of parameters is not significant.

一般的に,最上位メディア型は,データの一般の型を宣言するために使われ,下位型は,そのデータの型の特定のフォーマットを指定するために使われる。 "image/xyz"というメディア型は,利用者エージェントが"xyz"という特定の画像フォーマットに関して知識をもたない場合でも,そのデータが画像であるということを利用者エージェントに知らせるのに十分である。 この様な情報は,例えば,認識されない下位型から生データを利用者に見せるのかどうかを決めるために,使うことができる。この様な動作は,"text"の認識されない下位型には妥当であるかもしれないが,"image"又は"audio"の認識されない下位型には妥当でない。 この理由から,"text","image","audio"及び"video"の登録された下位型には,型とは実際に異なる組み込んだ情報を,含まないほうがよい。 このような複合フォーマットは,"multipart"型又は"application"型を使って表現したほうがよい。

  In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of "image/xyz" is enough to tell a user agent that the data is an image, even if the user agent has no knowledge of the specific image format "xyz". Such information can be used, for example, to decide whether or not to show a user the raw data from an unrecognized subtype -- such an action might be reasonable for unrecognized subtypes of "text", but not for unrecognized subtypes of "image" or "audio". For this reason, registered subtypes of "text", "image", "audio", and "video" should not contain embedded information that is really of a different type. Such compound formats should be represented using the "multipart" or "application" types.

パラメタは,メディア下位型の修飾子だから,基本的には内容の性質に影響を与えてはならない。 意味のあるパラメタの組は,メディア型と下位型に依存する。 大部分のパラメタは,単一の特定の下位型と関連する。 しかし,与えられた最上位メディア型は,その型のどの下位型にも適用可能なパラメタを定義してよい。 パラメタは,それらを定義するメディア型又は下位型に対して,必須であってもよいし,オプションであってもよい。 MIME実装は,認識しないすべてのパラメタ名を,無視しなければならない。

Parameters are modifiers of the media subtype, and as such do not fundamentally affect the nature of the content. The set of meaningful parameters depends on the media type and subtype. Most parameters are associated with a single specific subtype. However, a given top-level media type may define parameters which are applicable to any subtype of that type. Parameters may be required by their defining media type or subtype or they may be optional. MIME implementations must also ignore any parameters whose names they do not recognize.

MIMEのContent-Typeヘッダフィールド及びメディア型の機構は,拡張性をもつように注意深く設計されていて,メディア型/下位型の対の組及びそれらに関連するパラメタが,時間が経つにつれて,著しく増加していくことが期待される。 転送符号化及び"message/external-body"アクセス型の様な,多くの他のMIME機能は,時間が経つにつれて,新しい値を持つことになりそうである。 この様な値の組が,順序良く,上手な定義で,公的な方法で,開発されることを確実にするため,MIMEは,MIMEの多くの拡張性の領域のための中央の登録簿としてInternet Assigned Numbers Authority (IANA)を使った登録処理を設定する。 これらの領域の登録処理については,この標準仕様書(TS)と組をなすRFC 2048を原規定とする標準仕様書(TS)(1)で規定する。

MIME's Content-Type header field and media type mechanism has been carefully designed to be extensible, and it is expected that the set of media type/subtype pairs and their associated parameters will grow significantly over time. Several other MIME facilities, such as transfer encodings and "message/external-body" access types, are likely to have new values defined over time. In order to ensure that the set of such values is developed in an orderly, well-specified, and public manner, MIME sets up a registration process which uses the Internet Assigned Numbers Authority (IANA) as a central registry for MIME's various areas of extensibility. The registration process for these areas is described in a companion document, RFC 2048.

この標準仕様書(TS)の残りの部分では,七つの標準の初期の最上位メディア型を定義及び記述する。

The initial seven standard top-level media type are defined and described in the remainder of this document.

2. 最上位メディア型の定義

2. Definition of a Top-Level Media Type

最上位メディア型の定義は次からなる。

The definition of a top-level media type consists of:
  1. 型の名前及び記述。特定の型がその型に認定されるかどうかの基準を含む。
  2. (1) a name and a description of the type, including criteria for whether a particular type would qualify under that type,
  3. パラメタの名前及び定義。もしあれば,パラメタが必須又はオプションかを含め,そのパラメタがその型の下位型のすべてに対して定義されたものかどうか。
  4. (2) the names and definitions of parameters, if any, which are defined for all subtypes of that type (including whether such parameters are required or optional),
  5. 利用者エージェント及び/又はゲートウェイが,この型の未知の下位型をどのように扱うとよいか。
  6. (3) how a user agent and/or gateway should handle unknown subtypes of this type,
  7. もしあれば,この最上位の型の実体をゲートウェイするときに一般的に考慮すること。
  8. (4) general considerations on gatewaying entities of this top-level type, if any, and
  9. この最上位型の実体のためのcontent-transfer-encodings上の制限。
(5) any restrictions on content-transfer-encodings for entities of this top-level type.

3. 初期の最上位メディア型の概要

3. Overview Of The Initial Top-Level Media Types

五つの個別最上位メディア型は次のとおりとする。

The five discrete top-level media types are:
  1. text
    テキストによる情報。 とりわけ,下位型"plain"は,フォーマット命令又はどんな種類の指示も含まないプレーンテキストを表す。 プレーンテキストは"現状のまま"で表示されることが想定される。 指示された文字集合がサポートされていれば,テキストの完全な意味を得るために,特別なソフトウェアを必要としない。 その他の下位型は,アプリケーションソフトウェアがテキストの見映えを強調してよい形式の,フォーマット付テキストに使われるが,その場合は,内容の一般的な理解のためにそのようなソフトウェアを必要としてはならない。 ゆえに"text"の可能な下位型は,フォーマットを理解するソフトウェアに頼らなくても読むことが可能な,ワードプロセッサのフォーマットを含む。 特に単純で可搬性のある下位型は,RFC 1341で定義された"richtext"であり,RFC 1896では,"enriched"という名前で改定された。
  2. (1) text -- textual information. The subtype "plain" in particular indicates plain text containing no formatting commands or directives of any sort. Plain text is intended to be displayed "as-is". No special software is required to get the full meaning of the text, aside from support for the indicated character set. Other subtypes are to be used for enriched text in forms where application software may enhance the appearance of the text, but such software must not be required in order to get the general idea of the content. Possible subtypes of "text" thus include any word processor format that can be read without resorting to software that understands the format. In particular, formats that employ embeddded binary formatting information are not considered directly readable. A very simple and portable subtype, "richtext", was defined in RFC 1341, with a further revision in RFC 1896 under the name "enriched".
  3. image
    画像データ。 "image"は,情報を見るために,画像ディスプレイ,画像プリンタ又はファクス機器のような表示機器を必要とする。 広く使われている画像フォーマットであるJPEGのための初期の下位型を定義する。
  4. (2) image -- image data. "Image" requires a display device (such as a graphical display, a graphics printer, or a FAX machine) to view the information. An initial subtype is defined for the widely-used image format JPEG. . subtypes are defined for two widely-used image formats, jpeg and gif.
  5. audio
    音声データ。 "audio"は,内容を提示するために,スピーカ又は電話のような音声出力機器を必要とする。 この標準仕様書(TS)では,初期の下位型"basic"を定義する。
  6. (3) audio -- audio data. "Audio" requires an audio output device (such as a speaker or a telephone) to "display" the contents. An initial subtype "basic" is defined in this document.
  7. video
    映像データ。 "video"は,典型的には特別なハードウェアとソフトウェアを含め,映像を表示するための性能を必要とする。 この標準仕様書(TS)では,初期の下位型"mpeg"を定義する。
  8. (4) video -- video data. "Video" requires the capability to display moving images, typically including specialized hardware and software. An initial subtype "mpeg" is defined in this document.
  9. application
    典型的には,アプリケーションにより処理される,解釈されない2値データ又は情報。 解釈できない2値データの場合は,下位型"octet-stream"が使われ,この場合の最も単純な動作は情報をファイルに書き出すことを利用者に提供することである。 PostScriptのデータを転送するために,"PostScript"下位型も定義する。 その他に期待される"application"の使用法には,表計算,メールを利用したスケジュール管理システムのデータ,"能動的"(計算的)メッセージングのための言語,直接は読むことのできないワードプロセッサのフォーマットを含む。 いくつかの型のアプリケーションデータ,特に"application/PostScript"及びどんな形式であれ,能動的メッセージには,セキュリティに関する考慮が存在するかもしれないので注意すること。 これらの論点に関してはこの標準仕様書(TS)の後の方で論じる。
  10. (5) application -- some other kind of data, typically either uninterpreted binary data or information to be processed by an application. The subtype "octet- stream" is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user. The "PostScript" subtype is also defined for the transport of PostScript material. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) messaging, and word processing formats that are not directly readable. Note that security considerations may exist for some types of application data, most notably "application/PostScript" and any form of active messaging. These issues are discussed later in this document.

二つの複合の最上位メディア型は次のとおりとする。

The two composite top-level media types are:
  1. multipart
    複数の独立なデータ型の実体からなるデータ。 次の四つの下位型が初期に定義される。 基本的な"mixed"下位型は,はん(汎)用の混合の部分の組を指定する。 "alternative"は,同じデータを複数のフォーマットで表現する。 "parallel"は,部分を同時に見ることを想定する。 "digest"は,それぞれの部分が"message/rfc822"というデフォルトの型をもつマルチパート実体である。
  2. (1) multipart -- data consisting of multiple entities of independent data types. Four subtypes are initially defined, including the basic "mixed" subtype specifying a generic mixed set of parts, "alternative" for representing the same data in multiple formats, "parallel" for parts intended to be viewed simultaneously, and "digest" for multipart entities in which each part has a default type of "message/rfc822". Freed & Borenstein Standards Track [Page 5] RFC 2046 Media Types November 1996
  3. message
    カプセル化されたメッセージ。 メディア型"message"の本体は,それ自体で,ある種類のメッセージオブジェクトの全部又は一部とする。 このようなオブジェクトは,さらに,他の実体を含んでもよいし,含まなくてもよい。 カプセル化されたメッセージ自体がRFC 822メッセージである場合,下位型"rfc822"が使われる。 転送機能へ一つのメッセージとして渡すには大きすぎると考えられる場合,本体を細分化した転送を許容するため,部分的なRFC 822メッセージとして,下位型"partial"を定義する。 もう一つの下位型"external-body"は,外部のデータ源への参照により,大きい本体を指定するために,定義する。
  4. (2) message -- an encapsulated message. A body of media type "message" is itself all or a portion of some kind of message object. Such objects may or may not in turn contain other entities. The "rfc822" subtype is used when the encapsulated content is itself an RFC 822 message. The "partial" subtype is defined for partial RFC 822 messages, to permit the fragmented transmission of bodies that are thought to be too large to be passed through transport facilities in one piece. Another subtype, "external-body", is defined for specifying large bodies by reference to an external data source.

ここで与えられたメディア型の一覧は,上記の機構によって,時間の経過と共に拡張され,下位型の組は大いに増えていくことが予期されることを心に留めておいたほうがよい。

It should be noted that the list of media type values given here may be augmented in time, via the mechanisms described above, and that the set of subtypes is expected to grow substantially.

4. 個別メディア型値

4. Discrete Media Type Values

七つの初期のメディア型値のうちの五つは,個別の本体を参照する。 これらの型の内容は,MIME処理系では処理せず,非MIME機構で処理されなければならない。

Five of the seven initial media type values refer to discrete bodies. The content of these types must be handled by non-MIME mechanisms; they are opaque to MIME processors.

4.1 textメディア型

4.1. Text Media Type

"text"メディア型は,原則として形式的にテキストのデータを送ることを想定する。 特にプレーンテキストのためのはん(汎)用下位型である"text/plain"下位型を含め,"text"の下位型の本体テキストの文字集合を指示するために,"charset"パラメタを使ってよい。 プレーンテキストは,フォーマット命令,フォント属性指定,処理命令,解釈指示又は内容マーク付けを提供も許容もしない。 プレーンテキストは,行区切り又はページ区切りに割り込まれることはあるが,単純に線形な文字の列に見える。 プレーンテキストは,いくつかの文字をテキスト中の同じ位置に積み重ねることを,許してよい。 アラビア語やヘブライ語のようなスクリプト中でのプレーンテキストでは,逆筆記方向のテキストの区間の任意な混合を許す機能を含めてよい。

The "text" media type is intended for sending material which is principally textual in form. A "charset" parameter may be used to indicate the character set of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text. Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks. Plain text may allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilitites that allow the arbitrary mixing of text segments with opposite writing directions.

プレーンテキスト以上の,”リッチテキスト”として知られているようなものを表現するために,多くのフォーマットがある。 多くのそのような表現の興味深い特徴は,それらを解釈するソフトウェアがないときでさえ,ある程度は読めるということである。 そして,読めないデータを,画像,音声又は読めない形式で表現されたテキストとして,最上位で区別することは有用である。 適当な解釈ソフトウェアがない場合,"text"の下位型のデータを利用者に見せることは妥当であるが,ほとんどの場合非テキストデータを見せることは妥当でない。 フォーマットされたテキストデータは,"text"の下位型を使って表現されるのがよい。

Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful, then, to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Such formatted textual data should be represented using subtypes of "text".

4.1.1 行区切りの表現

4.1.1. Representation of Line Breaks

全てのMIMEの"text"下位型の正準形式は,いつでも行区切りをCRLF列として表さなければならない。同様に,MIMEの"text"中のCRLFの発生は,行区切りを表さなければならない。CR及びLFを行区切り列以外に使うことも禁止される。

The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden.

この規則は,フォーマット又は関係する文字集合にかかわらず適用する。

This rule applies regardless of format or character set or sets involved.

備考  本体が表示されるときの,行区切りの正しい解釈は,メディア型に依存する。 特に,"text/plain"本体を表示するとき,行区切りを新しい行への移動として扱うことは適当だが, "text/enriched" (RFC 1896を参照)のような"text"の他の下位型に対しては,この扱いは,実際に誤りである。 同様に,表示操作中行区切りを加えるのがよいかどうかも,メディア型の機能である。 "text/enriched"の正しい表示には適当な行区切りの付加を要求するが,"text/plain"を正しく表示するためには行区切りは加える必要がない方がよい。

NOTE: The proper interpretation of line breaks when a body is displayed depends on the media type. In particular, while it is appropriate to treat a line break as a transition to a new line when displaying a "text/plain" body, this treatment is actually incorrect for other subtypes of "text" like "text/enriched" [RFC-1896]. Similarly, whether or not line breaks should be added during display operations is also a function of the media type. It should not be necessary to add any line breaks to display "text/plain" correctly, whereas proper display of "text/enriched" requires the appropriate addition of line breaks.

備考  いくつかのプロトコルは最大行長を定義する。 例えば,SMTP [RFC-821]では,次のCRLF列の前に最大998オクテットを許容する。 このようなプロトコルによって転送されるためには,CRLF列なしに長すぎる区間を含むデータは,適当なcontent-transfer-encodingで符号化されなければならない。

NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC- 821] allows a maximum of 998 octets before the next CRLF sequence. To be transported by such protocols, data which includes too long segments without CRLF sequences must be encoded with a suitable content-transfer-encoding.

4.1.2 charsetパラメタ

4.1.2. Charset Parameter

"text/plain"データのためにContent-Typeフィールド中に指定されてよい重要なパラメタは,文字集合である。これは"charset"パラメタで,次のように指定される。

Content-type: text/plain; charset=iso-8859-1

A critical parameter that may be specified in the Content-Type field for "text/plain" data is the character set. This is specified with a "charset" parameter, as in: Content-type: text/plain; charset=iso-8859-1

その他いくつかのパラメタ値とは違って,charsetパラメタの値は,大文字小文字を区別しない。 charsetパラメタがないときに仮定されなければならない,デフォルトの文字集合は,US-ASCIIとする。

Unlike some other parameter values, the values of the charset parameter are NOT case sensitive. The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.

"text"の将来のどんな下位型の仕様も,"charset"パラメタも利用するかどうかを規定しなければならず,さらに場合によってはその値を制限してもよい。 "text/plain"以外の"text"の下位型では,"charset"パラメタのセマンティクスは,"text/plain"のためにここで指定されたものと同一となるように定義したほうがよい。すなわち,本体は,すべて,与えられた文字集合内の文字からなる。 特に,将来の"text"の下位型を定義する者は,下位型の定義における複数オクテット文字集合の関わり合いについて,よく注意したほうがよい。

The specification for any future subtypes of "text" must specify whether or not they will also utilize a "charset" parameter, and may possibly restrict its values as well. For other subtypes of "text" than "text/plain", the semantics of the "charset" parameter should be defined to be identical to those specified here for "text/plain", i.e., the body consists entirely of characters in the given charset. In particular, definers of future "text" subtypes should pay close attention to the implications of multioctet character sets for their subtype definitions.

"text"の下位型の文字集合パラメタは,TR X 0069で定義される"文字集合"のとおりに,文字集合の名前を与える。 4.1.1で詳しく規定している行区切りに関する規則も,遵守されなければならない。 これらの規則に適合しない定義をもつ文字集合は,MIMEの"text"の下位型で使うことはできない。

The charset parameter for subtypes of "text" gives a name of a character set, as "character set" is defined in RFC 2045. The rules regarding line breaks detailed in the previous section must also be observed -- a character set whose definition does not conform to these rules cannot be used in a MIME "text" subtype.

あらかじめ定義された文字集合名の初期の一覧は,この箇条の最後にある。 追加の文字集合はIANAによって登録してよい。

An initial list of predefined character set names can be found at the end of this section. Additional character sets may be registered with IANA.

"text"の下位型の他のメディア型は,CRLF又は行区切りの制限を排除して,ここで定義されたcharsetパラメタを使うことを選んでもよい。 したがって,TR X 0069の"文字集合"の一般的な定義に適合する,すべての文字集合は,MIMEでの使用のために登録できる。

Other media types than subtypes of "text" might choose to employ the charset parameter as defined here, but with the CRLF/line break restriction removed. Therefore, all character sets that conform to the general definition of "character set" in RFC 2045 can be registered for MIME use.

もし,指定された文字集合が8ビット文字を含み,このような文字が本体に使われたら,SMTP [RFC-821]のようないくつかのメール転送プロトコルを通した本体の転送のために,Content-Transfer-Encodingヘッダフィールド及びデータへの対応する符号化が,要求されることに注意すること。

Note that if the specified character set includes 8-bit characters and such characters are used in the body, a Content-Transfer-Encoding header field and a corresponding encoding on the data are required in order to transmit the body via some mail transfer protocols, such as SMTP [RFC-821].

デフォルトの文字集合US-ASCIIは,過去にはいくつかの混乱とあいまい性があった。 定義におけるいくつかのあいまい性だけでなく,実践において広い多様性があった。 このようなあいまい性と多様性を将来なくすため,新しい利用者エージェントは,"Content-Type"ヘッダフィールドのメディア型のパラメタとして,明示的に文字集合を指定することを強く推奨する。 "US-ASCII"は,任意の7ビット文字集合を指すのでなく,本体中の全てのオクテットは,US-ASCII文字集合に従った文字として解釈されなければならない。 ISO 646 [ISO-646]の,国内版及びアプリケーション指向版は,通常は,US-ASCIIと同一ではなく,インターネットメールにおけるそれらの使用は,やめたほうがよいことは明らかである。 この標準仕様書(TS)からISO 646文字集合を省くことは,慎重に考えられたことである。 文字集合名"US-ASCII"は,ANSI X3.4-1986 [US-ASCII]で定義される文字集合を,明示的に参照する。 ISO 646の1991年版である新しい国際参照版(IRV)は,US-ASCIIと同一である。 文字集合名"ASCII"は予約済みであり,どんな目的にも使ってはならない。

The default character set, US-ASCII, has been the subject of some confusion and ambiguity in the past. Not only were there some ambiguities in the definition, there have been wide variations in practice. In order to eliminate such ambiguity and variations in the future, it is strongly recommended that new user agents explicitly specify a character set as a media type parameter in the Content-Type header field. "US-ASCII" does not indicate an arbitrary 7-bit character set, but specifies that all octets in the body must be interpreted as characters according to the US-ASCII character set. National and application-oriented versions of ISO 646 [ISO-646] are usually NOT identical to US-ASCII, and in that case their use in Internet mail is explicitly discouraged. The omission of the ISO 646 character set from this document is deliberate in this regard. The character set name of "US-ASCII" explicitly refers to the character set defined in ANSI X3.4-1986 [US- ASCII]. The new international reference version (IRV) of the 1991 edition of ISO 646 is identical to US-ASCII. The character set name "ASCII" is reserved and must not be used for any purpose.

備考  RFC 821は,明示的に"ASCII"を指定していて,米国規格の初期の版を参照している。 メディア型及び文字集合を指定する目的の一つが,送信者が解釈される符号化されたメッセージをどのように意図したかを,受信者があいまい性なく決定することを許すことである限りは, デフォルトとしての"厳密なASCII"以外のどんなものも仮定することは,今送信されているメッセージのセマンティクスへの意図しない及び互換性のない変更の危険を起こすであろう。 US-ASCII及び1991 IRV以外のISO 646の他の版に従って符号化された文字を含むメッセージ, 又は,例えばISO 2022の符号切り換え手続きは,8ビット又は複数オクテット文字符号化と同様, MIMEと矛盾しない適切な文字集合指定を使わなければならないことも,示唆する。

NOTE: RFC 821 explicitly specifies "ASCII", and references an earlier version of the American Standard. Insofar as one of the purposes of specifying a media type and character set is to permit the receiver to unambiguously determine how the sender intended the coded message to be interpreted, assuming anything other than "strict ASCII" as the default would risk unintentional and incompatible changes to the semantics of messages now being transmitted. This also implies that messages containing characters coded according to other versions of ISO 646 than US-ASCII and the 1991 IRV, or using code-switching procedures (e.g., those of ISO 2022), as well as 8bit or multiple octet character encodings MUST use an appropriate character set specification to be consistent with MIME.

完全なUS-ASCII文字集合は,ANSI X3.4-1986に列挙されている。 改行を識別する組合せCRLF(US-ASCII値の13及び10)以外は,DELを含む制御文字(0-31, 127)に,定義された意味は何もないことに注意すること。 次の二つの文字は,広く使われている事実上の意味がある。 FF(12)は"続きのテキストは新しいページの先頭から始める"ことをしばしば意味する。TAB又はHT(9)は,いつもではないけれども,"初めのカラムをカラム0と数えて,現在のカラムより後の次の可能な8の倍数のカラム番号へカーソルを動かす"ことを意味する。 これらの規約とは別に,本体中での制御文字又はDELの使用は,次のどちらかで生じる。

The complete US-ASCII character set is listed in ANSI X3.4- 1986. Note that the control characters including DEL (0-31, 127) have no defined meaning in apart from the combination CRLF (US-ASCII values 13 and 10) indicating a new line. Two of the characters have de facto meanings in wide use: FF (12) often means "start subsequent text on the beginning of a new page"; and TAB or HT (9) often (though not always) means "move the cursor to the next available column after the current position where the column number is a multiple of 8 (counting the first column as column 0)." Aside from these conventions, any use of the control characters or DEL in a body must either occur
  1. "plain"以外の下位型が,いくつかの追加の意味を具体的に割り当てる場合。 (1) because a subtype of text other than "plain" specifically assigns some additional meaning, or

    又は

  2. 送信者と受信者の間の私的な合意の状況の場合。 このような私的な合意は,やめたほうがよく,この標準仕様書(TS)で規定する他の機能におきかえたほうがよい。
  3. (2) within the context of a private agreement between the sender and recipient. Such private agreements are discouraged and should be replaced by the other capabilities of this document.

備考  US-ASCII以外にも多くの異なった文字集合が存在する。 部分的又は全体的に重なる文字集合がたくさんあることはよいことではない。 インターネットメールで,世界中の言語の全てを表現できて万国共通に使える,単一の文字集合が好ましい。 しかし,多くのコミュニティでの実在の実践は,近い将来のうちには複数の文字集合を使い続けることに向いている。 したがって,この標準仕様書(TS)では少数の標準的な文字集合を定義する。

NOTE: An enormous proliferation of character sets exist beyond US- ASCII. A large number of partially or totally overlapping character sets is NOT a good thing. A SINGLE character set that can be used universally for representing all of the world's languages in Internet mail would be preferrable. Unfortunately, existing practice in several communities seems to point to the continued use of multiple character sets in the near future. A small number of standard character sets are, therefore, defined for Internet use in this document.

定義するcharset値は次とする。

The defined charset values are:
  1. US-ASCII
    ANSI X3.4-1986 [US-ASCII]で定義される文字集合。
  2. (1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII].
  3. ISO-8859-X
    "X"の部分は,ISO-8859 [ISO-8859]の部分のために,必要に応じて置換する。 インターネットメールで指定された文字集合である,それら8859置換の方を優先し,ISO 646文字集合はわざと省いていることを注記しておく。 この標準仕様書(TS)の原規定のRFC 2046が公表された時点では,"X"の値として数字の1から10が合法である。
  4. (2) ISO-8859-X -- where "X" is to be replaced, as necessary, for the parts of ISO-8859 [ISO-8859]. Note that the ISO 646 character sets have deliberately been omitted in favor of their 8859 replacements, which are the designated character sets for Internet mail. As of the publication of this document, the legitimate values for "X" are the digits 1 through 10.

128-159の範囲の文字は,ISO-8859-Xでは,指定された意味をもたない。 ISO-8859-Xの128より小さい値の文字は,US-ASCIIと同じ指定された意味をもつ。

Characters in the range 128-159 has no assigned meaning in ISO-8859- X. Characters with values below 128 in ISO-8859-X have the same assigned meaning as they do in US-ASCII.

ISO 8859の第6部(ラテンアルファベット及びアラビアアルファベット)及び第8部(ラテンアルファベット及びヘブライアルファベット)は,左から右への普通の筆記方向の文字及び右から左への反対の筆記方向の文字を両方含むが,双方向テキストを表現するための正準的な順序付け方法は定義していない。 しかし,"ISO-8859-6"及び"ISO-8859-8"のcharset値は,視覚的な方法が使われることを指定する [RFC-1556]。

Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew alphabet) includes both characters for which the normal writing direction is right to left and characters for which it is left to right, but do not define a canonical ordering method for representing bi-directional text. The charset values "ISO-8859-6" and "ISO-8859- 8", however, specify that the visual method is used [RFC-1556].

これらすべての文字集合は,シフト機能又はエスケープ機能なしの,純粋な7ビット又は8ビット集合として使うものとする。 これら文字集合のシフト及びエスケープシーケンスの意味は定義しない。

All of these character sets are used as pure 7bit or 8bit sets without any shift or escape functions. The meaning of shift and escape sequences in these character sets is not defined.

上記で規定された文字集合は,MIMEの原案作成中比較的自由なものであった。 この標準仕様書(TS)は,US-ASCII以外の特定のどんな文字集合の使用も支持せず,世界文字集合の将来の進化が不明確なままであることを認識する。

The character sets specified above are the ones that were relatively uncontroversial during the drafting of MIME. This document does not endorse the use of any particular character set other than US-ASCII, and recognizes that the future evolution of world character sets remains unclear.

US-ASCII以外の文字集合の使用する場合は必ずContent-Typeフィールドに明示的に指定されなければならないことに注意すること。

Note that the character set used, if anything other than US- ASCII, must always be explicitly specified in the Content-Type field.

上記で定義された以外のどんな文字集合名も,公式の仕様の出版及びIANAでの登録,又は,私的な合意によるものでなければならない。私的な合意により使う場合は,"X-"で始まらなければならない。

No character set name other than those defined above may be used in Internet mail without the publication of a formal specification and its registration with IANA, or by private agreement, in which case the character set name must begin with "X-".

実装者は,絶対的に必要な場合を除き,新しい文字集合を定義しないほうがよい。

Implementors are discouraged from defining new character sets unless absolutely necessary.

"charset"パラメタは,主としてテキストデータのために定義されていて,そのために,この箇条に記述されている。 しかし,何らかの目的で,同じ構文と値が使われるほうがよいときには,非テキストデータでもcharset値を指定したい場合が考えられる。

The "charset" parameter has been defined primarily for the purpose of textual data, and is described in this section for that reason. However, it is conceivable that non-textual data might also wish to specify a charset value for some purpose, in which case the same syntax and values should be used.

一般的にいって,文書作成ソフトウェアは,可能な限りいつも”一番小さい共通の”文字集合を使用するのがよい。 例えば,本体がUS-ASCII文字だけを含む場合,すべてのISO-8859ファミリと同様にUS-ASCIIのスーパセットであるISO-8859-1とするのではなく,US-ASCII文字集合として,マーク付けするのがよい。 もっと一般的にいえば,広く使われている文字集合がもう一つの広く使われている文字集合のサブセットであった場合,本体が広く使われているサブセットの文字だけを含むならば,それはサブセットが使われているとラベル付けするのがよい。 これは,受信者が結果の実体を正しく見ることができる機会を,増やすことになる。

In general, composition software should always use the "lowest common denominator" character set possible. For example, if a body contains only US-ASCII characters, it SHOULD be marked as being in the US- ASCII character set, not ISO-8859-1, which, like all the ISO-8859 family of character sets, is a superset of US-ASCII. More generally, if a widely-used character set is a subset of another character set, and a body contains only characters in the widely-used subset, it should be labelled as being in that subset. This will increase the chances that the recipient will be able to view the resulting entity correctly.

4.1.3 plain下位型

4.1.3. Plain Subtype

最も単純で最も重要な"text"の下位型は"plain"である。 これは,フォーマット命令又はフォーマット指示を含まない,プレーンテキストを示す。 プレーンテキストは,"そのまま"表示されることが意図される。 すなわち,適正な表示のために,組み込まれたフォーマット命令,フォント属性指定,処理命令,解釈指示又は内容マーク付けの解釈を必要としないほうがよい。 インターネットメールのためのデフォルトのメディア型"text/plain; charset=us-ascii"は,既存のインターネット実践を記述する。 すなわち,これはRFC 822で定義される本体の型である。

The simplest and most important subtype of "text" is "plain". This indicates plain text that does not contain any formatting commands or directives. Plain text is intended to be displayed "as-is", that is, no interpretation of embedded formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup should be necessary for proper display. The default media type of "text/plain; charset=us-ascii" for Internet mail describes existing Internet practice. That is, it is the type of body defined by RFC 822.

他の"text"の下位型は,この標準仕様書(TS)では,定義されない。

No other "text" subtype is defined by this document.

4.1.4 認識されない下位型

4.1.4. Unrecognized Subtypes

"text"の認識されない下位型は,MIME実装がcharsetをどう処理するかを知っている限りは,"plain"下位型として扱うのがよい。 認識されないcharsetも指定している,認識されない下位型は,"application/octet-stream"として扱うのがよい。

Unrecognized subtypes of "text" should be treated as subtype "plain" as long as the MIME implementation knows how to handle the charset. Unrecognized subtypes which also specify an unrecognized charset should be treated as "application/octet- stream".

4.2 imageメディア型

4.2. Image Media Type

メディア型"image"は,本体が画像を含むことを指示する。 下位型は,特定の画像フォーマットを,名前付けする。 これらの名前は,大文字小文字を区別しない。 初期の下位型は,JFIF符号化[JPEG]を使ったJPEGフォーマットのための,"jpeg"とする。

A media type of "image" indicates that the body contains an image. The subtype names the specific image format. These names are not case sensitive. An initial subtype is "jpeg" for the JPEG format using JFIF encoding [JPEG].

"image"の下位型の一覧は,排他的でもすべてでもなく,ここで与えられ,これ以上の型は,RFC 2048を原規定とする標準仕様書(TS)(1)に記述されている とおりに,IANAで登録されて,増えていくことが期待される。

The list of "image" subtypes given here is neither exclusive nor exhaustive, and is expected to grow as more types are registered with IANA, as described in RFC 2048.

"image"の認識されない下位型は,少なくとも"application/octet-stream"として扱うのがよい。 実装は,安全で頑健なはん(汎)用画像表示アプリケーションが利用可能ならば,オプションで"image"の下位型をアプリケーションに渡してもよい。

Unrecognized subtypes of "image" should at a miniumum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of "image" that they do not specifically recognize to a secure and robust general-purpose image viewing application, if such an application is available.

備考  このようにしてはん(汎)用画像表示アプリケーションは,アプリケーションでサポートする最も危険なセキュリティ上の問題を受け継ぐ。

NOTE: Using of a generic-purpose image viewing application this way inherits the security problems of the most dangerous type supported by the application.

4.3 audioメディア型

4.3. Audio Media Type

メディア型"audio"は,本体が音声データを含むことを示す。 計算機で使う理想的な音声のフォーマットについては,いまだに合意が得られていないが,相互運用可能な振舞いを供給することの出来るフォーマットの強い必要性はある。

A media type of "audio" indicates that the body contains audio data. Although there is not yet a consensus on an "ideal" audio format for use with computers, there is a pressing need for a format capable of providing interoperable behavior.

初期の下位型"basic"は,絶対的に一番小さい共通の音声フォーマットを提供することによって,この要求に答えるために規定された。 より高品質及び/又はより狭帯域音声のためのより高度なフォーマットは,今後の文書で定義されることが期待される。

The initial subtype of "basic" is specified to meet this requirement by providing an absolutely minimal lowest common denominator audio format. It is expected that richer formats for higher quality and/or lower bandwidth audio will be defined by a later document.

"audio/basic"下位型の内容は,標本化周波数8000Hzで,8ビットのISDNの μ則[PCM]により符号化された,単一チャネル音声とする。

The content of the "audio/basic" subtype is single channel audio encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz.

"audio"の認識されない下位型は,最低でも,"application/octet-stream"として扱うのがよい。 実装は,オプションで,明確には認識しない"audio"の下位型を,頑健な一般用途音声再生アプリケーションへ,そのようなアプリケーションが利用可能であれば,渡してよい。

Unrecognized subtypes of "audio" should at a miniumum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of "audio" that they do not specifically recognize to a robust general-purpose audio playing application, if such an application is available.

4.4 videoメディア型

4.4. Video Media Type

メディア型"video"は,本体が,時間につれて変動する画像を含むことを示す。 用語'video'は,特定の技術やフォーマットへの参照ではなく,最も一般的な感覚で使われ, それは小さく符号化されるアニメーションの描画のような下位型を排除することを意味しない。 下位型"mpeg"はMPEG標準に従って符号化された映像を参照する。

A media type of "video" indicates that the body contains a time- varying-picture image, possibly with color and coordinated sound. The term 'video' is used in its most generic sense, rather than with reference to any particular technology or format, and is not meant to preclude subtypes such as animated drawings encoded compactly. The subtype "mpeg" refers to video coded according to the MPEG standard [MPEG].

この標準仕様書(TS)では,一般的には単一の本体に複数のメディアを混ぜることを強く非推奨とするが, 多くのいわゆる映像フォーマットが同期した音声の表現を含むことが認識され, これは"video"の下位型として明確に許される。

Note that although in general this document strongly discourages the mixing of multiple media in a single body, it is recognized that many so-called video formats include a representation for synchronized audio, and this is explicitly permitted for subtypes of "video".

"video"の認識されない下位型は,少なくとも,"application/octet-stream"として扱うのがよい。 実装は,オプションで,明確には認識しない"video"の下位型を,頑健な一般用途映像再生アプリケーションへ,そのようなアプリケーションが利用可能であれば,渡してよい。

Unrecognized subtypes of "video" should at a minumum be treated as "application/octet-stream". Implementations may optionally elect to pass subtypes of "video" that they do not specifically recognize to a robust general-purpose video display application, if such an application is available.

4.5 applicationメディア型

4.5. Application Media Type

"application"メディア型は,他の種別には合致しない個別データ,特にいくつかの型のアプリケーションプログラムにより処理されるデータのために使われる。 これは,利用者により見えるようになる前に又は使えるようになる前に,アプリケーションにより処理されなければならない情報とする。 "application"メディア型の想定される使われ方は,ファイル転送,表計算,メールによるスケジュール管理システムのデータ,"能動的"(計算的)内容の言語を含む。 最後のものは,実装者によって理解されなければならないセキュリティ上の問題を起こし得,"application/PostScript"メディア型の議論で深く考える。

The "application" media type is to be used for discrete data which do not fit in any of the other categories, and particularly for data to be processed by some type of application program. This is information which must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" media type include file transfer, spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) material. (The latter, in particular, can pose security problems which must be understood by implementors, and are considered in detail in the discussion of the "application/PostScript" media type.)

例えば,会議スケジューラソフトウェアは,提案の会議日程についての情報の標準的な表現を,定義するかもしれない。 知的な利用者エージェントは,利用者に対話形式で案内するために,この情報を使うかもしれないし,この対話に基づき追加のデータを送るかもしれない。 もっと一般的には,適切に特化した言語によるプログラムが遠隔地に転送され,受信者の環境上で自動的に実行される,多くの"能動的"メッセージング言語が開発されている。

For example, a meeting scheduler might define a standard representation for information about proposed meeting dates. An intelligent user agent would use this information to conduct a dialog with the user, and might then send additional material based on that dialog. More generally, there have been several "active" messaging languages developed in which programs in a suitably specialized language are transported to a remote location and automatically run in the recipient's environment.

このようなアプリケーションは,"application"メディア型の下位型として定義されてよい。 この標準仕様書(TS)では二つの下位型,octet-stream及びPostScriptを定義する。

Such applications may be defined as subtypes of the "application" media type. This document defines two subtypes: octet-stream, and PostScript.

"application"の下位型は,データを想定する,アプリケーションの名前であるか又は名前の一部を含むことが多い。 しかし,このこことは,"application"の下位型として,任意のアプリケーションプログラムの名前を使ってよいことは,意味しない。

The subtype of "application" will often be either the name or include part of the name of the application for which the data are intended. This does not mean, however, that any application program name may be used freely as a subtype of "application".

4.5.1 octet-stream下位型

4.5.1. Octet-Stream Subtype

"octet-stream"下位型は,本体が任意の2値データを含むことを示すのに使う。 現在定義されているパラメタの組は,次の二つである。

The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. The set of currently defined parameters is:
  1. TYPE
    2値データの一般的な型又は分類。 これは,何らかの自動処理のためではなく,人間の受信者のための情報として意図される。
  2. (1) TYPE -- the general type or category of binary data. This is intended as information for the human recipient rather than for any automatic processing.
  3. PADDING
    含まれた8ビットバイト指向のデータを作るために実際の内容を構成するビットストリームに付加されたパディングのビット数。 これは,ビットの総数が8の倍数でないときに,本体中にビットストリームを入れるのに有用である。
  4. (2) PADDING -- the number of bits of padding that were appended to the bit-stream comprising the actual contents to produce the enclosed 8bit byte-oriented data. This is useful for enclosing a bit-stream in a body when the total number of bits is not a multiple of 8.

これらのどちらのパラメタもオプションとする。

Both of these parameters are optional.

追加のパラメタ"CONVERSIONS"がRFC 1341で定義されたが,その後削除された。 RFC 1341は,データをファイルに書き込むときに使われる,推奨されるファイル名のために"NAME"パラメタを使うことも定義している。 これは,後続するRFCで定義される,別の"Content-Disposition"ヘッダフィールドを見越して,非推奨とした。

An additional parameter, "CONVERSIONS", was defined in RFC 1341 but has since been removed. RFC 1341 also defined the use of a "NAME" parameter which gave a suggested file name to be used if the data were to be written to a file. This has been deprecated in anticipation of a separate Content-Disposition header field, to be defined in a subsequent RFC.

"aplication/octet-stream"実体を受け取ったときに,実装の推奨される動作は,Content-Transfer-Encodingを解除して,単純にデータをファイルに書き出すか,又は,多分利用者が指定した処理への入力として使うことである。

The recommended action for an implementation that receives an "application/octet-stream" entity is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone, or perhaps to use it as input to a user-specified process.

悪意のあるプログラムを転送する危険をなくすために,Content-Typeパラメタ(例えば,"interpreter="パラメタ)で名前付けされた任意のプログラムが見つかったら,メッセージ本体を入力として使って実行するという,経路探索機構を実装しないことと強く推奨する。

To reduce the danger of transmitting rogue programs, it is strongly recommended that implementations NOT implement a path-search mechanism whereby an arbitrary program named in the Content-Type parameter (e.g., an "interpreter=" parameter) is found and executed using the message body as input.

4.5.2 PostScript下位型

4.5.2. PostScript Subtype

"application/postscript"メディア型は,PostScriptのプログラムを示す。 現在,PostScript言語の二つの種類が許容される。 オリジナルのレベル1は[POSTSCRIPT]に記述され,より新しいレベル2[POSTSCRIPT2]に記述されている。

A media type of "application/postscript" indicates a PostScript program. Currently two variants of the PostScript language are allowed; the original level 1 variant is described in [POSTSCRIPT] and the more recent level 2 variant is described in [POSTSCRIPT2].

PostScriptはAdobe Systems Inc.の登録商標である。 MIMEメディア型"application/postscript"の使用は,登録商標及びそれに伴う一切の権利を認識することを暗示する。

PostScript is a registered trademark of Adobe Systems, Inc. Use of the MIME media type "application/postscript" implies recognition of that trademark and all the rights it entails.

PostScript言語定義は,与えられたプログラムが使用する,特定の言語の内部的なラベル付けのための機能を,提供する。 このPostScript文書構造化規約又はDSC(document structuring conventions)と呼ばれるラベル付けは,とても一般的であって,言語レベルだけでない十分に多くの情報を提供する。 文書構造化規約の使用は,要求はされないが,相互運用性のための補助として,強く推奨される。 適格な構造化規約を欠いた文書は,与えられた環境で動作するかどうかを見るための検証ができない。 このようにして,いくつかのシステムは,最悪を仮定してもよく,構造化されていない文書を処理することを拒否する。

The PostScript language definition provides facilities for internal labelling of the specific language features a given program uses. This labelling, called the PostScript document structuring conventions, or DSC, is very general and provides substantially more information than just the language level. The use of document structuring conventions, while not required, is strongly recommended as an aid to interoperability. Documents which lack proper structuring conventions cannot be tested to see whether or not they will work in a given environment. As such, some systems may assume the worst and refuse to process unstructured documents.

一般用途のPostScriptインタプリタの実行は,深刻なセキュリティ上の危険を伴い,実装者は,単純に"規格品の"インタプリタにPostScriptの本体を送ることは,しないほうがよい。 典型的なプリンタ環境では害を与える可能性が大いに制限されていて,通常はPostScriptをプリンタに送ることは安全だが, 実装者は,PostScript本体の対話的表示をMIME解読器に追加する前に,次の全てを考慮したほうがよい。

The execution of general-purpose PostScript interpreters entails serious security risks, and implementors are discouraged from simply sending PostScript bodies to "off- the-shelf" interpreters. While it is usually safe to send PostScript to a printer, where the potential for harm is greatly constrained by typical printer environments, implementors should consider all of the following before they add interactive display of PostScript bodies to their MIME readers.

この箇条の残りでは,多分すべてではないけれども,PostScript実体の転送に伴う,可能性のある問題についての概要を述べる。

The remainder of this section outlines some, though probably not all, of the possible problems with the transport of PostScript entities.
  1. PostScript言語の危険な操作は,PostScriptオペレータ"deletefile", "renamefile", "filenameforall"及び"file"を含むが,これだけとは限らない。 "file"は,標準入力又は標準出力以外の何かに適用するときだけ,危険である。 実装は,追加の非標準のファイルオペレータを定義するかも知れず,それらはセキュリティ上の脅威をを与えるかもしれない。 ワイルドカードファイル検索オペレータの"filenameforall"は,一見したところでは,無害に見えるかもしれない。 しかし,このオペレータは,受信者が,どのファイルにアクセスしているかについての情報を暴露する可能性があり,この情報自体が要注意なものである。 メッセージの送信者は,危険な可能性があるファイルオペレータを,セキュリティを考慮したPostScript実装ではこれらのオペレータは使えないであろうから,避けたほうがよい。 メッセージを受信及び表誦するソフトウェアは,全ての危険な可能性のあるファイルオペレータを完全に無効にするか,又は,これらの操作を行えるなんらかの特別な権威を委任しないように,特別の注意をするほうがよい。 これらのオペレータは,PostScript文書を解釈するとき,外部機関によって見られたほうがよい。 このような無効化及び/又は検証は,PostScript言語自体の及ぶ範囲の外側で,完全に行った方がよい。 これらのオペレータの完全機能版を再有効化するための方法が存在しないことを保証するように,特別な注意を払ったほうがよい。
  2. (1) Dangerous operations in the PostScript language include, but may not be limited to, the PostScript operators "deletefile", "renamefile", "filenameforall", and "file". "File" is only dangerous when applied to something other than standard input or output. Implementations may also define additional nonstandard file operators; these may also pose a threat to security. "Filenameforall", the wildcard file search operator, may appear at first glance to be harmless. Note, however, that this operator has the potential to reveal information about what files the recipient has access to, and this information may itself be sensitive. Message senders should avoid the use of potentially dangerous file operators, since these operators are quite likely to be unavailable in secure PostScript implementations. Message receiving and displaying software should either completely disable all potentially dangerous file operators or take special care not to delegate any special authority to their operation. These operators should be viewed as being done by an outside agency when interpreting PostScript documents. Such disabling and/or checking should be done completely outside of the reach of the PostScript language itself; care should be taken to insure that no method exists for re-enabling full- function versions of these operators.
  3. PostScript言語は,通常のインタプリタ又はサーバのループから抜け出す機能を提供している。 この"外部の"環境でなされる変更は,慣例上文書間でも保持され,場合によっては半永久的に不揮発性メモリに保持されるかもしれない。 インタプリタのループから抜け出すことに関連するオペレータは,後続の文書処理に干渉する可能性がある。 このようにして,これらの抑制されない使用は,サービス拒絶の脅威の構成要素となる。 インタプリタのループを抜け出すPostScriptオペレータは,これらだけには限らないが,exitserver及びstartjobオペレータである。 セキュリティを考慮したPostScript実装では,インタプリタのループを抜け出す能力は多分利用不可能だから,メッセージを送るソフトウェアは,動作するのにインタプリタのループを抜け出すことに依存するPostScriptは,生成しないほうがよい。 メッセージを受信し表示するソフトウェアは,"startjob"オペレータ又は"exitserver"オペレータを排除するか又は無効にすることによって,PostScript環境へ保持される変更を行える能力を,完全に無効にしたほうがよい。 もし,これらの操作が,排除されるか完全に無効に出来ない場合,少なくとも,これらに関連する想像されにくいパスワード値を設定したほうがよい。
  4. (2) The PostScript language provides facilities for exiting the normal interpreter, or server, loop. Changes made in this "outer" environment are customarily retained across documents, and may in some cases be retained semipermanently in nonvolatile memory. The operators associated with exiting the interpreter loop have the potential to interfere with subsequent document processing. As such, their unrestrained use constitutes a threat of service denial. PostScript operators that exit the interpreter loop include, but may not be limited to, the exitserver and startjob operators. Message sending software should not generate PostScript that depends on exiting the interpreter loop to operate, since the ability to exit will probably be unavailable in secure PostScript implementations. Message receiving and displaying software should completely disable the ability to make retained changes to the PostScript environment by eliminating or disabling the "startjob" and "exitserver" operations. If these operations cannot be eliminated or completely disabled the password associated with them should at least be set to a hard- to-guess value.
  5. PostScriptは,システム全体及び機器特有のパラメタを設定するオペレータを提供する。 これらのパラメタ設定は,ジョブ間で保持されるかもしれず,インタプリタの正しい処理への脅威となる可能性がある。 システムパラメタ及び機器パラメタを設定するPostScriptオペレータは,これらだけとは限らないが,"setsysemparams"オペレータ及び"setdevparams"オペレータである。 メッセージ送信ソフトウェアは,正しく動作するためにシステムパラメタ及び機器パラメタを設定することに依存するPostScriptを生成しないほうがよい。 これらのパラメタを設定する機能は,セキュリティを考慮したPostScript実装では,多分利用不可であろう。 もし,これらの操作が,排除されるか完全に無効に出来ない場合,少なくとも,これらに関連する想像されにくいパスワード値を設定したほうがよい。
  6. (3) PostScript provides operators for setting system-wide and device-specific parameters. These parameter settings may be retained across jobs and may potentially pose a threat to the correct operation of the interpreter. The PostScript operators that set system and device parameters include, but may not be limited to, the "setsystemparams" and "setdevparams" operators. Message sending software should not generate PostScript that depends on the setting of system or device parameters to operate correctly. The ability to set these parameters will probably be unavailable in secure PostScript implementations. Message receiving and displaying software should disable the ability to change system and device parameters. If these operators cannot be completely disabled the password associated with them should at least be set to a hard-to-guess value.
  7. いくつかのPostScript実装は,機械語を直接ロードし実行する,非標準の機能を提供する。 このような機能は,多くの悪用への道を開いていることが明白である。 メッセージ送信ソフトウェアは,このような機能の使用を生成しないほうがよい。 完全にハードウェア固有であるほか,これらも,PostScriptのセキュリティを考慮した実装では,おそらく使用不可である。 メッセージ受信及び表示ソフトウェアは,このようなオペレータが存在する場合,それらを使用することを許さないほうがよい。
  8. (4) Some PostScript implementations provide nonstandard facilities for the direct loading and execution of machine code. Such facilities are quite obviously open to substantial abuse. Message sending software should not make use of such features. Besides being totally hardware-specific, they are also likely to be unavailable in secure implementations of PostScript. Message receiving and displaying software should not allow such operators to be used if they exist.
  9. PostScriptは拡張性のある言語であって,ほとんどというほどではないにしろその多くの実装は,たくさんの固有の拡張を提供する。 この標準仕様書(TS)は,このような拡張については,未知の要素を構成するので,明示的には論じない。 メッセージ送信ソフトウェアは,非標準拡張の使用を生成しないほうがよい。 メッセージ受信及び表示ソフトウェアは,どの非標準のPostScriptオペレータもセキュリティを考慮されて,どんな種類の脅威も呈さないことを,確認したほうがよい。
  10. (5) PostScript is an extensible language, and many, if not most, implementations of it provide a number of their own extensions. This document does not deal with such extensions explicitly since they constitute an unknown factor. Message sending software should not make use of nonstandard extensions; they are likely to be missing from some implementations. Message receiving and displaying software should make sure that any nonstandard PostScript operators are secure and don't present any kind of threat.
  11. 幾つものシステム資源を大量に消費するPostScriptを書くことができる。無限に繰り返すPostScriptを書くこともできる。 どちらのタイプのプログラムも,疑うことのない受信者に送られたならば,障害を引き起こす可能性がある。 メッセージ送信ソフトウェアは,このような反社会的なプログラムの組立て又は拡散を避けたほうがよい。 メッセージ受信及び表示ソフトウェアは,ある程度の時間が経過したら,処理を中断する適当な機構を提供したほうがよい。 さらに,PostScriptインタプリタは,与えられたシステム資源のある程度の量だけを消費するように制限したほうがよい。
  12. (6) It is possible to write PostScript that consumes huge amounts of various system resources. It is also possible to write PostScript programs that loop indefinitely. Both types of programs have the potential to cause damage if sent to unsuspecting recipients. Message-sending software should avoid the construction and dissemination of such programs, which is antisocial. Message receiving and displaying software should provide appropriate mechanisms to abort processing after a reasonable amount of time has elapsed. In addition, PostScript interpreters should be limited to the consumption of only a reasonable amount of any given system resource.
  13. 幾つもの形式でPostScriptの中に2値の情報を含むことができる。 これは,全てのPostScriptインタプリタでサポートされていないという理由及びMIME Content-Tranfer-Encodingの使用を著しく複雑にするという理由で, インターネットメールでの使用は推奨されない。 このような2値なしでは,PostScriptは,典型的には,行指向データとして見られてよい。 2値及び行指向データが単一のPostScriptデータストリームに混ざっていた場合,CRLF列の振舞いは非常に問題となる。
  14. (7) It is possible to include raw binary information inside PostScript in various forms. This is not recommended for use in Internet mail, both because it is not supported by all PostScript interpreters and because it significantly complicates the use of a MIME Content- Transfer-Encoding. (Without such binary, PostScript may typically be viewed as line-oriented data. The treatment of CRLF sequences becomes extremely problematic if binary and line-oriented data are mixed in a single Postscript data stream.)
  15. 最後に,いくつかのPostScriptインタプリタには,受信者のシステムへの認証されないアクセスを得ることができるかもしれない,不具合が存在するかもしれない。 この可能性とは別に,このような不具合が発見された場合に,タイムリーに修正することのほかには,これを防ぐためにとる特定の措置はない。
  16. (8) Finally, bugs may exist in some PostScript interpreters which could possibly be exploited to gain unauthorized access to a recipient's system. Apart from noting this possibility, there is no specific action to take to prevent this, apart from the timely correction of such bugs if any are found.

4.5.3 その他のapplicationの下位型

4.5.3. Other Application Subtypes

将来には,多くの他の"application"の下位型が定義されることが期待される。 MIME実装は,最低限,認識されない下位型を"application/octet-stream"として取り扱わなければならない。

It is expected that many other subtypes of "application" will be defined in the future. MIME implementations must at a minimum treat any unrecognized subtypes as being equivalent to "application/octe stream".

5. 複合メディア型値

5. Composite Media Type Values

七つの初期のContent-Type値のうち,残る二つは,複合の実体を参照する。 複合の実体は,MIME機構を使って扱われる。すなわち,典型的には,MIME処理系が本体を直接扱う。

The remaining two of the seven initial Content-Type values refer to composite entities. Composite entities are handled using MIME mechanisms -- a MIME processor typically handles the body directly.

5.1 multipartメディア型値

5.1. Multipart Media Type

単一の本体の中に一つ以上の異なるデータの組が結合される マルチパート実体の場合,実体のヘッダの中に"multipart"メディア型フィールドが現れなければならない。 本体は,一つ以上の本体部分を含まなければならず,それぞれの部分は境界区切り子行が先行し,最後の部分に終了境界区切り子行が後続している。 境界区切り子行の後,それぞれの本体部分は,ヘッダ領域,空白行及び本体領域からなる。ゆえに,本体部分は,構文上はRFC 822メッセージに似ているが, 意味は異なる。

In the case of multipart entities, in which one or more different sets of data are combined in a single body, a "multipart" media type field must appear in the entity's header. The body must then contain one or more body parts, each preceded by a boundary delimiter line, and the last one followed by a closing boundary delimiter line. After its boundary delimiter line, each body part then consists of a header area, a blank line, and a body area. Thus a body part is similar to an RFC 822 message in syntax, but different in meaning.

本体部分は実体だから,実際にRFC 822メッセージであるとは,解釈されない。 最初に,本体部分には,ヘッダフィールドは実際には要求されない。 だから、空白行で始まる本体部分は許され,それはすべてのデフォルト値が仮定される本体部分になる。 このような場合,Content-Typeヘッダがないことは,通常, 対応する本体が"text/plain; charset=US-ASCII"のcontent-typeをもつことを示す。

A body part is an entity and hence is NOT to be interpreted as actually being an RFC 822 message. To begin with, NO header fields are actually required in body parts. A body part that starts with a blank line, therefore, is allowed and is a body part for which all default values are to be assumed. In such a case, the absence of a Content-Type header usually indicates that the corresponding body has a content-type of "text/plain; charset=US-ASCII".

本体部分のために意味を定義したヘッダフィールドは,"Content-"で始まる名前をもつものだけとする。 本体部分中,その他のすべてのフィールドは,無視してよい。 それらは,一般的に言って,可能ならば残しておいたほうがよいが,必要であればゲートウェイによって廃棄されてよい。 このような他のフィールドは,本体部分に表われることを許すが,依存されてはいけない。 "X-"フィールドは,それが含む情報がいくつかのゲートウェイで失われるかもしれないことを認識の上で,実験目的又は私的目的のために,作成されてもよい。

The only header fields that have defined meaning for body parts are those the names of which begin with "Content-". All other header fields may be ignored in body parts. Although they should generally be retained if at all possible, they may be discarded by gateways if necessary. Such other fields are permitted to appear in body parts but must not be depended on. "X-" fields may be created for experimental or private purposes, with the recognition that the information they contain may be lost at some gateways.

備考  RFC 822メッセージと本体部分との区別はつけにくいが,重要である。 例えば,インターネットとX.400メールとのゲートウェイは,画像を含む本体部分と,本体がJPEG画像であるカプセル化されたメッセージを含む本体部分との違いをわからなければならない。 後者を表現するためには,本体部分は,"Content-Type: message/rfc822"をもたなければならず,空白行の後の本体は,それ自身が"Content-Type: image/jpeg"ヘッダフィールドをもつカプセル化されたメッセージでなければならない。 同様な構文の使用は,本体部分へのメッセージの変換及びその逆変換を促進するが,その二つの区別を,実装者は理解しなければならない。 部分が実際のメッセージである特別な場合のために,"digest"下位型も定義される。

NOTE: The distinction between an RFC 822 message and a body part is subtle, but important. A gateway between Internet and X.400 mail, for example, must be able to tell the difference between a body part that contains an image and a body part that contains an encapsulated message, the body of which is a JPEG image. In order to represent the latter, the body part must have "Content-Type: message/rfc822", and its body (after the blank line) must be the encapsulated message, with its own "Content-Type: image/jpeg" header field. The use of similar syntax facilitates the conversion of messages to body parts, and vice versa, but the distinction between the two must be understood by implementors. (For the special case in which parts actually are messages, a "digest" subtype is also defined.)

前に宣言したように,それぞれの本体部分は,境界区切り子を含む境界区切り子行によって先行される。 境界区切り子は,カプセル化された部分,それ自身の行,又は,どの行の接頭辞としても,現れてはならない。 このことは,作成エージェントが,囲まれたマルチパートに境界パラメタ値を接頭辞として含まない,一意の境界パラメタ値を選んで指定できることが重要であることを示唆する。

As stated previously, each body part is preceded by a boundary delimiter line that contains the boundary delimiter. The boundary delimiter MUST NOT appear inside any of the encapsulated parts, on a line by itself or as the prefix of any line. This implies that it is crucial that the composing agent be able to choose and specify a unique boundary parameter value that does not contain the boundary parameter value of an enclosing multipart as a prefix.

全ての現在と将来の"multipart"型の下位型は,同一の構文を使わなければならない。 下位型は,それらのセマンティクスで異なってよく,構文上追加の制限を課してもよいが,"multipart"型で要求された構文に適合していなくてはならない。 この要求は,全ての適合した利用者エージェントが,認識しない下位型であっても,少なくともマルチパート実体の部分を認識し分割できるようにすることを保証する。

All present and future subtypes of the "multipart" type must use an identical syntax. Subtypes may differ in their semantics, and may impose additional restrictions on syntax, but must conform to the required syntax for the "multipart" type. This requirement ensures that all conformant user agents will at least be able to recognize and separate the parts of any multipart entity, even those of an unrecognized subtype.

Content-Transfer-Encodingフィールド[RFC 2045]の定義の中で宣言したとおり, "7bit","8bit"又は"binary"以外の符号化は,"multipart"型の実体として,許されない。 "multipart"境界区切り子及びヘッダフィールドは,RFC 2047による非US-ASCIIヘッダテキストとして符号化してもよいが,どんな場合もいつも, 7bit US-ASCIIとして表現され, 本体部分中のデータは,それぞれの適切な本体部分のためのContent-Tranfer-Encodingフィールドで,部分ごとに符号化することができる。

As stated in the definition of the Content-Transfer-Encoding field [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The "multipart" boundary delimiters and header fields are always represented as 7bit US-ASCII in any case (though the header fields may encode non-US-ASCII header text as per RFC 2047) and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part.

5.1.1 共通構文

5.1.1. Common Syntax

この箇条では,"multipart"の下位型のための共通構文を定義する。 全ての"multipart"の下位型は,この構文を使わなければならない。 マルチパートメッセージの単純な例も,この箇条で示す。 もっと複雑なマルチパートメッセージの例は,RFC 2049を原規定とする標準仕様書(TS)(1)で与えられる。

This section defines a common syntax for subtypes of "multipart". All subtypes of "multipart" must use this syntax. A simple example of a multipart message also appears in this section. An example of a more complex multipart message is given in RFC 2049.

マルチパート実体のためのContent-Typeフィールドは,一つのパラメタ"boundary"を要求する。 境界区切り子行は,二つのハイフン文字("-",10進値の45)に後続してContent-Typeヘッダフィールドからの境界パラメタ値があり,オプションで線形空白があり,終わりのCRLFで構成される行として,定義される。

The Content-Type field for multipart entities requires one parameter, "boundary". The boundary delimiter line is then defined as a line consisting entirely of two hyphen characters ("-", decimal value 45) followed by the boundary parameter value from the Content-Type header field, optional linear whitespace, and a terminating CRLF.

備考  ハイフンは,以前のメッセージをカプセル化するRFC 934の方法と大まかな互換性のため,及び,いくつかの実装で検索を容易にするためである。 しかし,マルチパートメッセージは,RFC 934のカプセル化とは,完全には互換性がないこと,特に,ハイフンで始まる埋込み行のためのRFC 934引用規約には従っていないことに注意したほうがよい。 後者は,それぞれの引用のレベルで行の成長を引き起こすから,RFC 934の上にこの機構が選ばれた。 SMTP実装が時々長い行を折り返すという事実と,この成長の結合は,RFC 934の機構を深い入れ子のマルチパート構造付けが望まれるイベントにおいての使用を不適切なものにしている。

NOTE: The hyphens are for rough compatibility with the earlier RFC 934 method of message encapsulation, and for ease of searching for the boundaries in some implementations. However, it should be noted that multipart messages are NOT completely compatible with RFC 934 encapsulations; in particular, they do not obey RFC 934 quoting conventions for embedded lines that begin with hyphens. This mechanism was chosen over the RFC 934 mechanism because the latter causes lines to grow with each level of quoting. The combination of this growth with the fact that SMTP implementations sometimes wrap long lines made the RFC 934 mechanism unsuitable for use in the event that deeply-nested multipart structuring is ever desired.

実装者への警告
Content-Typeフィールドのパラメタのための文法は,Content-type行上の引用で,境界パラメタ値を囲うのにしばしば必要となることなどである。 これはいつも必要ではないが,支障もない。 実装者は,不正なContent-typeフィールドが生成されないように,注意深く文法を学習した方がよい。 ゆえに,典型的な"multipart" Content-Typeヘッダフィールドは,次のように見える。
Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p
しかし,次は,正しくない。
Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p
なぜならばコロン(:)があるからであり,かわりに,次のようにあらわさなければならない。
Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"

WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- type field is such that it is often necessary to enclose the boundary parameter values in quotes on the Content-type line. This is not always necessary, but never hurts. Implementors should be sure to study the grammar carefully in order to avoid producing invalid Content-type fields. Thus, a typical "multipart" Content-Type header field might look like this: Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p But the following is not valid: Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p (because of the colon) and must instead be represented as Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"

このContent-Type値は,内容が一つ以上の部分からなり,それぞれは,ヘッダ領域が完全に空であることを許すこと及びそれぞれの部分が次に示す行に先行されること以外は,RFC 822メッセージと構文上,同一の構造とする。
--gc0pJq0M:08jU534c0p

This Content-Type value indicates that the content consists of one or more parts, each with a structure that is syntactically identical to an RFC 822 message, except that the header area is allowed to be completely empty, and that the parts are each preceded by the line --gc0pJq0M:08jU534c0p

境界区切り子は,行の先頭,すなわち,CRLFの直後になければならず,最初のCRLFは,先行する部分の一部ではなく,境界区切り行につけられたものと考える。 境界は,0文字以上の線形空白に後続されてよく,別のCRLF及び次の部分のヘッダフィールドか又は二つのCRLF(この場合,次の部分にヘッダフィールドがない)のどちらかで終了する。 Content-Typeフィールドがない場合,"multipart/digest"中の"message/rfc822",そうでない場合は,"text/plain"とみなす。

The boundary delimiter MUST occur at the beginning of a line, i.e., following a CRLF, and the initial CRLF is considered to be attached to the boundary delimiter line rather than part of the preceding part. The boundary may be followed by zero or more characters of linear whitespace. It is then terminated by either another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part. If no Content-Type field is present it is assumed to be "message/rfc822" in a "multipart/digest" and "text/plain" otherwise.

参考  境界区切り行に先行するCRLFは,概念的に境界に付いているので,CRLF(改行)で終わらない部分をもつことができる。 だから,改行で終わる事が想定されなければならない本体部分は,境界区切り行に先行する二つのCRLFをもたなければならず,1番目は先行する本体部分のもの,2番目はカプセル化した境界の部分のものである。

NOTE: The CRLF preceding the boundary delimiter line is conceptually attached to the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, must have two CRLFs preceding the boundary delimiter line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.

境界区切り子は,カプセル化されたデータ中にあらわれてはならず,二つの先行するハイフンを含まずに,70文字より長くてはならない。

Boundary delimiters must not appear within the encapsulated material, and must be no longer than 70 characters, not counting the two leading hyphens.

最後の本体部分に続く境界区切り子行は,それ以上本体部分が続かないことを示す,区別された区切り子とする。 このような境界行は,それ以前の区切り行と同一のものに,境界パラメタ値の後ろに二つのハイフンを加えたものとする。
--gc0pJq0M:08jU534c0p--

The boundary delimiter line following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter line is identical to the previous delimiter lines, with the addition of two more hyphens after the boundary parameter value. --gc0pJq0M:08jU534c0p--

備考  境界文字列の比較は,それぞれの候補行の始めから境界値を比較しなければならない。 候補行全体の完全な一致は要求されない。 CRLFに後続して境界が完全に現れるだけで十分とする。

NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the boundary value with the beginning of each candidate line. An exact match of the entire candidate line is not required; it is sufficient that the boundary appear in its entirety following the CRLF.

一番目の境界区切り行の前及び最後の境界区切り行の後に,追加の情報のための場所がある。 これらの領域は,一般的には,空白のままであり,実装者は,一番目の境界区切り行の前及び最後の境界区切り行の後に現れるどんなものも無視しなければならない。

There appears to be room for additional information prior to the first boundary delimiter line and following the final boundary delimiter line. These areas should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one.

備考  これらの"まえがき"及び"あとがき"の領域は,これらの部分の適切な型付けがないこと及びゲートウェイ,特にX.400ゲートウェイにおいてこれらの領域をどう処理するか明確なセマンティクスがないことから,一般的には使われない。 しかし,まえがき領域を空白のままにしておくのではなく,MIME適合のソフトウェアでは無視されるので,多くのMIME実装は,MIME以前のソフトウェアでメッセージを読む受信者に,説明的な備考を挿入する便利な場所でなることがわかる。

NOTE: These "preamble" and "epilogue" areas are generally not used because of the lack of proper typing of these parts and the lack of clear semantics for handling these areas at gateways, particularly X.400 gateways. However, rather than leaving the preamble area blank, many MIME implementations have found this to be a convenient place to insert an explanatory note for recipients who read the message with pre-MIME software, since such notes will be ignored by MIME-compliant software.

備考  境界区切り子は,カプセル化された本体部分中には現れてはならないから,利用者エージェントは,一意の境界パラメタ値を選ぶために注意をしなければならない。 上記の例で境界パラメタ値は,データをプレスキャンすることもなくカプセル化されたデータ中にすでに存在する可能性の非常に低い境界区切り子を生成するように設計されたアルゴリズムの結果であり得た。 代替のアルゴリズムは,古い利用者エージェントでの受信者に,もっと”読みやすい”境界区切り子をもたらしうるが,境界区切り子が組み込まれた部分の,ある行の先頭に現れる可能性があることに,特に注意する必要がある。 最も簡単な境界区切り子行は,"---"のようなものであり,それの終了の区切り子行は"-----"のようなものである。

NOTE: Because boundary delimiters must not appear in the body parts being encapsulated, a user agent must exercise care to choose a unique boundary parameter value. The boundary parameter value in the example above could have been the result of an algorithm designed to produce boundary delimiters with a very low probability of already existing in the data to be encapsulated without having to prescan the data. Alternate algorithms might result in more "readable" boundary delimiters for a recipient with an old user agent, but would require more attention to the possibility that the boundary delimiter might appear at the beginning of some line in the encapsulated part. The simplest boundary delimiter line possible is something like "---", with a closing boundary delimiter line of "-----".

とても簡単な例として,次のマルチパートメッセージは二つの部分をもち,両方ともプレーンテキストで,一つは明示的に型付けされ,もう一つは暗黙的に型付けされる。

  From: Nathaniel Borenstein 
     To: Ned Freed 
     Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
     Subject: Sample message
     MIME-Version: 1.0
     Content-type: multipart/mixed; boundary="simple boundary"

     これはまえがきである。これは作成エージェントが非MIME適合リーダへの
   説明的備考を含めるための手軽な場所であるが,これは無視される。

     --simple boundary

     これは暗黙的にプレーンUS-ASCIIテキストに型付けされる。
  これは行区切りでは終わらない。

     --simple boundary
     Content-type: text/plain; charset=us-ascii

     これは明示的にプレーンUS-ASCIIテキストに型付けされる。
     これは行区切りで終わる。

     --simple boundary--

     これはあとがきである。これも無視される。
As a very simple example, the following multipart message has two parts, both of them plain text, one of them explicitly typed and one of them implicitly typed: From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST) Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" This is the preamble. It is to be ignored, though it is a handy place for composition agents to include an explanatory note to non-MIME conformant readers. --simple boundary This is implicitly typed plain US-ASCII text. It does NOT end with a linebreak. --simple boundary Content-type: text/plain; charset=us-ascii This is explicitly typed plain US-ASCII text. It DOES end with a linebreak. --simple boundary-- This is the epilogue. It is also to be ignored.

別の"multipart"実体中の本体部分の中に"multipart"メディア型を使用することは,明示的に許可される。このような場合,明白な理由で,それぞれの入れ子になった"multipart"実体は異なる境界区切り子を使うことを保証するように,注意を払わなければならない。 入れ子の"multipart"実体の例は,RFC 2049を原規定とする標準仕様書(TS)(1)を参照するとよい。

The use of a media type of "multipart" in a body part within another "multipart" entity is explicitly allowed. In such cases, for obvious reasons, care must be taken to ensure that each nested "multipart" entity uses a different boundary delimiter. See RFC 2049 for an example of nested "multipart" entities.

"multipart"メディア型を単一の本体部分だけで使用することは,ある文脈には便利である場合もあり,明示的に許される。

The use of the "multipart" media type with only a single body part may be useful in certain contexts, and is explicitly permitted.

備考  "multipart"メディア型を単一の本体部分で使用することは,非テキストメディア型を送るのに便利であることを経験が示している。 それは,復号の指示を含める場所としてのまえがきを提供する利点をもつ。 さらに,多くのSMTPゲートウェイは,MIMEヘッダを動かすか又は取り除き,そして,賢いMIME復号器は,Content-Typeヘッダがない場合でもマルチパート境界でよい予測をすることができ,そのためメッセージを成功裡に復号する。

NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types. It has the advantage of providing the preamble as a place to include decoding instructions. In addition, a number of SMTP gateways move or remove the MIME headers, and a clever MIME decoder can take a good guess at multipart boundaries even in the absence of the Content-Type header and thereby successfully decode the message.

"multipart"メディア型の唯一の必須の大域パラメタは,境界パラメタとし,境界パラメタは,メールゲートウェイを通して非常に耐性のあるものとして知られる文字の組からの,1から70文字からなり,空白で終わってはならない。 もし,境界区切り子行が空白で終わっている場合,その空白はゲートウェイによって加えられたものとみなされ,削除されなければならない。 次のBNFにより,これを形式定義する。

The only mandatory global parameter for the "multipart" media type is the boundary parameter, which consists of 1 to 70 characters from a set of characters known to be very robust through mail gateways, and NOT ending with white space. (If a boundary delimiter line appears to end with white space, the white space must be presumed to have been added by a gateway, and must be deleted.) It is formally specified by the following BNF:
     boundary := 0*69 bcharsnospace

     bchars := bcharsnospace / " "

     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"

   全般的に,"multipart"実体の本体は,次のように規定してよい。

     dash-boundary := "--" boundary
                      ; Content-Typeフィールドの境界
                      ; 値からとられた境界
                      ; 

     multipart-body := [preamble CRLF]
                       dash-boundary transport-padding CRLF
                       body-part *encapsulation
                       close-delimiter transport-padding
                       [CRLF epilogue]

     transport-padding := *LWSP-char
                          ; 作成者は長さゼロでないトランスポートパディングを
             ; 生成してはならないが,
                          ; 受信者はメッセージトランスポートによって
             ; 加えられたパディングを処理できなけらばならない。

     encapsulation := delimiter transport-padding
                      CRLF body-part

     delimiter := CRLF dash-boundary

     close-delimiter := delimiter "--"

     preamble := discard-text

     epilogue := discard-text

     discard-text := *(*text CRLF) *text
                     ; 無視又は削除されてよい。

     body-part := MIME-part-headers [CRLF *OCTET]
                  ; 本体部分の行は指定されたダッシュ境界で
                  ; 始まってはならず,区切り子は本体部分の
                  ; どこにも現れてはならない。
                  ; 文中に記述されているとおり,本体部分の
                  ; セマンティクスは,メッセージの
                  ; セマンティクスと異なる。
                  ; 

     OCTET := <0から255の任意のオクテット値>
boundary := 0*69<bchars> bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?" Overall, the body of a "multipart" entity may be specified as follows: dash-boundary := "--" boundary ; boundary taken from the value of ; boundary parameter of the ; Content-Type field. multipart-body := [preamble CRLF] dash-boundary transport-padding CRLF body-part *encapsulation close-delimiter transport-padding [CRLF epilogue] transport-padding := *LWSP-char ; Composers MUST NOT generate ; non-zero length transport ; padding, but receivers MUST ; be able to handle padding ; added by message transports. encapsulation := delimiter transport-padding CRLF body-part delimiter := CRLF dash-boundary close-delimiter := delimiter "--" preamble := discard-text epilogue := discard-text discard-text := *(*text CRLF) *text ; May be ignored or discarded. body-part := MIME-part-headers [CRLF *OCTET] ; Lines in a body-part must not start ; with the specified dash-boundary and ; the delimiter must not appear anywhere ; in the body part. Note that the ; semantics of a body-part differ from ; the semantics of a message, as ; described in the text. OCTET := <any 0-255 octet value>

備考  このBNFは構造化されたヘッダフィールドを規定しないから,このBNFに示される要素間の線形空白及びRFC 822コメントの自由な挿入は許されない。

IMPORTANT: The free insertion of linear-white-space and RFC 822 comments between the elements shown in this BNF is NOT allowed since this BNF does not specify a structured header field.

備考  特定のトランスポートの領域では,印字可能US-ASCII文字に本体を制限することなどRFC 822の制限が有効でないかもしれない。 すなわち,トランスポート領域は,RFC 821で規定される標準的なインターネットメールトランスポートに似ていてRFC 822を想定しているが,特定の制限がないものが存在するかもしれない。 これらの制限の緩和は,これらの拡張がトランスポートによってサポートされてContent-Transfer-Encodingヘッダフィールド中で適切に文書化されている限りは,局所的に拡張した本体の定義と解釈したほうがよい。 しかし,メッセージヘッダ又は本体部分ヘッダのどちらかでも,US-ASCII文字以外を含むことは許されない。

NOTE: In certain transport enclaves, RFC 822 restrictions such as the one that limits bodies to printable US-ASCII characters may not be in force. (That is, the transport domains may exist that resemble standard Internet mail transport as specified in RFC 821 and assumed by RFC 822, but without certain restrictions.) The relaxation of these restrictions should be construed as locally extending the definition of bodies, for example to include octets outside of the US-ASCII range, as long as these extensions are supported by the transport and adequately documented in the Content- Transfer-Encoding header field. However, in no event are headers (either message headers or body part headers) allowed to contain anything other than US-ASCII characters.

備考  "multipart"型から著しい欠損は,構造化され,関連する本体部分の意向である。 さらに構造化又は統合化されたマルチパートメッセージング機能を提供したい場合は,構文的には同一だが,多くの部分間での関連を定義するマルチパートの下位型を定義することが推奨される。 例えば,他の部分との関連を指定するのに使われ,多分それらのContent-IDフィールドを参照する,個別の部分を含む,マルチパートの下位型を定義できる。 この方法が使われる場合,古い実装は新しい下位型を認識しないが,multipart/mixedとしてあつかわれ,そのため利用者に認識される部分を見せることができる。

NOTE: Conspicuously missing from the "multipart" type is a notion of structured, related body parts. It is recommended that those wishing to provide more structured or integrated multipart messaging facilities should define subtypes of multipart that are syntactically identical but define relationships between the various parts. For example, subtypes of multipart could be defined that include a distinguished part which in turn is used to specify the relationships between the other parts, probably referring to them by their Content-ID field. Old implementations will not recognize the new subtype if this approach is used, but will treat it as multipart/mixed and will thus be able to show the user the parts that are recognized.

5.1.2 入れ子となったメッセージ及びマルチパートの処理

5.1.2. Handling Nested Messages and Multiparts

この標準仕様書(TS)の後続の箇条で定義される"message/rfc822"下位型は,データが尽きる以外には,終了する状態をもたない。 同様に,不正に切られた"multipart"実体は,終了境界のマーカをもたないで,メールシステム故障の結果,運用上やめることができる。

The "message/rfc822" subtype defined in a subsequent section of this document has no terminating condition other than running out of data. Similarly, an improperly truncated "multipart" entity may not have any terminating boundary marker, and can turn up operationally due to mail system malfunctions.

別の構造の中に埋め込まれる場合,このような実体が正しく処理されることは,本質的である。そのため,MIME実装には,内側の入れ子のどんなレベルでも外側のレベルの境界を認識することが,要求される。 次の期待されるマーカ又は他の終了状態を検査するだけでは十分でない。

It is essential that such entities be handled correctly when they are themselves imbedded inside of another "multipart" structure. MIME implementations are therefore required to recognize outer level boundary markers at ANY level of inner nesting. It is not sufficient to only check for the next expected marker or other terminating condition.

5.1.3 mixed下位型

5.1.3. Mixed Subtype

"multipart"内容型の"mixed"下位型は,本体部分が独立であり,特定の順番に束ねられることが必要な場合での使用が意図されている。 実装が認識しない"multipart"のどんな下位型も,下位型"mixed"であるとして,扱わなければならない。

The "mixed" subtype of "multipart" is intended for use when the body parts are independent and need to be bundled in a particular order. Any "multipart" subtypes that an implementation does not recognize must be treated as being of subtype "mixed".

5.1.4 alternative下位型

5.1.4. Alternative Subtype

"multipart/alternative"下位型は,構文的には"multipart/mixed"と同一であるが,セマンティクスは異なる。特に,本体部分のそれぞれは,同じ情報の"代替"版とする。

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

システムは,多くの部分の内容は交換可能であることを,認識したほうがよい。 システムは,いくつかの場合には利用者との対話があるにせよ,局所的な環境及び参照に基づいて,”最良の”型を選んだほうがよい。 "multipart/mixed"では,本体部分の順番は顕著とする。 この場合,代替は,原内容に忠実さが増す順番で現れるとする。 一般的に,最良の選択は,受信システムの局所環境によりサポートされる型の最後の部分である。

Systems should recognize that the content of the various parts are interchangeable. Systems should choose the "best" type based on the local environment and references, in some cases even through user interaction. As with "multipart/mixed", the order of body parts is significant. In this case, the alternatives appear in an order of increasing faithfulness to the original content. In general, the best choice is the LAST part of a type supported by the recipient system's local environment.

"multipart/alternative"は,例えば,どこにも簡単に表示できる,装飾的なテキストによるメッセージを送るのに使われてもよい。

     From: Nathaniel Borenstein 
     To: Ned Freed 
     Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
     Subject: Formatted text mail
     MIME-Version: 1.0
     Content-Type: multipart/alternative; boundary=boundary42

     --boundary42
     Content-Type: text/plain; charset=us-ascii

       ... メッセージのプレーンテキスト版がここ来る ...

     --boundary42
     Content-Type: text/enriched

       ... 同じメッセージのRFC 1896 text/enriched版がここに来る ...

     --boundary42
     Content-Type: application/x-whatever

       ... 同じメッセージの最も装飾的な版がここに来る ...

     --boundary42--

"Multipart/alternative" may be used, for example, to send a message in a fancy text format in such a way that it can easily be displayed anywhere: From: Nathaniel Borenstein <nsb@bellcore.com> To: Ned Freed <ned@innosoft.com> Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST) Subject: Formatted text mail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=boundary42 --boundary42 Content-Type: text/plain; charset=us-ascii ... plain text version of message goes here ... --boundary42 Content-Type: text/enriched ... RFC 1896 text/enriched version of same message goes here ... --boundary42 Content-Type: application/x-whatever ... fanciest version of same message goes here ... --boundary42--

この例では,システムの機能に依存して,フォーマット付き又はプレーンテキストだけしか見られない利用者もいるし,"application/x-whatever"フォーマットを理解したメールシステムの利用者は,装飾的な版だけを見る。

In this example, users whose mail systems understood the "application/x-whatever" format would see only the fancy version, while other users would see only the enriched or plain text version, depending on the capabilities of their system.

一般的に,"multipart/alternative"実体を作成する利用者エージェントは,お勧め度の昇順,すなわちお勧めのフォーマットを最後に,本体部分を配置しなければならない。 装飾的なテキストについては,送った利用者エージェントは,最もプレーンなフォーマットを先に,最もリッチなフォーマットを最後に置くほうがよい。 受信利用者エージェントは,表示可能な最後のフォーマットを取り出して表示するほうがよい。 一つの代替がそれ自身"multipart"の型の場合で認識されない下位部分を含む場合,利用者エージェントは,その代替,それより前の代替,又はそれらの両方か表示するために選んでよい。

In general, user agents that compose "multipart/alternative" entities must place the body parts in increasing order of preference, that is, with the preferred format last. For fancy text, the sending user agent should put the plainest format first and the richest format last. Receiving user agents should pick and display the last format they are capable of displaying. In the case where one of the alternatives is itself of type "multipart" and contains unrecognized sub-parts, the user agent may choose either to show that alternative, an earlier alternative, or both.

備考  実装者の観点からは,この順番を逆にし,最もプレーンな代替を最後に置くほうが,より感覚的によく見えるかもしれない。 しかし,最もプレーンな代替をはじめに置くことは,"multipart/alternative"実体がMIMEに適合しないビュアを使って見られたとき,最も親切な可能性がある選択である。 この方法は,MIMEに適合するビュアに負担をかけるが,この場合,より古いメールリーダとの相互運用性がより重要であると思われる。

NOTE: From an implementor's perspective, it might seem more sensible to reverse this ordering, and have the plainest alternative last. However, placing the plainest alternative first is the friendliest possible option when "multipart/alternative" entities are viewed using a non-MIME-conformant viewer. While this approach does impose some burden on conformant MIME viewers, interoperability with older mail readers was deemed to be more important in this case.

いくつかの利用者エージェントで,それらが一つ以上のフォーマットを認識できるなら,どのフォーマットで見るか利用者に選択を提供することを好む場合があるかもしれない。 例えば,メッセージが,きれいにフォーマットされた画像版及び簡単に編集できるテキスト版の両方を含む場合などに,有意義である。 しかし,最も大事なことは,自動的に同じデータの複数の版を利用者が見せられるのではないことである。 利用者は最後に認識された版を見せた方がよいか、又は、選択を与えられた方がよいかである。

It may be the case that some user agents, if they can recognize more than one of the formats, will prefer to offer the user the choice of which format to view. This makes sense, for example, if a message includes both a nicely- formatted image version and an easily-edited text version. What is most critical, however, is that the user not automatically be shown multiple versions of the same data. Either the user should be shown the last recognized version or should be given the choice.

multipart/alternate中のContent-IDのセマンティクス  "multipart/alternative"実体のそれぞれの部分は同じデータを表すが,二つの間の対応付けは,必ずしも情報を失わないとは限らない。 例えば,ODAからPostScript又はプレーンテキストへ変換するときは,情報を失う。 二つの部分が同一の情報内容でないときは,それぞれの部分は,異なるContent-ID値を持つことが推奨される。 情報内容が同一のとき,例えば,"message/external-body"のいくつもの部分が,同一のデータにアクセスする代替の方法を指定する場合,受信者側にあり得るキャッシュ機構を最適化するため,同じContent-IDフィールド値が用いられる方がよい。 しかし,部分により使われるContent-ID値は,このようなContent-IDフィールドがあるならば,"multipart/alternative"全体を記述するContent-IDと同じにしない方がよい。 すなわち,一つ以上の他のContent-ID値が実体中の部分を参照するが,一つのContent-ID値が"multipart/alternative"実体を参照する。

THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a "multipart/alternative" entity represents the same data, but the mappings between the two are not necessarily without information loss. For example, information is lost when translating ODA to PostScript or plain text. It is recommended that each part should have a different Content-ID value in the case where the information content of the two parts is not identical. And when the information content is identical -- for example, where several parts of type "message/external-body" specify alternate ways to access the identical data -- the same Content-ID field value should be used, to optimize any caching mechanisms that might be present on the recipient's end. However, the Content-ID values used by the parts should NOT be the same Content-ID value that describes the "multipart/alternative" as a whole, if there is any such Content-ID field. That is, one Content-ID value will refer to the "multipart/alternative" entity, while one or more other Content-ID values will refer to the parts inside it.

5.1.5 digest下位型

5.1.5. Digest Subtype

この文書は,"multipart"Content-Typeの"digest"下位型を定義する。 この型は,構文的に"multipart/mixed"と同一だが,セマンティクスは異なる。 特に,ダイジェストでは,本体部分のためのデフォルトのContent-Tyep値は,"text/plain"から"message/rfc822"に変更された。 これは,引用の規約を除いて,RFC934と互換性の強い,より読める ダイジェストのフォーマットを許すために行われた。

This document defines a "digest" subtype of the "multipart" Content- Type. This type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, in a digest, the default Content-Type value for a body part is changed from "text/plain" to "message/rfc822". This is done to allow a more readable digest format that is largely compatible (except for the quoting convention) with RFC 934.

備考  ダイジェスト中の本体部分に対して,ダイジェスト中のデータの記述を含む"text/plain"部分などのような,"message/rfc822"以外のContent-Type値を指定することは可能であるが,実際にそうすることは好ましくない。 "multipart/digest"Content-Type"は,メッセージを集めたものを送ることを意図する。もし,"text/plain"部分が必要ならば,それは"multipart/mixed"メッセージの別の部分として含まれたほうがよい。

Note: Though it is possible to specify a Content-Type value for a body part in a digest which is other than "message/rfc822", such as a "text/plain" part containing a description of the material in the digest, actually doing so is undesireble. The "multipart/digest" Content-Type is intended to be used to send collections of messages. If a "text/plain" part is needed, it should be included as a seperate part of a "multipart/mixed" message.

このフォーマットによるダイジェストは,次のようである。

A digest in this format might, then, look something like this:
     From: Moderator-Address
     To: Recipient-List
     Date: Mon, 22 Mar 1994 13:34:51 +0000
     Subject: Internet Digest, volume 42
     MIME-Version: 1.0
     Content-Type: multipart/mixed;
                   boundary="---- main boundary ----"

     ------ main boundary ----

       ... 紹介のテキスト又は目次 ...

     ------ main boundary ----
     Content-Type: multipart/digest;
                   boundary="---- next message ----"

     ------ main boundary ----

     From: someone-else
     Date: Fri, 26 Mar 1993 11:13:32 +0200
     Subject: my opinion

       ... 本体がここにくる ...

     ------ next message ----

     From: someone-else-again
     Date: Fri, 26 Mar 1993 10:07:13 -0500
     Subject: my different opinion

       ... もう一つの本体がここにくる ...

     ------ next message ------

     ------ main boundary ------
From: Moderator-Address To: Recipient-List Date: Mon, 22 Mar 1994 13:34:51 +0000 Subject: Internet Digest, volume 42 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- main boundary ----" ------ main boundary ---- ...Introductory text or table of contents... ------ main boundary ---- Content-Type: multipart/digest; boundary="---- next message ----" ------ next message ---- From: someone-else Date: Fri, 26 Mar 1993 11:13:32 +0200 Subject: my opinion ...body goes here ... ------ next message ---- From: someone-else-again Date: Fri, 26 Mar 1993 10:07:13 -0500 Subject: my different opinion ... another body goes here ... ------ next message ------ ------ main boundary ------

5.1.6 parallel下位型

5.1.6. Parallel Subtype

この標準仕様書(TS)は,"multipart"内容型の下位型"parallel"を定義する。 この型は,構文的には"multipart/mixed"と同一であるが,セマンティクスは異なる。 特に,パラレル実体では,本体部分の順番は意味をもたない。

This document defines a "parallel" subtype of the "multipart" Content-Type. This type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, in a parallel entity, the order of body parts is not significant.

この型の普通の表現は,ハードウェア及びソフトウェアですることができるなら同時に部分のすべてを表示する。 しかし,作成エージェントは,多くのメールリーダでこの機能がなく,いずれにせよ部分を直列的に見せることに注意を払った方がよい。

A common presentation of this type is to display all of the parts simultaneously on hardware and software that are capable of doing so. However, composing agents should be aware that many mail readers will lack this capability and will show the parts serially in any event.

5.1.7 その他のmultipartの下位型

5.1.7. Other Multipart Subtypes

他の"multipart"下位型は将来的に期待される。 MIME実装は,一般的に,認識しない"multipart"の下位型を,"multipart/mixed"と同等なものとして,扱わなければならない。

Other "multipart" subtypes are expected in the future. MIME implementations must in general treat unrecognized subtypes of "multipart" as being equivalent to "multipart/mixed".

5.2 messageメディア型

5.2. Message Media Type

メールを送るとき,別のメールメッセージにカプセル化することは,頻繁に好まれる。 特別のメディア型"message"はこれを推進するために定義されている。 特に,"message"の"rfc822"下位型は,RFC 822メッセージをカプセル化するのに使われる。

It is frequently desirable, in sending mail, to encapsulate another mail message. A special media type, "message", is defined to facilitate this. In particular, the "rfc822" subtype of "message" is used to encapsulate RFC 822 messages.

備考  転送メッセージ又は拒絶メッセージのため,"message"の下位型を定義できることが推奨される。 しかし,転送メッセージ及び拒絶メッセージは,マルチパートメッセージとして,取り扱うことができ, そのマルチパートメッセージは,1番目の部分が制御又は記述的情報を含み,2番目の部分が"message/rfc822"型の転送メッセージ又は拒絶メッセージである。 このような拒絶の作成及びメッセージの転送は,原メッセージ上の型情報を保存し,それを受信者が正しく表現することを許すので,強く推奨される。

NOTE: It has been suggested that subtypes of "message" might be defined for forwarded or rejected messages. However, forwarded and rejected messages can be handled as multipart messages in which the first part contains any control or descriptive information, and a second part, of type "message/rfc822", is the forwarded or rejected message. Composing rejection and forwarding messages in this manner will preserve the type information on the original message and allow it to be correctly presented to the recipient, and hence is strongly encouraged.

"messege"の下位型は,どの符号化が許されるかについて制限を課す場合がある。 これらの制限は,それぞれの特定の下位型とともに記述する。

Subtypes of "message" often impose restrictions on what encodings are allowed. These restrictions are described in conjunction with each specific subtype.

メールゲートウェイ,リレー及び他のメール処理エージェントは,RFC 822メッセージの最上位ヘッダを替えることが一般に知られている。 特に,それらは,頻繁にヘッダフィールドを追加,削除又は並び替えを行う。 これらの操作は,"message"型のメッセージの型に組み込まれてカプセル化されたヘッダでは,明示的に禁止される。

Mail gateways, relays, and other mail handling agents are commonly known to alter the top-level header of an RFC 822 message. In particular, they frequently add, remove, or reorder header fields. These operations are explicitly forbidden for the encapsulated headers embedded in the bodies of messages of type "message."

5.2.1 RFC822下位型

5.2.1. RFC822 Subtype

"message/rfc822"メディア型は,本体が,RFC 822メッセージの構文でカプセル化されたメッセージを含むことを示す。しかし,最上位のRFC 822メッセージとは異なり,それぞれの"message/rfc822"本体が"From","Date"及び少なくとも一つの宛先を含まなければならないという制限が削除され,少なくとも一つの"From","Subject"又は"Date"が現れなければならないという要求に置き換えられる。

A media type of "message/rfc822" indicates that the body contains an encapsulated message, with the syntax of an RFC 822 message. However, unlike top-level RFC 822 messages, the restriction that each "message/rfc822" body must include a "From", "Date", and at least one destination header is removed and replaced with the requirement that at least one of "From", "Subject", or "Date" must be present.

しかし,"822"という数字の使用にかかわらず,"message/rfc822"実体は,厳密なRFC 822への適合性のデータに制限されることはなく,"message/rfc822"オブジェクトのセマンティクスが,RFC 822で定義されるセマンティクスに制限されることもない。もっと具体的にいえば,"message/rfc822"メッセージは,ニュース記事又はMIMEメッセージである。

It should be noted that, despite the use of the numbers "822", a "message/rfc822" entity isn't restricted to material in strict conformance to RFC822, nor are the semantics of "message/rfc822" objects restricted to the semantics defined in RFC822. More specifically, a "message/rfc822" message could well be a News article or a MIME message. "message/rfc822"実体の本体は,"7bit","8bit"又は"binary以外の符号化であってはならない。 メッセージヘッダフィールドは,どんな場合もいつもUS-ASCIIでなければならず,本体内のデータは符号化され,その場合,カプセル化されたメッセージのContent-Transfer-Encodingヘッダフィールドはこれを反映する。 カプセル化されたメッセージのヘッダ中の非US-ASCIIテキストは,RFC 2047に記述される機構を使って,指定することができる。

No encoding other than "7bit", "8bit", or "binary" is permitted for the body of a "message/rfc822" entity. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. Non-US-ASCII text in the headers of an encapsulated message can be specified using the mechanisms described in RFC 2047.

5.2.2 partial下位型

5.2.2. Partial Subtype

"partial"下位型は,大きい実体を,幾つもに分割したメールの部分として配信し,受信する利用者エージェントにより自動的に再構成することを許容するために定義する。 考え方は,基本的なInternet Protocolにおける,IP断片及び再構成に似ている。 この機構は,中間の転送エージェントが,送ることのできる個別のメッセージの大きさを,制限する場合に使うことができる。 メディア型"message/partial"は,本体がより大きい実体の断片を含んでいることを示す。

The "partial" subtype is defined to allow large entities to be delivered as several separate pieces of mail and automatically reassembled by a receiving user agent. (The concept is similar to IP fragmentation and reassembly in the basic Internet Protocols.) This mechanism can be used when intermediate transport agents limit the size of individual messages that can be sent. The media type "message/partial" thus indicates that the body contains a fragment of a larger entity.

"message"型のデータは,base64又はquoted-printableで符号化されることはないので, 2値又は8ビットのトランスポートをサポートする環境で,"message/partial"実体が組み立てられている場合に問題がおこる。 問題は,2値データが複数の"message/partial"メッセージに分割され,それぞれが2値のトランスポートを要求することである。 7ビットのトランスポートへのゲートウェイで,このようなメッセージに遭遇したとき,すべての断片を待ち,内部のメッセージを再組み立てし,そして再組み立てされたデータをbase64又はquoted-printableで符号化する場合を除けば, それらを適切に7ビットの世界に符号化する方法がない。 異なる断片が異なるゲートウェイを通過する場合もあり得るから,再組み立てする方法でさえも,許容できる解決策ではない。 この理由から,"message/partial"型の実体はいつでも7ビット(デフォルト値)のContent-transfer-encodingでなければならないことが規定される。 特に,2値又は8ビットのトランスポートをサポートする環境である場合でさえも,"8bit"又は"binary"のcontent-transfer-encodingの使用は,"message/partical"型のMIME実体には,明示的に禁止される。 このことは,順番に内部のメッセージが"8bit"又は"binary"符号化を使ってはならないことを意味する。

Because data of type "message" may never be encoded in base64 or quoted-printable, a problem might arise if "message/partial" entities are constructed in an environment that supports binary or 8bit transport. The problem is that the binary data would be split into multiple "message/partial" messages, each of them requiring binary transport. If such messages were encountered at a gateway into a 7bit transport environment, there would be no way to properly encode them for the 7bit world, aside from waiting for all of the fragments, reassembling the inner message, and then encoding the reassembled data in base64 or quoted-printable. Since it is possible that different fragments might go through different gateways, even this is not an acceptable solution. For this reason, it is specified that entities of type "message/partial" must always have a content- transfer-encoding of 7bit (the default). In particular, even in environments that support binary or 8bit transport, the use of a content- transfer-encoding of "8bit" or "binary" is explicitly prohibited for MIME entities of type "message/partial". This in turn implies that the inner message must not use "8bit" or "binary" encoding.

いくつかのメッセージ転送エージェントは大きいメッセージを自動的に細分化してもよいこと,及びそのようなエージェントは大きく異なる細分化の範囲を使ってよいなどから,部分メッセージの断片が,再組み立てにおいてそれら自身が部分メッセージを構成する検証してもよいことが可能である。 これは明示的に許容される。

Because some message transfer agents may choose to automatically fragment large messages, and because such agents may use very different fragmentation thresholds, it is possible that the pieces of a partial message, upon reassembly, may prove themselves to comprise a partial message. This is explicitly permitted. "message/partial"型のContent-Typeフィールドでは,3つのパラメタが指定されなければならない。 1番目は,"id"であり,これは一意の識別しであり,断片を合わせるために使われるために,できる限り世界一意の識別子に近いものであるとする。一般に,識別子は本質的には"message-id"であり,二重引用符中におかれたならば,RFC 2045で与えられる"parameter"のためのBNFに従う,どんなmessage-idも可能とする。 2番目は,"number"であり,整数で,断片の番号であり,この断片が断片の列のなかでどこに合うかを支持する。 3番目は,"total"であり,もう一つの整数で,断片の総数とする。 この3番目の下位フィールドは,最後の断片では必須とし,それ以前の断片ではオプションとするが,あったほうがよい。 これらのパラメタはどの順番で与えられてもよいことに注意すること。

Three parameters must be specified in the Content-Type field of type "message/partial": The first, "id", is a unique identifier, as close to a world-unique identifier as possible, to be used to match the fragments together. (In general, the identifier is essentially a message-id; if placed in double quotes, it can be ANY message-id, in accordance with the BNF for "parameter" given in RFC 2045.) The second, "number", an integer, is the fragment number, which indicates where this fragment fits into the sequence of fragments. The third, "total", another integer, is the total number of fragments. This third subfield is required on the final fragment, and is optional (though encouraged) on the earlier fragments. Note also that these parameters may be given in any order.

だから,3つの断片のメッセージの2番目の断片は,次のヘッダフィールドのうちいずれであってもよい。

Thus, the second piece of a 3-piece message may have either of the following header fields:
     Content-Type: Message/Partial; number=2; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

     Content-Type: Message/Partial;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
                   number=2
Content-Type: Message/Partial; number=2; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com" Content-Type: Message/Partial; id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; number=2

しかし,3番目の断片は,断片の総数を指定しなければならない。

But the third piece MUST specify the total number of fragments:
     Content-Type: Message/Partial; number=3; total=3;
                   id="oc=jpbe0M2Yt4s@thumper.bellcore.com"
Content-Type: Message/Partial; number=3; total=3; id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

細分化番号は,0でなく,1で始まることに注意すること。

Note that fragment numbering begins with 1, not 0.

このようにして分けた実体の断片が,一緒にされるとき,結果は,いつも,自身のContent-Typeヘッダを持つかもしれず,そして他のデータ型を持つかもしれない,完全なMIME実体である。

When the fragments of an entity broken up in this manner are put together, the result is always a complete MIME entity, which may have its own Content-Type header field, and thus may contain any other data type.

5.2.2.1 メッセージ細分化及び再組立て

5.2.2.1. Message Fragmentation and Reassembly 再構築された部分的メッセージのセマンティクスは,メッセージが内部のメッセージを含むのではなく,"内部の"セマンティクスでなければならない。 このことは,例えば,大きい音声メッセージを幾つもの部分的メッセージとして送るために, しかも,音声メッセージを含むカプセル化したメッセージではなく,単純な音声メッセージとして受信者に表現することを可能とする。 すなわち,メッセージのカプセル化は,「透過的」であると考えられる。

The semantics of a reassembled partial message must be those of the "inner" message, rather than of a message containing the inner message. This makes it possible, for example, to send a large audio message as several partial messages, and still have it appear to the recipient as a simple audio message rather than as an encapsulated message containing an audio message. That is, the encapsulation of the message is considered to be "transparent".

"message/partial"メッセージの断片の生成及び再構築をする場合,カプセル化されたメッセージのヘッダは,同封の実体のヘッダーで合体させなければならない。 この処理では,次の規則が観察されなければならない。

When generating and reassembling the pieces of a "message/partial" message, the headers of the encapsulated message must be merged with the headers of the enclosing entities. In this process the following rules must be observed:
  1. 細分化エージェントはメッセージを行の境界だけで分割しなければならない。 この制限は,行の最後以外の地点での分割がCRLFで終わらないメッセージのセマンティクスを保存することができるメッセージトランスポートに依存するために,課せられた。 多くのトランスポートは,このようなセマンティクスを保存することができない。
  2. (1) Fragmentation agents must split messages at line boundaries only. This restriction is imposed because splits at points other than the ends of lines in turn depends on message transports being able to preserve the semantics of messages that don't end with a CRLF sequence. Many transports are incapable of preserving such semantics.
  3. "Content-"で始まるヘッダフィールド並びに特別なヘッダフィールドの"Subject", "Message-ID", "Encrypted"及び"MIME-Version"を除いて,最初の囲まれたメッセージからのすべてのヘッダフィールドは新しいメッセージに順番に複写されなければならない。
  4. (2) All of the header fields from the initial enclosing message, except those that start with "Content-" and the specific header fields "Subject", "Message-ID", "Encrypted", and "MIME-Version", must be copied, in order, to the new message.
  5. Content-"と"Subject", "Message-ID", "Encrypted"で始まる囲まれたメッセージのヘッダフィールド及び"MIME-Version"のヘッダフィールドは,新しいメッセージに順番に追加されなければならない。 "Content-"で始まらない囲まれたメッセージの,"Subject", "Message-ID", "Encrypted"及び"MIME-Version"ではないフィールドは,無視されて,落とされる。
  6. (3) The header fields in the enclosed message which start with "Content-", plus the "Subject", "Message-ID", "Encrypted", and "MIME-Version" fields, must be appended, in order, to the header fields of the new message. Any header fields in the enclosed message which do not start with "Content-" (except for the "Subject", "Message-ID", "Encrypted", and "MIME- Version" fields) will be ignored and dropped.

    2番目及び後続の囲まれたメッセージからのすべてのフィールドは,再組み立て処理によって廃棄される。

    (4) All of the header fields from the second and any subsequent enclosing messages are discarded by the reassembly process.

5.2.2.2 細分化及び再組立ての例

5.2.2.2. Fragmentation and Reassembly Example

音声メッセージが,二つの部分に分断される場合,最初の断片は,次のようなものであろう。

If an audio message is broken into two pieces, the first piece might look something like this:
     X-Weird-Header-1: Foo
     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 1 of 2)
     Message-ID: 
     MIME-Version: 1.0
     Content-type: message/partial; id="ABC@host.com";
                   number=1; total=2

     X-Weird-Header-1: Bar
     X-Weird-Header-2: Hello
     Message-ID: 
     Subject: Audio mail
     MIME-Version: 1.\\0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... 符号化された音響データの最初の半分はここに来る ...
X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Audio mail (part 1 of 2) Message-ID: <id1@host.com> MIME-Version: 1.0 Content-type: message/partial; id="ABC@host.com"; number=1; total=2 X-Weird-Header-1: Bar X-Weird-Header-2: Hello Message-ID: <anotherid@foo.com> Subject: Audio mail MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... first half of encoded audio data goes here ...

そして,後半は,次のようなものであろう。

and the second half might look something like this:
     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail (part 2 of 2)
     MIME-Version: 1.0
     Message-ID: 
     Content-type: message/partial;
                   id="ABC@host.com"; number=2; total=2

       ... 符号化された音響データの後半はここに来る ...
From: Bill@host.com To: joe@otherhost.com Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Audio mail (part 2 of 2) MIME-Version: 1.0 Message-ID: <id2@host.com> Content-type: message/partial; id="ABC@host.com"; number=2; total=2 ... second half of encoded audio data goes here ...

そして,細分化されたメッセージが再構成されるとき,利用者に表示される結果のメッセージは次のようなものであろう。

Then, when the fragmented message is reassembled, the resulting message to be displayed to the user should look something like this:
     X-Weird-Header-1: Foo
     From: Bill@host.com
     To: joe@otherhost.com
     Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
     Subject: Audio mail
     Message-ID: 
     MIME-Version: 1.0
     Content-type: audio/basic
     Content-transfer-encoding: base64

       ... 符号化された音響データの最初の半分はここに来る ...
       ... 符号化された音響データの後半はここに来る ...
X-Weird-Header-1: Foo From: Bill@host.com To: joe@otherhost.com Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) Subject: Audio mail Message-ID: <anotherid@foo.com> MIME-Version: 1.0 Content-type: audio/basic Content-transfer-encoding: base64 ... first half of encoded audio data goes here ... ... second half of encoded audio data goes here ...

前の部分のMessage-Idを参照する細分化されたメッセージの2番目及び後続の断片のヘッダに "Reference"フィールドを含めることは,メールリーダが参照を理解し追跡する利点があるかもしれない。 しかし,このような"Reference"フィールドの生成はすべてオプションである。

The inclusion of a "References" field in the headers of the second and subsequent pieces of a fragmented message that references the Message-Id on the previous piece may be of benefit to mail readers that understand and track references. However, the generation of such "References" fields is entirely optional.

最後に,"Encrypted"ヘッダフィールドは,Privacy Enhanced Messaging (PEM) [RFC-1421, RFC-1422, RFC-1423, RFC-1424]により,廃止されたが,"message/partial"断片へ及び断片からの変換の文脈において遭遇したとき,上記の規則は,それを取り扱う正しい方法を記述していると信じられている。

Finally, it should be noted that the "Encrypted" header field has been made obsolete by Privacy Enhanced Messaging (PEM) [RFC-1421, RFC-1422, RFC-1423, RFC-1424], but the rules above are nevertheless believed to describe the correct way to treat it if it is encountered in the context of conversion to and from "message/partial" fragments.

5.2.3 external-body下位型

5.2.3. External-Body Subtype

external-body下位型は,実際の本体データは含まれず,単に参照であることを指示する。 この場合,パラメタは,外部データにアクセスする機構を記述する。

The external-body subtype indicates that the actual body data are not included, but merely referenced. In this case, the parameters describe a mechanism for accessing the external data.

MIME実体が,型"message/external-body"の実体であるとき,これは,ヘッダ,連続する二つのCRLF及びカプセル化されたメッセージのメッセージヘッダからなる。別の連続する二つのCRLFの組が現れたとき,これはもちろん,カプセル化されたメッセージのメッセージヘッダを終了する。 しかし,カプセル化されたメッセージの本体は,それ自体外部にあるので,それは後続の領域には現れない。例えば,次のメッセージを考える。

When a MIME entity is of type "message/external-body", it consists of a header, two consecutive CRLFs, and the message header for the encapsulated message. If another pair of consecutive CRLFs appears, this of course ends the message header for the encapsulated message. However, since the encapsulated message's body is itself external, it does NOT appear in the area that follows. For example, consider the following message:
     Content-type: message/external-body;
                   access-type=local-file;
                   name="/u/nsb/Me.jpeg"

     Content-type: image/jpeg
     Content-ID: 
     Content-Transfer-Encoding: binary

     THIS IS NOT REALLY THE BODY!
Content-type: message/external-body; access-type=local-file; name="/u/nsb/Me.jpeg" Content-type: image/jpeg Content-ID: <id42@guppylake.bellcore.com> Content-Transfer-Encoding: binary THIS IS NOT REALLY THE BODY!

"見せかけの本体"と呼ばれるかもしれない最後の領域は,殆どのexternal-bodyメッセージで無視される。 しかし,access-typeが"mail-server"である場合などこのようないくつかのメッセージのためには,外部情報を含むのに用いてよい。 この標準仕様書(TS)で定義される,"見せかけの本体"を使うaccess-typeは"mail-server"だけとするが,将来的に,この領域を使う他の使用によって,他のaccess-typesが定義されてよい。

The area at the end, which might be called the "phantom body", is ignored for most external-body messages. However, it may be used to contain auxiliary information for some such messages, as indeed it is when the access-type is "mail- server". The only access-type defined in this document that uses the phantom body is "mail-server", but other access-types may be defined in the future in other specifications that use this area.

すべての"message/external-body"実体中のカプセル化されたヘッダは,データを参照するために一意の識別子を与えるContent-IDヘッダフィールドを含まなければならない。 この識別子は,キャッシュ機構のため,又は,access-typeが"mail-server"であるときデータの受領を認識するために使ってもよい。

The encapsulated headers in ALL "message/external-body" entities MUST include a Content-ID header field to give a unique identifier by which to reference the data. This identifier may be used for caching mechanisms, and for recognizing the receipt of the data when the access-type is "mail-server".

ここで規定するように,ファイル名及びメールサーバ命令のような,externel-bodyのデータを記述するトークンは,US-ASCII文字集合であることが要求されることに注意すること。

Note that, as specified here, the tokens that describe external-body data, such as file names and mail server commands, are required to be in the US-ASCII character set.

実践において問題がある場合,"message/external-body"の新しく定義されたaccess-type又はその他の機構によって,将来のMIMEの拡張として,新しい機構が必要かもしれない。

If this proves problematic in practice, a new mechanism may be required as a future extension to MIME, either as newly defined access-types for "message/external-body" or by some other mechanism.

"message/partial"と同じように,型"message/external-body"のMIME実体は,7bitのcontent-transfer-encodingの使用(デフォルト)でなければならない。 特に,binary又は8bitトランスポートをサポートする環境においてさえ,"8bit"又は"binary"のcontent-transfer-encodingの使用は,型"message/external-body"の実体として,明示的に禁止される。

As with "message/partial", MIME entities of type "message/external- body" MUST have a content-transfer-encoding of 7bit (the default). In particular, even in environments that support binary or 8bit transport, the use of a content- transfer-encoding of "8bit" or "binary" is explicitly prohibited for entities of type "message/external-body".

5.2.3.1 一般のexternal-bodyパラメタ

5.2.3.1. General External-Body Parameters

"message/external- body"で使ってよいパラメタは次とする。

The parameters that may be used with any "message/external- body" are:
  1. ACCESS-TYPE
    ファイル又はデータが得られる,サポートされるアクセス機構を指示する語とする。 この語は,大文字小文字を区別しない。 値は,"FTP","ANON-FTP","TFTP","LOCAL-FILE"及び"MAIL-SERVER"を含むが,これらに限定されない。 "X-"で始まる実験値を除く将来の値は,RFC 2048を原規定とする標準仕様書(TS)(1)に記述されているように,IANAに登録されなけらばならない。 このパラメタは,無条件に必須であり,すべての"message/external-body"ごとに存在しなければならない。
  2. (1) ACCESS-TYPE -- A word indicating the supported access mechanism by which the file or data may be obtained. This word is not case sensitive. Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL- FILE", and "MAIL-SERVER". Future values, except for experimental values beginning with "X-", must be registered with IANA, as described in RFC 2048. This parameter is unconditionally mandatory and MUST be present on EVERY "message/external-body".
  3. EXPIRATION
    RFC 822の"date-time"構文で,RFC 1123によって年フィールドに4数字を許すように拡張された,外部データの存在が保証されない後の日付。 このパラメタはどんなaccess-typeと共に使ってもよく,いつでもオプションとする。
  4. (2) EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as extended by RFC 1123 to permit 4 digits in the year field) after which the existence of the external data is not guaranteed. This parameter may be used with ANY access-type and is ALWAYS optional.
  5. SIZE
    オクテット数によるデータの大きさ。 このパラメタの内容は,受信者が,外部データをもってくるために,必要な資源を拡張するかどうかを決定するのを援助する。 これはデータの大きさを正準形つまり,どのContent-Transfer-Encodingも適用する前又はデータが復号化された後,で記述することに注意すること。 このパラメタはどんなaccess-typeと共に使ってもよく,いつでもオプションとする。
  6. (3) SIZE -- The size (in octets) of the data. The intent of this parameter is to help the recipient decide whether or not to expend the necessary resources to retrieve the external data. Note that this describes the size of the data in its canonical form, that is, before any Content-Transfer-Encoding has been applied or after the data have been decoded. This parameter may be used with ANY access-type and is ALWAYS optional.
  7. PERMISSION
    クライアントがデータを上書きしようとするかもしれないことを期待するかどうかを指示する,大文字小文字を区別しないフィールドとする。 デフォルトにより又は許可が"read"の場合,それらが存在しないと仮定して,データが一度とってこられたら,それは再び必要ではない。 PERMISSIONが"read-write"の場合,この仮定は不正であり,局所的な複写が,キャッシュ以上でないことを考えなければならない。 "read"又は"read-write"だけを,許可の値として定義する。 このパラメタはどんなaccess-typeと共に使ってもよく,いつでもオプションとする。
  8. (4) PERMISSION -- A case-insensitive field that indicates whether or not it is expected that clients might also attempt to overwrite the data. By default, or if permission is "read", the assumption is that they are not, and that if the data is retrieved once, it is never needed again. If PERMISSION is "read-write", this assumption is invalid, and any local copy must be considered no more than a cache. "Read" and "Read- write" are the only defined values of permission. This parameter may be used with ANY access-type and is ALWAYS optional.

ここで定義されるaccess-typeの正確なセマンティクスは,後続の箇条に記述される。

The precise semantics of the access-types defined here are described in the sections that follow.

5.2.3.2 'ftp'及び'tftp' access-type

5.2.3.2. The 'ftp' and 'tftp' Access-Types

FTP又はTFTPのaccess-typeは,メッセージ本体が,FTP[RFC-959]プロトコル又はTFTP[RFC-783]プロトコルにより,ファイルとしてアクセスできることを指示する。これらのaccess-typeには,次の追加のパラメタが必須とする。

An access-type of FTP or TFTP indicates that the message body is accessible as a file using the FTP [RFC-959] or TFTP [RFC- 783] protocols, respectively. For these access-types, the following additional parameters are mandatory:
  1. NAME
    実際の本体データを含むファイルの名前。
  2. (1) NAME -- The name of the file that contains the actual body data.
  3. SITE
    与えられたプロトコルを使用して,ファイルが得られるかも知れない。
  4. (2) SITE -- A machine from which the file may be obtained, using the given protocol. This must be a fully qualified domain name, not a nickname.
  5. FTPを使用して,どんなデータでも引き出すときにも,サイトのパラメタによって名付けられた機械のために,利用者は一般にログインID及びパスワードを尋ねられる必要がある。 セキュリティ上の理由から,このようなIDとパスワードはcontent-typeパラメタとして指定されないが,利用者から得られなければならない。
  6. (3) Before any data are retrieved, using FTP, the user will generally need to be asked to provide a login id and a password for the machine named by the site parameter. For security reasons, such an id and password are not specified as content-type parameters, but must be obtained from the user.

加えて,次のパラメタをオプションとする。

In addition, the following parameters are optional:
  1. DIRECTORY
    NAMEにより名付けられたデータがとられてよいディレクトリ。
  2. (1) DIRECTORY -- A directory from which the data named by NAME should be retrieved.
  3. MODE
    情報をとってくるとき,使われるモードを指示する,大文字小文字を区別しない文字列。 access-type"TFTP"に正当な値は,TFTPプロトコル[RFC-783]で規定されるとおり,"NETASCII","OCTET"及び"MAIL"とする。 access-type"FTP"に正当な値は,"ASCII", "EBCDIC","IMAGE","LOCALn",ここで,"n"は10進の整数で典型的には8,とする。 これらは,FTPプロトコル[RFC-959]で規定されるとおり,表現の型"A""E""I"及び"L n"に対応している。 "BINARY"及び"TENEX"はMODEの値として正しくなく,かわりに"OCTET","IMAGE"又は"LOCAL8"を使ったほうがよいことに注意すること。 MODEが指定されなかった場合,TFTPの場合のデフォルト値は"NETASCII",それ以外は"ASCII"とする。
  4. (2) MODE -- A case-insensitive string indicating the mode to be used when retrieving the information. The valid values for access-type "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the TFTP protocol [RFC- 783]. The valid values for access-type "FTP" are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a decimal integer, typically 8. These correspond to the representation types "A" "E" "I" and "L n" as specified by the FTP protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid values for MODE and that "OCTET" or "IMAGE" or "LOCAL8" should be used instead. IF MODE is not specified, the default value is "NETASCII" for TFTP and "ASCII" otherwise.

5.2.3.3 'anon-ftp' access-type

5.2.3.3. The 'anon-ftp' Access-Type "anon-ftp" access-typeは,利用者が,指定のサイトで,名前とパスワードを提供することを尋ねられる必要がないことを除いて,"ftp"アクセス型と同一とする。 かわりに,ログインが"anonymous"及び利用者のメールアドレスに対応したパスワードで,ftpプロトコルが使われる。

The "anon-ftp" access-type is identical to the "ftp" access type, except that the user need not be asked to provide a name and password for the specified site. Instead, the ftp protocol will be used with login "anonymous" and a password that corresponds to the user's mail address.

5.2.3.4 'local-file' access-type

5.2.3.4. The 'local-file' Access-Type

"local-file"のaccess-type"は,実際の本体が,局所の機械上のファイルとしてアクセス可能であることを指示する。 このaccess-typeのために二つの追加のパラメタが定義される。

An access-type of "local-file" indicates that the actual body is accessible as a file on the local machine. Two additional parameters are defined for this access type:
  1. NAME
    実際の本体データを含むファイルの名前。 このパラメタは,"local-file" access-typeで必須とする。
  2. (1) NAME -- The name of the file that contains the actual body data. This parameter is mandatory for the "local-file" access-type.
  3. SITE
    データファイルへアクセスを持つために知られる,機械又は機械の組のための,ドメイン指定子。 このオプションのパラメタは,データのための参照の局所性,すなわち,ファイルが視覚化されることが期待される単数又は複数のサイト,を記述するために使われる。 例えば大域ファイルシステム経由のように,広く可能にすることを期待するファイルを指定するために,単一のアステリスクを使ってもよいけれども, 直接可視化したほうがよいデータの機械の組を指示するため, "*.bellcore.com"のように,ドメイン名の一部をワイルドカード対応するために,アステリスクを使ってよい。
  4. (2) SITE -- A domain specifier for a machine or set of machines that are known to have access to the data file. This optional parameter is used to describe the locality of reference for the data, that is, the site or sites at which the file is expected to be visible. Asterisks may be used for wildcard matching to a part of a domain name, such as "*.bellcore.com", to indicate a set of machines on which the data should be directly visible, while a single asterisk may be used to indicate a file that is expected to be universally available, e.g., via a global file system.

5.2.3.5 'mail-server' access-type

5.2.3.5. The 'mail-server' Access-Type

"mail-server" access-typeは,実際の本体がメールサーバから可能であることを指示する。 このaccess-typeのために,二つの追加のパラメタが定義される。

The "mail-server" access-type indicates that the actual body is available from a mail server. Two additional parameters are defined for this access-type:
  1. SERVER
    実際の本体データを得ることのできる,メールサーバのaddr-spec。 このパラメタは"mail-server" access-typeで必須とする。
  2. (1) SERVER -- The addr-spec of the mail server from which the actual body data can be obtained. This parameter is mandatory for the "mail-server" access-type.
  3. SUBJECT
    データを得るために送られるメールの中で,使われる主題。 主題行のメールサーバをキーイングすることは推奨しないが,このようなメールサーバは存在することが知られている。 このパラメタはオプションとする。
  4. (2) SUBJECT -- The subject that is to be used in the mail that is sent to obtain the data. Note that keying mail servers on Subject lines is NOT recommended, but such mail servers are known to exist. This is an optional parameter.

メールサーバは様々な構文を受け入れ,それらのいくつかは複数行なので,メールサーバへ送られる完全な命令は,content-typeヘッダフィールドのパラメタとして含まれない。 かわりに,メディア型が"message/external-body"及びaccess-typeがmail-serverであるとき,"見せかけの本体"として,それは提供される。

Because mail servers accept a variety of syntaxes, some of which is multiline, the full command to be sent to a mail server is not included as a parameter in the content-type header field. Instead, it is provided as the "phantom body" when the media type is "message/external-body" and the access-type is mail-server.

MIMEは,メールサーバの構文を定義しないことに注意すること。 そうではなく,見せかけの本体の中に任意のメールサーバの命令を含むことを許す。 実装は,関連のデータを引いてくるためにメールサーバアドレスへ送ったメッセージの本体の中に,見せかけの本体を含まなければならない。

Note that MIME does not define a mail server syntax. Rather, it allows the inclusion of arbitrary mail server commands in the phantom body. Implementations must include the phantom body in the body of the message it sends to the mail server address to retrieve the relevant data.

他のaccess-typeと異なり,mail-serverアクセスは非同期で,将来予想できない時間に起きる。 この理由により,戻ってきたデータを原"message/external-body"実体とマッチさせることができる,機構があることは重要である。 MIMEメールサーバは,このようなマッチングを容易にするため,原"message/external-body"実体に使われた,戻ってきたメッセージ同じContent-IDを使わなければならない。

Unlike other access-types, mail-server access is asynchronous and will happen at an unpredictable time in the future. For this reason, it is important that there be a mechanism by which the returned data can be matched up with the original "message/external-body" entity. MIME mail servers must use the same Content-ID field on the returned message that was used in the original "message/external-body" entities, to facilitate such matching.

5.2.3.6 external-bodyのセキュリティ上の論点

5.2.3.6. External-Body Security Issues

"message/external-body"実体は,二つの重要なセキュリティ上の論点を起こす。

"Message/external-body" entities give rise to two important security issues:
  1. "message/external-body"参照を通したデータへのアクセスは,メッセージ作成者により指定された操作をメッセージ受信者が実行するのを,効果的にできる。 ゆえに,メッセージ作成者が,受信者をだまして,別な方法では成せないものをするようにする可能性がある。 例えば,受信者が得ることを承認されていないデータを引き取る動作を指定することができ,受信者は,知らないうちに,あるセキュリティポリシを破ることを起こす。 この理由により,外部参照を解決できる利用者エージェントは,受信者にもたらす動作の記述をいつも段階的に行い,それを実行する前に明示的な許可を求めなければならない。

    'mail-server' access-typeは,受信者に,もともとのメッセージ作成者による指定された内容の新しいメッセージを送ることをおこすので,特に攻撃されやすい。 不正の可能性があるとすると,MIMEの"message/external-body"参照を解決しようとするときに,例えば,ヘッダフィールドの注釈内で,構成された要求メッセージが自動的に生成されたものであることを示す,明確な通知を含むほうがよい。
  2. (1) Accessing data via a "message/external-body" reference effectively results in the message recipient performing an operation that was specified by the message originator. It is therefore possible for the message originator to trick a recipient into doing something they would not have done otherwise. For example, an originator could specify a action that attempts retrieval of material that the recipient is not authorized to obtain, causing the recipient to unwittingly violate some security policy. For this reason, user agents capable of resolving external references must always take steps to describe the action they are to take to the recipient and ask for explicit permisssion prior to performing it. The 'mail-server' access-type is particularly vulnerable, in that it causes the recipient to send a new message whose contents are specified by the original message's originator. Given the potential for abuse, any such request messages that are constructed should contain a clear indication that they were generated automatically (e.g. in a Comments: header field) in an attempt to resolve a MIME "message/external-body" reference.
  3. MIMEは時々メッセージの完全性と確実性のなんらかの保証を抵抗する環境で,使われ得る。 もしそうなら,このような保証は,メッセージの実際の直接のないように対してだけ適用してよい。それらは,MIMEの"message/external-body"機構を通してアクセスされるデータには適用してもよいし,適用しなくてもよい。 特に,メッセージングシステム自身がセキュリティがあるときでさえ,特定のアクセス機構を失う可能性をもつかもしれない。

    MIME機構の利用可能である又はないどちらの場合にも,この問題はが存在することに注意するほうがよい。 安全なメッセージのテキストでの文書を含むFTPサイトへの安易な参照も同様の問題を起こす。ただ一つの違いは,MIMEはこのようなデータへの自動的な引き取りを提供することで,利用者は,保障されない信頼はこのような自動的な引き取り機構であると 位置付けるかもしれない。
  4. (2) MIME will sometimes be used in environments that provide some guarantee of message integrity and authenticity. If present, such guarantees may apply only to the actual direct content of messages -- they may or may not apply to data accessed through MIME's "message/external-body" mechanism. In particular, it may be possible to subvert certain access mechanisms even when the messaging system itself is secure. It should be noted that this problem exists either with or without the availabilty of MIME mechanisms. A casual reference to an FTP site containing a document in the text of a secure message brings up similar issues -- the only difference is that MIME provides for automatic retrieval of such material, and users may place unwarranted trust is such automatic retrieval mechanisms.

5.2.3.7 例と追加説明

5.2.3.7. Examples and Further Explanations

external-body機構が"multipart/alternative"メディア型と結合して使われるとき,同じ実体が同じフォーマットであるが異なったアクセス機構を経由する場合を含むように,"multipart/alternative"の機能を拡張する。 これが行われる場合,メッセージの発信者は,最初,好みのフォーマットそして好みのアクセス機構で,部分を順序付けしなければならない。 受信者のビュアは,フォーマット及びアクセス機構の両方により,一覧を評価した方がよい。

When the external-body mechanism is used in conjunction with the "multipart/alternative" media type it extends the functionality of "multipart/alternative" to include the case where the same entity is provided in the same format but via different accces mechanisms. When this is done the originator of the message must order the parts first in terms of preferred formats and then by preferred access mechanisms. The recipient's viewer should then evaluate the list both in terms of format and access mechanisms.

非常に広い領域のファイルシステムの新しい可能性とともに, ファイルシステムから直接ファイルがアクセスできるのかできないのかの機械の組を,前もって知ることは大変難しくなった。 それゆえ,直接に試みるファイル名及びファイルがアクセス可能であることが知られている一つ以上のサイトの名前の両方を提供することは意味があるかもしれない。 実装は,FTP又はその他のプロトコルを使うか,匿名ファイル検索を使うか,又は,利用者に必要な名前とパスワードを入力するように促すことによって,遠隔のファイルを引き出すことを試みることができる。 もし,外部本体が,複数の機構でアクセス可能ならば, 送信者は,中に入っている"multipart/alternative"実体の本体部分のなかに,"message//external-body"型の複数の実体を含めることができる。

With the emerging possibility of very wide-area file systems, it becomes very hard to know in advance the set of machines where a file will and will not be accessible directly from the file system. Therefore it may make sense to provide both a file name, to be tried directly, and the name of one or more sites from which the file is known to be accessible. An implementation can try to retrieve remote files using FTP or any other protocol, using anonymous file retrieval or prompting the user for the necessary name and password. If an external body is accessible via multiple mechanisms, the sender may include multiple entities of type "message/external-body" within the body parts of an enclosing "multipart/alternative" entity.

しかし,external-body機構は,mail-server access-typeに示されるように,ファイル検索に限定することを想定していない。 これを超えて,例えば,ビデオクリップへの外部参照のためのビデオサーバを使うことが想像できる。

However, the external-body mechanism is not intended to be limited to file retrieval, as shown by the mail-server access-type. Beyond this, one can imagine, for example, using a video server for external references to video clips.

"message/external-body"データの本体内に現われる,組み込みメッセージヘッダフィールドは,プレーンUS-ASCIIテキスト以外の何かであったら,外部本体はその型を宣言するヘッダ部を持たないから,外部本体のメディア型を宣言するために使わなければならない。 同様に,"7bit"以外のContent-transfer-encodingも,ここで宣言されなければならない。 だから,PostScriptフォーマットでのオブジェクトを参照する,完全な"message/external-body"メッセージは次のようになる。

The embedded message header fields which appear in the body of the "message/external-body" data must be used to declare the media type of the external body if it is anything other than plain US-ASCII text, since the external body does not have a header section to declare its type. Similarly, any Content-transfer-encoding other than "7bit" must also be declared here. Thus a complete "message/external-body" message, referring to an object in PostScript format, might look like this:
     From: Whomever
     To: Someone
     Date: Whenever
     Subject: whatever
     MIME-Version: 1.0
     Message-ID: 
     Content-Type: multipart/alternative; boundary=42
     Content-ID: 

     --42
     Content-Type: message/external-body; name="BodyFormats.ps";
                   site="thumper.bellcore.com"; mode="image";
                   access-type=ANON-FTP; directory="pub";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: 

     --42
     Content-Type: message/external-body; access-type=local-file;
                   name="/u/nsb/writing/rfcs/RFC-MIME.ps";
                   site="thumper.bellcore.com";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: 

     --42
     Content-Type: message/external-body;
                   access-type=mail-server
                   server="listserv@bogus.bitnet";
                   expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

     Content-type: application/postscript
     Content-ID: 

     get RFC-MIME.DOC

     --42--
From: Whomever To: Someone Date: Whenever Subject: whatever MIME-Version: 1.0 Message-ID: <id1@host.com> Content-Type: multipart/alternative; boundary=42 Content-ID: <id001@guppylake.bellcore.com> --42 Content-Type: message/external-body; name="BodyFormats.ps"; site="thumper.bellcore.com"; mode="image"; access-type=ANON-FTP; directory="pub"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> --42 Content-Type: message/external-body; access-type=local-file; name="/u/nsb/writing/rfcs/RFC-MIME.ps"; site="thumper.bellcore.com"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> --42 Content-Type: message/external-body; access-type=mail-server server="listserv@bogus.bitnet"; expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" Content-type: application/postscript Content-ID: <id42@guppylake.bellcore.com> get RFC-MIME.DOC --42--

上記の例題では,外部PostScriptデータのために,デフォルトのContent-transfer-encodingの"7bit"が仮定される。

Note that in the above examples, the default Content-transfer- encoding of "7bit" is assumed for the external postscript data.

"message/partial"型のように,"message/external-body"メディア型が透過的であることが想定される,すなわち,その型の本体のメッセージを運ぶのではなく,外部本体のデータ型を運ぶことが想定される。 ゆえに,外側及び内側部分のヘッダは,"message/partial"と同じ規則で,結合されなければならない。 特に,このことは,Content-typeフィールド及びSubjectフィールドは上書きされるが,Fromフィールドは保存されることを意味する。

Like the "message/partial" type, the "message/external-body" media type is intended to be transparent, that is, to convey the data type in the external body rather than to convey a message with a body of that type. Thus the headers on the outer and inner parts must be merged using the same rules as for "message/partial". In particular, this means that the Content-type and Subject fields are overridden, but the From field is preserved.

外部本体は,外部本体参照とともには転送されないため,参照自身に適用される転送制限に適合する必要はないことに注意すること。 特に,インターネットメールトランスポートは7bit及び行長制限を課すが,これらは,2値の外部本体参照に自動的に適用されることはない。 だから,Content-Transfer-Encodingは,許容されるが,一般に必要ではない。

Note that since the external bodies are not transported along with the external body reference, they need not conform to transport limitations that apply to the reference itself. In particular, Internet mail transports may impose 7bit and line length limits, but these do not automatically apply to binary external body references. Thus a Content-Transfer-Encoding is not generally necessary, though it is permitted.

"message/external-body"型のメッセージの本体は,RFC 822メッセージのための基本構文が適用されることに注意すること。 特に,最初のCRLFが連続した組の前は,ヘッダ情報であり,その後は,多くのaccess-typeで無視される,本体情報である。

Note that the body of a message of type "message/external-body" is governed by the basic syntax for an RFC 822 message. In particular, anything before the first consecutive pair of CRLFs is header information, while anything after it is body information, which is ignored for most access-types.

5.2.4 その他のメッセージ下位型

5.2.4. Other Message Subtypes

MIME実装は,一般的にいって,認識されない"message"の下位型を,"application/octet-stream"と同等であるものとして,扱わなければならない。

MIME implementations must in general treat unrecognized subtypes of "message" as being equivalent to "application/octet-stream".

電子メールで用いることを想定した,将来の"message"の下位型は,"7bit"符号化に制限するほうがよい。 "7bit"に制限することができない場合は,"message"以外の型を使うほうがよい。

Future subtypes of "message" intended for use with email should be restricted to "7bit" encoding. A type other than "message" should be used if restriction to "7bit" is not possible.

6. 実験メディア型値

6. Experimental Media Type Values

文字"X-"で始まるメディア型値は,相互の合意の上で同意するシステムによって使われる私的な値とする。 厳密な公的定義以外のフォーマットは,"X-"接頭辞とともに命名されなければならず,公的に規定される値は"X-"で始まってはならない。 広く使われているAndrewシステムの旧版では"X-BE2"という名前を使っているので,新しいシステムは多分異なる名前を選んだほうがよい。

A media type value beginning with the characters "X-" is a private value, to be used by consenting systems by mutual agreement. Any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-". (Older versions of the widely used Andrew system use the "X- BE2" name, so new systems should probably choose a different name.)

一般的に,最上位の型で"X-"を使うことは強く非推奨とする。 実装者は,可能な限り,存在する型の下位型を作ったほうがよい。 多くの場合,新しい最上位の型より,"application"の下位型とするほうが適当である。

In general, the use of "X-" top-level types is strongly discouraged. Implementors should invent subtypes of the existing types whenever possible. In many cases, a subtype of "application" will be more appropriate than a new top-level type.

7. まとめ

7. Summary

五つの個別メディア型は,"audio","image"又は多くの他の種類のデータとして,実体をタグ付けするための標準的な機構を提供した。 複合メディア型の"multipart"及び"message"は,単一のメッセージ中に,異なる型の実体の混合と階層的構造化を可能にした。 一つの個別のパラメタ構文は,データフォーマットの詳細の追加の指定,特に代替の文字集合の指定を可能にした。 追加のオプションのヘッダフィールドは,たくさんの実装者に望まれると思われる,信頼できる拡張を提供した。 最後に,同意した利用者エージェントによる一般的な使用のため,特に"message/partial"及び"message/external-body"が注目されるが,たくさんの便利なメディア型が定義された。

The five discrete media types provide provide a standardized mechanism for tagging entities as "audio", "image", or several other kinds of data. The composite "multipart" and "message" media types allow mixing and hierarchical structuring of entities of different types in a single message. A distinguished parameter syntax allows further specification of data format details, particularly the specification of alternate character sets. Additional optional header fields provide mechanisms for certain extensions deemed desirable by many implementors. Finally, a number of useful media types are defined for general use by consenting user agents, notably "message/partial" and "message/external-body".

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

9. Security Considerations

セキュリティに関する論点は,"application/postscript"型及び"message/external-body"型の箇所並びにRFC 2048を原規定とする標準仕様書(TS)(1)で論じられている。 実装者は,受信者の環境でのあらゆる動作の遠隔実行を起すことができるすべてのメディア型のセキュリティとの関わり合いに特別の注意を払ったほうがよい。 このような場合,"application/postscript"型の議論は,遠隔実行機能をもつ他のメディアについて考えるためのモデルとして提供されるであろう。

Security issues are discussed in the context of the "application/postscript" type, the "message/external-body" type, and in RFC 2048. Implementors should pay special attention to the security implications of any media types that can cause the remote execution of any actions in the recipient's environment. In such cases, the discussion of the "application/postscript" type may serve as a model for considering other media types with remote execution capabilities.

9. 原著者の連絡先

9. Authors' Addresses

追加の情報のために原規定の著者に連絡をとるにはインターネットメールを使うのがよい。

For more information, the authors of this document are best contacted via Internet mail:
   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
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
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のRFC 822拡張に関する作業グループの作業の結果である。作業グループ議長のGreg Vaudreuilには,次の連絡先によって連絡できる。

MIME is a result of the work of the Internet Engineering Task Force Working Group on RFC 822 Extensions. The chairman of that group, Greg Vaudreuil, may be reached at:
   Gregory M. Vaudreuil
   Octel Network Services
   17080 Dallas Parkway
   Dallas, TX 75248-1905
   USA

   EMail: Greg.Vaudreuil@Octel.Com
Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA EMail: Greg.Vaudreuil@Octel.Com