RFC2557 日本語訳
2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML).J. Palme, A. Hopmann, N. Shelness. March 1999. (Format: TXT=61854 bytes) (Obsoletes RFC2110) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
コメントを求めるワーキンググループJ.パルメの要求をネットワークでつないでください: 2557ストックホルム大学/KTHは以下を時代遅れにします。 2110年のA.Hopmannカテゴリ: 1999年の標準化過程マイクロソフト社N.シェルのLotus Development Corporation行進
MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
HTMLなどのAggregate DocumentsのMIME Encapsulation(MHTML)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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[RFC1866]はマルチメディアドキュメントを指定する強力な手段を定義します。 これらのマルチメディアドキュメントはテキスト/html根のリソースの中でテキスト/html根のリソース(オブジェクト)とUniform Resource Identifierによって参照をつけられる他の補助のリソース(イメージ、ビデオクリップ、アプレットなどオブジェクト)(URI)から成ります。 HTMLマルチメディアドキュメントがブラウザによって検索されるとき、それぞれに関するこれらのコンポーネントリソースは、リアルタイムで位置から個別に検索されて、各URIによって指定されたプロトコルを使用しています。
In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure.
ただ一つのメールメッセージの完全なHTMLマルチメディアドキュメントを移すために、それが以下に必要です。 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)は複合の、または、関連するテキスト/html根の身体の部分に同じ複合の、または、関連する構造の他の身体の部分の参照子会社リソースにURIを許容するMIMEの満足しているヘッダー(満足している位置)を指定します。
Palme, et al. Standards Track [Page 1] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[1ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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.
これとRFC2110として発行されたこの規格の旧バージョンの違いは第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
1. 序論… 3 2. 用語… 4 2.1 順応要件用語… 4 他の2.2用語… 4 3. 概要… 6 4. 満足している位置のMIMEの満足しているヘッダー… 6 4.1 MIME内容ヘッダー… 6 4.2 満足している位置のヘッダー… 7 MHTMLの4.3のURIが集められます… 8 4.4 MIMEヘッダーフィールドにおけるURIは、コード化して、解読します… 8 5. 相対的なURIの解決のためのURIを基礎づけてください… 9 6. 繋がっているオブジェクトなしでドキュメントを送ります… 10 7. 「複合/は関係づけた」コンテントタイプの使用… 11 8. 他のボディ・パーツへのリンクの使用法… 13 8.1の一般原則… 13 テキスト/html身体の部分でのURIの8.2解決… 13 8.3 コンテントIDヘッダーとCID URLの使用… 14 9. 例… 14 含まれることのないHTML本体に関する9.1の例はオブジェクトをリンクしました… 15 埋め込まれたGIF画像への絶対URIがある9.2の例。 15 埋め込まれたGIF画像への相対的なURIがある9.3の例… 16 相対的なURIにもかかわらず、どんな基地も利用可能でないことの9.4の例… 17 埋め込まれたGIF画像にCID URLとコンテントIDヘッダーを使用する9.5の例… 18 入れ子にされた身体の部分の間の参照が受入れられて、禁じられた9.6例の表示… 19 10. 文字符号化問題と行末問題… 21 11. セキュリティ問題… 22 11.1 セキュリティ問題はキャッシュに関連しませんでした… 22 11.2 セキュリティ問題はキャッシュに関連しました… 23 12. この旧バージョンにたとえられる違いはRFC2110で規格を提案しました… 24 13. 承認… 24 14. 参照… 25 15. 作者のアドレス… 27 16. 完全な著作権宣言文… 28
Palme, et al. Standards Track [Page 2] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[2ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
1. Introduction
1. 序論
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]、Extended Markup Language[XML]、Portable Document形式[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でフォーマットされた[MIME5へのMIME1]メッセージのそのようなマルチリソースドキュメントに集める方法を指定します。
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によってリンクされた他のマルチリソースドキュメント表現に適切であるかもしれません。 これはそうですが、この規格に順応を要求する実装が根が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などの他のプロトコルか、完全なウェブページの格納であることに検索されているように見えましたが、また、根のリソースのただ一つのメッセージとそれが参照をつける補助のリソースへのこの集合もリソースに適切であるかもしれません。
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は実装メソッドといくつかの実装問題について議論するでしょう。この規格の実装を開発するとき、Implementersがこの情報の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(Message-ID値を含んでいる)かContent-位置で参照をつけられるべき身体の部分を特定できると指定します(任意のURLを含んでいて)。 この規格がコンテントID sの使用を推薦するだけではない理由はメールでウェブページの原始テキストを書き直す必要はなくて既存のウェブページを進めるのが可能であるべきであるということです。 そのような書き直しには、セキュリティチェックサムがたぶんあるそれらの1つが無効にされる数回の損失があります。
Palme, et al. Standards Track [Page 3] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[3ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
2. Terminology
2. 用語
2.1 Conformance requirement terminology
2.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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[IETF-用語]で説明されるように本書では解釈されることであるべきですか?
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つか以上を満たさないなら実装が対応でない、それが実装するプロトコルのための要件はそうしなければなりません。 そして、すべてを満たす実装、プロトコルのためのすべてのSHOULD要件が「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、プロトコルのためのすべてのSHOULD要件だけが「条件付きに言いなりになる」と言われているというわけではないという要件はそうしなければなりません。
2.2 Other terminology
2.2 他の用語
Most of the terms used in this document are defined in other RFCs.
本書では使用される用語の大部分は他のRFCsで定義されます。
Absolute URI, See Relative Uniform Resource Locators AbsoluteURI [RELURL].
絶対URI、親類Uniform Resource Locator 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.
満足している基地のThisヘッダーをRFC2110で指定しましたが、MHTML規格のこの新しいバージョンで取り除きました。
Content-ID See Message/External Body Content-ID [MIDCID].
コンテント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.
満足している位置のMIMEメッセージか下のセクション4.2で定義されたMIMEメッセージか満足している部分本体の1つのURIがある満足している部分ヘッダー。
Content-Transfer- Conversion of a text into 7-bit octets as Encoding specified in [MIME1] chapter 6.
Encodingとしての7ビットの八重奏へのテキストの満足している転送変換は第6[MIME1]章で指定しました。
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.
テキストが表示した、ウェブブラウザでドキュメントを読んでいるユーザに示されたテキスト。 これはHTMLマークアップと異なるかもしれなくて、以下のHTMLマーク付けの定義を見てください。
Palme, et al. Standards Track [Page 4] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[4ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
Header Field in a message or content heading
specifying the value of one attribute.
1つの属性の値を指定しながら向かうメッセージか内容のヘッダーField。
Heading Part of a message or content before the first
CRLFCRLF, containing formatted fields with
attributes of the message or content.
最初のCRLFCRLFの前のメッセージか内容の見出しPart、含有はメッセージか内容の属性で分野をフォーマットしました。
HTML See HTML 2 specification [HTML2].
HTML See HTML2仕様[HTML2]。
HTML Aggregate HTML objects together with some or all objects,
objects to which the HTML object contains hyperlinks,
directly or indirectly.
直接か間接的にAggregate 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 encodingsを含んでいて、HTMLマーク付けAはファイルされます。 例えば、HTMLマークアップは表示されたテキストがキャラクタ"<"を含む"<"を含むかもしれません。
LF See [RFC822].
LFは[RFC822]を見ます。
MIC Message Integrity Codes, codes use to verify
that a message has not been modified.
MIC Message Integrity Codes、コードはメッセージが変更されていないことを確かめるのを使用します。
MIME See the MIME specifications [MIME1 to MIME5].
MIME See MIME仕様[MIME5へのMIME1。]
MUA Messaging User Agent.
MUAメッセージングユーザエージェント。
PDF Portable Document Format, see [PDF].
PDF Portable Document Format、[PDF]を見てください。
Relative URI, See HTML 2 [HTML2] and RFC 1808 [RELURL]. RelativeURI
相対URI、HTML2[HTML2]とRFC1808[RELURL]を見てください。 RelativeURI
URI, absolute and See RFC 1866 [HTML2]. relative
絶対とSee RFC1866[HTML2] URI、親類
URL See RFC 1738 [URL].
URLはRFC1738[URL]を見ます。
URL, relative See Relative Uniform Resource Locators [RELURL].
URL、親類See Relative Uniform Resource Locator[RELURL。]
VRML See Virtual Reality Markup Language [VRML].
VRMLは仮想現実マークアップ言語[VRML]を見ます。
Palme, et al. Standards Track [Page 5] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[5ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
3. Overview
3. 概要
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などの他のプロトコルと共にも、集合ドキュメントを検索する必要が時々あるかもしれません。 また、受信エージェントには、いくつかの異なった必要性があります。 何人かの受信エージェントが、ちょうどいかなる他のテキストcontent typeも表示するように集合ドキュメントを受け取って、それを表示できるかもしれません。 他のものはこの集合ドキュメントをブラウジングプログラムに渡さなければならないかもしれません、そして、条項はこれが可能にさせられる必要があります。
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)チェックサムを壊さないでそれに書類に署名して、伝えて、表示するのにおいて可能であることは、重要です。
4. The Content-Location MIME Content Header
4. 満足している位置のMIMEの満足しているヘッダー
4.1 MIME content headers
4.1 MIME内容ヘッダー
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.
1個のMIME内容ヘッダーが他の身体の部分のリソースのURI参照を決議するために定義される、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と等しいです。 空白キャラクタ
Palme, et al. Standards Track [Page 6] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[6ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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はWS-CTLがない/と等しいです。 非余白は%d33-39/を制御します。 米国-ASCII%d42-91/の残り。 包含ではなく、キャラクタ、「(「%d93-127;、」、)、」 「\」
comment = "(" *([FWS] (ctext / quoted-pair / comment))
[FWS] ")"
「(「*([FWS](引用されたctext/組の/コメント))[FWS]」)」というコメント=
CFWS = *([FWS] comment) (([FWS] comment) / FWS)
CFWSは*([FWS]コメント)と等しいです。(([FWS]コメント)/FWS)
content-location = "Content-Location:" [CFWS] URI [CFWS]
満足している位置が等しい、「満足している位置:」 [CFWS]ユリ[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.
URIがURLのためにIETFが他の種類のURIを指定するまでUniform Resource Locator[URL]で定義されるように構文に制限されるところで。
4.2 The Content-Location Header
4.2 満足している位置のヘッダー
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.
Content-位置のヘッダーはそれが見出しに置かれる身体の部分の内容をラベルするURIを指定します。 値は、絶対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.
Content-位置のヘッダーのURIは検索にこのURI(相対的なURIの解決の後の)を使用することでグローバルに利用可能なリソースを示す必要はありません。 しかしながら、Content-位置のヘッダー(絶対である、または絶対URIに溶解性であるなら)SHOULDのURI sはまだグローバルにそうです。ユニーク。
A Content-Location header can thus be used to label a resource which is not retrievable by some or all recipients of a message. For example a Content-Location header may label an object which is only retrievable using this URI in a restricted domain, such as within a company-internal web space. A Content-Location header can even contain a fictitious URI. Such an URI need not be globally unique.
その結果、メッセージのいくつかかすべての受取人が回収可能でないリソースをラベルするのにContent-位置のヘッダーを使用できます。 例えば、Content-位置のヘッダーは制限されたドメインでこのURIを使用することで回収可能であるだけであるオブジェクトをラベルするかもしれません、会社の内部のウェブスペースなどのように。 Content-位置のヘッダーは架空の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]で指定されるように)とMessage見出しのMessage-IDに加えて向かうどんなメッセージや内容にも許容されています([RFC822]で指定されるように)。 これらがすべて、異なって、等しく有効なボディー部分ラベルを構成して、それらのいずれも、身体の部分の参照を満たすのに使用されるかもしれません。 同じメッセージ見出しの複数のContent-位置のヘッダーフィールドは許容されていません。
Palme, et al. Standards Track [Page 7] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[7ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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"
コンテントタイプ: 複合か関連する。 境界は「境界例」と等しいです。 =「テキスト/html」をタイプしてください。
--boundary-example
--境界例
Content-Type: text/html; charset="US-ASCII"
コンテントタイプ: テキスト/html。 charsetは「米国-ASCII」と等しいです。
... ... <IMG SRC="fiction1/fiction2"> ... ...
... ... <IMG SRC="cid:97116092811xyz@foo.bar.net"> ... ...
... ... <IMG SRCは「fiction1/fiction2">」と等しいです… ... ... ... <IMG SRCが「Cid: 97116092811xyz@foo.bar.net 」と等しい、gt;、… ...
--boundary-example
Content-Type: image/gif
Content-ID: <97116092511xyz@foo.bar.net>
Content-Location: fiction1/fiction2
--境界例のコンテントタイプ: イメージ/gifコンテントID: <の97116092511xyz@foo.bar.netの>の満足している位置: fiction1/fiction2
--boundary-example
Content-Type: image/gif
Content-ID: <97116092811xyz@foo.bar.net>
Content-Location: fiction1/fiction3
--境界例のコンテントタイプ: イメージ/gifコンテントID: <の97116092811xyz@foo.bar.netの>の満足している位置: fiction1/fiction3
--boundary-example--
--境界例--
4.3 URIs of MHTML aggregates
MHTMLの4.3のURIが集められます。
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は直接根のリソース自体だけを検索するでしょう、ウェブブラウザが別々にそれでインライン繋がっているリソースを検索してもさえ。 Content-位置のヘッダーフィールドが関係づけられた複合/に関する見出しで使用されるなら、このContent-位置のSHOULDは根の部分ではなく、全体の集合に適用します。
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がこの集合を検索するのに使用されるとき、検索されたリソースのセットは部品のContent-位置決めを使用することで検索されたリソースのセットと異なっている場合があります。 例えば、MHTML集合を検索すると、古いバージョンは返るかもしれません、根のURIを検索して、インライン繋がっているオブジェクトは、より新しいバージョンを返すかもしれませんが。
4.4 Encoding and decoding of URIs in MIME header fields
4.4 MIMEヘッダーフィールドにおけるURIは、コード化して、解読すること。
4.4.1 Encoding of URIs containing inappropriate characters
4.4.1 不適当なキャラクタを含む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
いくつかのドキュメントがRFC822ヘッダーに、不適当なキャラクタを伴うURIを含むかもしれません、[URL]かURI構文に従った不正確な構文がURI自体で標準になるので
Palme, et al. Standards Track [Page 8] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[8ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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が起こるなら、[MIME3]セクション4で説明されたメソッドの1つを使用することでそれのすべての空間と他の違法キャラクタをコード化しなければなりません。 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ビットの範囲の外に八重奏を全く含んでいないなら、値の「米国-ASCII」というcharsetパラメタは使用されるべきです。 そのような八重奏であるなら、プレゼント、正しいcharsetパラメタ価値(例えば、URIが見つけられたHTMLドキュメントの情報から、引き出される)はSHOULDです。使用されます。 安全にこれを設立できないなら、値「未知-8ビット」[RFC1428]を使用しなければなりません。
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.
注意、したがって、Content-位置のヘッダーのURIへのテキスト/html身体の部分でのURIのマッチングに、charsetパラメタの値が無関係ですが、他の目的、およびその不正確なラベリングにおいて、それが関連しているかもしれないのを避けなければなりません。 警告: charsetパラメタの無関係は将来本当でないかもしれません、同じ非イギリスのファイル名の異なった文字符号化がHTMLに使用されるなら。
4.4.2 Folding of long URIs
4.4.2 長いURIの折り重なり
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がこの長さを超えているContent-位置のヘッダーをもたらすことができるので、Content位置のヘッダーは折り重ねられなければならないかもしれません。
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で定義されたアルゴリズムを使用して、折り重なりができます。
4.4.3 Unfolding and decoding of received URLs in MIME header fields
4.4.3 MIMEヘッダーフィールドで容認されたURLを広げて、解読すること。
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コード化も取り除くべきです。
5. Base URIs for resolution of relative URIs
5. 相対的なURIの解決のための基地のURI
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を決定するために、最初に、以下のリストの適用される方式は申し込まれます。
Palme, et al. Standards Track [Page 9] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[9ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
(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-位置のヘッダーが身体の部分のすぐに周囲の見出しにあります、そして、それは絶対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) 必要なら、複合かメッセージの周囲の見出しで適当なContent-位置のヘッダーを見つけるためにステップ(b)を再帰的に繰り返すことができます。
(d) If the MIME object is returned in a HTTP response, use the URI
used to initiate the request
(d) HTTP応答でMIMEオブジェクトを返すなら、要求を開始するのに使用される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で説明されます。
6. Sending documents without linked objects
6. 繋がっているオブジェクトのない資料送付
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が社外からアクセスしやすくない会社の内部のネットワークの中のリソースを示すとき、例えば、これは起こります。
Palme, et al. Standards Track [Page 10] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[10ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
7. Use of the Content-Type "multipart/related"
7. 「複合/は関係づけた」コンテントタイプの使用
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(例えば、HTML2.0[HTML2]で定義されるように)は参照される)を含んでいるなら、この全体集合のボディーは(身体の部分と言及している身体の部分を参照します)SHOULDを分けます。[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身体の部分が沿うURIを含んだか、または複合の、または、関連する構造を入れ子にしたところ、または別のMIMEメッセージにおけるケースをカバーしていません、この規格で説明されたものと同様のメソッドが使用されていても。 そのようなURIを使うImplementersはこの規格を実装するエージェントを受ける場合そのような参照を処理できないかもしれないと警告されます。
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して、それはSHOULDです。その複合/に関する根のリソースが構造を関係づけたので、使われてください。 スタート本体であるときに、複合の、または、関連する構造の一部が複合の、または、代替の構造です、そして、その構造は適当な原子オブジェクトである少なくとも1つの選択肢の身体の部分を含んでいます、テキスト/htmlリソースのように、身体のパートSHOULDが集合ドキュメントに関する根のリソースとして使われるその時。 しかしながら、Implementersはまるでそれが複合か混ぜられたかのように(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]は、型引数が「内容は以下をタイプするところ」で義務的であると指定します。 「複合/は、複合の、または、関連するスタートオブジェクトのタイプを指定するために」 ヘッダーについて話して、それが使われるのを必要とします。 したがって、型引数値は「複合か代替でしょう」、スタート部分が「文書内容複合/代替手段」のものであるときに、タイプ「テキスト/html」に実際の根のリソースがあっても。 さらに、[REL]が、複合の、または、関連するスタートオブジェクトが複合の、または、関連する構造において最初の身体の部分でないなら、スタートパラメタの値として中でコンテントIDを指定しなければならないのをさらに必要とする、「コンテントタイプ:」 「複合か関連する」ヘッダー。
Palme, et al. Standards Track [Page 11] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[11ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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.
これが、あなたがメールでどれが受取人が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.
埋め込まれたURIが参照されるリソースを後で変える、または削除しても内容を保存するドキュメントを送る(c)。
(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から検索されました)それはSHOULDです。それらのWWWがURIであることを支持してください。 それ、それらを伝える前に、SHOULDはこれらの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はメッセージで含まれていたMICsについて確かめて、それらのWWW対位法に対してドキュメントについて確かめます、これが適切であるなら。
In certain cases this will not work - for example, if a resource contains URIs as parameters to objects and applets. In such a case, it might be better to rewrite the document before sending it. This problem is discussed in more detail in the informational RFC which will be published as a supplement to this standard.
ある場合には、リソースが例えばパラメタとしてオブジェクトとアプレットにURIを含んでいると、これは働かないでしょう。 このような場合には、それを送る前に、ドキュメントを書き直すほうがよいかもしれません。 さらに詳細に補足としてこの規格に発行される情報のRFCでこの問題について議論します。
Within a multipart/related structure, each body part MUST have, if assigned, a different Content-ID header value and a Content-Location header field values which resolve to a different URI.
複合の、または、関連する構造の中では、割り当てられるなら、それぞれの身体の部分は異なったコンテントIDヘッダー価値を持たなければなりません、そして、Content-位置のヘッダーフィールドは異なった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つの身体の部分が同じ相対的なContent-位置のヘッダー価値を持つことができます、絶対URIに決議されていると異なるようになる場合にだけ。
Palme, et al. Standards Track [Page 12] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[12ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
8. Usage of Links to Other Body Parts
8. 他のボディ・パーツへのリンクの使用法
8.1 General principle
8.1 一般原則
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繋がっているリソースは参照をつけた身体の部分のビューアーへの表示されたインラインであることが意味されます。 例えば、オブジェクトはHTML2.0における、IMG要素のSRC属性で[HTML2]に参照をつけました。 この特性がある新しい要素と属性はHTML(例: アプレット、フレーム、プロフィール、OBJECT、classid、codebase、データ、SCRIPT)の開発現況で提案されます。 また、送付者は読者が横断できて、A要素の属性hrefに関連づけられる1セットの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リソース、およびそれが参照をつける補助のリソースから形成されたウェブページを検索して、表示して、単にテキスト/htmlリソースを保存するなら、そのユーザは、救われると現れたので、ウェブページを検索して、後で表示できないかもしれません。 ウェブページを表示するのに必要であるリソースのすべてを格納して、検索するのにこの規格で説明された形式は使用できます、時間のある瞬間に元々現れたように、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が別の身体の部分でどうリソースに参照をつけることができるかを指定する必要があります。
8.2 Resolution of URIs in text/html body parts
8.2 テキスト/html身体の部分での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]で説明された種類のキャラクタencodingsを翻訳しません。 例: 「%2eb/c%20d」を「/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 encodings(しかしながら、満足している転送コード化とMIMEパート3[MIME3]で定義されるヘッダーencodingsが[URL]で説明された種類のキャラクタencodingsを翻訳しないようなもの)を取り外してください。 例: 「%2eb/c%20d」を「/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
(c) 上の第5章で説明された手順を用いることでHTML内容とContent-位置のヘッダーのすべての相対的なURIを決議するようにしてください。 この解決の結果は絶対URIであるかもしれませんかベースがある絶対URIが中で指定されるとして「thismessage: /」です。
Palme, et al. Standards Track [Page 13] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[13ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
chapter 5.
第5章。
(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に参照をつけるには、(a)と(b)でURIで説明される決議がコンテントIDとContent位置からヘッダーを他の身体の部分に引き出した後に同じくらいか周囲のMultipart/関連組織の中で参照箇所URIの値を比較してください。 ストリングが同じであるなら、八重奏による八重奏、そして、ボディーが離れさせる参照をつけたURI参照します。 2つのURIが同じである場合にだけ、この比較は成功するでしょう。 また、比較されているのが、「thismessage: /」、他がそうしなければならないベースがある架空の絶対URIであったということである2つの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タイプ」か「Cid」のURIの解決は、この規格でカバーされていなくて、このようにしてどちらも奨励されないで、禁じられます。
8.3 Use of the Content-ID header and CID URLs
8.3 コンテントIDヘッダーとCID URLの使用
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(コンテントID)計画を使うURIがMHTMLの複合の、または、関連する構造の参照他の身体の部分に使用されるとき、CIDがあるContent-位置のヘッダーではなく、コンテントIDヘッダー値に取り組ませるだけでよいです: 値。 したがって、以下の2個のヘッダーは意味が同じですが、コンテント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]。 それでメッセージ以内かだけただ一つの複合の、または、関連する構造の中でユニークになることはこのようにして許可されていません。
9. Examples
9. 例
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.
記法: 例は構造を見せている刻み目を含んでいて、実在の事物にこのようにギザギザを付けさせるべきではありません。
Palme, et al. Standards Track [Page 14] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[14ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
9.1 Example of a HTML body without included linked objects
9.1 含まれている繋がっている物のないHTML本体に関する例
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アクセスか電子メールウェブゲートウェイのどちらかを必要とするでしょう。
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
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: テキスト/html。 charsetが等しい、「8859を何1インチもisoしているContent転送コード化:」 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>
次の2つの線が見える<HTML><ヘッド></ヘッド><ボディー><h1>Acuteアクセント</h1>は同じスクリーン表現を持っています: 鋭アクセントがある<p>Eはノになります。鋭アクセントがある<Br>EがÉ<p>Tryクリック<a href=になる、「 http://www.ietf.cnri.reston.va.us/ 、「>、ここで. </a><p></が></HTML>を具体化させる、」
9.2 Example with an absolute URI to an embedded GIF picture
9.2 埋め込まれたGIFの絵への絶対URIがある例
The second example is an HTML message which includes a single image, referenced using the Content-Location mechanism.
2番目の例はContent-位置のメカニズムを使用することで参照をつけられるただ一つのイメージを含んでいる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>"
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: 複合か関連する。 境界は「境界例」と等しいです。 =「テキスト/html」をタイプしてください。 =「<foo3@foo1@bar.net>」を始めてください。
--boundary-example
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3@foo1@bar.net>
--境界例のコンテントタイプ: テキスト/html; charsetは「米国-ASCII」コンテント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"
… HTMLドキュメントの原本。(それは、例えば、以下などの声明を通して別の身体の部分でリソースに参照をつけるURIを含むかもしれません)。 <IMG SRCは" http://www.ietf.cnri.reston.va.us/images/ietflogo.gif "と等しいです。
Palme, et al. Standards Track [Page 15] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[15ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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
--境界例のContent-位置: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif コンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example--
--境界例--
9.3 Example with relative URIs to embedded GIF pictures
9.3 埋め込まれたGIFの絵への相対的なURIがある例
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-位置のヘッダーフィールドはすべての相対的なURLへのベースになるでしょう、また、送られるHTMLテキストで。
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"
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0 満足している位置: http://www.ietf.cnri.reston.va.us/ コンテントタイプ: 複合か関連する。 境界は「境界例」と等しいです。 =「テキスト/html」をタイプしてください。
--boundary-example
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE
--境界例のコンテントタイプ: テキスト/html。 charsetは「ISO8859の1インチの内容以下をコード化するのを移すこと」と等しいです。 引用されて印刷可能です。
... text of the HTML document, which might contain URIs
referencing resources in other body parts, for example through
statements such as:
… HTMLドキュメントの原本。(それは、例えば、以下などの声明を通して他の身体の部分でリソースに参照をつけるURIを含むかもしれません)。
<IMG SRC="images/ietflogo1.gif" ALT="IETF logo1">
<IMG SRC="images/ietflogo2.gif" ALT="IETF logo2">
<IMG SRC="images/ietflogo3.gif" ALT="IETF logo3">
「「イメージ/ietflogo1.gif」 ALT=「IETF logo1"><IMG SRC=」イメージ/ietflogo2.gif」<IMG SRC=ALTは「IETF logo2"><IMG SRC=」イメージ/ietflogo3.gifと等しく」ALTは「IETF logo3">」と等しいです。
Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: ¨
Quoted印刷可能でコード化された著作権サインに関する例: =著作権サインのA9 Exampleはマーク付けをHTMLに写像しました: ¨
--boundary-example
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif
; Note - Absolute Content-Location does not require a
; base
--境界例のContent-位置: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif 。 注意--絶対Content-位置はaを必要としません。 ベース
Palme, et al. Standards Track [Page 16] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[16ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
コンテントタイプ: 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
--境界例のContent-位置: イメージ/ietflogo2.gif。 注意--相対的なContent-位置はベースによって決議されています。 関連Content-位置の見出しContent転送Multipart/コード化で指定される: 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
--境界例のContent-位置: http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif の満足している転送コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example--
--境界例--
9.4 Example with a relative URI and no BASE available
9.4 相対的なURIにもかかわらず、どんな基地も利用可能でないことの例
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"
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: 複合か関連する。 境界は「境界例」と等しいです。 =「テキスト/html」をタイプしてください。
--boundary-example
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE
--境界例のコンテントタイプ: テキスト/html。 charsetが等しい、「8859を何1インチもisoしているContent転送コード化:」 引用されて印刷可能です。
... 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: ¨
… HTMLドキュメントの原本。(それは、例えば、以下などの声明を通して別の身体の部分でリソースに参照をつけるURIを含むかもしれません)。 <IMG SRCが"ietflogo.gif"ALT=と等しい、「IETFロゴ、「Quoted印刷可能でコード化された著作権サインの>Example:」 =著作権サインのA9 Exampleはマーク付けをHTMLに写像しました: ¨
Palme, et al. Standards Track [Page 17] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[17ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
--boundary-example
Content-Location: ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例のContent-位置: ietflogo.gifコンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example--
--境界例--
9.5 Example using CID URL and Content-ID header to an embedded GIF
picture
9.5 埋め込まれたGIFの絵にCID URLとコンテントIDヘッダーを使用する例
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"
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: 複合か関連する。 境界は「境界例」と等しいです。 =「テキスト/html」をタイプしてください。
--boundary-example
Content-Type: text/html; charset="US-ASCII"
--境界例のコンテントタイプ: テキスト/html。 charsetは「米国-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">
… HTMLドキュメントの原本。(それは、例えば、以下などの声明を通して別の身体の部分でリソースに参照をつけるURIを含むかもしれません)。 <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
--境界例のContent-位置: Cid: something@else 。 このヘッダーは無視されたコンテントIDです: <foo4@foo1@bar.net>コンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example--
--境界例--
Palme, et al. Standards Track [Page 18] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[18ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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"
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: 複合か関連する。 境界の=「境界例の1インチ」。 =「テキスト/html」をタイプしてください。
--boundary-example-1
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3@foo1@bar.net>
--境界例1のコンテントタイプ: テキスト/html; charsetは「米国-ASCII」コンテント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はイメージ/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>
入れ子にされたテキスト/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>
入れ子にされたテキスト/html身体の部分が以下にある状態で、すぐに以下でのアンカー参照は決議されるでしょう: <A HREFは「 http://www.ietf.cnri.reston.va.us/even-more-info >Evenより多くのインフォメーション</A>」と等しいです。
--boundary-example-1
Content-Location:
http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例1のContent-位置: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif コンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
Palme, et al. Standards Track [Page 19] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[19ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
--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>
--境界例1のContent-位置: http://www.ietf.cnri.reston.va.us/more-info コンテントタイプ: 複合か関連する。 境界の=「境界例の2インチ」。 タイプ=「テキスト/html」--境界例-2コンテントタイプ: テキスト/html; charsetは「米国-ASCII」コンテント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が「イメージ/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はイメージ/ietflogo2e. gifと等しく」ALTが等しい、「透明なバックグラウンド">"があるIETFロゴ
--boundary-example-2
Content-Location: http:images/ietflogo2.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例2のContent-位置: http: イメージ/ietflogo2.gifコンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4
SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa
etc...
R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t eQnNzjHNzlGtrjGNjhFpae1pa7e4 SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/など。
--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>
--境界例2----境界例-1Content-位置: http://www.ietf.cnri.reston.va.us/even-more-info コンテントタイプ: 複合か関連する。 境界の=「境界例の3インチ」。 タイプ=「テキスト/html」--境界例-3コンテントタイプ: テキスト/html; charsetは「米国-ASCII」コンテント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はイメージ/ietflogo2d. gifと等しく」ALTが等しい、「影の">"があるIETFロゴ
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はイメージ/ietflogo2e. gifと等しく」ALTが等しい、「透明なバックグラウンド">"があるIETFロゴ
Palme, et al. Standards Track [Page 20] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[20ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
--boundary-example-3
Content-Location: http:images/ietflogo2d.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例3のContent-位置: http: イメージ/ietflogo2d. gifコンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz
c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v
etc...
R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v etc...
--boundary-example-3--
--boundary-example-1--
--境界例3----境界例-1--
10. Character encoding issues and end-of-line issues
10. 問題と行末問題をコード化するキャラクター
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]、SGML[SGML]のアプリケーションとしての[HTML-I18N]はキャラクタがHTML値上げでキャラクタ実体と番号文字参照で指示されるのを(例えば、「鋭いのがあるaがアクセントをつけるラテン語の小文字」は"á"か"á"によって表されるかもしれません)許容します。
- 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.
- MIMEコンテントタイプ「テキスト」の他のドキュメントと共用して、MIMEで数個のキャラクタencodingsの1つを使用することでHTMLドキュメントを表すことができます。 MIMEコンテントタイプ"charset"パラメタ価値は、特定のコード化が使用したのを示します。 "charset"パラメタの正確な意味と使用に関しては、第4[MIME2]章を見てください。
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キャラクタコード化について言及することに注意してください。 例えば、「charsetは米国-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形式でドキュメントを送るとき、それらのどんな混合物も現れるかもしれません。 ユーザエージェント(彼らがドキュメントを表示するのに使用するどんなウェブブラウザに伴うも)を受けると、これらのメカニズムのどんな組み合わせも扱うことができなければなりません。
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,
- 7ビットの範囲の外に八重奏値を保管しているHTMLドキュメントを含むどんなドキュメントもあるトランスポート・プロトコルの上の以前適用された満足している転送コード化トランスミッションを必要とする、[MIME1
Palme, et al. Standards Track [Page 21] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[21ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
chapter 5].
第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]がその電子メールで送られてきた書類を必要とする、「コンテントタイプ:」 テキスト/はContentの前の標準形では、転送コード化が適用されていて、すなわち、ラインブレイクがむき出しのCRs、むき出しのLFsまたは他の何かとしてコード化されるのではなく、CRLFsとしてコード化されるということであるに違いありません。 これはセクション3.6.1がラインブレイクの他の表現を許容するところに[HTTP]と対照的になっています。
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環境へドキュメントを移すとき保存されないかもしれないチェックサムに基づく保全チェックで問題を起こすかもしれないことに注意してください。 チェックサムに基づいているメッセージの保全チェックが無効になって、次に、この保全チェックがヘッダーSHOULDであるように方法でドキュメントを変換しなければならないなら、ドキュメントから、取り除いてください。
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では許されなかったContent-コード化と、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.
[HTTP、MIME1]をなにもに供給しないなら、いくつかの移送機構がデフォルト"charset"パラメタを指定するかもしれません。 デフォルトを当てにするよりむしろ含まれていて、デフォルトが異なったメカニズム、メール、charsetパラメタSHOULDを通してHTMLを移す時異なるので。
11. Security Considerations
11. セキュリティ問題
11.1 Security considerations not related to caching
11.1 キャッシュに関連しないセキュリティ問題
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によるその参照とそれをラベルするのによる別のリソースを分けるのは、可能です。 したがって、メッセージ受取人はリソースの源ではなく、同じ複合の、または、関連するメッセージ構造の身体の部分からの参照の解決のために身体の部分をラベルするとContent-位置の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、メッセージにおける変化なしで使用されるなら、特にFile URIはうっかり特定のセキュリティ文脈の外で明らかにされることを意図しなかった情報を明らかにするかもしれません。 彼らがそれらが属するどんなセキュリティ文脈の外でも情報を明らかにしていないというこの規格で定義された新しいヘッダーフィールドを含むメッセージを構成するとき、メッセージ送付者は注意するべきです。
Palme, et al. Standards Track [Page 22] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[22ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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)を含むことができます。 受信Userエージェントがその実行可能な内容の能力で制限に関する慎重な注意なしでメール・メッセージに受け取られた内容を実行するのは、きわめて危険です。
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取引は、だれがメッセージを読んでいるかを明らかにするでしょう。 例: だれが匿名のユーザアイデンティティの後ろにいるか、そして、またはユーザがどのワークステーションから彼のメールを読んでいるかを見つけたくて、インラインリンクでメッセージを送ることによってこれをして、次にどこからこのリンクを観測できる人は、物を要求するのに使用されます。
11.2 Security considerations related to caching
11.2 キャッシュに関連するセキュリティ問題
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.
直接検索されたウェブリソースのキャッシュに関する周知の問題があります。 キャッシュから検索されたリソースはソースから再検索されたそれと異なるかもしれません。 この問題、また、複合の、または、関連する構造でリソースのコピーを届けるとき、現れます。
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身体の部分がリソースで満足するのではなく、それらのリソースで満足していた状態で構造、中の同じ複合の、または、関連する構造SHALLの中で補助のリソースに参照をつけるテキスト/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
さらに、複合の、または、関連する構造に受け取られたリソースがキャッシュに格納されるなら、複合の、または、関連する構造に受け取られたリソースの源を誤り伝えることができるので(上の11.1を見てください)、a以外のそのキャッシュからそれを検索してはいけません。
Palme, et al. Standards Track [Page 23] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[23ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
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.
参照は同じ複合の、または、関連する構造の一部を一団となって含みました。 この指示を光栄に思わないと、複合の、または、関連する構造がトロイの木馬として使われるのを許容するでしょう。 例えばにせのリソース(すなわち、競争相手のウェブサイトの誤伝)を受取人の一般にアクセスしやすいウェブキャッシュに注入するために。
12. Differences as compared to the previous version of this proposed
standard in RFC 2110
12. RFC2110でこの提案された標準の旧バージョンと比較される違い
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-見出しのContent-位置のヘッダーを使用できます。 内側の見出しのContent位置のヘッダーフィールドにおける基地の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.
Content-基地のヘッダー(RFC2110に出席していた)を取り除きました。 保守的な作成者は、このヘッダーがRFC2110の実現との互換性のために中で入力されていると受け入れるのを選ぶかもしれませんが、どんなContent-基地のヘッダーも決して送ってはいけません、このヘッダーがこの規格のそれ以上のa部分でないので。
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の取り扱いはただ一つの記述(「thismessage: /」という相対的なURI(別の方法で決議できない)がまるでそれらを与えたかのように扱われるべきであると指定するのによるURL)に合併されました。
13. Acknowledgments
13. 承認
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、ルイス・イェール、ロイFielding、ネッド・フリード、アル・ギルマン、ポール・ホフマン、アンディ・ジェイコブズ、リチャードW.Jesmajian、マーク・K.ジョゼフ、グレッグHerlihy、ヴァルディスKletnieks、ダニエルLaLiberte、エド・レヴィンソン、ジェイ・レビット、アルバート・ルンデ、ラリーMasinter、キース・ムーア、ギャヴィン・ニコル、マーティン・W.ペック、ピートレズニック、ジョンSmirl、Einar Stefferud、ジェイミーZawinski、スティーブZilles、および数人の他の人々がこのドキュメントを準備するのに私たちを助けました。 私たちだけがドキュメントにまだあるどんな誤りへの責任も取ります。
Palme, et al. Standards Track [Page 24] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[24ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
14. References
14. 参照
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[CONDISP] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-
Disposition Header", RFC 2183, August 1997.
[CONDISP] Troost、R.、およびS.デルナー、「インターネットでプレゼンテーション情報を伝えるのは通信します」。 「内容気質ヘッダー」、RFC2183、1997年8月。
[HOSTS] Braden, R., Ed., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October
1989.
[ホスト]ブレーデン、R.、エド、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[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: 「ハイパーテキストマークアップランゲージの国際化」、RFC2070、1997年1月。
[HTML2] Berners-Lee, T. and D. Connolly: "Hypertext Markup
Language - 2.0", RFC 1866, November 1995.
[HTML2] バーナーズ・リー、T.、およびD.コノリー: 「2インチ、RFC1866、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]デーヴRaggett: HTML3.2関連仕様書、W3C推薦、URL http://www.w3.org/TR/REC-html32.html の1997年1月
[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インチ、RFC1945、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.、「Indicate Requirements LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.パルメ: MIMEにおける送付HTML、RFCへの情報の補足: HTMLなどのAggregate Documents(MHTML)のMIME Encapsulation、ProgressのWork。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[MIDCID] Levinson, E., "Content-ID and Message-ID Uniform
Resource Locators", RFC 2387, August 1998.
[MIDCID] レヴィンソン、E.、「コンテントIDとMessage ID Uniform Resource Locator」、RFC2387、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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年12月。
Palme, et al. Standards Track [Page 25] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[25ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
[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を分けます」。 「メディアタイプ」、RFC2046、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.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、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)は4を分けます」。 「登録手順」、RFC2048、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を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
[NEWS] Horton, M. and R. Adams: "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[ニュース] ホートン、M.、およびR.アダムス: 「USENETメッセージの置き換えの規格」、RFC1036、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] ティムBienzとRicharコーン: 「Portable Document Formatリファレンスマニュアル」、アディソン-ウエスリー、読書、MA(米国)1993、ISBN0-201-62628-4。
[REL] Levinson, E., "The MIME Multipart/Related Content-
Type", RFC 2389, August 1998.
[REL]レヴィンソン、1998年8月のE.、「MIMEの複合の、または、関連の満足しているタイプ」RFC2389。
[RELURL] Fielding, R., "Relative Uniform Resource Locators",
RFC 1808, June 1995.
[RELURL] フィールディング、R.、「相対的なUniform Resource Locator」、RFC1808、1995年6月。
[RFC822] Crocker, D., "Standard for the format of ARPA
Internet text messages." STD 11, RFC 822, August
1982.
[RFC822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格。」 STD11、RFC822、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] ISO8879。 情報処理--マークアップ言語(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.、「簡単なメール転送プロトコル」、STD10、RFC821、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、「Uniform Resource Locator(URL)」、RFC1738、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外部のボディーアクセス型の定義」、RFC2017、1996年10月。
Palme, et al. Standards Track [Page 26] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[26ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
[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/
ワールドワイドウェブコンソーシアム、URL http://www.w3.org/XML/ によって発行された[XML]拡張マークアップ言語
15. Authors' Addresses
15. 作者のアドレス
For contacting the editors, preferably write to Jacob Palme.
望ましくは、エディタに連絡するには、ヤコブ・パルメに書いてください。
Jacob Palme Stockholm University and KTH Electrum 230 S-164 40 Kista, Sweden
ヤコブパルメストックホルム大学とKTH琥珀金230秒間-164 40Kista、スウェーデン
Phone: +46-8-16 16 67 Fax: +46-8-783 08 29 EMail: jpalme@dsv.su.se
以下に電話をしてください。 +46-8-16、16 67、Fax: +46-8-783 08 29はメールされます: jpalme@dsv.su.se
Alex Hopmann Microsoft Corporation One Microsoft Way Redmond WA 98052
アレックスHopmannマイクロソフト社1マイクロソフト道レッドモンドワシントン98052
Phone: +1-425-703-8238 EMail: alexhop@microsoft.com
以下に電話をしてください。 +1-425-703-8238 メールしてください: alexhop@microsoft.com
Nick Shelness Lotus Development Corporation 55 Cambridge Parkway Cambridge MA 02142-1295
ニックシェルLotus Development Corporation55ケンブリッジ公園道路ケンブリッジMA02142-1295
EMail: Shelness@lotus.com
メール: Shelness@lotus.com
Working group chairman:
ワーキンググループ議長:
Einar Stefferud EMail: stef@nma.com
Einar Stefferudはメールします: stef@nma.com
Palme, et al. Standards Track [Page 27] RFC 2557 MIME Encapsulation of Aggregate Documents March 1999
パルメ、他 標準化過程[27ページ]RFC2557は1999年3月に集合ドキュメントのカプセル化をまねます。
16. Full Copyright Statement
16. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Palme, et al. Standards Track [Page 28]
パルメ、他 標準化過程[28ページ]
一覧
スポンサーリンク
