[要約] RFC 2557は、HTMLなどの集約ドキュメントをMIMEでカプセル化する方法を定義しています。目的は、関連するリソースを1つのファイルにまとめ、単一のオブジェクトとして扱うことで、ドキュメントの配布や保存を容易にすることです。
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)
HTML（MHTML）などの集計ドキュメントのMIMEカプセル
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.
Copyright（c）The Internet Society（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ルートのurisがその複合メッセージ構造内の子会社を参照できる手段。
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）MIMEマルチパート/関連構造の使用を定義して、テキスト/HTMLルートリソースとそれが参照する子会社リソースを集約し、b）MultiPart/で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マルチメディアドキュメントの電子メール転送をサポートするように設計されていますが、これらの規則は、HTTPやFTPなどの他の転送プロトコルによって取得されたリソースにも使用でき、単一の転送で完全なマルチリソースHTMLマルチメディアドキュメントを取得することもできます。または、完全な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.
多くのドキュメント形式（HyperText Markup Language [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ドキュメントの特定の集約要件を満たすために開発されましたが、URISがリンクした他のマルチリソース文書表現にも適用できる場合があります。これは事実ですが、この標準への適合性を主張する実装が、ルートがHTMLであるもの以外のURIリンクされたドキュメント表現を処理できるという要件はありません。
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.
この標準は、参照する身体の部分は、コンテンツID（メッセージ-ID値を含む）またはコンテンツロケーション（任意のURLを含む）によって識別できることを指定します。この標準がContent-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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[IETFTERMS]で説明されているように解釈される。
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つ以上を満たすことができない場合、実装は準拠していません。すべてのマストを満たす実装とそのプロトコルのすべての要件は、「無条件に準拠している」と言われています。すべての必須要件を満たすが、そのプロトコルのすべての要件が「条件付きに準拠している」と言われるものではない。
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メッセージ/外部ボディコンテンツID [MidCID]を参照してください。
Content-Base This header was specified in RFC 2110, but has been removed in this new version of the MHTML standard.
コンテンツベースこのヘッダーはRFC 2110で指定されていましたが、この新しいバージョンのMHTML標準で削除されています。
Content-ID See Message/External Body Content-ID [MIDCID].
Content-IDメッセージ/外部ボディコンテンツ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メッセージまたはコンテンツパーツボディの1つのURIを備えたコンテンツロケーションMIMEメッセージまたはコンテンツパーツヘッダー。
Content-Transfer- Conversion of a text into 7-bit octets as Encoding specified in [MIME1] chapter 6.
[MIME1]第6章で指定されたエンコードとして、テキストのテキストを7ビットオクテットに変換する。
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.
1つの属性の値を指定するメッセージまたはコンテンツ見出しのヘッダーフィールド。
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]で指定されているHTMLエンコーディングを含むファイルをマークアップします。これは、Webブラウザーを使用している人が見ている表示されたテキストとは異なる場合があります。たとえば、HTMLマークアップには「＆lt;」が含まれている場合があります。表示されたテキストには、文字「<」が含まれています。
LF See [RFC822].
LF [RFC822]を参照してください。
MIC Message Integrity Codes, codes use to verify that a message has not been modified.
マイクメッセージの整合性コード、コードは、メッセージが変更されていないことを確認するために使用します。
MIME See the MIME specifications [MIME1 to MIME5].
MIME MIME仕様[MIME1からMIME5]を参照してください。
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]を参照してください。Retarturi
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.
メール送信エージェントは、通常の日常の電子メールのエンコードとして集計ドキュメントを送信する場合があります。メール送信エージェントは、ユーザーがWebから他の誰かに特定のドキュメントを郵送することを希望する場合に、総文書を送信する場合があります。最後に、メール送信エージェントは、Aggregate Documentsを自動レスポンダーとして送信し、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の参照を解決するために、1つの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
%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]
content-location = "content-location：" [cfws] uri [cfws]
URI = absoluteURI | relativeURI
uri = absoluteuri |Retarturi
where URI is restricted to the syntax for URLs as defined in Uniform Resource Locators [URL] until IETF specifies other kinds of URIs.
URIは、IETFが他の種類のURIを指定するまで、均一なリソースロケーター[URL]で定義されている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-S（絶対的、または絶対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.
したがって、コンテンツロケーションヘッダーを使用して、メッセージの一部またはすべての受信者が取得できないリソースにラベルを付けます。たとえば、コンテンツロケーションヘッダーは、会社内部のWebスペース内など、制限付きドメインでこのURIを使用してのみ取得可能なオブジェクトにラベルを付けることができます。コンテンツロケーションヘッダーには、架空の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-IDヘッダー（[MIME1]で指定）に加えて、メッセージの見出し（[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は、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.
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ヘッダーで許可されていない文字を許可するように変更されているため、RFC 822ヘッダーに不適切な文字を持つURIが含まれている場合があります。これらのURIは、メッセージヘッダーに直接送信することはできません。このようなURIが発生した場合、[MIME3]セクション4で説明した方法のいずれかを使用して、すべてのスペースおよびその他の違法文字をエンコードする必要があります。このエンコードは、HTMLテキストではなく、ヘッダーでのみ実行する必要があります。受信クライアントは、ボディテキストのURIをコンテンツロケーションヘッダーのURISと比較する前に、見出しでエンコードする[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パラメーター値（たとえば、HTMLドキュメントに関する情報から派生したURIが見つかりました）を使用する必要があります。これを安全に確立できない場合、値「不明-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.
テキスト/HTMLボディ部分におけるURIのURIへのuRISへのコンテンツロケーションヘッダーのURIの一致のために、charsetパラメーターの値は無関係であるが、それは他の目的に関連する可能性があり、したがって、誤ったラベル付けは、避けた。警告：HTMLで同じ非英語のファイル名の異なる文字エンコーディングが使用されている場合、課題パラメーターの無関係は将来的には当てはまらない場合があります。
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]に記載されている相対的なurisを解決する方法を使用して、塩基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に分解するベース仕様があります。たとえば、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) 身体部分のすぐ周囲の見出しにコンテンツロケーションヘッダーがあり、絶対的なURIが含まれています。このURIは、要求されたURIがHTTP [HTTP]を介して取得されたファイル内の相対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.
(e) 上記の方法が絶対URIを生成しない場合、「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が含まれていない場合があります。テキスト/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).
MultiPart/関連構造の開始本体部分がテキスト/HTMLリソースなどの原子オブジェクトである場合、そのマルチパート/関連構造のルートリソースとして使用する必要があります。マルチパート/関連構造の開始ボディ部分がマルチパート/代替構造であり、その構造には、テキスト/HTMLリソースなどの適切な原子オブジェクトである少なくとも1つの代替体の部分が含まれている場合、その身体部分は使用する必要があります。集約文書のルートリソースとして。ただし、実装者は、一部の受信エージェントがマルチパート/代替案をマルチパート/ミックスされているかのように扱うことを警告されています（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.
[REL]タイプパラメーターは「コンテンツタイプ：MultiPART/関連する」ヘッダーで必須であり、MultiPart/関連する開始オブジェクトのタイプを指定するために使用する必要があります。したがって、実際のルートリソースが「テキスト/HTML」というタイプの場合でも、型パラメーター値は「コンテンツタイプのマルチパート/代替」の開始部分が「コンテンツタイプのマルチパート/代替」の場合の「マルチパート/代替」でなければなりません。さらに、MultiPart/関連の開始オブジェクトがMultiPart/関連構造の最初のボディ部分ではない場合、[Rel]では、そのコンテンツIDを「コンテンツタイプ：の開始パラメーターの値として指定する必要があります。MultiPart/関連するヘッダー。
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.
(b) ファイアウォールや会社内リンクの使用など、他の理由で他の理由で、URI指定プロトコルを介してURI参照リソースを取得できない受信者の場合。
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.
これは、電子メールを介して、受信者がHTTPまたはその他の接続を必要とするURIを介して解決できないURIを含むテキスト/HTMLオブジェクトを送信できることを意味することに注意してください。
(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を他の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.
受信MUAは、メッセージに含まれるMICを検証し、これが適切な場合は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.
特定の場合、これは機能しません - たとえば、リソースにオブジェクトとアプレットのパラメーターとしてurisが含まれている場合。そのような場合、ドキュメントを送信する前に書き換える方が良いかもしれません。この問題については、この標準の補足として公開される情報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つの体の部分は、絶対的なurisに解決したときに異なる場合にのみ、同じ相対的なコンテンツロケーションヘッダー値を持つことができます。
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.
テキスト/HTMLボディの部分などのボディの部分には、同じメッセージの身体部分として含まれるリソースを参照するURIが含まれている場合があります。多くの場合、そのようなURIリンクされたリソースは、参照する身体部分の視聴者にインラインで表示されることを意図しています。たとえば、HTML 2.0 [HTML2]のIMG要素のSRC属性で参照されるオブジェクト。このプロパティの新しい要素と属性は、HTMLの継続的な開発で提案されています（例：アプレット、フレーム、プロファイル、オブジェクト、ClassID、コードベース、データ、スクリプト）。送信者は、読者が通過できるHTMLドキュメントのセットを送信することもできます。これは、A要素の属性HREFに関連しています。
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リソースから形成されたWebページを取得して表示し、それが参照する子会社リソースを表示し、単にテキスト/HTMLリソースを保存する場合、そのユーザーは後でWebページを取得して表示できない場合があります保存されたときに現れたように。この標準で説明されている形式は、最初に特定の瞬間に表示されていたWebページを1つの集約ファイルに表示するために必要なすべてのリソースをアーカイブおよび取得するために使用できます。
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が別の身体部分のリソースを参照する方法を指定する必要があります。
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％2EB/C％20D」を「A/B/C D」に変換しないでください。
(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".
(b) MIMEパート3 [MIME3]で定義されているコンテンツ転移エンコーディングやヘッダーエンコーディングなど、すべてのMIMEエンコーディングを削除しますが、[URL]に記載されている種類の文字エンコーディングを翻訳しません。例：「A％2EB/C％20D」を「A/B/C D」に変換しないでください。
(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) 上記の第5章で説明した手順を使用して、HTMLコンテンツとコンテンツロケーションヘッダーのすべての相対URIを解決してみてください。この解像度の結果は、絶対URI、または第5章で指定されているベース「thismessage：/」を備えた絶対的な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.
(d) テキスト/HTMLボディパートでURIを参照する各URIについて、（a）および（b）に記載されている解像度後の参照URIの値を、内部の他のボディパーツのコンテンツIDおよびコンテンツロケーションヘッダーから派生したURIと比較します。同じまたは周囲のマルチパート/関連構造。文字列が同一である場合、オクテットのオクテット、次にURIの参照がその身体部分を参照します。この比較は、2つのURIが同一である場合にのみ成功します。これは、比較される2つのURIのうちの1つがベース「thismessage：/」の架空の絶対的なURIである場合、もう1つはそのような架空の絶対的な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.
(e) （d）失敗した場合、通常のインターネット検索を介してURI参照リソースハイパーリンクを取得してみてください。他のコンテンツパートに対するURLタイプのurlタイプの「MID」または「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]で定義されているCID（Content-ID）スキームを使用しているURIが、MHTMLマルチパート/関連構造の他の身体部分を参照するために使用される場合、Content-IDヘッダー値とのみ一致する必要があります。CIDを使用したコンテンツロケーションヘッダーに対して：値。したがって、次の2つのヘッダーの意味は同一ですが、コンテンツID値のみが一致し、コンテンツロケーション値は無視されます。
Content-ID: <foo@bar.net>
Content-Location: 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.
注：Content-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
<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>
The second example is an HTML message which includes a single image, referenced using the Content-Location mechanism.
2番目の例は、コンテンツロケーションメカニズムを使用して参照される単一の画像を含む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>"
--boundary-example
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ドキュメントのテキスト。/images/ietflogo.gif "
ALT="IETF logo">
alt = "ietf logo">
--boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
-Boundary-Exampleコンテンツロケーション：http：//www.ietf.cnri.reston.va.us/images/ietflogo.gif content-type：image/gif content-transfer-encoding：base64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach+punvchlyawdodcaoqykgmtk5 nsbjrvgrglibvvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchjvagliaxrlzc4aなど...
--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.
この例では、最も外側の見出しにあるコンテンツロケーションヘッダーフィールドは、送信される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"
--boundary-example
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 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">
Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: ¨
--boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif ; Note - Absolute Content-Location does not require a ; base Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
-boundary-example content-location：http：//www.ietf.cnri.reston.va.us/images/ietflogo1.gif;注 - 絶対的なコンテンツロケーションは、を必要としません。ベースコンテンツタイプ：Image/GIFコンテンツ転移エンコード：base64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach+punvchlyawdodcaoqykgmtk5 nsbjrvgrglibvvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchjvagliaxrlzc4aなど...
--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
- バウンドリー - 例コンテンツロケーション：Images/ietflogo2.gif;注 - 相対的なコンテンツロケーションはベースによって解決されます。マルチパート/関連コンテンツロケーション見出しコンテンツ - 転送エンコードで指定：base64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach+punvchlyawdodcaoqykgmtk5 nsbjrvgrglibvvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchjvagliaxrlzc4aなど...
--boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif Content-Transfer-Encoding: BASE64
-Boundary-Exampleコンテンツロケーション：http：//www.ietf.cnri.reston.va.us/images/ietflogo3.gif content-transfer-encoding：base64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach+punvchlyawdodcaoqykgmtk5 nsbjrvgrglibvvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchjvagliaxrlzc4aなど...
--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
... 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: ¨
--boundary-example Content-Location: ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
-boundary-exampleコンテンツロケーション：ietflogo.gif content-type：画像/GIFコンテンツ転送エンコード：base64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach+punvchlyawdodcaoqykgmtk5 nsbjrvgrglibvvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchjvagliaxrlzc4aなど...
--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="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">
--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
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach+punvchlyawdodcaoqykgmtk5 nsbjrvgrglibvvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchjvagliaxrlzc4aなど...
--boundary-example--
- バウンドリー - 例 -
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"
--boundary-example-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">
以下の画像リファレンスは、このマイムメッセージ内で解決することはできません。これは、この標準ではサポートされていない外側の身体部分から内部体の部分への参照が含まれているためです。<img src = images/ietflogo2e.gif "alt ="透明な背景を備えたietfロゴ ">
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>
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>
--boundary-example-1 Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
- Boundary-Example-1コンテンツロケーション：http：//www.ietf.cnri.reston.va.us/images/ietflogo.gif content-type：image/gif content-transfer-encoding：base64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc...
r0lgodlhgaggapeaap ///// zracgoaaaaach+punvchlyawdodcaoqykgmtk5 nsbjrvgrglibvvbmf1dghvcml6zwqgzhvwbgljyxrpb24gchjvagliaxrlzc4aなど...
--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>
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">
以下の画像参照は、周囲のマルチパート/関連の画像で解決されます。<img src = "images/ietflogo.gif" alt = "白い背景付きietfロゴ">
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 = images/ietflogo2e.gif "alt ="透明な背景を備えたietfロゴ ">
--boundary-example-2 Content-Location: http:images/ietflogo2.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
- Boundary-Example-2コンテンツロケーション：http：images/ietflogo2.gif content-type：image/gif content-transfer-encoding：base64
R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4 SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa etc...
r0lgodlhgagganx/ackpktexmtk5oujcqkkpksljsulpawmnjy2tra3nzc3t7e4 sehiymjjsuljycnknkwlpa2trbw1tcdawm7ozv/eqnnzjhnzlgtrjggnjhfpae1paなど...
--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>
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 = images/ietflogo2d.gif "alt =" ietf with shadows ">
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 = images/ietflogo2e.gif "alt ="透明な背景を備えたietfロゴ ">
--boundary-example-3 Content-Location: http:images/ietflogo2d.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64
-boundary-example-3コンテンツロケーション：http：images/ietflogo2d.gif content-type：image/gif content-transfer-encoding：base64
R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v etc...
r0lgodlhgagganx/amdawckpktexmtk5oujcqkpksljsulpawmnjy2tra3nz c3t7e4sehiymjjsuljycnkwlpa2trbw1tb29vvcbgxs7oztbw1t7e3ufn5+/vなど
--boundary-example-3-- --boundary-example-1--
-boundary-example-3-- - Boundary-example-1--
For the encoding of characters in HTML documents and other text documents into a MIME-compatible octet stream, the following mechanisms are relevant:
HTMLドキュメントやその他のテキストドキュメントの文字をMIME互換のオクテットストリームにエンコードするために、次のメカニズムが関連しています。
- 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]のアプリケーションとしての[html-i18n]により、文字は文字エンティティと数値文字参照によって示されることができます（たとえば、「鋭いアクセントを備えたラテン小文字a」は、＆aacuteyteによって表される場合があります。; "または"＆＃225; "）htmlマークアップ。
- 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コンテンツタイプの「テキスト」の他のドキュメントと共通して、いくつかのキャラクターエンコーディングのいずれかを使用してMIMEで表現できます。MIMEコンテンツタイプの「charset」パラメーター値は、使用される特定のエンコードを示します。「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.
「charset」パラメーターは、mime文字エンコードのみを指していることに注意してください。たとえば、文字列「＆aacute;」「charset = 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.
- MIME標準[MIME2]では、「コンテンツタイプ：テキスト/は、コンテンツ転送エンコードが適用される前に、標準形式である必要があります。LFSまたは他の何か。これは[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.
これにより、チェックサムに基づいた整合性チェックの問題が発生する可能性があります。これは、HTTPからMIME環境にドキュメントを移動するときに保存されない可能性があります。チェックサムベースのメッセージ整合性チェックが無効になるようにドキュメントを変換する必要がある場合、この整合性チェックヘッダーはドキュメントから削除する必要があります。
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.
他の問題の原因は、HTTPで使用されるコンテンツエンコードですが、MIMEでは許可されていないコンテンツ、およびCRLFとしてラインブレークを表すことができないキャラクターセットです。コンテンツタイプに関する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.
一部のトランスポートメカニズムは、供給されていない場合、デフォルトの「charset」パラメーターを指定する場合があります[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.
メッセージ送信者が、別のリソースを参照するコンテンツロケーション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、特にファイルURISは、メッセージに変更なしで使用された場合、特定のセキュリティコンテキストの外で明らかにされることを意図していない情報を誤って明らかにする可能性があります。メッセージ送信者は、この標準で定義されている新しいヘッダーフィールドを含むメッセージを作成する際に、属するセキュリティコンテキストの外側に情報を公開していないという注意を払う必要があります。
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.
一部のリソースサーバーは、パスワードとチケット（他の人に啓示されるべきではない情報へのトークンにアクセス）およびテキスト/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トランザクションは、誰がメッセージを読んでいるかを明らかにします。例：匿名のユーザーのアイデンティティの背後にいる人を見つけたい人、またはユーザーが自分のメールを読んでいるワークステーションを見つけたい人は、インラインリンクでメッセージを送信して、このリンクを使用して要求する場所からこれを行うことができますオブジェクト。
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 MultiPart/関連構造のテキスト/HTMLボディの部分を処理（レンダリング）する場合、同じマルチパート/関連構造内の子会社リソースを参照するそのテキスト/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キャッシュに注入すること。
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はコンポーネントパーツ自体から派生できない場合のみです。内側の見出しのコンテンツロケーションヘッダーフィールドのベース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の取り扱いは、他の方法では解決できない相対的なURIがurl「thismessage：/」を与えられたかのように処理する必要があることを指定することにより、単一の説明にマージされました。
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・アルベスランド、リチャード・ベイカー、アイザック・チャン、デイブ・クロッカー、マーティン・J・デュエルスト、ルイス・ジャー、ロイ・フィールディング、ネッド・フリード、アル・ギルマン、ポール・ホフマン、アンディ・ジェイコブス、リチャード・W・ジェスマジアン、マーク・K・ジョセフ、グレッグ・ヘルリー、ヴァルディス・クレットニエクス、ダニエル・ラリベルテ、エド・レビンソン、ジェイ・レヴィット、アルバート・ルンデ、ラリー・マシンテ、キース・ムーア、ガヴィン・ニコル、マーティン・W・ペック、ピート・レストニック、ジョン・スマール、アイナル・ステフェルード、ジェイミー・ザウィンスキー、スティーブ・ジレスなどこのドキュメントを準備することで。私たちだけで、まだ文書にある可能性のあるエラーに対して責任を負います。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、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。and S. Dorner、「インターネットメッセージのプレゼンテーション情報の通信：コンテンツ - 分散ヘッダー」、RFC 2183、1997年8月。
[HOSTS] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[ホスト] Braden、R.、ed。、「インターネットホストの要件 - アプリケーションとサポート」、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.、Nicol、G。Adams、G。およびM. Duerst：「ハイパーテキストマークアップ言語の国際化」、RFC 2070、1997年1月。
[HTML2] Berners-Lee, T. and D. Connolly: "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML2] Berners -Lee、T。およびD. Connolly：「HyperText Markup Language -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] Dave Raggett：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] Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer Protocol-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.
[IETFTERMS] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、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.
[情報] J. Palme：RFCの情報サプリメントであるMIMEでHTMLを送信：HTML（MHTML）などの集計ドキュメントのMIMEカプセル化が進行中です。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[MIDCID] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2387, August 1998.
[Midcid] Levinson、E。、「Content-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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年12月。
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[Mime2] Freed、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] Moore、K。、「Mime（多目的インターネットメールエクステンション）パート3：非ASSASCIIテキスト用のメッセージヘッダー拡張機能」、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] Freed、N.、Klensin、J。およびJ. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、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] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート5：適合基準と例」、RFC 2049、1996年11月。
[NEWS] Horton, M. and R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987.
[ニュース] Horton、M。およびR. Adams：「Usenetメッセージの交換の標準」、RFC 1036、1987年12月。
[PDF] Tim Bienz and Richar Cohn: "Portable Document Format Reference Manual", Addison-Wesley, Reading, MA, USA, 1993, ISBN 0-201-62628-4.
[PDF] Tim BienzとRichar Cohn： "Portable Document Format Reference Manual"、Addison-Wesley、Reading、MA、USA、1993、ISBN 0-201-62628-4。
[REL] Levinson, E., "The MIME Multipart/Related Content-Type", RFC 2389, August 1998.
[Rel] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2389、1998年8月。
[RELURL] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[Relurl] Fielding、R。、「相対均一なリソースロケーター」、RFC 1808、1995年6月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982.
[RFC822] Crocker、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>
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP] Postel、J。、「Simple Mail Transfer Protocol」、Std 10、RFC 821、1982年8月。
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（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] Freed、N。and K. Moore、「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] Gavin Bell、Anthony Parisi、Mark Pesce：「Virtual Reality Modeling Language（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]拡張可能なマークアップ言語、World Wide Webコンソーシアム、URL http://www.w3.org/xml/が発行
For contacting the editors, preferably write to Jacob Palme.
編集者に連絡するために、できればJacob Palmeに書き込みます。
Jacob Palme Stockholm University and KTH Electrum 230 S-164 40 Kista, Sweden
ジェイコブパルムストックホルム大学およびKTH ELECTRUM 230 S-164 40キスタ、スウェーデン
Phone: +46-8-16 16 67
Fax: +46-8-783 08 29
EMail: jpalme@dsv.su.se
Alex Hopmann Microsoft Corporation One Microsoft Way Redmond WA 98052
Alex Hopmann Microsoft Corporation One Microsoft Way Redmond WA 98052
Phone: +1-425-703-8238
EMail: alexhop@microsoft.com
Nick Shelness Lotus Development Corporation 55 Cambridge Parkway Cambridge MA 02142-1295
ニックシェルネスロータス開発公社55ケンブリッジパークウェイケンブリッジMA 02142-1295
EMail: Shelness@lotus.com
Working group chairman:
ワーキンググループ会長：
Einar Stefferud EMail: stef@nma.com
Einar Stefferudメール：stef@nma.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。