If an audio message is broken into two pieces, the first piece might look something like this:

オーディオのメッセージが2つの断片に分かれているならば、最初の断片はこのような何かのようであるかもしれません：

and the second half might look something like this:

そして、後半はこのような何かのようであるかもしれません：

Then, when the fragmented message is reassembled, the resulting message to be displayed to the user should look something like this:

そして、粉々にされたメッセージが再集合される時に、ユーザに表示される結果として生じているメッセージはこのような何かのようであるべきです：

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.

2番目のヘッダーでの「References」フィールドの包含、前の断片の参照メッセージ-IDが分かる読者に郵送するためには利益のものであるかもしれないという断片化しているメッセージ、およびその後の道の参照。 しかしながら、そのような「References」フィールドの世代は完全にオプションです。

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.

最後に、それは、ヘッダーフィールドがあった「Encrypted」と注意した、RFC-1421、RFC-1422、RFC-1423、RFC-1424をメッセージで送って(PEM)、強化されたプライバシによって、時代遅れにしたことはそうであるべきであるけれども、それが「message/partial」フラグメントへの(からの)変換の文脈の中で見つかるならば、上の規則は、それにもかかわらず、それを扱う正しい方法を説明すると信じられます。

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.

external-bodyサブタイプは、実際のボディデータが含まれるのでなく単に参照されることを示します。この場合に、外部データにアクセスすることに、パラメータはメカニズムを記述します。

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:

MIME実体がタイプ「message/external-body」をもっている時に、それはカプセル化したメッセージのためにヘッダー、2つの連続的な複数のCRLF、およびメッセージヘッダから成ります。連続的な複数のCRLFの別のペアが出現するならば、これはもちろんカプセル化したメッセージのためにメッセージヘッダを終えます。しかし、カプセル化したメッセージの体が自身で外部なので、それは続いているエリアに出ません。例えば、以下のメッセージを考慮してください：

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.

「phantom body」と呼ばれるかもしれない終わりのエリアはほとんどの外部ボディメッセージのために無視されます。しかし、実にそれが、アクセスタイプが「メールサーバ」である時である時に、それは、いくつかのそのようなメッセージのために補助の情報を含むように使われるかもしれません。phantom bodyを使うこの文書の中で定義された唯一のアクセスタイプは「メールサーバ」であるけれども、他のアクセスタイプは、このエリアを使う他の仕様の中の未来に定義されるかもしれません。

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".

すべての「message/external-body」実体の中のカプセル化したヘッダーは、一意の名前(それによってデータを参照します)を与えるために内容idヘッダーフィールドを含まなければなりません。アクセスタイプが「メールサーバ」である時に、この識別子は、キャッシングメカニズムのために、そしてデータの受け取りを認めるために使われるかもしれません。

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.

ここで指定されるように、ファイル名とメールサーバコマンドなどの外部ボディデータを説明するトークンが、US-ASCII文字セットの中にあることを要求されることに注意してください。

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.

これが実際の場で疑わしいと判明するならば、新しいメカニズムはMIMEへの将来の拡張として、「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".

「message/partial」と同様に、タイプ「message/external-body」のMIME実体は7ビット(デフォルト)のコンテンツ転送エンコーディングを持たなければなりません。特に、二進または8ビットのトランスポートをサポートする環境の中で、「8ビット」または「2進です」のコンテンツ転送エンコーディングの使用はタイプ「message/external-body」の実体のために明示的に禁止されています。

The parameters that may be used with any "message/external- body" are:

どのような「message/external-body」によってでも使われるかもしれないパラメータは以下の通りです：

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

ここで定義されたアクセスタイプの精密な意味論は、続いているセクションの中で説明されます。

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:

FTPまたはTFTPのアクセスタイプは、それぞれFTP[RFC-959]またはTFTP[RFC-783]プロトコルを使って、本文がファイルとしてアクセス可能であることを示します。これらのアクセスタイプにとって、以下の追加のパラメータは義務的です：

In addition, the following parameters are optional:

さらに、以下のパラメータはオプションです：

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.

ユーザが、指定されたサイトに名前とパスワードを明かすように頼まれる必要がない以外、「そのうち、ftpします」アクセスタイプは「ftp」アクセスタイプに同一です。代わりに、ftpプロトコルは、ログイン「匿名です」とユーザのメール・アドレスと一致しているパスワードによって使われるでしょう。

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:

