MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
HTML(MHTML)などの集合文書のMIMEカプセル化

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.

この文書はインターネットコミュニティのためにインターネット標準トラックプロトコルを指定し、改良のために議論と提案を要求します。このプロトコルの標準化状態とステータスのために「インターネット公式プロトコル標準」(STD 1)の現行版を参照してください。このメモの配布は無制限です。

Copyright (C) The Internet Society (1999). All Rights Reserved.

HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI.

HTML[RFC 1866]は、マルチメディア文書を指定するための強力な方法を定義します。これらのマルチメディア文書はtext/html根資源(オブジェクト)とtext/html根資源の中で均一な資源識別子(URI)によって参照された他の補助的な資源(イメージ、ビデオクリップ、アプレットなどオブジェクト)から成ります。HTMLマルチメディア文書がブラウザによって取り戻される時に、これらのコンポーネント資源のそれぞれは位置からリアルタイムで個々に取り戻されて、各URIによって指定されて、プロトコルを使っています。

In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure.

完全なHTMLマルチメディア文書を1つの電子メールメッセージの中に移すために、次をすることは必要です：a) text/html根資源とそれが1つの合成のメッセージ構造の中に参照する補助的な資源のすべてを集めてください、および b) text/htmlのルートにおけるURIがその合成のメッセージ構造の中で補助的な資源を参照することができる方法を定義してください。

This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure.

これは、a）が、text/html根資源とそれが参照する補助的な資源を集めるMIME multipart/related構造の使用を定義し、b）が、URIが同じmultipart/related構造の他のボディ部分で補助的な資源を参照することをmultipart/related text/html根ボディ部分の中で可能にするMIME内容ヘッダー(内容位置)を指定すると記述します。

While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed to resources retrieved by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents.

最初、完全なマルチ資源HTMLマルチメディア文書の電子メール転送をサポートするようにデザインされる一方、これらの会議は、また、1回の転送においてまたは完全HTML文書のストレージとアーカイブのために完全なマルチ資源HTMLマルチメディア文書を取り戻すためにHTTPとFTPなどの他の転送プロトコルによって取り戻された資源に雇用されることができます。

Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12.

これとRFC 2110として出版されたこの標準の前のバージョンとの違いは12章の中で要約されます。

1.　はじめに
2.　専門用語
　2.1　順応要件用語
　2.2　他の専門用語
3.　概要
4.　内容位置MIME内容ヘッダ
　4.1　MIME内容ヘッダ
　4.2　内容位置ヘッダ
　4.3　MHTML集合URI
　4.4　MIMEヘッダーフィールドのURIのエンコーディングとデコード
5.　相対的なURI解読のための基本URI
6.　リンクされたオブジェクトなしで文書を送る
7.　multipart/relatedの用法
8.　他のボディ部分へのリンクの用法
　8.1　一般原則
　8.2　text/htmlボディ部分のURIの解読
　8.3　CIDとContent-IDヘッダの用法
9.　例
　9.1　含まれたリンクされたオブジェクトのないHTMLボディの例
　9.2　埋め込まれたGIF画像への絶対のURIを持つ例
　9.3　埋め込まれたGIF画像への相対的なURIを持つ例
　9.4　BASEがなく入手可能な相対的なURIの例
　9.5　埋め込まれたGIF画像にCID URLと内容IDヘッダーを使っている例
　9.6　ネスティングされたボディ部分の間で許されて、禁じられた参照を示している例
10.　文字符号化問題と行末問題
11.　セキュリティ考慮
　11.1　キャッシュすることと関連しなかったセキュリティ考慮
　11.2　キャッシュすることと関連したセキュリティ考慮
12.　RFC2110で提案されたこの規格の旧バージョンと比較される違い
13.　謝辞
14.　参考
15.　奥付
16.　完全な著作権声明

There are a number of document formats (Hypertext Markup Language [HTML2], Extended Markup Language [XML], Portable Document format [PDF] and Virtual Reality Markup Language [VRML]) that specify documents consisting of a root resource and a number of distinct subsidiary resources referenced by URIs within that root resource. There is an obvious need to be able to send such multi-resource documents in e-mail [SMTP], [RFC822] messages.

