Network Working Group J. Palme
Request for Comments: 2557 Stockholm University/KTH
Obsoletes: 2110 A. Hopmann
Category: Standards Track Microsoft Corporation
N. Shelness
Lotus Development Corporation
March 1999
MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
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]は、マルチメディア文書を指定する強力な手段を定義します。これらのマルチメディアドキュメントはテキスト/ HTMLルートリソース内のユニフォームリソース識別子（URIの）によって参照されるテキスト/ HTMLルートリソース（オブジェクト）及び他の補助リソース（イメージ、ビデオクリップ、アプレットなどのオブジェクト）から成ります。 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マルチメディア文書を転送するためには、する必要があります。a）テキスト/ HTMLルートリソースと子会社のすべてのリソースを集約し、それは単一の複合メッセージ構造に参照すると、b）を定義しますテキスト/ 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）は、テキスト/ HTMLルートリソースとそれが参照する補助リソースを集約するMIMEマルチパート/関連構造の使用を定義し、b）は、マルチパートでURIを可能にするMIMEコンテンツヘッダ（コンテンツの場所）を指定し関連するテキスト/ HTMLルート本体部分は、同一のマルチパート/関連構造の他の身体部分に補助リソースを参照します。
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マルチメディアドキュメントの電子メールの転送をサポートするために設計されたが、これらの規則は、単一の転送で、完全なマルチリソースHTMLマルチメディアドキュメントを取得するために、HTTPやFTPなどの他の転送プロトコルによって取得したリソースに使用することができますまたは完全なHTML-文書の保存、アーカイブのために。
Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12.
これとRFC 2110として公開されたこの規格の前のバージョンとの違いは、第12章にまとめられています。
Table of Contents
目次
1. Introduction ................................................. 3
2. Terminology ................................................. 4
2.1 Conformance requirement terminology ...................... 4
2.2 Other terminology ........................................ 4
3. Overview ..................................................... 6
4. The Content-Location MIME Content Header ..................... 6
4.1 MIME content headers ..................................... 6
4.2 The Content-Location Header .............................. 7
4.3 URIs of MHTML aggregates ................................. 8
4.4 Encoding and decoding of URIs in MIME header fields ...... 8
5. Base URIs for resolution of relative URIs .................... 9
6. Sending documents without linked objects ..................... 10
7. Use of the Content-Type "multipart/related" .................. 11
8. Usage of Links to Other Body Parts ........................... 13
8.1 General principle ........................................ 13
8.2 Resolution of URIs in text/html body parts ............... 13
8.3 Use of the Content-ID header and CID URLs ................ 14
9. Examples ..................................................... 14
9.1 Example of a HTML body without included linked objects ... 15
9.2 Example with an absolute URI to an embedded GIF picture .. 15
9.3 Example with relative URIs to embedded GIF pictures ...... 16
9.4 Example with a relative URI and no BASE available ........ 17
9.5 Example using CID URL and Content-ID header to an embedded
GIF picture .............................................. 18
9.6 Example showing permitted and forbidden references between
nested body parts ........................................ 19
10. Character encoding issues and end-of-line issues ............ 21
11. Security Considerations ..................................... 22
11.1 Security considerations not related to caching .......... 22
11.2 Security considerations related to caching .............. 23
12. Differences as compared to the previous version of this
proposed standard in RFC 2110 ............................... 24
13. Acknowledgments ............................................. 24
14. References .................................................. 25
15. Authors' Addresses .......................................... 27
16. Full Copyright Statement .................................... 28
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.
この文書で定義された標準は、[MIME5にMIME1]まさにこの目的のためにメッセージをMIME形式でこのようなマルチリソース文書を集約する方法を指定します。
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.
彼らは、特定の時点に現れたとして、ルートリソースの単一のメッセージとそれが参照する子会社のリソースへのこの凝集はまた、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.
この標準は、参照すべき身体部分がContent-ID（メッセージIDの値を含む）によって、またはコンテンツの場所（任意のURLを含む）のいずれかによって同定することができることを指定します。この規格は唯一のContent-ID-Sの使用を推奨しない理由は、Webページのソーステキストを書き換えることなく、電子メールを経由して、既存のWebページを転送することが可能でなければならないということです。このような書き換えはいくつかの欠点、セキュリティチェックサムは、おそらく無効になることをそれらのいずれかを持っています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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."
それが実装されたプロトコルのためのMUST要件の一つ以上を満たすために失敗した場合、実装は準拠していません。すべてのMUSTとそのプロトコルのためのすべてのSHOULD要件を満たす実装は「無条件に準拠した」と言われて。すべてのMUST要件ではなく、そのプロトコルのためのすべてのSHOULD要件を満たすものがあると言われて、「条件付きで準拠しています。」
Most of the terms used in this document are defined in other RFCs.
このドキュメントで使用される用語のほとんどは他のRFCで定義されています。
Absolute URI, See Relative Uniform Resource Locators AbsoluteURI [RELURL].
絶対URIは、相対的なユニフォームリソースロケータabsoluteURIで[RELURL]を参照してください。
CID See Message/External Body Content-ID [MIDCID].
CIDを参照してくださいメッセージ/外部ボディのContent-ID [MIDCID]。
Content-Base This header was specified in RFC 2110, but has been removed in this new version of the MHTML standard.
このヘッダのContent-BaseがRFC 2110で指定されたが、MHTML標準のこの新しいバージョンでは削除されました。
Content-ID See Message/External Body Content-ID [MIDCID].
コンテンツIDを参照してくださいメッセージ/外部ボディのContent-ID [MIDCID]。
Content-Location MIME message or content part header with one URI of the MIME message or content part body, defined in section 4.2 below.
以下のセクション4.2で定義されたコンテンツロケーションMIMEメッセージまたはMIMEメッセージまたはコンテンツ部分体の1つのURIを有するコンテンツ部分ヘッダ。
Content-Transfer- Conversion of a text into 7-bit octets as Encoding specified in [MIME1] chapter 6.
【MIME1]第6章で指定されたエンコーディングとして7ビットのオクテットにテキストのコンテンツ・Transfer-変換。
CR See [RFC822].
CR [RFC822]を参照してください。
CRLF See [RFC822].
CRLFは[RFC822]を参照してください。
Displayed text The text shown to the user reading a document with a web browser. This may be different from the HTML markup, see the definition of HTML markup below.
表示されたテキスト、Webブラウザで文書を読んで、ユーザーに表示されるテキスト。これは、以下のHTMLマークアップの定義を参照して、HTMLマークアップとは異なる場合があります。
Header Field in a message or content heading specifying the value of one attribute.
一つの属性の値を指定するメッセージやコンテンツの見出しでヘッダーフィールド。
Heading Part of a message or content before the first CRLFCRLF, containing formatted fields with attributes of the message or content.
メッセージやコンテンツの属性でフォーマットフィールドを含む、第一CRLFCRLF前にメッセージまたはコンテンツの一部を見出し。
HTML See HTML 2 specification [HTML2].
HTMLはHTML 2仕様[HTML2]を参照してください。
HTML Aggregate HTML objects together with some or all objects, objects to which the HTML object contains hyperlinks, directly or indirectly.
HTML集計HTMLは、一部またはすべてのオブジェクトと一緒にHTMLオブジェクトが、直接または間接的に、ハイパーリンクが含まれている先のオブジェクトをオブジェクト。
HTML markup A file containing HTML encodings as specified in [HTML] which may be different from the displayed text which a person using a web browser sees. For example, the HTML markup may contain "<" where the displayed text contains the character "<".
[HTML]で指定されたHTMLは、Webブラウザを使用している人が見ている表示されたテキストからも異なっていてもよく、HTMLエンコーディングを含むファイルをマークアップ。例えば、HTMLマークアップが含まれていてもよい「＆LT;」表示されたテキストは、「<」の文字が含まれています。
LF See [RFC822].
LFは[RFC822]を参照してください。
MIC Message Integrity Codes, codes use to verify that a message has not been modified.
MICのメッセージインテグリティコード、コードは、メッセージが変更されていないことを確認するために使用します。
MIME See the MIME specifications [MIME1 to MIME5].
MIMEは、MIME仕様[MIME5にMIME1]を参照してください。
MUA Messaging User Agent.
MUAメッセージングユーザーエージェント。
PDF Portable Document Format, see [PDF].
PDFポータブルドキュメントフォーマットは、[PDF]を参照してください。
Relative URI, See HTML 2 [HTML2] and RFC 1808 [RELURL]. RelativeURI
相対URIは、HTML 2 [HTML2]およびRFC 1808 [RELURL]を参照してください。 RelativeURI
URI, absolute and See RFC 1866 [HTML2]. relative
URI、絶対およびRFC 1866 [HTML2]を参照してください。相対的
URL See RFC 1738 [URL].
URLは、RFC 1738 [URL]を参照してください。
URL, relative See Relative Uniform Resource Locators [RELURL].
URLは、相対的な相対ユニフォームリソースロケータ[RELURL]を参照してください。
VRML See Virtual Reality Markup Language [VRML].
VRMLは、バーチャルリアリティマークアップ言語[VRML]を参照してください。
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コンテンツヘッダは、Content-ロケーション、定義されています。このヘッダーは、任意のメッセージまたはコンテンツの見出しで起こり得ます。
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
テキスト=％d1-9 /。 CR除く文字とLF％d11-12 /％d14-127
WSP = SP / HTAB ; Whitespace characters
WSP = SP / HTAB;空白文字
FWS = ([*WSP CRLF] 1*WSP) ; Folding white-space
FWS =（[* WSP CRLF] 1 * WSP）。ホワイトスペースを折りたたみ
ctext = NO-WS-CTL / ; Non-white-space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-127 ; ")", or "\"
CTEXT = NO - WS-CTL /。非空白コントロール％d33-39 /。 US-ASCIIの残り％のd42-91 /;含まない文字 "（" ％のd93-127、; "）"、または "\"
comment = "(" *([FWS] (ctext / quoted-pair / comment)) [FWS] ")"
コメント= "（" *（[FWS]（CTEXT /引用されたペア/コメント））[FWS] "）"
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
SFOS = *（[FOS] komment）（（FOS] komment）/ FOS）
content-location = "Content-Location:" [CFWS] URI [CFWS]
コンテンツの場所= "コンテンツロケーション：" [CFWS] URI [CFWS]
URI = absoluteURI | relativeURI
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.
ユニフォームリソースロケータ[URL]で定義されているIETFは、URIの他の種類を指定するまで、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に解決可能な場合は）まだ世界的に一意である必要があります。
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.
コンテンツロケーションヘッダーは、このように、メッセージの一部またはすべての受信者によって検索可能でないリソースを標識するために使用することができます。例えば、コンテンツLocationヘッダには、会社の内部Webスペース内として、制限されたドメインでこのURIを使用してのみ取得可能であるオブジェクトにラベルを付けることがあります。コンテンツLocationヘッダでも架空のURIを含むことができます。このような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.
単一のContent-Locationヘッダフィールドは、コンテンツIDヘッダ（[MIME1]で指定されるように）と、メッセージヘッダーに、メッセージID（[RFC822]で指定されるように）に加えて、任意のメッセージやコンテンツの見出しで許可されています。これらの全ては異なる、等しく有効な身体部分のラベルを構成し、それらのいずれかは、身体部分への参照を満たすために使用されてもよいです。同じメッセージのヘッダー内の複数のContent-Locationヘッダフィールドは許可されていません。
Example of a multipart/related structure containing body parts with both Content-Location and Content-ID labels:
両方のコンテンツの場所とContent-IDラベル付き本体部を含むマルチパート/関連構造の例：
Content-Type: multipart/related; boundary="boundary-example"; type="text/html"
コンテンツタイプ：マルチパート/関連;境界=「境界例」。タイプ= "text / htmlの"
--boundary-example
--boundary-例
Content-Type: text/html; charset="US-ASCII"
コンテンツタイプ：text / htmlの。文字セット= "US-ASCII"
... ... <IMG SRC="fiction1/fiction2"> ... ... ... ... <IMG SRC="cid:97116092811xyz@foo.bar.net"> ... ...
... ... <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、例えばコンテンツタイプ：image / gif形式のContent-ID：<97116092511xyz@foo.bar.net>コンテンツロケーション：fiction1 / fiction2
--boundary-example Content-Type: image/gif Content-ID: <97116092811xyz@foo.bar.net> Content-Location: fiction1/fiction3
--boundary、例えばコンテンツタイプ：image / gif形式のContent-ID：<97116092811xyz@foo.bar.net>コンテンツロケーション：fiction1 / fiction3
--boundary-example--
--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は、直接それは、Webブラウザを個別にインラインリンクされたリソースを取得することがあり場合でも、唯一のルートリソース自体を取得します。コンテンツロケーションヘッダーフィールドがマルチパート/関連の見出しで使用される場合、このコンテンツの場所ではなく、その根元部分に、全体の集約に適用されるべきです。
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.
URIは、MHTML集合体を参照するが、この凝集体を取得するために使用された場合、検索されたリソースのセットは、その部分のコンテンツの場所を使用して取得したリソースのセットとは異なることができます。新しいバージョンを返すことがルートURIとその中にインラインリンクされたオブジェクトを取得しているとき例えば、MHTMLの集計を取得することは、古いバージョンを返すことがあります。
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
URI自体が不正な構文を持っているので、いくつかのドキュメントは、[URL]またはURIの構文標準に従っていずれか、RFC 822ヘッダに不適切な文字でURIを含んでいてもよいです
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.
以前にMIMEヘッダで許可されていない文字を許可するように変更されました。これらのURIは、メッセージヘッダに直接送信することができません。そのようなURIが発生した場合、その中のすべてのスペースや他の不正な文字この符号化部4 [MIME3]に記載された方法のいずれかを使用して符号化されなければならないだけヘッダ内ではなく、HTMLテキストで行われなければなりません。受信しているクライアントには、Content-場所ヘッダーの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」は使用されるべきです。このようなオクテットが存在する場合、（URIの中に発見されたHTML文書についての情報から例えば誘導された）正しいcharsetパラメータ値を使用すべきです。これは安全に確立できない場合は、値「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. Warning: Irrelevance of the charset parameter may not be true in the future, if different character encodings of the same non-English filename are used in HTML.
コンテンツロケーションヘッダにURIにテキスト/ HTML本体部分におけるURIのマッチングのために、charsetパラメータの値は無関係であることに注意してください、それは他の目的に関連していてもよく、その誤った標識は、それゆえでなければならないこと回避。警告：同じ英語以外のファイル名の異なる文字エンコーディングをHTMLで使用されている場合は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.
受信すると、元のURIを取得するために、折り畳まれたMIMEヘッダフィールドを展開しなければならない、そしてその後任意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を決定するために、以下のリストの最初の適用可能な方法が適用されます。
(a) There is a base specification inside the MIME body part containing the relative URI which resolves relative URIs into absolute URIs. For example, HTML provides the BASE element for this purpose.
（a）は、絶対URIの中に相対URIを解決する相対URIを含むMIMEボディ部の内側ベース仕様があります。例えば、HTMLは、この目的のための基本要素を提供します。
(b) There is a Content-Location header in the immediately surrounding heading of the body part and it contains an absolute URI. This URI can serve as a base in the same way as a requested URI can serve as a base for relative URIs within a file retrieved via HTTP [HTTP].
（b）の存在のContent-Locationヘッダは、ボディ部のすぐ周囲の見出しであり、それは絶対URIを含んでいます。このURIはHTTP [HTTP]を介して取得したファイル内の相対URIのベースとして役立つことができる要求されたURIと同様にベースとして働くことができます。
(c) If necessary, step (b) can be repeated recursively to find a suitable Content-Location header in a surrounding multi-part or message heading.
（C）必要に応じて、工程（b）は、周囲のマルチパートまたはメッセージ見出しに適切なコンテンツロケーションヘッダを見つけるために再帰的に繰り返すことができます。
(d) If the MIME object is returned in a HTTP response, use the URI used to initiate the request
（D）MIMEオブジェクトはHTTP応答で返された場合、URIを使用して、要求を開始するために使用しました
(e) When the methods above do not yield an absolute URI, a base URL of "thismessage:/" MUST be employed. This base URL has been defined for the sole purpose of resolving relative references within a multipart/related structure when no other base URI is specified.
方法は上記絶対URIを得ていない場合（E）、「thismessage：/」のベースURLを使用しなければなりません。このベースURLは、他のベース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.
そのようなテキスト/ 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].
メッセージは、URIを含む1つ以上のMIME本体部分を含み、また、身体部分のこれらのURI（定義されるように、例えば、HTML 2.0 [HTML2]）参照、この全体のセット（これには、別体の部品、リソースとして含まれている場合参照身体部分と呼ば-に身体部分）は、[REL]で定義されるようにマルチパート/関連構造内で送信されるべきです。
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.
ヘッダは、関連するマルチパート/関連構造を欠いているメッセージで起こり得るにもかかわらず、この規格は、マルチパート/関連構造内部身体の部分との間のURIの解決のためのそれらの使用を包含する。この規格は、ネストされたマルチパート/関連構造内のリソースは、それが封入された別のマルチパート/関連構造にMIME本体部分を参照するURIを含む場合をカバーしません。この標準は、関連する/マルチパート構造でリソースがこの標準に記載されたものと類似の方法であっても、別の平行またはネストされたマルチパート/関連構造で、または別のMIMEメッセージに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).
マルチパート/関連構造の開始本体部は、原子オブジェクトである場合、そのようなテキスト/ HTMLリソースとして、それは、そのマルチパート/関連構造のルートリソースとして使用されるべきです。マルチパート/関連構造の開始本体部は、マルチパート/代替的な構造であり、その構造は、適切なアトミックオブジェクトは、テキスト/ HTMLリソースとして、少なくとも一つの別の身体部分を含有する場合、その本体部が使用されてください集約文書のルートリソースとして。実装者は、それが（MIMEは、[MIME1]マルチパート/代替のためのサポートを必要としていても）、マルチパート/混合されていたかのように、いくつかの受信エージェントがマルチパート/代替手段を扱うこと、しかし、警告が表示されます。
[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.
「：マルチパート/関連のContent-Type」ヘッダを、マルチパート/関連の開始オブジェクトのタイプを指定するために使用されることを必要[REL]はタイプパラメータが必須であることを指定します。このように、型パラメータの値は、開始部分は、実際のルートリソースのタイプがある場合でも、「コンテンツタイプのマルチパート/代替」である「text / htmlの」、「マルチパート/代替」でなければなりません。マルチパート/関連の開始オブジェクトがマルチパート/関連構造における第1のボディ部分でない場合に加えて、[REL]は、さらに、そのコンテンツIDが「Content-Typeの内の開始パラメータの値として指定しなければならないことを要求します。マルチパート/関連」ヘッダ。
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:
マルチパート/関連構造内のリソースをレンダリングするときに、そのリソース内のURI参照は、（以下のセクション8.2を参照）は、同じマルチパート/関連構造内の身体の部分によって満たすことができます。これは便利です。
(a) For those recipients who only have email but not full Internet access.
（a）は電子メールのみではなく、完全なインターネットアクセスを持っているそれらの受信者のために。
(b) For those recipients who for other reasons, such as firewalls or the use of company-internal links, cannot retrieve URI referenced resources via URI specified protocols.
URIはプロトコルを指定介して他のファイアウォールなどの理由から、または企業内部リンクの使用のために、URI参照されるリソースを取得することはできませんそれらの受信者のために（B）。
Note, that this means that you can, via e-mail, send text/html
objects which includes URIs which the recipient cannot resolve
via HTTP or other connectivity-requiring URIs.
(c) To send a document whose content is preserved even if the resources to which embedded URIs refer are later changed or deleted.
（C）そのコンテンツに埋め込まURIが参照先のリソースが後で変更または削除されても保存された文書を送信します。
(d) For resources which are not available for protocol based retrieval.
プロトコルベースの検索のために利用できないリソースについて（D）。
(e) To speed up access.
（e）のアクセスを高速化するには。
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
送信MUAは、WWWから取得されたオブジェクトを送信するとき、それは彼らのWWW URIを維持する必要があります。これは、それらを送信する前に、いくつかの他のURIの形式にこれらのURIを変換するべきではありません。これができるようになります
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.
MICを検証するために、両方の受信MUAは、メッセージに含まれているだけでなく、これが適切である場合、その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.
マルチパート/関連構造内に、各本体部分は、割り当てられている場合、異なるコンテンツIDヘッダ値とコンテンツロケーションヘッダーフィールド値の異なる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.
同じマルチパート/関連構造における2つの本体部分は、絶対URIに解決されたときに、それらが異なってくる場合にのみ、同一の相対含量-Locationヘッダの値を有することができます。
A body part, such as a text/html body part, may contain URIs that reference resources which are included as body parts in the same message -- in detail, as body parts within the same multipart/related structure. Often such URI linked resources are meant to be displayed inline to the viewer of the referencing body part; for example, objects referenced with the SRC attribute of the IMG element in HTML 2.0 [HTML2]. New elements and attributes with this property are proposed in the ongoing development of HTML (examples: applet, frame, profile, OBJECT, classid, codebase, data, SCRIPT). A sender might also want to send a set of HTML documents which the reader can traverse, and which are related with the attribute href of the A element.
詳細には、同一のマルチパート/関連構造内の身体の部分のよう - 身体部分は、text / htmlの本体部として、同じメッセージで身体の部分として含まれるリソースを参照するURIを含んでいてもよいです。多くの場合、そのようなURIリンクされたリソースを参照する身体部分のビューアにインラインで表示されるように意図されています。例えば、オブジェクトは、HTML 2.0 [HTML2]でIMG要素のSRC属性で参照されます。新しい要素と、このプロパティを持つ属性は、HTML（：アプレット、フレーム、プロフィール、OBJECT、CLASSID、コードベース、データ、SCRIPT例）の継続的な開発に提案されています。送信者はまた、読者が要素の属性HREFに関連している横断し、そして可能HTML文書のセットを送信することもできます。
If a user retrieves and displays a web page formed from a text/html resource, and the subsidiary resources it references, and merely saves the text/html resource, that user may not at a later time be able to retrieve and display the web page as it appeared when saved. The format described in this standard can be used to archive and retrieve all of the resources required to display the web page, as it originally appeared at a certain moment of time, in one aggregate file.
ユーザーがテキスト/ htmlのリソースを取得し、text / htmlのリソースから形成されたウェブページ、およびそれが参照子会社のリソースを表示し、単に保存した場合、そのユーザは、後の時点で取得し、Webページを表示することができないかもしれませんそれが現れたとして保存するとき。それは、もともと1つの集約ファイルでは、時間の特定の瞬間に現れとして、この規格に記述フォーマットは、アーカイブし、Webページを表示するために必要なすべてのリソースを取得するために使用することができます。
In order to send or store complete such messages, there is a need to specify how a URI in one body part can reference a resource in another body part.
完全にそのようなメッセージを送信したり、保存するためには、URIは、1つの本体部分に別のボディ部内のリソースを参照することができる方法を指定する必要があります。
The resolution of inline, retrieval and other kinds of URIs in text/html body parts is performed in the following way:
インライン、検索およびテキスト/ HTML本体部分におけるURIの他の種類の解像度は、次のように行われます。
(a) Unfold multiple line header values according to [URLBODY]. Do NOT however translate character encodings of the kind described in [URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d".
（A）[URLBODY]に記載の複数のラインヘッダ値を広げ。しかし、[URL]に記載された種類の文字エンコーディングを変換しないでください。例： "A / B / CのD" に変身 "％の2EB / Cの％20D" しないでください。
(b) Remove all MIME encodings, such as content-transfer encoding and header encodings as defined in MIME part 3 [MIME3] Do NOT however translate character encodings of the kind described in [URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d".
MIMEで定義されている（b）は、コンテンツ転送符号化ヘッダエンコーディングなどのすべてのMIMEエンコーディングを、削除部3 [MIME3しかしながら[URL]に記載された種類の文字コードを変換しません。例： "A / B / CのD" に変身 "％の2EB / Cの％20D" しないでください。
(c) Try to resolve all relative URIs in the HTML content and in Content-Location headers using the procedure described in chapter 5 above. The result of this resolution can be an absolute URI, or an absolute URI with the base "thismessage:/" as specified in chapter 5.
（c）は、HTMLコンテンツ内及び上記第5章で説明する手順を使用してContent-場所ヘッダーのすべての相対URIを解決するために試してみてください。 5章で指定されるようにこの解像度の結果がベース「/ thismessage」と絶対URI、または絶対URIであることができます。
(d) For each referencing URI in a text/html body part, compare the value of the referencing URI after resolution as described in (a) and (b), with the URI derived from Content-ID and Content-Location headers for other body parts within the same or a surrounding Multipart/related structure. If the strings are identical, octet by octet, then the referencing URI references that body part. This comparison will only succeed if the two URIs are identical. This means that if one of the two URIs to be compared was a fictitious absolute URI with the base "thismessage:/", the other must also be such a fictitious absolute URI, and not resolvable to a real absolute URI.
text / htmlの本体部内の各参照URIの（D）に記載のように解像度の後に参照するURIの値を比較する（a）及び（b）に示すように、URIは他のためのContent-IDとContent-ロケーションヘッダに由来すると同じまたは周囲のマルチパート/関連構造内の身体の部分。文字列が同一である場合、オクテットによってオクテット、その後、参照URIは、その身体の部分を参照します。 2つのURIが同じである場合には、この比較にのみ成功します。これは、2つのURIのいずれか比較する場合は塩基「thismessage：/」の架空の絶対URIであったことを意味し、他にもそのような架空の絶対URIであること、及び実際の絶対URIに解決してはなりません。
(e) If (d) fails, try to retrieve the URI referenced resource hyperlink through ordinary Internet lookup. Resolution of URIs of the URL-types "mid" or "cid" to other content-parts, outside the same multipart/related structure, or in other separately sent messages, is not covered by this standard, and is thus neither encouraged nor forbidden.
（d）が失敗した場合は、URIを取得しよう（e）は、通常のインターネット検索を通じて資源のハイパーリンクを参照しました。 URL-タイプの「中期」のURIの解像度や個別のメッセージを送った同じマルチパート/関連構造の外側、または他に、他のコンテンツの部分に「CID」、この規格でカバーされており、これもない奨励も禁止されていません。
When URIs employing a CID (Content-ID) scheme as defined in [URL] and [MIDCID] are used to reference other body parts in an MHTML multipart/related structure, they MUST only be matched against Content-ID header values, and not against Content-Location header with CID: values. Thus, even though the following two headers are identical in meaning, only the Content-ID value will be matched, and the Content-Location value will be ignored.
[URL]で定義されており、[MIDCID] MHTMLマルチパート/関連構造の他の身体の部分を参照するために使用される場合にCIDを使用するURI（コンテンツID）方式、それらは唯一のContent-IDヘッダの値と照合し、ないしなければなりません値：CIDを使用したコンテンツ・Locationヘッダに対して。したがって、以下の2つのヘッダが意味は同じであるにもかかわらず、唯一のContent-IDの値が一致するだろう、とContent-場所値は無視されます。
Content-ID: <foo@bar.net> Content-Location: CID: foo@bar.net
コンテンツID：<foo@bar.net>コンテンツ - ロケーション：CID：foo@bar.net
Note: Content-IDs MUST be globally unique [MIME1]. It is thus not permitted to make them unique only within a message or within a single multipart/related structure.
注意：コンテンツIDは、[MIME1]グローバルにユニークでなければなりません。このようにだけメッセージ内または単一のマルチパート/関連構造内でそれらを一意にするために許可されていません。
Warning: The examples are provided for illustrative purposes only. If there is a contradiction between the explanatory text and the examples in this standard, then the explanatory text is normative.
警告：実施例は例示の目的のみのために提供されます。説明文とこの規格の例の間に矛盾がある場合、説明テキストは規範的です。
Notation: The examples contain indentation to show the structure, the real objects should not be indented in this way.
表記：例は、実際のオブジェクトは、このようにインデントしてはならない、構造を示すためにインデントが含まれています。
The first example is the simplest form of an HTML email message. This message does not contain an aggregate HTML object, but simply a message with a single HTML body part. This body part contains a URI but the messages does not contain the resource referenced by that URI. To retrieve the resource referenced by the URI the receiving client would need either IP access to the Internet, or an electronic mail web gateway.
最初の例では、HTML形式の電子メールメッセージの最も単純な形式です。このメッセージは、単一のHTML本体部分と集約HTMLオブジェクトが、単にメッセージが含まれていません。この身体の部分は、URIが含まれていますが、メッセージはそのURIが参照するリソースが含まれていません。 URIで参照されるリソースを取得するために受信するクライアントは、インターネットへのIPアクセス、または電子メールのWebゲートウェイのいずれかが必要になります。
From: foo1@bar.net To: foo2@bar.net Subject: A simple example Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
投稿者：foo1@bar.netへ：foo2@bar.net件名：簡単な例マイム・バージョン：1.0のContent-Type：text / htmlの。文字セット= "ISO-8859-1" コンテンツ転送 - エンコード：8ビット
<HTML> <head></head> <body> <h1>Acute accent</h1> The following two lines look have the same screen rendering:<p> E with acute accent becomes É.<br> E with acute accent becomes É.<p> Try clicking <a href="http://www.ietf.cnri.reston.va.us/"> here.</a><p> </body></HTML>
<HTML> <HEAD> </ HEAD> <BODY> <H1>急性アクセントは</ H1>は次の2行は、同じ画面のレンダリングを持って見て：<P>急性アクセント付きEは、Eとなり、急性アクセントと<BR> E。となり＆Eacute; <P>ここでは<a href="http://www.ietf.cnri.reston.va.us/">をクリックしてみてください</a>の<P> </ BODY> </ HTML>。
The second example is an HTML message which includes a single image, referenced using the Content-Location mechanism.
第二の例は、コンテンツロケーションメカニズムを使用して参照される単一の画像を含むHTMLメッセージです。
From: foo1@bar.net To: foo2@bar.net Subject: A simple example Mime-Version: 1.0 Content-Type: multipart/related; boundary="boundary-example"; type="text/html"; start="<foo3@foo1@bar.net>"
投稿者：foo1@bar.netへ：foo2@bar.net件名：簡単な例マイム・バージョン：1.0のContent-Type：マルチパート/関連;境界=「境界例」。タイプ= "text / htmlの";開始= "<foo3 @ foo1の@ bar.net>"
--boundary-example Content-Type: text/html;charset="US-ASCII" Content-ID: <foo3@foo1@bar.net>
--boundary-例のContent-Type：text / htmlの;のcharset = "US-ASCII" のContent-ID：<foo3 @ foo1の@ bar.net>
... text of the HTML document, which might contain a URI referencing a resource in another body part, for example through a statement such as: <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
... URIのようなステートメントを使用して、たとえば、他の身体部分のリソースを参照して含まれている可能性があり、HTML文書のテキスト：<IMG SRC = "http://www.ietf.cnri.reston.va.us /images/ietflogo.gif」
ALT="IETF logo">
ALT = "IETFロゴ">
--boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
--boundary-例のContent-場所：http://www.ietf.cnri.reston.va.us/images/ietflogo.gifのContent-Type：IMAGE / GIFコンテンツ転送 - エンコード：BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A等...
--boundary-example--
--boundary-example--
In this example, a Content-Location header field in the outermost heading will be a base to all relative URLs, also inside the HTML text being sent.
この例では、最も外側のヘッダーのContent-Locationヘッダフィールドも送信されるHTMLテキストの内部に、すべての相対URLのベースであろう。
From: foo1@bar.net To: foo2@bar.net Subject: A simple example Mime-Version: 1.0 Content-Location: http://www.ietf.cnri.reston.va.us/ Content-Type: multipart/related; boundary="boundary-example"; type="text/html"
投稿者：foo1@bar.netへ：foo2@bar.net件名：簡単な例マイム・バージョン：1.0コンテンツ所在地：http://www.ietf.cnri.reston.va.us/のContent-Type：マルチパート/関連する;境界=「境界例」。タイプ= "text / htmlの"
--boundary-example Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE
--boundary-例のContent-Type：text / htmlの。文字セット= "ISO-8859-1" コンテンツ転送 - エンコード：quoted-printableの
... text of the HTML document, which might contain URIs referencing resources in other body parts, for example through statements such as:
...のURIのようなステートメントを例えば、他の体の部分にリソースを参照して含まれている可能性があり、HTML文書のテキスト：
<IMG SRC="images/ietflogo1.gif" ALT="IETF logo1"> <IMG SRC="images/ietflogo2.gif" ALT="IETF logo2"> <IMG SRC="images/ietflogo3.gif" ALT="IETF logo3">
<IMG SRC = "画像/ ietflogo1.gif" ALT = "IETF LOGO1"> <IMG SRC = "画像/ ietflogo2.gif" ALT = "IETFロゴ2"> <IMG SRC = "画像/ ietflogo3.gif" ALT =」 IETFロゴ3" >
Example of a copyright sign encoded with Quoted-Printable: =A9 Example of a copyright sign mapped onto HTML markup: ¨
quoted-printable形式でエンコードされた著作権記号の例：HTMLマークアップにマッピングされた著作権記号の= A9例：＆＃168;
--boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif ; Note - Absolute Content-Location does not require a ; base
--boundary-例のContent-場所：http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif。注 - 絶対のContent-場所は必要ありません。ベース
Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
コンテンツタイプ：IMAGE / GIFコンテンツ転送 - エンコード：BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A等...
--boundary-example Content-Location: images/ietflogo2.gif ; Note - Relative Content-Location is resolved by base ; specified in the Multipart/Related Content-Location heading Content-Transfer-Encoding: BASE64
--boundary-例のContent-場所：画像/ ietflogo2.gif。注 - 相対含有量、ロケーションベースによって解決されます。コンテンツ転送エンコードを見出しマルチパート/関連コンテンツ-場所に指定された：BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A等...
--boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif Content-Transfer-Encoding: BASE64
--boundary-例のContent-場所：http://www.ietf.cnri.reston.va.us/images/ietflogo3.gifコンテンツ転送 - エンコード：BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A等...
--boundary-example--
--boundary-example--
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"
--boundary-example Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: QUOTED-PRINTABLE
--boundary-例のContent-Type：text / htmlの。文字セット= "ISO-8859-1" コンテンツ転送 - エンコード：quoted-printableの
... text of the HTML document, which might contain a URI referencing a resource in another body part, for example through a statement such as: <IMG SRC="ietflogo.gif" ALT="IETF logo"> Example of a copyright sign encoded with Quoted-Printable: =A9 Example of a copyright sign mapped onto HTML markup: ¨
<IMG SRC =「ietflogo.gif」ALT =「IETFロゴ」>著作権の例次のような声明を通じて例えば別の身体の一部のリソースを参照するURIが含まれている場合があり、HTML文書のテキスト...、 quoted-printable形式でエンコードされた記号：=著作権HTMLマークアップにマッピングされた記号のA9例：＆＃168;
--boundary-example Content-Location: ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
--boundary-例のContent-場所：IMAGE / GIFコンテンツ転送 - エンコード：BASE64のContent-Type ietflogo.gif
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A等...
--boundary-example--
--boundary-example--
9.5 Example using CID URL and Content-ID header to an embedded GIF picture
埋め込まれたGIF画像にCID URLとContent-IDヘッダを使用して、9.5例
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
type="text/html"
--boundary-example Content-Type: text/html; charset="US-ASCII"
--boundary-例のContent-Type：text / htmlの。文字セット= "US-ASCII"
... text of the HTML document, which might contain a URI referencing a resource in another body part, for example through a statement such as: <IMG SRC="cid:foo4@foo1@bar.net" ALT="IETF logo">
... URIは以下のようなステートメントを使用して、たとえば、他の身体部分のリソースを参照して含まれている可能性があり、HTML文書のテキスト：<IMG SRC =「CID：foo4 @ foo1の@ bar.net」ALT = "IETFロゴ「>
--boundary-example Content-Location: CID:something@else ; this header is disregarded Content-ID: <foo4@foo1@bar.net> Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
--boundary-例のContent-場所：CID：@何か他のもの。このヘッダは無視のContent-IDされています。<foo4 @ foo1の@ bar.net>のContent-Type：IMAGE / GIFコンテンツ転送 - エンコード：BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A等...
--boundary-example--
--boundary-example--
9.6 Example showing permitted and forbidden references between nested body parts
9.6実施例は、ネストされた身体の部分との間の参照を許可と禁止を示します
This example shows in which cases references are allowed between multiple multipart/related body parts in a message.
この例では、参照は、メッセージ内の複数のマルチパート/関連する身体の部分との間に許可されている場合に示します。
From: foo1@bar.net To: foo2@bar.net Subject: A simple example Mime-Version: 1.0 Content-Type: multipart/related; boundary="boundary-example-1"; type="text/html"
投稿者：foo1@bar.netへ：foo2@bar.net件名：簡単な例マイム・バージョン：1.0のContent-Type：マルチパート/関連;境界= "境界例-1";タイプ= "text / htmlの"
--boundary-example-1 Content-Type: text/html;charset="US-ASCII" Content-ID: <foo3@foo1@bar.net>
--boundary-例-1のContent-Type：text / htmlの;のcharset = "US-ASCII" のContent-ID：<foo3 @ foo1の@ bar.net>
The image reference below will be resolved with the image in the next body part. <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif" ALT="IETF logo with white background">
下の画像参照は、次の身体部分の画像を使用して解決されるであろう。 <IMG SRC = "http://www.ietf.cnri.reston.va.us/images/ietflogo.gif" ALT = "白い背景を持つIETFロゴ">
The image reference below cannot be resolved within this MIME message, since it contains a reference from an outside body part to an inside body part, which is not supported by this standard. <IMG SRC=images/ietflogo2e.gif" ALT="IETF logo with transparent background">
それは、この規格でサポートされていない内部の身体部分に外側本体部分からの参照が含まれているので以下の画像参照は、このMIMEメッセージ内で解決することはできません。 <IMG SRC =画像/透明な背景を持つ「ALTは= "IETFロゴ" ietflogo2e.gif>
The anchor reference immediately below will be resolved with the nested text/html body part below: <A HREF="http://www.ietf.cnri.reston.va.us/more-info> More info</A>
アンカー参照は、すぐ下の下にネストされたtext / htmlのボディ部品を使用して解決されます：<A HREF="http://www.ietf.cnri.reston.va.us/more-info>詳細情報</A>
The anchor reference immediately below will be resolved with the nested text/html body part below: <A HREF="http://www.ietf.cnri.reston.va.us/even-more-info> Even more info</A>
/ <でも詳細<A HREF="http://www.ietf.cnri.reston.va.us/even-more-info>：すぐ下のアンカー参照は、以下のネストされたtext / htmlのボディ部品を使用して解決されますA>
--boundary-example-1 Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
--boundary-例-1のContent-場所：http://www.ietf.cnri.reston.va.us/images/ietflogo.gifのContent-Type：IMAGE / GIFコンテンツ転送 - エンコード：BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
R0lGODlhGAGgAPEAAP ///// ZRaCgoAAAACH + PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A等...
--boundary-example-1 Content-Location: http://www.ietf.cnri.reston.va.us/more-info Content-Type: multipart/related; boundary="boundary-example-2"; type="text/html" --boundary-example-2 Content-Type: text/html;charset="US-ASCII" Content-ID: <foo4@foo1@bar.net>
--boundary-例-1コンテンツロケーション：http://www.ietf.cnri.reston.va.us/more-infoのContent-Type：マルチパート/関連します。境界= "境界例-2";タイプ= "text / htmlの" --boundary-例-2のContent-Type：text / htmlの;のcharset = "US-ASCII" のContent-ID：<foo4 @ foo1の@ bar.net>
The image reference below will be resolved with the image in the surrounding multipart/related above. <IMG SRC="images/ietflogo.gif" ALT="IETF logo with white background">
以下の画像参照は、周囲のマルチパート/関連する上記の画像で解決されるであろう。 <ALT = "白い背景を持つIETFロゴ" IMG SRC = "ietflogo.gif画像/">
The image reference below will be resolved with the image inside the current nested multipart/related below. <IMG SRC=images/ietflogo2e.gif" ALT="IETF logo with transparent background">
以下の画像参照は、以下に関連する現在のネストされたマルチパート/内部の画像を使用して解決されるであろう。 <IMG SRC =画像/透明な背景を持つ「ALTは= "IETFロゴ" ietflogo2e.gif>
--boundary-example-2 Content-Location: http:images/ietflogo2.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
IMAGE / GIFコンテンツ転送 - エンコード：BASE64 --boundary-例-2のContent-場所：のhttp：Content-Typeのietflogo2.gif画像/
R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4 SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa etc...
R0lGODlhGAGgANX / ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4 SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv / eQnNzjHNzlGtrjGNjhFpae1pa等...
--boundary-example-2-- --boundary-example-1 Content-Location: http://www.ietf.cnri.reston.va.us/even-more-info Content-Type: multipart/related; boundary="boundary-example-3"; type="text/html" --boundary-example-3 Content-Type: text/html;charset="US-ASCII" Content-ID: <4@foo@bar.net>
--boundary-例-2-- --boundary-例-1コンテンツロケーション：http://www.ietf.cnri.reston.va.us/even-more-infoのContent-Type：マルチパート/関連します。境界=「境界例-3」。タイプ= "text / htmlの" --boundary-例-3のContent-Type：text / htmlの;のcharset = "US-ASCII" のContent-ID：<4 @ FOO @ bar.net>
The image reference below will be resolved with the image inside the current nested multipart/related below. <IMG SRC=images/ietflogo2d.gif" ALT="IETF logo with shadows">
以下の画像参照は、以下に関連する現在のネストされたマルチパート/内部の画像を使用して解決されるであろう。 <IMG SRC =画像/影との「ALTは= "IETFロゴ" ietflogo2d.gif>
The image reference below cannot be resolved according to this standard since references between parallel multipart/ related structures are not supported. <IMG SRC=images/ietflogo2e.gif" ALT="IETF logo with transparent background">
以下の画像参照は、並列マルチパート/関連構造がサポートされていない間の参照ので、この規格に従って解決することができません。 <IMG SRC =画像/透明な背景を持つ「ALTは= "IETFロゴ" ietflogo2e.gif>
--boundary-example-3 Content-Location: http:images/ietflogo2d.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
IMAGE / GIFコンテンツ転送 - エンコード：BASE64 --boundary-例-3のContent-場所：のhttp：Content-Typeのietflogo2d.gif画像/
R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v etc...
R0lGODlnGAGgANH / AMDAvskpKTEhMTk5OUYSKkpKSlZhSOlpaShmnyO2traZNz s3tsche4SEhIyMySUlZhiknkVlpa2trvV1tv29vsvGkss7OztvV1t7e3ufn5 + / ETCで...
--boundary-example-3-- --boundary-example-1--
--boundary-例-3-- --boundary-例-1--
For the encoding of characters in HTML documents and other text documents into a MIME-compatible octet stream, the following mechanisms are relevant:
MIME互換のオクテットストリームにHTML文書やその他のテキスト文書中の文字のエンコーディングについては、以下のメカニズムが関連しています。
- HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] allows characters to be denoted by character entities as well as by numeric character references (e.g. "Latin small letter a with acute accent" may be represented by "á" or "á") in the HTML markup.
- HTML [HTML2]、[HTML-I18N] SGML [SGML]のアプリケーションとしては、文字を文字エンティティによってだけでなく、数値文字参照（で表すことができる例えば、「急性アクセント付きラテン小文字A」と表記することができます」 HTMLマークアップで "）;＆aacute;」や" ＆＃225。
- HTML documents, in common with other documents of the MIME Content-Type "text", can be represented in MIME using one of several character encodings. The MIME Content-Type "charset" parameter value indicates the particular encoding used. For the exact meaning and use of the "charset" parameter, please see [MIME2] chapter 4.
- HTML文書は、MIMEのContent-Type「テキスト」の他の文書と共通して、いくつかの文字エンコーディングのいずれかを使用してMIMEで表現することができます。 MIMEのContent-Type「のcharset」パラメータの値が使用される特定のエンコーディングを示しています。 「文字セット」パラメータの正確な意味と使用については、[MIME2]第4章を参照してください。
Note that the "charset" parameter refers only to the MIME character encoding. For example, the string "á" can be sent in MIME with "charset=US-ASCII", while the raw character "Latin small letter a with acute accent" cannot.
「文字セット」パラメータは唯一のMIME文字エンコーディングを示すことに注意してください。例えば、文字列「＆aacute;」 、「文字セット= US-ASCII」とMIMEで送信することができますが、生の文字「鋭アクセント付きラテン小文字aは」できません。
The above mechanisms are well defined and documented, and therefore not further explained here. In sending a message, all the above mentioned mechanisms MAY be used, and any mixture of them MAY occur when sending the document in MIME format. Receiving user agents (together with any Web browser they may use to display the document) MUST be capable of handling any combinations of these mechanisms.
上記のメカニズムは十分に定義され、文書化され、したがって、ここでは説明しません。メッセージを送信する際に、すべての上記の機構を使用することができ、MIME形式で文書を送信するとき、それらの任意の混合物が生じる可能性があります。 （これらは、文書を表示するために使用することができる任意のWebブラウザと一緒に）ユーザエージェントを受信するこれらのメカニズムの任意の組み合わせを取り扱うことができなければなりません。
Also note that:
また、次の点に注意してください
- Any documents including HTML documents that contain octet values outside the 7-bit range need a content-transfer-encoding applied before transmission over certain transport protocols [MIME1, chapter 5].
- 7ビットの範囲外のオクテット値を含むHTMLドキュメントを含む任意の文書は、特定のトランスポートプロトコル[MIME1、第5章]を介して送信する前に適用されるコンテンツ転送エンコードを必要とします。
- The MIME standard [MIME2] requires that e-mailed documents of "Content-Type: Text/ MUST be in canonical form before a Content-Transfer-Encoding is applied, i.e. that line breaks are encoded as CRLFs, not as bare CRs or bare LFs or something else. This is in contrast to [HTTP] where section 3.6.1 allows other representations of line breaks.
コンテンツ転送エンコードが適用される前に、その改行はCRLFが、裸ではないのCRまたはとしてエンコードされている。すなわち、テキスト/正規形である必要があります - MIME標準[MIME2は]のContent-Type」の電子メールで送信文書があることが必要です裸のLFまたは何か他のもの。これは、[HTTP]セクション3.6.1は、改行の他の表現を許容する場合とは対照的です。
Note that this might cause problems with integrity checks based on checksums, which might not be preserved when moving a document from the HTTP to the MIME environment. If a document has to be converted in such a way that a checksum based message integrity check becomes invalid, then this integrity check header SHOULD be removed from the document.
これはMIME環境へのHTTPから文書を移動するときに、保存されない可能性があり、チェックサムに基づいて、整合性チェックで問題を起こす可能性があることに注意してください。文書チェックサムベースのメッセージ完全性チェックが無効になるように変換する必要がある場合、この整合性チェックヘッダが文書から除去されるべきです。
Other sources of problems are Content-Encoding used in HTTP but not allowed in MIME, and character sets that are not able to represent line breaks as CRLF. A good overview of the differences between HTTP and MIME with regards to Content-Type: "text" can be found in [HTTP], appendix C.
問題の他の供給源は、CRLFとしてラインブレイクを表すことができないコンテンツのエンコーディングHTTPで使用されるが、MIMEに許可されていない、と文字セットです。 Content-Typeのにに関してHTTPとMIMEの間の違いの良い概要：「テキスト」は[HTTP]、付録C.で見つけることができます
Some transport mechanisms may specify a default "charset" parameter if none is supplied [HTTP, MIME1]. Because the default differs for different mechanisms, when HTML is transferred through e-mail, the charset parameter SHOULD be included, rather than relying on the default.
いずれも供給されない場合、いくつかのトランスポート・メカニズムはデフォルトの「文字セット」パラメータを指定することができる[HTTP、MIME1]。デフォルトは異なるメカニズムのために異なるため、HTMLは、電子メールを介して転送されたときに、charsetパラメータではなく、デフォルトに頼るよりも、含まれるべきです。
It is possible for a message sender to misrepresent the source of a multipart/related body part to a message recipient by labeling it with a Content-Location URI that references another resource. Therefore, message recipients should only interpret Content-Location URIs as labeling a body part for the resolution of references from body parts in the same multipart/related message structure, and not as the source of a resource, unless this can be verified by other means.
メッセージの送信者が別のリソースを参照するのContent-場所URIでそれを標識することにより、メッセージの受信者にマルチパート/関連身体部分のソースを偽るすることが可能です。したがって、メッセージの受信者は、同じマルチパート/関連メッセージ構造における身体部分からの参照の解決のために身体部分を標識として、コンテンツロケーションURIを解釈し、そしてべきではないリソースの供給源として、これは、他の手段によって確認することができる場合を除き。
URIs, especially File URIs, if used without change in a message, may inadvertently reveal information that was not intended to be revealed outside a particular security context. Message senders should take care when constructing messages containing the new header fields, defined in this standard, that they are not revealing information outside of any security contexts to which they belong.
URIは、特にURIをファイル、メッセージに変更せずに使用した場合、誤って特定のセキュリティコンテキスト外明らかにすることを意図していなかった情報を公開してもよいです。この標準で定義された新しいヘッダフィールドを含むメッセージを構築する際に、メッセージの送信者は、彼らが属する任意のセキュリティコンテキストの外の情報を明らかにしていないことを、世話をする必要があります。
Some resource servers hide passwords and tickets (access tokens to information which should not be reveled to others) and other sensitive information in non-visible fields or URIs within a text/html resource. If such a text/html resource is forwarded in an email message, this sensitive information may be inadvertently revealed to others.
いくつかのリソースサーバは、パスワードやチケット（他の人に確かめたべきではない情報へのアクセストークン）とtext / htmlのリソース内の非表示フィールドまたはURIの中の他の機密情報を非表示にします。そのようなテキスト/ HTMLリソースが電子メールメッセージで転送される場合、この機密情報が誤って他人に明らかにされてもよいです。
Since HTML documents can either directly contain executable content (i.e., JavaScript) or indirectly reference executable content (The "INSERT" specification, Java). It is exceedingly dangerous for a receiving User Agent to execute content received in a mail message without careful attention to restrictions on the capabilities of that executable content.
HTML文書は、直接実行可能なコンテンツを含むことができるので（即ち、JavaScriptの）、または間接的には、実行可能なコンテンツ（「挿入」仕様、Java（登録商標））を参照します。これは、その実行可能なコンテンツの機能上の制限に注意することなく、メールメッセージで受信したコンテンツを実行するための受信ユーザエージェントのために非常に危険です。
HTML-formatted messages can be used to investigate user behaviour, for example to break anonymity, in ways which invade the privacy of individuals. If you send a message with a inline link to an object which is not itself included in the message, the recipients mailer or browser may request that object through HTTP. The HTTP transaction will then reveal who is reading the message. Example: A person who wants to find out who is behind an anonymous user identity, or from which workstation a user is reading his mail, can do this by sending a message with an inline link and then observe from where this link is used to request the object.
HTML形式のメッセージは、個人のプライバシーを侵害な方法で、匿名性を破るために、たとえば、ユーザーの行動を調査するために使用することができます。あなたは、それ自体がメッセージに含まれていないオブジェクトへのインラインリンクを含むメッセージを送信する場合、受信者のメーラーやブラウザがHTTPを通じてそのオブジェクトを要求することができます。 HTTPトランザクションは、メッセージを読んでいる人明らかにします。例：匿名ユーザーIDの背後にある人を見つけたい、またはユーザーが自分のメールを読んでいるワークステーション、そこから、インラインリンクを含むメッセージを送信することにより、これを行うと、このリンクを要求するために使用された場所から観察することができた人オブジェクト。
There is a well-known problem with the caching of directly retrieved web resources. A resource retrieved from a cache may differ from that re-retrieved from its source. This problem, also manifests itself when a copy of a resource is delivered in a multipart/related structure.
直接取得Webリソースのキャッシュでよく知られている問題があります。キャッシュから検索リソースは、そのソースから再取得異なっていてもよいです。リソースのコピーがマルチパート/関連構造で提供されている場合、この問題は、また現れます。
When processing (rendering) a text/html body part in an MHTML multipart/related structure, all URIs in that text/html body part which reference subsidiary resources within the same multipart/related structure SHALL be satisfied by those resources and not by resources from any another local or remote source.
処理時にMHTMLマルチパート/関連構造のテキスト/ HTML本体部（レンダリング）、同じマルチパート/関連構造内の補助リソースを参照することをtext / htmlの本体部内のすべてのURIは、それらのリソースによってはないからリソースによって満足すること任意の他のローカルまたはリモートのソース。
Therefore, if a sender wishes a recipient to always retrieve an URI referenced resource from its source, an URI labeled copy of that resource MUST NOT be included in the same multipart/related structure.
送信者は、常にURIを取得するために、受信者がそのソースからのリソースを参照したい場合そのため、そのリソースのURIラベルされたコピーは、同じ関連/マルチパート構造に含んではいけません。
In addition, since the source of a resource received in a multipart/related structure can be misrepresented (see 11.1 above), if a resource received in multipart/related structure is stored in a cache, it MUST NOT be retrieved from that cache other than by a reference contained in a body part of the same multipart/related structure. Failure to honor this directive will allow a multipart/related structure to be employed as a Trojan Horse. For example, to inject bogus resources (i.e. a misrepresentation of a competitor's Web site) into a recipient's generally accessible Web cache.
リソースがキャッシュに格納されているマルチパート/関連構造で受信した他に、リソースのソースがマルチパート/関連構造で受信するので、（上記11.1を参照）を詐称することができ、それ以外のそのキャッシュから取得してはいけません同じマルチパート/関連構造のボディ部に含まれる参照によって。このディレクティブを称えるために失敗すると、マルチパート/関連構造がトロイの木馬として使用することができるようになります。たとえば、受信者の一般アクセス可能なWebキャッシュに偽のリソース（競合他社のWebサイトの、すなわち不当表示）を注入します。
12. Differences as compared to the previous version of this proposed standard in
で、この提案された標準の以前のバージョンと比較して12違い
The specification has been changed to show that the formats described do not only apply to multipart MIME in email, but also to multipart MIME transferred through other protocols such as HTTP or FTP.
仕様では、説明の形式は、電子メールのMIMEマルチパートをして適用されないだけでなく、HTTPやFTPなどの他のプロトコルを介して転送MIMEマルチパートをしていることを示すために変更されました。
In order to agree with [RELURL], Content-Location headers in multipart Content-Headings can now be used as a base to resolve relative URIs in their component parts, but only if no base URI can be derived from the component part itself. Base URIs in Content-Location header fields in inner headings have precedence over base URIs in outer multipart headings.
【RELURL]と一致するために、マルチパートコンテンツ見出しにおけるコンテンツロケーションヘッダーは現在、それらの構成部品の相対URIを解決するためのベースとして使用することができるが、何らベースURIは、構成部品自体に由来することができない場合のみ。内側ヘッダーのContent-LocationヘッダフィールドのベースURIは、外側マルチ見出しにおける基底URIに優先します。
The Content-Base header, which was present in RFC 2110, has been removed. A conservative implementor may choose to accept this header in input for compatibility with implementations of RFC 2110, but MUST never send any Content-Base header, since this header is not any more a part of this standard.
RFC 2110に存在したコンテンツベースのヘッダは、除去されています。保守的な実装は、RFC 2110の実装との互換性のための入力は、このヘッダを受け入れることを選択することができるが、このヘッダはもはや、この規格の一部ではないので、任意のコンテンツベースのヘッダを送信してはいけません。
A section 4.4.1 has been added, specifying how to handle the case of sending a body part whose URI does not agree with the correct URI syntax.
セクション4.4.1は、そのURI正しいURI構文と一致しない身体の部分を送信する場合の処理方法を指定して、追加されました。
The handling of relative and absolute URIs for matching between body parts have been merged into a single description, by specifying that relative URIs, which cannot be resolved otherwise, should be handled as if they had been given the URL "thismessage:/".
身体の部分とのマッチングのための相対および絶対URIの取り扱いは、それらがURL「/ thismessage」を与えられたかのようにそうでなければ解決できない相対URIは、取り扱われるべきであることを指定して、単一の記述に統合されています。
Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W. Peck, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve Zilles and several other people have helped us with preparing this document. We alone take responsibility for any errors which may still be in the document.
ハラルドT. Alvestrand、リチャード・ベイカー、アイザック・チャン、デイブ・クロッカー、マーティン・J. Duerst、ルイスヘール、ロイ・フィールディング、ネッドフリード、アルギルマン、ポール・ホフマン、アンディ・ジェイコブス、リチャード・W. Jesmajian、マーク・K.ジョセフ、グレッグ・ハーリー、 Valdis Kletnieks、ダニエル・リベルテ、エド・レビンソン、ジェイ・レヴィット、アルバート・ルンデ、ラリーMasinter、キースムーア、ギャビン・ニコル、マーティンW.ペック、ピート・レズニック、ジョンSmirl、はEinar Stefferud、ジェイミー・ザウィンスキー、スティーブZillesおよびいくつかの他の人たちを助けましたこの文書を準備しています。我々だけでは、まだ文書であってもよく、任意の誤りについて責任を取ります。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[CONDISP] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[CONDISP] Troost、R.とS.ドルナー、 "インターネット・メッセージでプレゼンテーション情報を伝える：のContent-Dispositionヘッダー"、RFC 2183、1997年8月。
[HOSTS] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[HOSTS]ブレーデン、R.、エド、 "インターネットホストのための要件 - 、アプリケーションとサポート"。、STD 3、RFC 1123、1989年10月。
[HTML-I18N] Yergeau, F., Nicol, G. Adams, G. and M. Duerst: "Internationalization of the Hypertext Markup Language", RFC 2070, January 1997.
[HTML-I18N] Yergeau、F.、ニコル、G.アダムス、G.およびM. Duerst：、RFC 2070 "ハイパーテキストマークアップ言語の国際化"、1997年1月。
[HTML2] Berners-Lee, T. and D. Connolly: "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML2]バーナーズ=リー、T.、およびD.コノリー： "ハイパーテキストマークアップ言語 - 2.0"、RFC 1866、1995年11月。
[HTML3.2] Dave Raggett: HTML 3.2 Reference Specification, W3C Recommendation, January 1997, at URL http://www.w3.org/TR/REC-html32.html
[HTML3.2]デイブ・ラゲット：HTML 3.2リファレンス仕様、W3C勧告、1997年1月、URLでhttp://www.w3.org/TR/REC-html32.html
[HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[HTTP]バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
[IETF-TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997.
[IETF-TERMS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[INFO] J. Palme: Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), Work in Progress.
[INFO] J.パルメ：MIMEでHTMLを送信する、RFCへの情報の補足：HTMLなどの文書集合、のMIMEカプセル化（MHTML）、進行中で働いています。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest氏、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[MIDCID] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2387, August 1998.
[MIDCID]レビンソン、E.、 "コンテンツIDとMessage-IDユニフォームリソースロケータ"、RFC 2387、1998年8月。
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[MIME1]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年12月。
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[MIME2]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年12月。
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, December 1996.
[MIME3]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年12月。
[MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, January 1997.
[MIME4]解放され、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1997年1月。
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[MIME5]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[NEWS] Horton, M. and R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987.
[NEWS]ホートン、M.およびR.アダムス：、RFC 1036、1987年12月 "USENETメッセージの交換のための標準"。
[PDF] Tim Bienz and Richar Cohn: "Portable Document Format Reference Manual", Addison-Wesley, Reading, MA, USA, 1993, ISBN 0-201-62628-4.
[PDF]ティムBienzとRicharコーン： "ポータブルドキュメントフォーマットリファレンスマニュアル"、アディソン・ウェズリー、読書、MA、USA、1993、ISBN 0-201-62628-4。
[REL] Levinson, E., "The MIME Multipart/Related Content-Type", RFC 2389, August 1998.
[REL]レビンソン、E.、 "MIMEマルチパート/関連のContent-Type"、RFC 2389、1998年8月。
[RELURL] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[RELURL]フィールディング、R.、 "相対的なユニフォームリソースロケータ"、RFC 1808、1995年6月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982.
[RFC822]クロッカー、D.、「ARPAインターネットテキストメッセージの形式の規格。」 STD 11、RFC 822、1982年8月。
[SGML] ISO 8879. Information Processing -- Text and Office - Standard Generalized Markup Language (SGML), 1986. <URL:http://www.iso.ch/cate/d16387.html>
[SGML] ISO 8879情報処理 - テキストとオフィス - 標準一般化マークアップ言語（SGML）、1986年<URL：のhttp：//www.iso.ch/cate/d16387.html>
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[URLBODY] Freed, N. and K. Moore, "Definition of the URL MIME External-Body Access-Type", RFC 2017, October 1996.
[URLBODY]解放され、N.とK.ムーア、 "URL MIME外部-ボディアクセスタイプの定義"、RFC 2017、1996年10月。
[VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual Reality Modeling Language (VRML) Version 1.0 Language Specification." May 1995, http://www.vrml.org/Specifications/.
[VRML]ギャビン・ベル、アンソニー・パリシ、マーク・ペス：「バーチャルリアリティモデリング言語（VRML）バージョン1.0言語仕様」 1995年5月、http://www.vrml.org/Specifications/。
[XML] Extensible Markup Language, published by the World Wide Web Consortium, URL http://www.w3.org/XML/
[XML]拡張マークアップ言語、ワールドワイドウェブコンソーシアムによって公開され、URL http://www.w3.org/XML/
For contacting the editors, preferably write to Jacob Palme.
編集者に接触するため、好ましくはヤコブパルメに書き込みます。
Jacob Palme Stockholm University and KTH Electrum 230 S-164 40 Kista, Sweden
ヤコブパルメストックホルム大学とKTHエレクトラ230のS-164 40シスタ、スウェーデン
Phone: +46-8-16 16 67 Fax: +46-8-783 08 29 EMail: jpalme@dsv.su.se
電話：+ 46-8-16 16 67ファックス：+ 46-8-783 08 29 Eメール：jpalme@dsv.su.se
Alex Hopmann Microsoft Corporation One Microsoft Way Redmond WA 98052
アレックスHopmannマイクロソフト社1つのマイクロソフト道、レドモンドWA 98052
Phone: +1-425-703-8238 EMail: alexhop@microsoft.com
電話：+ 1-425-703-8238 Eメール：alexhop@microsoft.com
Nick Shelness Lotus Development Corporation 55 Cambridge Parkway Cambridge MA 02142-1295
ニックShelnessロータス開発公社55ケンブリッジパークウェイケンブリッジMA 02142から1295
EMail: Shelness@lotus.com
メールアドレス：Shelness@lotus.com
Working group chairman:
ワーキンググループ会長：
Einar Stefferud EMail: stef@nma.com
Einar Stefferud Eメール：stef@nma.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。