「local-file」のアクセスタイプは、実際のボディがローカル・マシンの上のファイルとしてアクセス可能であることを示します。2つの追加のパラメータがこのアクセスタイプのために定義されます：

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:

「mail-server」アクセスタイプは、実際のボディがメールサーバから使用可能であることを示します。2つの追加のパラメータがこのアクセスタイプのために定義されます：

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.

メールサーバが、さまざまなシンタックス(それのいくつかがマルチ行です)を受信するので、メールサーバに送信される完全なコマンドはContent-Typeヘッダーフィールドのパラメータとして含まれません。代わりに、メディアタイプが「message/external-body」であり、アクセスタイプがメールサーバである時に、それは「phantom body」として提供されます。

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.

MIMEがメールサーバシンタックスを定義しないことに注意してください。むしろ、それはphantom bodyィの中で任意のメールサーバコマンドの含意を許します。インプリメンテーションは、phantom bodyを、関連データを検索するために、それがメールサーバアドレスに送信するメッセージのボディに含めなければなりません。

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.

他のアクセスタイプと違って、メールサーバアクセスは非同期で、未来の予期不能の時に起こるでしょう。この理由にとって、戻ったデータがオリジナルの「message/external-body」実体によって調和することができるメカニズムがあることは重要です。MIMEメールサーバは、そのような照合を容易にするためにオリジナルの「message/external-body」実体の中で使われた戻ったメッセージの上の同じContent-IDフィールドを使わなければなりません。

"Message/external-body" entities give rise to two important security issues:

「Message/external-body」実体は2つの重要なセキュリティ問題を起こします：

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.

外部ボディメカニズムが「multipart/alternative」メディアタイプと連携して使われる時に、同じ実体が同じフォーマットの中で提供されるケースを含むために、それは「multipart/alternative」の機能性を拡張するけれども、違うacccesメカニズム経由でです。これがされる時に、メッセージの発信者は好まれたフォーマットで、それから好まれたアクセスメカニズムによって最初に部分を配列しなければなりません。受領者のビュアーはフォーマットとアクセスメカニズムで両方ともその時リストを評価するべきです。

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.

まさしくその広いエリアファイルのシステムの明らかになる可能性によって、ファイルが直接ファイルシステムからアクセス可能になるであろうし、ないであろうマシンのセットを事前に知ることは非常に難しくなります。従って、両方のファイル名を提供し、直接試されることは意味をなすかもしれず、1以上の名前は置きます(ファイルが、アクセス可能であると知られています)。インプリメンテーションは、FTPまたはすべての他のプロトコルを使い、匿名のファイル検索を使うか、ユーザで必要な名前とパスワードの入力を促して、リモートファイルを検索しようとすることができます。外部のボディが多重機構経由でアクセス可能ならば、送信側は取り囲んでいる「multipart/alternative」実体のボディ部分の中にタイプ「message/external-body」の複数の実体を含むかもしれません。

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.

しかし、メールサーバアクセスタイプによって示されるように、外部ボディメカニズムは、検索をファイルするために制限されることを意図していません。これを越えて、人は、想像し、例えばビデオクリップに外部参照のためにビデオ・サーバーを使うことができます。

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:

「message/external-body」データのボディの中で出現する埋め込まれたメッセージヘッダフィールドは、外部のボディが、そのタイプを宣言するためにヘッダーセクションを持っていないので、それが平易なUS-ASCIIテキスト以外の何かであるならば外部のボディのメディアタイプを宣言するために使われなければなりません。同様に、「7ビット」以外のどのようなコンテンツ転送エンコーディングでもまたここに宣言されなければなりません。従って、完全な「message/external-body」メッセージは、PostScriptフォーマットの中のオブジェクトを参照して、このように見えるかもしれません：

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

上記の例において、「7ビット」のデフォルトコンテンツ転送エンコーディングが外部のPostScriptデータのために仮定されることに注意してください。

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.

「message/partial」タイプのように、「message/external-body」メディアタイプは、透過的で、すなわち、そのタイプのボディを持つメッセージを伝えることというよりも外部のボディの中でデータ型を伝えることを意図しています。従って、外と内側の部分の上のヘッダーは、「message/partial」について同じ規則を使って、マージされなければなりません。特に、これは、Content-Typeとサブジェクトのフィールドが無効にされることを意味しているけれども、Fromフィールドは保存されます。

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.