根資源から成る文書を指定する多くの文書形式(ハイパーテキスト・マークアップ言語[HTML2]、拡張されたマークアップ言語[XML]、可搬ファイルフォーマット[PDF]、およびバーチャルリアリティーマークアップ言語[VRML])とその根資源の中でURIによって参照された多くの別個の補助的な資源があります。電子メール[SMTP]、[RFC822]メッセージの中にそのようなマルチ資源文書を送ることができる明らかなニーズがあります。

The standard defined in this document specifies how to aggregate such multi-resource documents in MIME-formatted [MIME1 to MIME5] messages for precisely this purpose.

この文書の中で定義された標準は正確なこの目的のためにMIMEでフォーマットされた[MIME1からMIME5]メッセージの中でどのようにそのようなマルチ資源文書を集めるかを指定します。

While this specification was developed to satisfy the specific aggregation requirements of multi-resource HTML documents, it may also be applicable to other multi-resource document representations linked by URIs. While this is the case, there is no requirement that implementations claiming conformance to this standard be able to handle any URI linked document representations other than those whose root is HTML.

この仕様が、マルチ資源HTML文書の具体的な集合体要件を満たすために開発されたのに対して、それはまたURIによってリンクされた他のマルチ資源文書表現に適用可能であるかもしれません。これがそのケースである間、この標準への対応が、どのようなURIでも扱うことができると主張しているインプリメンテーションが、根がHTMLであるそれら以外の文書表現をリンクしたという必要条件が全然ありません。

This aggregation into a single message of a root resource and the subsidiary resources it references may also be applicable to resources retrieved by other protocols such as HTTP or FTP, or to the archiving of complete web pages as they appeared at a particular point in time.

彼らが特定の時点に現れた時に、根資源とそれが参照する補助的な資源の1つのメッセージの中へのこの集合体はまたHTTPまたはFTPなどの他のプロトコルによって取り戻された資源にまたは完全なWebページのアーカイブに適用可能であるかもしれません。

An informational RFC will be published as a supplement to this standard. The informational RFC will discuss implementation methods and some implementation problems. Implementers are strongly recommended to read this informational RFC when developing implementations of this standard. You can find it through URL http://www.dsv.su.se/~jpalme/ietf/mhtml.html.

情報のRFCはこの標準への補足として出版されるでしょう。情報のRFCは実現法といくつかのインプリメンテーション問題を議論するでしょう。実装者はこの標準の実行を発展させる時に、この情報のRFCを読むように強く勧められます。URL http://www.dsv.su.se/~jpalme/ietf/mhtml.htmlを通してそれを見つけることができます。

This standard specifies that body parts to be referenced can be identified either by a Content-ID (containing a Message-ID value) or by a Content-Location (containing an arbitrary URL). The reason why this standard does not only recommend the use of Content-ID-s is that it should be possible to forward existing web pages via e-mail without having to rewrite the source text of the web pages. Such rewriting has several disadvantages, one of them that security checksums will probably be invalidated.

この標準は、参照されるボディ部分が、内容ID(メッセージID値を含みます)によってまたは内容位置(任意のURLを含みます)によって識別されることができると指定します。この標準が内容ID-sの使用を推奨しないだけの理由は、それが、Webページのソーステキストを書き直す必要があらずに電子メール経由で前の既存のWebページに可能であるべきであることです。そのような書き直しはいくつかの不利の1つを持っているので、セキュリティチェックサムはたぶん無効にされるでしょう。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [IETF-TERMS].

この文書の中のキーワード「しなければなりません」、「してはなりません」、「必要とされています」、「することとします」、「しないこととします」、「するべきです」、「するべきでありません」、「勧められます」、「することができます」、および「オプションです」は、[IETF-TERMS]において説明されるように解釈されることになっています。

An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant."

それが、1以上に、それが実装するプロトコルのための必須要件を納得させることに失敗するならば、インプリメンテーションは従順でありません。すべての必須およびすべてのtheを満たしているインプリメンテーションはするべきです そのプロトコルのための要件 「無条件に従順です」であるようにいわれています ；すべての必須要件を満たしているけれどもそのプロトコルのためのすべてのSHOULD要件を満たしているわけではないものは、「条件付きで従順である」そうです。

Most of the terms used in this document are defined in other RFCs.

この文書の中で使われた用語のほとんどは他のRFCの中で定義されます。

An aggregate document is a MIME-encoded message that contains a root resource (object) as well as other resources linked to it via URIs. These other resources may be required to display a multimedia document based on the root resource (inline pictures, style sheets, applets, etc.), or be the root resources of other multimedia documents. It is important to keep in mind that aggregate documents need to satisfy the differing needs of several audiences.

総計の文書は、URI経由でそれと接続した他の財源だけでなく根資源(オブジェクト)を含んでいるMIMEでエンコードされたメッセージです。これらの他の資源は、根資源(インライン写真、スタイルシート、アプレットなど)に基づいたマルチメディア文書を表示するか、他のマルチメディア文書の根資源であるために必要とされているかもしれません。総計の文書が、何人かの聴衆の異なるニーズを満たす必要があることを心に留めることは重要です。

Mail sending agents might send aggregate documents as an encoding of normal day-to-day electronic mail. Mail sending agents might also send aggregate documents when a user wishes to mail a particular document from the web to someone else. Finally mail sending agents might send aggregate documents as automatic responders, providing access to WWW resources for non-IP connected clients. Also with other protocols such as HTTP or FTP, there may sometimes be a need to retrieve aggregate documents. Receiving agents also have several differing needs. Some receiving agents might be able to receive an aggregate document and display it just as any other text content type would be displayed. Others might have to pass this aggregate document to a browsing program, and provisions need to be made to make this possible.

エージェントを行かせているメールは正常な日常的な電子メールのエンコーディングとして総計の文書を送るかもしれません。ユーザーが、特定の文書をウェブから他の誰かにメールすることを望む時に、エージェントを行かせているメールはまた総計の文書を送るかもしれません。非IPのためのWWW資源へのアクセスがクライアントを接続したならば、エージェントを行かせている最後にメールは自動的な応答者として総計の文書を送るかもしれません。また、HTTPまたはFTPなどの他のプロトコルによって、時々、総計の文書を取り戻すニーズがあるかもしれません。受け取っているエージェントはまたいくつかの異なるニーズを持っています。何人かの受け取っているエージェントは、総計の文書を受け取り、ちょうど、どのような他のテキストコンテントタイプでも表示されるであろうようにそれを表示することができるかもしれません。他は、この総計の文書をブラウジングプログラムに手渡す必要があるかもしれず、供給は、これを可能にするためにされる必要があります。

Finally several other constraints on the problem arise. It is important that it be possible for a document to be signed and for it to be transmitted and displayed without breaking the message integrity (MIC) checksum that is part of the signature.

最終的に、問題の上のいくつかの他の制約は生じます。文書がサインされて、それに向いていることが、サインの一部であるメッセージの完全性(MIC)チェックサムを壊さずに送られて、表示されるために可能であることは重要です。

In order to resolve URI references to resources in other body parts, one MIME content header is defined, Content-Location. This header can occur in any message or content heading.

他のボディ部分で資源へのURIリファレンスを解決するために、一方のMIME内容ヘッダーが定義されて、内容位置です。このヘッダーはどのようなメッセージにでも存在するか、表題を満足させることができます。

The syntax for this header is, using the syntax definition tools from [ABNF]:

このヘッダーのためのシンタックスは以下の通りであり、シンタックス定義を使うことは[ABNF]からツールを備えつけます：