外部のボディが外部のボディリファレンスとともに輸送されないので、それらが、リファレンス自身にあてはまる制限を輸送するために対応する必要がないことに注意してください。 特に、インターネットメールトランスポートは7ビットを課し、長さ限界に線を引くかもしれないけれども、これらは自動的に2進の外部のボディリファレンスにあてはまりません。従って、それが許されるけれども、Content-Transfer-Encodingは一般に必要でありません。

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.

タイプ「message/external-body」のありのメッセージのボディがRFC 822メッセージのために基本のシンタックスによって制御したことに注意してください。特に、それの後の何でもボディ情報である間、複数のCRLFの最初の連続的なペアの前の何でもヘッダー情報です(それはほとんどのアクセスタイプのために無視されます)。

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

MIMEインプリメンテーションは一般に「application/octet-stream」と等しいこととして「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.

Eメールによって使用のために意図されていた「メッセージ」の未来のサブタイプは「7ビット」エンコーディングに限定されるべきです。 「7ビット」への制限が可能でないならば、「メッセージ」以外のタイプは使われるべきです。

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-」から始まっているメディアタイプ値は、双方の合意によって同意システムによって使われるために私用の値です。過酷で、公開の定義のないどのようなフォーマットでも「X-」接頭部によって名付けられなければならず、公然と指定された値は決して「X-」から始まらないこととします。(広く使われたアンドリューシステムのより古いバージョンは「X-BE2」名を使うので、新システムはたぶん違う名前を選ぶべきです。)

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.

一般に、「X-」トップレベルのタイプの使用は強くやめさせられます。作成者は可能である時はいつでも既存のタイプのサブタイプを発明するべきです。 多くの場合に、「application」のサブタイプは新しいトップレベルのタイプより適切になるでしょう。

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".

5種類の離散的なメディアタイプは提供し、実体を、「オーディオ」、「イメージ」、またはいくつかの他の種類のデータと名付けるための標準化されたメカニズムを提供します。 複合の「multipart」と「message」メディアタイプは1つのメッセージの中の違うタイプの実体の混合と階層の構造化を許します。 区別されたパラメータシンタックスはさらにデータフォーマット詳細の仕様、特に文字セット切替機構の仕様を許します。多くの作成者によって望ましいと考えられている一定の拡張のために追加のオプショナル・ヘッダ・フィールドはメカニズムを提供します。 最終的に、多くの有益なメディアタイプは一般の使用のために同意ユーザエージェント、特に「message/partial」、および「message/external-body」によって定義されます。

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.

セキュリティ問題はRFC 2048「application/PostScript」タイプ(「message/external-body」タイプ)のコンテキストの中とRFCの中で議論されます。作成者は、受領者の環境の中でどのような行動のリモート実行でも起こすことができるどのようなメディアタイプのセキュリティ含意にでも特殊な注意を払うべきです。そのような場合に、「application/PostScript」タイプの議論は、リモート実行能力によって他のメディアタイプを考慮するためにモデルとして役立つかもしれません。

For more information, the authors of this document are best contacted via Internet mail:

詳細については、この文書の著者はインターネットメール経由で最もよく連絡されます：

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:

MIMEはRFC 822拡張の上のインターネット技術特別調査委員会作業グループの作業の結果です。そのグループの会長、Gregory Vaudreuilに次で連絡することができます：

This appendix contains the complete BNF grammar for all the syntax specified by this document.

この文書によって指定されたすべてのシンタックスのためにこの付録は完全なBNF文法を含んでいます。

By itself, however, this grammar is incomplete. It refers by name to several syntax rules that are defined by RFC 822. Rather than reproduce those definitions here, and risk unintentional differences between the two, this document simply refers the reader to RFC 822 for the remaining definitions. Wherever a term is undefined, it refers to the RFC 822 definition.

しかし、単独ではこの文法は不完全です。RFC 822によって定義されるいくつかの構文規則に、それは名前によって差し向けます。ここでそれらの定義を複写し、両者の故意でない違いを思い切ってやってみるというよりも、この文書は単に残存定義のためにリーダをRFC 822に差し向けます。 たとえ、項がどこで不確定でも、それはRFC 822定義を参照します。