quoted-pair      =   ("\" text)

text             =   %d1-9 / ; Characters excluding CR and LF
                     %d11-12 /
                     %d14-127

WSP              =   SP / HTAB ; Whitespace characters

FWS              =   ([*WSP CRLF] 1*WSP) ; Folding white-space

ctext            =   NO-WS-CTL / ; Non-white-space controls
                                 ; 非空白類コントロール
                     %d33-39 / ; The rest of the US-ASCII
                               ; US-ASCIIの残り
                     %d42-91 / ; characters not including "(",
                     %d93-127  ; ")", or "\"
                               ; 「(」、「)」、または「\」を含まない文字

comment          =  "(" *([FWS] (ctext / quoted-pair / comment))
                     [FWS] ")"

CFWS             =   *([FWS] comment) (([FWS] comment) / FWS)

content-location =   "Content-Location:" [CFWS] URI [CFWS]

URI              =   absoluteURI | relativeURI

where URI is restricted to the syntax for URLs as defined in Uniform Resource Locators [URL] until IETF specifies other kinds of URIs.

IETFが他の種類のURIを指定するまでユニフォーム・リソース・ロケータ[URL]中で定義されるように、URIがURLのためにシンタックスに限定される所。

A Content-Location header specifies an URI that labels the content of a body part in whose heading it is placed. Its value CAN be an absolute or a relative URI. Any URI or URL scheme may be used, but use of non-standardized URI or URL schemes might entail some risk that recipients cannot handle them correctly.

内容位置ヘッダーは、表題の中で、それが置かれるボディ部分の内容にラベルを貼るURIを指定します。その価値は絶対物または相対的なURIであるかもしれません。どのようなURIまたはURL計画でも使われることができるけれども、規格化しなかったURIまたはURLの計画の使用は、受領者が彼らを正しく扱うことができないといういくらかのリスクを伴うかもしれません。

An URI in a Content-Location header need not refer to an resource which is globally available for retrieval using this URI (after resolution of relative URIs). However, URI-s in Content-Location headers (if absolute, or resolvable to absolute URIs) SHOULD still be globally unique.

内容位置ヘッダーの中のURIは、このURI(相対的なURIの解像度の後)を使って、検索でグローバルに利用可能な資源を参照する必要がありません。しかし、内容位置ヘッダー(絶対のURIに絶対であるか、分解できるならば)中のURI-sはまだグローバルにユニークであるべきです。

A Content-Location header can thus be used to label a resource which is not retrievable by some or all recipients of a message. For example a Content-Location header may label an object which is only retrievable using this URI in a restricted domain, such as within a company-internal web space. A Content-Location header can even contain a fictitious URI. Such an URI need not be globally unique.

内容位置ヘッダーは、従って、メッセージの何人かのまたはすべての受領者によって取り戻せていない資源にラベルを貼るために使われることができます。例えばコンテンツ位置ヘッダーは、会社内臓ウェブスペースの中など限定されたドメインでこのURIを使って、取り戻せているだけのオブジェクトにラベルを貼るかもしれません。

A single Content-Location header field is allowed in any message or content heading, in addition to a Content-ID header (as specified in [MIME1]) and, in Message headings, a Message-ID (as specified in [RFC822]). All of these constitute different, equally valid body part labels, and any of them may be used to satisfy a reference to a body part. Multiple Content-Location header fields in the same message heading are not allowed.

内容位置ヘッダーは架空のURIを含むことさえできます。そのようなURIはグローバルにユニークである必要がありません。1つの内容位置ヘッダーフィールドは、内容IDヘッダー([MIME1]において指定されるような)とメッセージ表題の中の、メッセージID([RFC822]において指定されるような)に加えてどのようなメッセージまたは内容表題の中ででも許されます。これらのすべては違い、等しく有効なボディを部分的なラベルに任命し、それらのいくらでも、ボディ部分へのリファレンスを満たすために使われることができます。同じメッセージ表題の中の複数の内容位置ヘッダーフィールドは許されません。

Example of a multipart/related structure containing body parts with both Content-Location and Content-ID labels:

内容位置と内容IDのラベルを持つボディ部分を含んでいる複数パート/関連した構造の例：

Content-Type: multipart/related; boundary="boundary-example";
              type="text/html"

--boundary-example

Content-Type: text/html; charset="US-ASCII"

... ... <IMG SRC="fiction1/fiction2"> ... ...
... ... <IMG SRC="cid:97116092811xyz@foo.bar.net"> ... ...

--boundary-example
Content-Type: image/gif
Content-ID: <97116092511xyz@foo.bar.net>
Content-Location: fiction1/fiction2

--boundary-example
Content-Type: image/gif
Content-ID: <97116092811xyz@foo.bar.net>
Content-Location: fiction1/fiction3

--boundary-example--

The URI of an MHTML aggregate is not the same as the URI of its root. The URI of its root will directly retrieve only the root resource itself, even if it may cause a web browser to separately retrieve in-line linked resources. If a Content-Location header field is used in the heading of a multipart/related, this Content-Location SHOULD apply to the whole aggregate, not to its root part.

MHTML集合体のURIはその根のURIと同じでありません。その根のURIは直接根資源自身だけを取り戻すであろうし、それが、ウェブブラウザに、別々に取り出させるかもしれなくても、インラインは財源を接続しました。内容位置ヘッダーフィールドが複数パートのヘディング/関連されたものに用いられるならば、この内容位置はその根部分にではなく総計全体にあてはまるべきです。

When an URI referring to an MHTML aggregate is used to retrieve this aggregate, the set of resources retrieved can be different from the set of resources retrieved using the Content-Locations of its parts. For example, retrieving an MHTML aggregate may return an old version, while retrieving the root URI and its in-line linked objects may return a newer version.

MHTML集合体を参照しているURIが、この総計を取り出すために使われる時に、取り戻された資源のセットは、その部分の内容位置を使って、取り戻された資源のセットと違うかもしれません。例えば、MHTML集合体を取り出すことは古いバージョンを戻すかもしれず、根URIとそのインラインを取り出す間に、リンクされたオブジェクトはより新しいバージョンを戻すかもしれません。

Some documents may contain URIs with characters that are inappropriate for an RFC 822 header, either because the URI itself has an incorrect syntax according to [URL] or the URI syntax standard has been changed to allow characters not previously allowed in MIME headers. These URIs cannot be sent directly in a message header. If such a URI occurs, all spaces and other illegal characters in it must be encoded using one of the methods described in [MIME3] section 4. This encoding MUST only be done in the header, not in the HTML text. Receiving clients MUST decode the [MIME3] encoding in the heading before comparing URIs in body text to URIs in Content-Location headers.

いくつかの文書は、URI自身が[URL]に従って不正確なシンタックスを持っているか、URIシンタックス標準が、MIMEヘッダーの中で以前に許されなかった文字を許すために変更されているので、RFC822ヘッダーに不適当な文字によってURIを含むかもしれません。これらのURIは直接メッセージヘッダーの中に送られることができません。そのようなURIが起こるならば、すべてのスペースとそれの中の他の不正文字は、[MIME3]のセクション4中で説明された方法の1つを使って、エンコードされなければなりません。このエンコーディングはHTMLテキストの中ではなくヘッダーの中でされるだけでなければなりません。受け取っているクライアントは、本文の中のURIを内容位置ヘッダーの中のURIと比較する前に表題の中で[MIME3]エンコーディングをデコードしなければなりません。

The charset parameter value "US-ASCII" SHOULD be used if the URI contains no octets outside of the 7-bit range. If such octets are present, the correct charset parameter value (derived e.g. from information about the HTML document the URI was found in) SHOULD be used. If this cannot be safely established, the value "UNKNOWN-8BIT" [RFC 1428] MUST be used.

URIが7ビットの範囲の外のオクテットを全然含んでいないならば、charsetパラメータ値は「US-ASCII」が使われるべきです。そのようなオクテットが存在するならば、正しいcharsetパラメータ値(例えば、URIが発見されたHTML文書についての情報から引き出されます)は使われるべきです。これが安全に設立されることができなく、価値「UNKNOWN-8BIT」ならば、[RFC 1428]は使われなければなりません。

Note, that for the matching of URIs in text/html body parts to URIs in Content-Location headers, the value of the charset parameter is irrelevant, but that it may be relevant for other purposes, and that incorrect labeling MUST, therefore, be avoided.

言及してください、text/htmlボディの中のURIのマッチのためのそれは内容位置ヘッダーの中のURIに分かれて、charsetパラメータの値は無関係であるけれども、従って、ラベル付けすることが他の目的のために関連していて、そんなに不正確であるかもしれないことは避けられなければなりません。

Since MIME header fields have a limited length and long URIs can result in Content-Location headers that exceed this length, Content-Location headers may have to be folded.

MIMEヘッダーフィールドが制限された長さを持ち、長いURIが、この長さを越えている内容位置ヘッダーを結果として生じることができるので、内容位置ヘッダーは、折りたたまれる必要があるかもしれません。

Encoding as discussed in clause 4.4.1 MUST be done before such folding. After that, the folding can be done, using the algorithm defined in [URLBODY] section 3.1.

条項4.4.1中で議論されるようなエンコードはそのような折りたための前にされなければなりません。それの後で、[URLBODY]セクション3.1中で定義されたアルゴリズムを使って、折りたたむことができます。

Upon receipt, folded MIME header fields should be unfolded, and then any MIME encoding should be removed, to retrieve the original URI.

受け取りにおいて、折りたたまれたMIMEヘッダーフィールドは広げられるべきであり、それから、オリジナルのURIを取り出すために、どのようなMIMEエンコーディングでも取り除かれるべきです。

Relative URIs inside the contents of MIME body parts are resolved relative to a base URI using the methods for resolving relative URIs described in [RELURL]. In order to determine this base URI, the first-applicable method in the following list applies.

MIMEボディ部分の内容の中の相対的なURIは、[RELURL]において説明された相対的なURIを解決するための方法を使っている基本のURIへの決定されている親族です。この基本のURIを決定するために、以下のリストの中の最初に適用可能な方法はあてはまります。

This is also described in other words in section 8.2 below.

これは下のセクション8.2中で説明されます。

If a text/html resource (object) is sent without subsidiary resources, to which it refers, it MAY be sent by itself. In this case, embedding it in a multipart/related structure is not necessary.

テキスト/html資源(オブジェクト)が、補助的な資源(それはそれを参照します)なしで送られるならば、それはひとりで送られるかもしれません。この場合に、それを複数パート/関連した構造に埋め込むことは必要でありません。

Such a text/html resource may either contain no URIs, or URIs which the recipient is expected to retrieve (if possible) via a URI specified protocol. A text/html resource may also be sent with unresolvable links in special cases, such as when two authors exchange drafts of unfinished resources.

そのようなtext/html資源はURIを全然含まないかもしれないか、受領者が、URI経由で取り出すこと(可能ならば)を期待されているURIはプロトコルを指定しました。text/html資源は、また、いつ2人の作者が未完成の資源のドラフトを交換するかなどの特別な場合に解決不能のリンクによって送られるかもしれません。

Inclusion of URIs referencing resources which the recipient has to retrieve via an URI specified protocol may not work for some recipients. This is because not all e-mail recipients have full Internet connectivity, or because URIs which work for a sender will not work for a recipient. This occurs, for example, when an URI refers to a resource within a company-internal network that is not accessible from outside the company.

受領者が、URI経由で取り戻す必要がある資源を参照しているURIの含有は、プロトコルが何人かの受領者のために作動しないかもしれないと指定しました。これは、すべての電子メール受領者が完全なインターネット接続を持っているわけではないためまたは送信側のために働くURIが受領者のために働かないであろうためです。会社の外から得やすくない会社内臓ネットワークの中で、URIが資源を参照する時に、例えばこれは起こります。

If a message contains one or more MIME body parts containing URIs and also contains as separate body parts, resources, to which these URIs (as defined, for example, in HTML 2.0 [HTML2]) refer, then this whole set of body parts (referring body parts and referred-to body parts) SHOULD be sent within a multipart/related structure as defined in [REL].

メッセージが1つ以上のMIMEを含んでいるならば、ボディは含んでいるURIと離別し、また、これらのURI(HTML2.0[HTML2]中で例えば定義されるような)が参照する同じくらい別個のボディ部分、資源を含んでいて、そして、[REL]において定義されるように、ボディ部分(参照ボディ部分とボディに差し向けられた部分)のこの全体セットはmultipart/related構造の中に送られるべきです。

Even though headers can occur in a message that lacks an associated multipart/related structure, this standard only covers their use for resolution of URIs between body parts inside a multipart/related structure. This standard does cover the case where a resource in a nested multipart/related structure contains URIs that reference MIME body parts in another multipart/related structure, in which it is enclosed. This standard does not cover the case where a resource in a multipart/related structure contains URIs that reference MIME body parts in another parallel or nested multipart/related structure, or in another MIME message, even if methods similar to those described in this standard are used. Implementers who employ such URIs are warned that receiving agents implementing this standard may not be able to process such references.

ヘッダーが、関連したmultipart/related構造を欠くメッセージに存在することができても、この標準はただmultipart/related構造の中のボディ部分の間でURIの解像度のためにそれらの使用をカバーします。 ネスティングされたmultipart/related構造の中の資源が、参照MIMEボディが別のmultipart/related構造の中で分けるURIを含んでいる所で、この標準はケースをカバーします(それにおいて、それは同封されます)。multipart/related構造の中の資源が、この標準の中で説明されたそれらに類似している方法が使われても、参照MIMEボディが別の並列の、またはネスティングされたmultipart/related構造の中または別のMIMEメッセージの中で分けるURIを含んでいる所で、この標準はケースをカバーしません。そのようなURIを使用する実装者は、この標準を実施している受け取っているエージェントが、そのような参照を処理することができないかもしれないことを警告されます。

When the start body part of a multipart/related structure is an atomic object, such as a text/html resource, it SHOULD be employed as the root resource of that multipart/related structure. When the start body part of a multipart/related structure is a multipart/alternative structure, and that structure contains at least one alternative body part which is a suitable atomic object, such as a text/html resource, then that body part SHOULD be employed as the root resource of the aggregate document. Implementers are warned, however, that some receiving agents treat multipart/alternative as if it had been multipart/mixed (even though MIME [MIME1] requires support for multipart/alternative).

multipart/related構造の開始ボディ部分がtext/html資源などの原子のオブジェクトである時に、それはそのmultipart/related構造の根資源として利用されるべきです。そして、multipart/related構造の開始ボディ部分がmultipart/alternativeの構造であり、その構造が、text/html資源などの適当な原子のオブジェクトである少なくとも1つの代わりのボディ部分を含んでいる時に、そのボディ部分は総計の文書の根資源として利用されるべきです。実装者は、しかし、それがmultipart/mixed(MIME[MIME1]がmultipart/alternativeへの支持を必要としていても)かのように、何人かの受け取っているエージェントがmultipart/alternativeを扱うことを警告されます。

[REL] specifies that a type parameter is mandatory in a "Content-Type: multipart/related" header, and requires that it be employed to specify the type of the multipart/related start object. Thus, the type parameter value shall be "multipart/alternative", when the start part is of "Content-type multipart/alternative", even if the actual root resource is of type "text/html". In addition, if the multipart/related start object is not the first body part in a multipart/related structure, [REL] further requires that its Content-ID MUST be specified as the value of a start parameter in the "Content-Type: multipart/related" header.

[REL]は、タイプパラメータが「コンテントタイプ：」において義務的であると指定します。「Content- Type: multipart/related」ヘッダーは、それが、multipart/related開始オブジェクトのタイプを指定するために雇用されることを必要としています。従って、実際の根資源がタイプ「text/html」をもっていても、開始部分が「Content-type multipart/alternative」をもっている時に、タイプパラメータ値は「multipart/alternative」になることとします。さらに、multipart/related開始オブジェクトがmultipart/related構造の中で最初のボディ部分ではないならば、さらに、[REL]は、その内容IDが「Content-Type： multipart/related」における起動パラメタの値として指定されなければならないことを必要としています。

When rendering a resource in a multipart/related structure, URI references within that resource can be satisfied by body parts within the same multipart/related structure (see section 8.2 below). This is useful:

multipart/related構造に資源を表現する時に、その資源の中のURI参照は、同じmultipart/related構造(下のセクション8.2を見てください)中でボディ部分によって満たされることができます。これは有益です：

When a sending MUA sends objects which were retrieved from the WWW, it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into some other URI form prior to transmitting them. This will allow the receiving MUA to both verify MICs included with the message, as well as verify the documents against their WWW counterpoints, if this is appropriate.

送付MUAがwwwから検索された物を送るとき、それはそれらのwww URIsを維持するべきです。 彼らを伝える前に、それはこれらのURIsをある他のURIフォームに変えるべきではありません。これで、受信MUAはメッセージで含まれていたMICsについて確かめて、それらのwww対位法に対してドキュメントについて確かめるでしょう、これが適切であるなら。

In certain cases this will not work - for example, if a resource contains URIs as parameters to objects and applets. In such a case, it might be better to rewrite the document before sending it. This problem is discussed in more detail in the informational RFC which will be published as a supplement to this standard.

ある場合には、リソースが例えばパラメタとしてオブジェクトとアプレットにURIを含んでいると、これは働かないでしょう。 このような場合には、それを送る前にドキュメントを書き直すのは、より十分であるかもしれません。 さらに詳細に補足としてこの規格に発行される情報のRFCでこの問題について議論します。

Within a multipart/related structure, each body part MUST have, if assigned, a different Content-ID header value and a Content-Location header field values which resolve to a different URI.

multipart/relatedの中では、割り当てられるなら、それぞれの身体の部分は異なったコンテントIDヘッダー価値を持たなければなりません、そして、Content-Locationのヘッダーフィールドは異なったURIにどの決心を評価するか。

Two body parts in the same multipart/related structure can have the same relative Content-Location header value, only if when resolved to absolute URIs they become different.

絶対URIに決議されていると異なるようになる場合にだけ、同じmultipart/relatedの2つの身体の部分が同じ相対的なContent-Locationのヘッダー価値を持つことができます。