RFC2110 日本語訳
2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML(MHTML). J. Palme, A. Hopmann. March 1997. (Format: TXT=41961 bytes) (Obsoleted by RFC2557) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Palme
Request for Comments: 2110 Stockholm University/KTH
Category: Standards Track A. Hopmann
Microsoft Corporation
March 1997
コメントを求めるワーキンググループJ.パルメの要求をネットワークでつないでください: 2110年のストックホルム大学/KTHカテゴリ: 1997年の標準化過程A.Hopmannマイクロソフト社行進
MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
HTMLなどのAggregate DocumentsのMIMEメールEncapsulation(MHTML)
Status of this Document
このDocumentの状態
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate using HTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content- Location" and "Content-Base".
HTML[RFC1866]はMIMEの文脈の中で設計されましたが、2人の電子メールユーザエージェントがドキュメント・フォーマットとしてHTMLを使用することで共同利用できるように、RFC1866の定義されるとしてのHTMLの仕様以上が必要です。 これらの問題は通常、URIによって言及されるオブジェクトの命名、および伴うオブジェクトに集める手段を含んでいます。 このドキュメントはURIによって表されたリンクを含むことができるHTMLオブジェクトなどのこれらのオブジェクトを送って、提供して、表示できるようにメールユーザエージェントを従わせるマニュアルについて説明します。 相互繋がっているオブジェクトを扱うことができるように、ドキュメントは、複合である、または関連していた状態でMIMEの種類を使用して、MIME満足しているヘッダー「満足している位置」と「満足している基地」を指定します。
Table of Contents
目次
1. Introduction.............................................. 2
2. Terminology............................................... 3
2.1 Conformance requirement terminology................... 3
2.2 Other terminology..................................... 4
3. Overview.................................................. 5
4. The Content-Location and Content-Base MIME Content Headers 6
4.1 MIME content headers.................................. 6
4.2 The Content-Base header............................... 7
4.3 The Content-Location Header........................... 7
4.4 Encoding of URIs in e-mail headers.................... 8
5. Base URIs for resolution of relative URIs................. 8
6. Sending documents without linked objects.................. 9
7. Use of the Content-Type: Multipart/related................ 9
8. Format of Links to Other Body Parts....................... 11
1. 序論… 2 2. 用語… 3 2.1 順応要件用語… 3 他の2.2用語… 4 3. 概要… 5 4. Content-位置とContent-基地のMIME Content Headers6 4.1個のMIME内容ヘッダー… 6 4.2 Content-基地のヘッダー… 7 4.3 満足している位置のヘッダー… 7 4.4 メールヘッダーでのURIのコード化… 8 5. 相対的なURIの解決のためのURIを基礎づけてください… 8 6. 繋がっているオブジェクトなしでドキュメントを送ります… 9 7. コンテントタイプの使用: 複合か関連する… 9 8. 他のボディ・パーツへのリンクの形式… 11
Palme & Hopmann Standards Track [Page 1] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[1ページ]。
8.1 General principle..................................... 11
8.2 Use of the Content-Location header.................... 11
8.3 Use of the Content-ID header and CID URLs............. 12
9 Examples................................................... 12
9.1 Example of a HTML body without included linked objects 12
9.2 Example with absolute URIs to an embedded GIF picture 13
9.3 Example with relative URIs to an embedded GIF picture 13
9.4 Example using CID URL and Content-ID header to an
embedded GIF picture.................................. 14
10. Content-Disposition header............................... 15
11. Character encoding issues and end-of-line issues......... 15
12. Security Considerations.................................. 16
13. Acknowledgments.......................................... 17
14. References............................................... 18
15. Author's Address......................................... 19
8.1の一般原則… 11 8.2 Content-位置のヘッダーの使用… 11 8.3 コンテントIDヘッダーとCID URLの使用… 12 9つの例… 12 9.1 含まれている繋がっているオブジェクトのないHTML本体に関する例、12、9.2Example、埋め込まれたGIF画像への絶対URI、13、9.3Example、埋め込まれたGIFへの相対的なURIで、13の9.4Example使用CID URLとコンテントIDヘッダーについて埋め込まれたGIF画像に描写してください… 14 10. 満足している気質ヘッダー… 15 11. 文字符号化問題と行末問題… 15 12. セキュリティ問題… 16 13. 承認… 17 14. 参照… 18 15. 作者のアドレス… 19
Mailing List Information
メーリングリスト情報
Further discussion on this document should be done through the mailing list MHTML@SEGATE.SUNET.SE.
メーリングリスト MHTML@SEGATE.SUNET.SE を通してこのドキュメントのさらなる議論をするべきです。
To subscribe to this list, send a message to
LISTSERV@SEGATE.SUNET.SE
which contains the text
SUB MHTML <your name (not your e-mail address)>
このリストに加入するために、テキストSUB MHTML<を含む LISTSERV@SEGATE.SUNET.SE にメッセージを送ってください、あなたの名前(あなたのEメールアドレスでない)>。
Archives of this list are available by anonymous ftp from
FTP://SEGATE.SUNET.SE/lists/mHTML/
The archives are also available by e-mail. Send a message to
LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get a list
of the archive files, and then a new message "GET <file name>" to
retrieve the archive files.
このリストのアーカイブはFTP://SEGATE.SUNET.SE/lists/mHTML/からのアノニマスFTPで利用可能です。また、アーカイブもメールで利用可能です。 アーカイブファイルのリストを得るテキスト「インデックスMHTML」、および次に、アーカイブファイルを取る「<ファイル名前>を手に入れてください」という新しいメッセージがある LISTSERV@SEGATE.SUNET.SE にメッセージを送ってください。
Comments on less important details may also be sent to the editor, Jacob Palme <jpalme@dsv.su.se>.
また、それほど重要でない詳細のコメントをエディタ、ヤコブ Palme <jpalme@dsv.su.se に送るかもしれない、gt。
More information may also be available at URL: HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML
また、詳しい情報もURLで利用可能であるかもしれません: HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML
1. Introduction
1. 序論
There are a number of document formats, HTML [HTML2], PDF [PDF] and VRML for example, which provide links using URIs for their resolution. There is an obvious need to be able to send documents in these formats in e-mail [RFC821=SMTP, RFC822]. This document gives additional specifications on how to send such documents in MIME [RFC 1521=MIME1] e-mail messages. This version of this standard was based on full consideration only of the needs for objects with links in the
多くのドキュメント・フォーマット、HTML[HTML2]、PDF[PDF]、および例えばVRMLがあります。(それは、彼らの解決にURIを使用することでリンクを提供します)。 メール[RFC821=SMTP、RFC822]にはこれらの形式でドキュメントを送ることができる明白な必要があります。 このドキュメントはどうMIME[RFC 1521=MIME1]メールメッセージのそのようなドキュメントを送るかに関する追加仕様を与えます。 中にリンクがある状態で、この規格のこのバージョンはオブジェクトの必要性だけの本格的な検討に基づきました。
Palme & Hopmann Standards Track [Page 2] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[2ページ]。
Text/HTML media type (as defined in RFC 1866 [HTML2]), but the standard may still be applicable also to other formats for sets of interlinked objects, linked by URIs. There is no conformance requirement that implementations claiming conformance to this standard are able to handle URI-s in other document formats than HTML.
テキスト/HTMLメディアはタイプされますが(RFC1866[HTML2]で定義されるように)、URIによってリンクされた連結オブジェクトのセットには、規格は他の形式にもまだ適切であるかもしれません。 HTML以外のドキュメント・フォーマットにはこの規格に順応を要求する実装がURI sを扱うことができるという順応要件が全くありません。
URIs in documents in HTML and other similar formats reference other objects and resources, either embedded or directly accessible through hypertext links. When mailing such a document, it is often desirable to also mail all of the additional resources that are referenced in it; those elements are necessary for the complete interpretation of the primary object.
ハイパーテキストリンクを通してHTMLにおけるドキュメントと他の同様の形式参照他のオブジェクトと埋め込まれたリソースか直接アクセスしやすいURI。 そのようなドキュメントを郵送するとき、また、それで参照をつけられる追加リソースのすべてを郵送するのはしばしば望ましいです。 それらの要素がプライマリオブジェクトの完全な解釈に必要です。
An alternative way for sending an HTML document or other object containing URIs in e-mail is to only send the URL, and let the recipient look up the document using HTTP. That method is described in [URLBODY] and is not described in this document.
メールにURIを含むHTMLドキュメントか他のオブジェクトを送るための代替の方法は、URLを送るだけであり、受取人にHTTPを使用するドキュメントを調べさせることです。 そのメソッドは、[URLBODY]で説明されて、本書では説明されません。
An informational RFC will at a later time be published as a supplement to this standard. The informational RFC will discuss implementation methods and some implementation problems. Implementors are recommended to read this informational RFC when developing implementations of the MHTML standard. This informational RFC is, when this RFC is published, still in IETF draft status, and will stay that way for at least six months in order to gain more implementation experience before it is published.
情報のRFCは後で補足としてこの規格に発行されるでしょう。 情報のRFCは実装メソッドといくつかの実装問題について議論するでしょう。作成者はMHTML規格の実装を開発するとき、この情報のRFCを読むためにお勧めです。 この情報のRFCはそうです、このRFCがまだIETFドラフト状態で発行されて、それが発行される前により多くの実装経験をするためにそのように少なくとも6カ月滞在すると。
2. Terminology
2. 用語
2.1 Conformance requirement terminology
2.1 順応要件用語
This specification uses the same words as RFC 1123 [HOSTS] for defining the significance of each particular requirement. These words are:
この仕様は、それぞれの特定の要件の意味を定義するのにRFC1123[HOSTS]と同じ単語を使用します。 これらの単語は以下の通りです。
MUST This word or the adjective "required" means that the item is
an absolute requirement of the specification.
「必要である」というThis単語か形容詞が、項目が仕様に関する絶対条件であることを意味しなければなりません。
SHOULD This word or the adjective "recommended" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the
case carefully weighed before choosing a different course.
SHOULD This単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
Palme & Hopmann Standards Track [Page 3] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[3ページ]。
MAY This word or the adjective "optional" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit
the same item.
この項目は、This単語か形容詞的「任意」の手段ですが、本当に、任意の状態でそうするかもしれません。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つのベンダーが、項目を含んでいるのを選ぶかもしれません。 別のベンダーは同じ項目を省略するかもしれません。
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 RFC 1808 [RELURL]. AbsoluteURI
絶対URI、RFC1808[RELURL]を見てください。 AbsoluteURI
CID See [MIDCID].
Cidは[MIDCID]を見ます。
Content-Base See section 4.2 below.
満足..基地..セクション..以下に
Content-ID See [MIDCID].
コンテントIDは[MIDCID]を見ます。
Content-Location MIME message or content part header with the
URI of the MIME message or content part body,
defined in section 4.3 below.
満足している位置のMIMEメッセージか下のセクション4.3で定義されたMIMEメッセージか満足している部分本体のURIがある満足している部分ヘッダー。
Content-Transfer-Enco Conversion of a text into 7-bit octets as ding specified in [MIME1].
鐘の音としての7ビットの八重奏へのテキストの満足している転送Enco Conversionは[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マーク付けの定義を見てください。
Header Field in a message or content heading specifying
the value of one attribute.
1つの属性の値を指定しながら向かうメッセージか内容のヘッダーField。
Palme & Hopmann Standards Track [Page 4] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[4ページ]。
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 RFC 1866 [HTML2].
HTMLはRFC1866[HTML2]を見ます。
HTML Aggregate HTML objects together with some or all objects,
to objects which the HTML object contains
hyperlinks.
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 RFC 1521 [MIME1], [MIME2].
[MIME2]、MIMEはRFC1521[MIME1]を見ます。
MUA Messaging User Agent.
MUAメッセージングユーザエージェント。
PDF Portable Document Format, see [PDF].
PDF Portable Document Format、[PDF]を見てください。
Relative URI, See RFC 1866 [HTML2] and RFC 1808[RELURL]. RelativeURI
相対URI、RFC1866[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 [RELURL].
URL、親類See[RELURL]。
VRML Virtual Reality Markup Language.
VRMLバーチャルリアリティマークアップ言語。
3. Overview
3. 概要
An aggregate document is a MIME-encoded message that contains a root document as well as other data that is required in order to represent that document (inline pictures, style sheets, applets, etc.). Aggregate documents can also include additional elements that are linked to the first object. It is important to keep in mind the differing needs of several audiences. Mail sending agents might send
集合ドキュメントはそのドキュメント(インライン画像、スタイルシート、アプレットなど)を表すのに必要である他のデータと同様に根のドキュメントを含むMIMEでコード化されたメッセージです。 また、集合ドキュメントは最初のオブジェクトにリンクされる追加要素を含むことができます。 数人の聴衆の異なった必要性を覚えておくのは重要です。 エージェントが送るかもしれない発信を郵送してください。
Palme & Hopmann Standards Track [Page 5] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[5ページ]。
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.
正常なその日その日の電子メールのコード化としてドキュメントに集めてください。 ユーザがウェブから他の誰かまで特定のドキュメントを郵送したがっているとき、またエージェントが送るかもしれない発信に集合ドキュメントを郵送してください。 非IPのためのWWWリソースへのアクセスがクライアントに接するなら、最終的にメール送付エージェントは自動応答者として集合ドキュメントを送るでしょうに。
Mail receiving agents also have several differing needs. Some mail 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.
エージェントを受信に郵送してください、そして、また、いくつかの異なった必要性を持ってください。 エージェントを受ける郵便配達人は、ちょうどいかなる他のテキスト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 able to be transmitted to a client and displayed with a minimum risk of breaking the message integrity (MIC) check that is part of the signature.
最終的に、問題における他のいくつかの規制が起こります。 それが書類に署名して、クライアントに伝えて、署名の一部であるメッセージの保全(MIC)チェックを壊すという最小危険と共に表示できるのにおいて可能であることは、重要です。
4. The Content-Location and Content-Base MIME Content Headers
4. 満足している位置と満足している基地のMIMEの満足しているヘッダー
4.1 MIME content headers
4.1 MIME内容ヘッダー
In order to resolve URI references to other body parts, two MIME content headers are defined, Content-Location and Content-Base. Both these headers can occur in any message or content heading, and will then be valid within this heading and for its content.
2個のMIME内容ヘッダーが他の身体の部分のURI参照を決議するために定義される、Content-位置とContent-基地。 これらのヘッダーの両方がどんなメッセージや満足している見出しにも起こることができます、そして、そして、この見出しとその内容において、有効でしょう。
In practice, at present only those URIs which are URLs are used, but it is anticipated that other forms of URIs will in the future be used.
実際には、現在のところ、URLであるそれらの唯一のURIは使用されていますが、他のフォームのURIが将来使用されると予期されます。
The syntax for these headers is, using the syntax definition tools from [RFC822]:
[RFC822]から構文定義ツールを使用して、これらのヘッダーのための構文は以下の通りです。
content-location ::= "Content-Location:" ( absoluteURI |
relativeURI )
満足している位置:、:= 「満足している位置:」 (absoluteURI| relativeURI)
content-base ::= "Content-Base:" absoluteURI
以下を内容で基礎づけてください:= 「以下を内容で基礎づけてください」 absoluteURI
where URI is at present (June 1996) restricted to the syntax for URLs as defined in RFC 1738 [URL].
現在のところURIがURLのためにRFC1738[URL]で定義されるように構文に制限された(1996年6月)であるところ。
These two headers are valid only for exactly the content heading or message heading where they occurs and its text. They are thus not valid for the parts inside multipart headings, and are thus meaningless in multipart headings.
まさに満足している見出しか彼らが起こるメッセージ見出しとそのテキストだけに、これらの2個のヘッダーが有効です。 それらは、その結果、複合見出しの中で部品には有効でなく、その結果、複合見出しで無意味です。
Palme & Hopmann Standards Track [Page 6] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[6ページ]。
These two headers may occur both inside and outside of a multipart/related part.
これらの2個のヘッダーが複合の、または、関連する部分の中と外に起こるかもしれません。
4.2 The Content-Base header
4.2 Content-基地のヘッダー
The Content-Base gives a base for relative URIs occurring in other heading fields and in HTML documents which do not have any BASE element in its HTML code. Its value MUST be an absolute URI.
Content-基地は他の見出し分野とHTMLコードでどんな基地の要素も持っていないHTMLドキュメントに起こる相対的なURIのためにベースを与えます。 値は絶対URIでなければなりません。
Example showing which Content-Base is valid where:
どのContent-基地を示している例が有効である、どこ:
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML; start=foo2*foo3@bar2.net
; A Content-Base header cannot be placed here, since this is a
; multipart MIME object.
コンテントタイプ: 複合か関連する。 境界の=「境界例の1インチ」。 =テキスト/HTMLをタイプしてください。 = foo2*foo3@bar2.net を始動してください。 これがaであるので、Content-基地のヘッダーをここに置くことができません。 複合MIMEオブジェクト。
--boundary-example-1
--境界例1
Part 1:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID: <foo2*foo3@bar2.net>
Content-Location: http://www.ietf.cnir.reston.va.us/images/foo1.bar1
; This Content-Location must contain an absolute URI, since no base
; is valid here.
第1部: コンテントタイプ: テキスト/HTML。 charsetは米国のASCIIのコンテントIDと等しいです: <のfoo2*foo3の@barの2.netの>の満足している位置: http://www.ietf.cnir.reston.va.us/images/foo1.bar1 。 どんなベース以来もこのContent-位置は絶対URIを含んではいけません。 ここで、有効です。
--boundary-example-1
--境界例1
Part 2:
Content-Type: Text/HTML; charset=US-ASCII
Content-ID: <foo4*foo5@bar2.net>
Content-Location: foo1.bar1 ; The Content-Base below applies to
; this relative URI
Content-Base: http://www.ietf.cnri.reston.va.us/images/
第2部: コンテントタイプ: テキスト/HTML。 charsetは米国のASCIIのコンテントIDと等しいです: <のfoo4*foo5の@barの2.netの>の満足している位置: foo1.bar1。 下のContent-基地は、申し込みます。 この親類URI Content-基地: http://www.ietf.cnri.reston.va.us/images/
--boundary-example-1--
--境界例1--
4.3 The Content-Location Header
4.3 満足している位置のヘッダー
The Content-Location header specifies the URI that corresponds to the content of the body part in whose heading the header is placed. Its value CAN be an absolute or 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やURL体系も使用されるかもしれませんが、受取人がそうすることができない非標準化されたURIか或るものが危険にさらすURL体系力の限嗣相続の使用は正しく彼らを扱います。
The Content-Location header can be used to indicate that the data sent under this heading is also retrievable, in identical format, through normal use of this URI. If used for this purpose, it must contain an absolute URI or be resolvable, through a Content-Base
また、この見出しの下で送られたデータも回収可能であることを示すのにContent-位置のヘッダーを使用できます、同じ形式で、このURIの通常の使用で。 このために使用されるなら、絶対URIを含んでいるか、またはContent-基地を通って溶解性であるに違いありません。
Palme & Hopmann Standards Track [Page 7] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[7ページ]。
header, into an absolute URI. In this case, the information sent in the message can be seen as a cached version of the original data.
絶対URIへのヘッダー。 この場合、情報は、メッセージをオリジナルのデータのキャッシュされたバージョンと考えることができるのを送りました。
The header can also be used for data which is not available to some or all recipients of the message, for example if the header refers to an object which is only retrievable using this URI in a restricted domain, such as within a company-internal web space. The header can even contain a fictious URI and need in that case not be globally unique.
また、メッセージのいくつかかすべての受取人にとって得ることができないデータにヘッダーを使用できます、例えば、ヘッダーが制限されたドメインでこのURIを使用することで回収可能であるだけであるオブジェクトについて言及するなら、会社の内部のウェブスペースなどのように。 ヘッダーは、fictious URIを含むことさえできて、その場合グローバルにユニークである必要はありません。
Example:
例:
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML
コンテントタイプ: 複合か関連する。 境界の=「境界例の1インチ」。 =テキスト/HTMLをタイプしてください。
--boundary-example-1
--境界例1
Part 1:
Content-Type: Text/HTML; charset=US-ASCII
第1部: コンテントタイプ: テキスト/HTML。 charsetは米国-ASCIIと等しいです。
... ... <IMG SRC="fiction1/fiction2"> ... ...
... ... <IMG SRCは「fiction1/fiction2">」と等しいです… ...
--boundary-example-1
--境界例1
Part 2:
Content-Type: Text/HTML; charset=US-ASCII
Content-Location: fiction1/fiction2
第2部: コンテントタイプ: テキスト/HTML。 charsetは米国のASCIIの満足している位置と等しいです: fiction1/fiction2
--boundary-example-1--
--境界例1--
4.4 Encoding of URIs in e-mail headers
4.4 メールヘッダーでのURIのコード化
Since MIME header fields have a limited length and URIs can get quite long, these lines may have to be folded. If such folding is done, the algorithm defined in [URLBODY] section 3.1 should be employed.
ヘッダーフィールドが持っているMIME以来、限られた長さとURIはかなり長くなることができて、これらの系列は折り重ねられなければならないかもしれません。 そのような折り重なりが完了しているなら、[URLBODY]セクション3.1で定義されたアルゴリズムは使われるべきです。
5. Base URIs for resolution of relative URIs
5. 相対的なURIの解決のための基地のURI
Relative URIs inside contents of MIME body parts are resolved relative to a base URI. In order to determine this base URI, the first-applicable method in the following list applies.
MIME身体の部分のコンテンツにおける相対URIはベースURIに比例して決議されています。 このベースURIを決定するために、最初に、以下のリストの適用される方式は申し込まれます。
(a) There is a base specification inside the MIME body part
containing the link which resolves relative URIs into absolute
URIs. For example, HTML provides the BASE element for this.
(a) 相対的なURIに絶対URIに変えるリンクを含むMIME身体の部分の中に基礎仕様があります。 例えば、HTMLは基地の要素をこれに提供します。
(b) There is a Content-Base header (as defined in section 4.2),
specifying the base to be used.
(b) 使用されるためにベースを指定して、Content-基地のヘッダー(セクション4.2で定義されるように)があります。
Palme & Hopmann Standards Track [Page 8] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[8ページ]。
(c) There is a Content-Location header in the heading of the body
part which can then serve as the base in the same way as the
requested URI can serve as a base for relative URIs within a
file retrieved via HTTP [HTTP].
(c) Content-位置のヘッダーが次に同様に、ファイルの中の相対的なURIのためのベースがHTTPで[HTTP]を検索したので要求されたURIが役立つことができてベースとして機能できる身体の部分に関する見出しにあります。
When the methods above do not yield an absolute URI the procedure in section 8.2 for matching relative URIs MUST be followed.
上のメソッドが絶対URIをもたらさないとき、合っている相対的なURIのためのセクション8.2の手順に従わなければなりません。
6. Sending documents without linked objects
6. 繋がっているオブジェクトのない資料送付
If a document, such as an HTML object, is sent without other objects, to which it is linked, it MAY be sent as a Text/HTML body part by itself. In this case, multipart/related need not be used.
他のオブジェクト(それは繋がっている)なしでHTMLオブジェクトなどのドキュメントを送るなら、Text/HTML身体の部分としてそれ自体でそれを送るかもしれません。 この場合、関係づけられた複合/は使用される必要はありません。
Such a document may either not include any links, or contain links which the recipient resolves via ordinary net look up, or contain links which the recipient cannot resolve.
そのようなドキュメントは、どんなリンクも含んでいませんし、普通のネットの外観で上がった状態で受取人が決議するリンクを含んでいませんし、また受取人が決議できないリンクを含まないかもしれません。
Inclusion of links which the recipient has to look up through the net may not work for some recipients, since all e-mail recipients do not have full internet connectivity. Also, such links may work for the sender but not for the recipient, for example when the link refers to an URI within a company-internal network not accessible from outside the company.
受取人がネットを通して見上げなければならないリンクの包含は何人かの受取人に効き目がないかもしれません、すべてのメール受取人には完全なインターネットの接続性がないので。 また、そのようなリンクは、送付者のために働いていますが、受取人のために働くかもしれないというわけではありません、例えば、リンクが社外からアクセスしやすくない会社の内部のネットワークの中のURIについて言及するとき。
Note that documents with links that the recipient cannot resolve MAY be sent, although this is discouraged. For example, two persons developing a new HTML page may exchange incomplete versions.
これはがっかりしていますが、受取人が決議できないリンクがあるドキュメントが送られるかもしれないことに注意してください。 例えば、新しいHTML形式のページを開発する2人の人々が不完全なバージョンを交換するかもしれません。
7. Use of the Content-Type: Multipart/related
7. コンテントタイプの使用: 複合である、または関連しています。
If a message contains one or more MIME body parts containing links and also contains as separate body parts, data, to which these links (as defined, for example, in RFC 1866 [HTML2]) refers, then this whole set of body parts (referring body parts and referred-to body parts) SHOULD be sent within a multipart/related body part as defined in [REL].
(これらのリンク(例えば、RFC1866[HTML2]で定義されるように)はデータを参照されます)。メッセージが1つ以上のMIME身体の部分を含んでいるなら、含有は、別々のボディーとして部品、データをリンクして、また、含んでいて、次に、この全体集合の身体の部分(身体の部分と言及している身体の部分を参照する)はSHOULDです。[REL]で定義されるように複合の、または、関連する身体の部分の中で送ってください。
The root body part of the multipart/related SHOULD be the start object for rendering the object, such as a text/html object, and which contains links to objects in other body parts, or a multipart/alternative of which at least one alternative resolves to such a start object. Implementors are warned, however, that many mail programs treat multipart/alternative as if it had been multipart/mixed (even though MIME [MIME1] requires support for multipart/alternative).
複合/の根の身体の部分はレンダリングのためのスタートオブジェクトがオブジェクトであったならSHOULDを関係づけました、テキスト/htmlオブジェクトや、どれが他の身体の部分にオブジェクトへのリンクを含んでいるか、そして、少なくとも1つの選択肢がスタートオブジェクトをそのようなものに分解する複合/代替手段などのように。 しかしながら、作成者はまるでそれが複合か混ぜられたかのように(MIME[MIME1]は複合/代替手段に支持を要しますが)多くのメールプログラムが複合である、または代替で扱われるのに注意されます。
Palme & Hopmann Standards Track [Page 9] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[9ページ]。
[REL] requires that the type attribute of the "Content-Type: Multipart/related" statement be the type of the root object, and this value can thus be "multipart/alternative". If the root is not the first body part within the multipart/related, [REL] further requires that its Content-ID MUST be given in a start parameter to the "Content-Type: Multipart/related" header.
[REL]がそれを必要とする、属性をタイプする、「コンテントタイプ:」 「複合か関連する」声明は、ルートオブジェクトのタイプであり、その結果、これが、評価する「複合か代替であることができます」。 [REL]が、根が複合か関連の中の最初の身体の部分でないなら、スタートパラメタでコンテントIDを与えなければならないのをさらに必要とする、「コンテントタイプ:」 「複合か関連する」ヘッダー。
When presenting the root body part to the user, the additional body parts within the multipart/related can be used:
根の身体の部分をユーザに提示するとき、複合か関連の中の追加身体の部分を使用できます:
(a) For those recipients who only have e-mail 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 the
linked body parts through the net.
会社の内部のリンクのファイアウォールか使用などの他の理由でネットを通して繋がっている身体の部分を検索できない受取人のための(b)。
Note that this means that you can, via e-mail, send HTML which
includes URIs which the recipient cannot resolve via HTTPor
other connectivity-requiring URIs.
これが、メールで受取人がHTTPorを通して決議できないURIを含んでいるHTMLに他のURIは接続性が必要な送ることができることを意味することに注意してください。
(c) For items which are not available on the web.
ウェブで利用可能でない項目のための(c)。
(d) For any recipient to speed up access.
(d) どんな受取人もアクセサリーを加速するように
The type parameter of the "Content-Type: Multipart/related" MUST be the same as the Content-Type of its root.
パラメタをタイプする、「コンテントタイプ:」 「複合/は関係したこと」が根のコンテントタイプと同じであるに違いありません。
When a sending MUA sends objects which were retrieved from the WWW, it SHOULD maintain their WWW URIs. It SHOULD not transform these URIs into some other URI form prior to transmitting them. This will allow the receiving MUA to both verify MICs included with the email message, as well as verify the documents against their WWW counterpoints.
送付MUAがいつ発信するかは反対して、(WWWから検索されました)それはSHOULDです。それらのWWWがURIであることを支持してください。 それ、それらを伝える前に、SHOULDはこれらのURIをある他のURIフォームに変えません。 これで、受信MUAはメールメッセージで含まれていたMICsについて確かめて、それらのWWW対位法に対してドキュメントについて確かめるでしょう。
In certain special cases this will not work if the original HTML document 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.
ある特別な場合では、オリジナルのHTMLドキュメントがパラメタとしてオブジェクトとアプレットにURIを含んでいると、これは働かないでしょう。 このような場合には、それを送る前に、ドキュメントを書き直すほうがよいかもしれません。 さらに詳細に補足としてこの規格に発行される情報のRFCでこの問題について議論します。
This standard does not cover the case where a multipart/related contains links to MIME body parts outside of the current multipart/related or in other MIME messages, even if methods similar to those described in this standard are used. Implementors who provide such links are warned that mailers implementing this standard may not be able to resolve such links.
この規格は、複合である、または関連していた状態で関係づけられた複合/が外のMIME身体の部分へのリンクを含む電流に関するケースをカバーもしていませんし、他のMIMEメッセージでそうもしません、この規格で説明されたものと同様のメソッドが使用されていても。 そのようなリンクを提供する作成者はこの規格を実装する郵送者がそのようなリンクを決議できないかもしれないのに注意されます。
Palme & Hopmann Standards Track [Page 10] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[10ページ]。
Within such a multipart/related, ALL different parts MUST have different Content-Location or Content-ID values.
すべての異なった部品の中に、異なったContent-位置かコンテントID値がなければなりません。
8. Format 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 hyperlinks to objects which are included as other body parts in the same message and within the same multipart/related content. Often such linked objects are meant to be displayed inline to the reader of the main document; for example, objects referenced with the IMG tag in HTML [RFC 1866=HTML2]. New tags with this property are proposed in the ongoing development of HTML (example: applet, frame).
テキスト/HTML身体の部分などの身体の部分は他の身体の部分として同じメッセージと、そして、同じ複合の、または、関連する内容の中に含まれているオブジェクトにハイパーリンクを含むかもしれません。 しばしば、そのような繋がっているオブジェクトは主なドキュメントの読者への表示されたインラインであることが意味されます。 例えば、IMGタグでHTML[RFC 1866=HTML2]で参照をつけられるオブジェクト。 この特性がある新しいタグはHTML(例: アプレット、フレーム)の開発現況で提案されます。
In order to send such messages, there is a need to indicate which other body parts are referred to by the links in the body parts containing such links. For example, a body part of Content-Type: Text/HTML often has links to other objects, which might be included in other body parts in the same MIME message. The referencing of other body parts is done in the following way: For each body part containing links and each distinct URI within it, which refers to data which is sent in the same MIME message, there SHOULD be a separate body part within the current multipart/related part of the message containing this data. Each such body part SHOULD contain a Content-Location header (see section 8.2) or a Content-ID header (see section 8.3).
そのようなメッセージを送るために、そのようなリンクを含んでいて、どの他の身体の部分が身体の部分でリンクによって言及されるかを示す必要があります。 例えば、コンテントタイプの身体の部分: テキスト/HTMLはしばしば他のオブジェクトにリンクを持っています。(オブジェクトは同じMIMEメッセージに他の身体の部分に含まれるかもしれません)。 他の身体の部分の参照箇所は以下の方法で完了しています: リンクを含むそれぞれの身体の部分とそれの中のそれぞれの異なったURIについて、どれが同じMIMEメッセージで送られるデータをそこと呼ぶか、SHOULD、このデータを含むメッセージの現在の複合の、または、関連する部分の中の別々の身体の部分になってください。 そのようなそれぞれの身体のパートSHOULDはContent-位置のヘッダー(セクション8.2を見る)かコンテントIDヘッダーを含んでいます(セクション8.3を見てください)。
An e-mail system which claims conformance to this standard MUST support receipt of multipart/related (as defined in section 7) with links between body parts using both the Content-Location (as defined in section 8.2) and the Content-ID method (as defined in section 8.3).
この規格に順応を要求する電子メール・システムは複合の、または、関連する(セクション7で定義されるように)身体の部分の間のContent-位置(セクション8.2で定義されるように)とコンテントIDの両方を使用しているリンクでメソッドの領収書を支えなければなりません(セクション8.3で定義されるように)。
8.2 Use of the Content-Location header
8.2 Content-位置のヘッダーの使用
If there is a Content-Base header, then the recipient MUST employ relative to absolute resolution as defined in RFC 1808 [RELURL] of relative URIs in both the HTML markup and the Content-Location header before matching a hyperlink in the HTML markup to a Content-Location header. The same applies if the Content-Location contains an absolute URI, and the HTML markup contains a BASE element so that relative URIs in the HTML markup can be resolved.
Content-基地のヘッダーがあれば、受取人がハイパーリンクを合わせる前に相対的なURIのRFC1808年[RELURL]に両方のHTMLマーク付けとContent-位置のヘッダーでContent-位置のヘッダーとHTMLマークアップで定義されるように絶対解決に比例して使わなければならないその時です。 Content-位置が絶対URIを含んでいるなら、同じくらいは申し込まれます、そして、HTMLマークアップはHTMLマークアップにおける相対的なURIを決議できるように基地の要素を含んでいます。
If there is NO Content-Base header, and the Content-Location header contains a relative URI, then NO relative to absolute resolution SHOULD be performed. Matching the relative URI in the Content- Location header to a hyperlink in an HTML markup text is in this case
絶対解決に比例していいえ、SHOULD Content-基地のヘッダーが全くなくて、Content-位置のヘッダーが相対的なURIを含んでいるなら。実行されます。 この場合Content位置のヘッダーでHTMLマーク付けテキストのハイパーリンクに相対的なURIを合わせるのは、そうです。
Palme & Hopmann Standards Track [Page 11] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[11ページ]。
a two step process. First remove any LWSP from the relative URI which may have been introduced as described in section 4.4. Then perform an exact textual match against the HTML URIs. For this matching process, ignore BASE specifications, such as the BASE element in HTML. Note that this only applies for matching Content-Location headers, not for URL-s in the HTML document which are resolved through network look up at read time.
ツーステッププロセス。 まず最初に、セクション4.4で説明されるように導入されたかもしれない相対的なURIからのどんなLWSPも取り外します。 そして、HTML URIに対して正確な原文のマッチを実行してください。 このマッチング過程には、HTMLにおける基地の要素などの基地の仕様を無視してください。 これが決議されているHTMLドキュメントのURL sのために申し込むのではなく、合っているContent-位置のヘッダーのために申し込むだけであるネットワークが見上げる注意は時間を読みました。
The URI in the Content-Location header need not refer to an object which is actually available globally 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の解決の後の)を使用することでContent-位置のヘッダーのURIは検索について実際にグローバルに利用可能なオブジェクトについて言及する必要はありません。 しかしながら、Content位置のヘッダー(絶対である、または絶対URIに溶解性であるなら)SHOULDのURI sはまだグローバルにそうです。ユニーク。
8.3 Use of the Content-ID header and CID URLs
8.3 コンテントIDヘッダーとCID URLの使用
When CID (Content-ID) URLs as defined in RFC 1738 [URL] and RFC 1873 [MIDCID] are used for links between body parts, the Content-Location statement will normally be replaced by a Content-ID header. Thus, the following two headers are identical in meaning:
身体の部分の間のリンクにRFC1738[URL]とRFC1873[MIDCID]で定義されるCID(コンテントID)URLを使用するとき、通常、Content-位置の声明をコンテントIDヘッダーに取り替えるでしょう。 したがって、以下の2個のヘッダーは意味が同じです:
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 this message or within this multipart/related.
以下に注意してください。 コンテントIDはグローバルにユニークでなければなりません[MIME1]。 それは、それらをこのメッセージだけの中でユニークにすることはこのようにして許可されていないか、またはこの複合/の中で話されます。
9 Examples
9つの例
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 is not an aggregate HTML object, but simply a message with a single HTML body part. This message contains a hyperlink but does not provide the ability to resolve the hyperlink. To resolve the hyperlink the receiving client would need either IP access to the Internet, or an electronic mail web gateway.
最初の例はHTMLメールメッセージの最も簡単なフォームです。 これは集合HTMLオブジェクトではなく、単にただ一つのHTML身体の部分があるメッセージです。 このメッセージは、ハイパーリンクを含んでいますが、ハイパーリンクを決議する能力を提供しません。 ハイパーリンクを決議するために、受信クライアントはインターネットへのIPアクセスか電子メールウェブゲートウェイのどちらかを必要とするでしょう。
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: Text/HTML; charset=US-ASCII
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: テキスト/HTML。 charsetは米国-ASCIIと等しいです。
Palme & Hopmann Standards Track [Page 12] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[12ページ]。
<HTML>
<head></head>
<body>
<h1>Hi there!</h1>
An example of an HTML message.<p>
Try clicking <a href="http://www.resnova.com/">here.</a><p>
</body></HTML>
<HTML><はそこに></ヘッド><ボディー><h1>Hiの上に立ちます。HTMLメッセージに関する</h1>Anの例、<aをクリックする<p>Tryが=をhrefする、「 http://www.resnova.com/ 、「>、ここで. </a><p></が></HTML>を具体化させる、」
9.2 Example with absolute URIs to an embedded GIF picture
9.2 埋め込まれたGIF画像への絶対URIがある例
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; start=foo3*foo1@bar.net
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0コンテントタイプ: 複合か関連する。 境界の=「境界例の1インチ」。 =テキスト/HTMLをタイプしてください。 = foo3*foo1@bar.net を始動してください。
--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>。
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo">
… HTMLドキュメントの原本。(それは、例えば、他の身体の部分、以下などの声明を通してハイパーリンクを含むかもしれません)。 <IMG SRCが" http://www.ietf.cnri.reston.va.us/images/ietflogo.gif "ALT=と等しい、「IETFロゴ">"
--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など。
--boundary-example-1--
--境界例1--
9.3 Example with relative URIs to an embedded GIF picture
9.3 埋め込まれたGIF画像への相対的なURIがある例
From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Base: http://www.ietf.cnri.reston.va.us
Content-Type: Multipart/related; boundary="boundary-example-1";
type=Text/HTML
From: foo1@bar.net To: foo2@bar.net Subject: 簡単な例のMime-バージョン: 1.0の満足している基地: http://www.ietf.cnri.reston.va.us コンテントタイプ: 複合か関連する。 境界の=「境界例の1インチ」。 =テキスト/HTMLをタイプしてください。
Palme & Hopmann Standards Track [Page 13] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[13ページ]。
--boundary-example-1
Content-Type: Text/HTML; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
--境界例1のコンテントタイプ: テキスト/HTML。 charset=ISO-8859-1の満足している転送コード化: 引用されて印刷可能です。
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="/images/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ドキュメントの原本。(それは、例えば、他の身体の部分、以下などの声明を通してハイパーリンクを含むかもしれません)。 <IMG SRCが"/images/ietflogo.gif"ALT=と等しい、「IETFロゴ、「Quoted印刷可能でコード化された著作権サインの>Example:」 =著作権サインのA9 Exampleはマーク付けをHTMLに写像しました: ¨
--boundary-example-1
Content-Location: /images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例1のContent-位置: /images/ietflogo.gifコンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example-1--
--境界例1--
9.4 Example using CID URL and Content-ID header to an embedded GIF picture
9.4 埋め込まれた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-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
--境界例1のコンテントタイプ: テキスト/HTML。 charsetは米国-ASCIIと等しいです。
... text of the HTML document, which might contain a hyperlink
to the other body part, for example through a statement such as:
<IMG SRC="cid:foo4*foo1@bar.net" ALT="IETF logo">
… HTMLドキュメントの原本。(それは、例えば、他の身体の部分、以下などの声明を通してハイパーリンクを含むかもしれません)。 <IMG SRCが「Cid: foo4*foo1@bar.net 」ALT=と等しい、「IETFロゴ">"
--boundary-example-1
Content-ID: <foo4*foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64
--境界例1のコンテントID: <foo4*foo1@bar.net>コンテントタイプ: GIFの満足している転送イメージ/コード化: BASE64
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...
R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4Aなど。
--boundary-example-1--
--境界例1--
Palme & Hopmann Standards Track [Page 14] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[14ページ]。
10. Content-Disposition header
10. 満足している気質ヘッダー
Note the specification in [REL] on the relations between Content- Disposition and multipart/related.
Content気質と複合/との関係での[REL]の仕様が関係したことに注意してください。
11. Character encoding issues and end-of-line issues
11. 文字符号化問題と行末問題
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.
- SGML[SGML]のアプリケーションとしてのHTML[HTML2、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
[MIME-IMB section 4.2].
- MIME「コンテントタイプテキスト」の他のドキュメントと共用して、MIMEでいくつかの文字符号化の1つを使用することでHTMLドキュメントを表すことができます。 MIMEコンテントタイプ"charset"パラメタ価値は、特定のコード化が使用したのを示します。 "charset"パラメタの正確な意味と使用に関しては、[MIME-IMB部4.2]を見てください。
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 via e-mail. Receiving mail user agents (together with any Web browser they may use to display the document) MUST be capable of handling any combinations of these mechanisms.
上のメカニズムは、よく定義されて、記録されて、したがって、ここでさらに説明されません。 メッセージを送る際に、上記のすべてのメカニズムが使用されるかもしれません、そして、メールでドキュメントを送るとき、それらのどんな混合物も現れるかもしれません。 メールユーザエージェント(彼らがドキュメントを表示するのに使用するどんなウェブブラウザに伴うも)を受けると、これらのメカニズムのどんな組み合わせも扱うことができなければなりません。
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 [MIME1] requires that documents of "Content-Type:
Text MUST be in canonical form before Content-Transfer-Encoding,
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規格[MIME1]がその書類を必要とする、「コンテントタイプ:」 テキストは以前、標準形では、Contentがコード化を移して、すなわち、ラインブレイクがむき出しのCRs、むき出しのLFsまたは他の何かとしてコード化されるのではなく、CRLFsとしてコード化されるということであるに違いありません。 これはセクション3.6.1がラインブレイクの他の表現を許容するところに[HTTP]と対照的になっています。
Palme & Hopmann Standards Track [Page 15] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[15ページ]。
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 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 charsets 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としてラインブレイクを表すことができないcharsetsです。 あいさつがあるHTTPとMIMEの違いの良い概要、「コンテントタイプ:」 [HTTP]、付録Cで「テキスト」を見つけることができます。
If the original document has line breaks in the canonical form (CRLF), then the document SHOULD remain unconverted so that integrity check sums are not invalidated.
正本が標準形(CRLF)にラインブレイクを持っているならドキュメントSHOULDが非変換されたままで残っているので、保全チェックサムは無効にされません。
A provider of HTML documents who wants his documents to be transferable via both HTTP and SMTP without invalidating checksum integrity checks, should always provide original documents in the canonical form with CRLF for line breaks.
HTMLのプロバイダーは、だれが、彼のドキュメントにチェックサム保全チェックを無効にすることのないHTTPとSMTPの両方を通して移転可能であって欲しいかを記録します、とラインブレイクのためのCRLFがある標準形の正本はいつも前提とするはずです。
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 mail, the charset parameter SHOULD be included, rather than relying on the default.
[HTTP、MIME1]をなにもに供給しないなら、いくつかの移送機構がデフォルト"charset"パラメタを指定するかもしれません。 デフォルトを当てにするよりむしろ含まれていて、デフォルトが異なったメカニズム、メール、charsetパラメタSHOULDを通してHTMLを移す時異なるので。
12. Security Considerations
12. セキュリティ問題
Some Security Considerations include the potential to mail someone an object, and claim that it is represented by a particular URI (by giving it a Content-Location header). There can be no assurance that a WWW request for that same URI would normally result in that same object. It might be unsuitable to cache the data in such a way that the cached data can be used for retrieval of this URI from other messages or message parts than those included in the same message as the Content-Location header. Because of this problem, receiving User Agents SHOULD not cache this data in the same way that data that was retrieved through an HTTP or FTP request might be cached.
いくつかのSecurity Considerationsが、オブジェクトをだれかに郵送する可能性を含んで、それが特定のURIによって表されると主張します(Content-位置のヘッダーをそれに与えることによって)。 通常、その同じURIを求めるWWW要求がその同じオブジェクトをもたらすだろうという保証が全くあるはずがありません。 Content-位置のヘッダーのようなこのURIの検索に同じメッセージにそれらを含んでいること以外のメッセージかメッセージの部品からキャッシュされたデータを使用できる方法でデータをキャッシュするのは不適当であるかもしれません。 この問題のために、受信UserエージェントSHOULDはHTTPかFTPを通して検索されたデータがキャッシュされるかもしれないよう要求する同じようにこのデータをキャッシュしません。
URLs, especially File URLs, may in their name contain company- internal information, which may then inadvertently be revealed to recipients of documents containing such URLs.
URL(特にFile URL)はそれらの名前に会社の内部の情報を含むかもしれません。(次に、それは、うっかりそのようなURLを含むドキュメントの受取人に明らかにされるかもしれません)。
One way of implementing messages with linked body parts is to handle the linked body parts in a combined mail and WWW proxy server. The mail client is only given the start body part, which it passes to a web browser. This web browser requests the linked parts from the
繋がっている身体の部分でメッセージを実装する1つの方法は結合したメールとWWWプロキシサーバで繋がっている身体の部分を扱うことです。スタート身体の部分をメールクライアントに与えるだけです。(それはウェブブラウザにそれを渡します)。 このウェブブラウザは繋がっている部分を要求します。
Palme & Hopmann Standards Track [Page 16] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[16ページ]。
proxy server. If this method is used, and if the combined server is used by more than one user, then methods must be employed to ensure that body parts of a message to one person is not retrievable by another person. Use of passwords (also known as tickets or magic cookies) is one way of achieving this. Note that some caching WWW proxy servers may not distinguish between cached objects from e-mail and HTTP, which may be a security risk.
プロキシサーバこのメソッドが使用されていて、結合したサーバが1人以上のユーザによって使用されるなら、1人の人へのメッセージの身体の部分が確実に別の人が回収可能にならないようにするのにメソッドを使わなければなりません。 パスワード(また、チケットか魔法のクッキーとして、知られている)の使用はこれを達成することにおいて一方通行です。 WWWプロキシサーバがそうするいくつかのキャッシュがメールとHTTPとキャッシュされたオブジェクトを見分けないことに注意してください。(HTTPはセキュリティリスクであるかもしれません)。
In addition, by allowing people to mail aggregate objects, we are opening the door to other potential security problems that until now were only problems for WWW users. For example, some HTML documents now either themselves contain executable content (JavaScript) or contain links to executable content (The "INSERT" specification, Java). It would be exceedingly dangerous for a receiving User Agent to execute content received through a mail message without careful attention to restrictions on the capabilities of that executable content.
さらに、人々が集団オブジェクトを郵送するのを許容することによって、私たちはWWWユーザに現在まで問題であるにすぎなかった他の潜在的警備上の問題へのドアを開けています。 例えば、何らかのHTMLが現在、自分たちを記録します。実行可能な内容(JavaScript)を含むか、または実行可能な内容(「差し込み」仕様、Java)へのリンクを含んでください。 受信Userエージェントがその実行可能な内容の能力で制限に関する慎重な注意なしでメール・メッセージを通して受け取られた内容を実行するのは、きわめて危険でしょう。
Some WWW applications hide passwords and tickets (access tokens to information which may not be available to anyone) and other sensitive information in hidden fields in the web documents or in on-the-fly constructed URLs. If a person gets such a document, and forwards it via e-mail, the person may inadvertently disclose sensitive information.
いくつかのWWWアプリケーションがパスワードとチケット(だれにはも、利用可能でないかもしれない情報へのアクセストークン)を隠します、そして、ウェブドキュメントかハエの上のコネにおける隠された分野の他の機密情報はURLを構成しました。 人がそのようなドキュメントを手に入れて、メールでそれを進めるなら、人はうっかり機密情報を明らかにするかもしれません。
13. Acknowledgments
13. 承認
Harald T. Alvestrand, Richard Baker, Dave Crocker, Martin J. Duerst, Lewis Geer, Roy Fielding, Al Gilman, Paul Hoffman, Richard W. Jesmajian, Mark K. Joseph, Greg Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve Zilles and several other people have helped us with preparing this document. I 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、キース・ムーア、ギャヴィン・ニコル、ピートレズニック、ジョンSmirl、Einar Stefferud、ジェイミーZawinski、スティーブZilles、および数人の他の人々がこのドキュメントを準備するのに私たちを助けました。 私だけがドキュメントにまだあるどんな誤りへの責任も取ります。
Palme & Hopmann Standards Track [Page 17] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[17ページ]。
14. References
14. 参照
Ref. Author, title --------- --------------------------------------------------------
審判。 作者、タイトル--------- --------------------------------------------------------
[CONDISP] R. Troost, S. Dorner: "Communicating Presentation
Information in Internet Messages: The
Content-Disposition Header", RFC 1806, June 1995.
[CONDISP] R.Troost、S.デルナー: 「インターネットメッセージのプレゼンテーション情報を伝えます:」 「満足している気質ヘッダー」、RFC1806、1995年6月。
[HOSTS] R. Braden (editor): "Requirements for Internet Hosts --
Application and Support", STD-3, RFC 1123, October 1989.
[ホスト]R.ブレーデン(エディタ): 「インターネットホストのための要件--、アプリケーションとサポート、」、STD-3、RFC1123、10月1989日
[HTML-I18N] F. Yergeau, G. Nicol, G. Adams, & M. Duerst:
"Internationalization of the Hypertext Markup
Language". RFC 2070, January 1997.
[HTML-I18N] F.Yergeau、G.ニコル、G.アダムス、およびM.Duerst: 「ハイパーテキストマークアップランゲージの国際化。」 1997年1月のRFC2070。
[HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language
- 2.0", RFC 1866, November 1995.
[HTML2] T.バーナーズ・リー、D.コノリー: 「2インチ、RFC1866、1995年ハイパーテキストマークアップランゲージ--11月。」
[HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.
[HTTP] T.バーナーズ・リー、R.フィールディング、H.Frystyk: ハイパーテキスト転送プロトコル--HTTP/1.0。 1996年5月のRFC1945。
[MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MD5]R.Rivest: 「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[MIDCID] E. Levinson: "Content-ID and Message-ID Uniform
Resource Locators". RFC 2111, February 1997.
[MIDCID]E.レヴィンソン: 「コンテントIDとMessage ID Uniform Resource Locator。」 1997年2月のRFC2111。
[MIME-IMB] N. Freed & N. Borenstein: "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bedies". RFC 2045, November 1996.
[MIME-IMB] 解放されたN.とN.Borenstein: 「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」 「インターネットメッセージBediesの形式。」 1996年11月のRFC2045。
[MIME1] N. Borenstein & N. Freed: "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1521, Sept 1993.
[MIME1]N.BorensteinとN.は解放しました: 「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、1993年9月。
[MIME2] N. Borenstein & N. Freed: "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types". RFC 2046,
November 1996.
[MIME2]N.BorensteinとN.は解放しました: 「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」 「メディアタイプ。」 1996年11月のRFC2046。
[NEWS] M.R. Horton, R. Adams: "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[ニュース] M.R.ホートン、R.アダムス: 「USENETメッセージの置き換えの規格」、RFC1036、1987年12月。
Palme & Hopmann Standards Track [Page 18] RFC 2110 MHTML March 1997
パルメとHopmann規格は1997年のMHTML行進のときにRFC2110を追跡します[18ページ]。
[PDF] Bienz, T., Cohn, R. and Meehan, J.: "Portable Document
Format Reference Manual, Version 1.1", Adboe Systems
Inc.
[PDF] BienzとT.とコーンとR.とミーハン、J.: 「Portable Document Formatリファレンスマニュアル、バージョン1.1インチ、AdboeシステムInc.」
[REL] Edward Levinson: "The MIME Multipart/Related Content-
Type". RFC 2112, February 1997.
[REL]エドワード・レヴィンソン: 「MIMEの複合の、または、関連の満足しているタイプ。」 1997年2月のRFC2112。
[RELURL] R. Fielding: "Relative Uniform Resource Locators", RFC
1808, June 1995.
[RELURL]R.フィールディング: 「相対的なUniform Resource Locator」、RFC1808、1995年6月。
[RFC822] D. Crocker: "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] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
[SMTP]J.ポステル: 「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[URL] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[URL]T. バーナーズ・リー、L.Masinter、M.McCahill: 「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME
External-Body Access-Type", RFC 2017, October 1996.
解放された[URLBODY]N.とキース・ムーア: 「URL MIME外部のボディーアクセス型の定義」、RFC2017、1996年10月。
15. Author's Address
15. 作者のアドレス
For contacting the editors, preferably write to Jacob Palme rather than Alex Hopmann.
望ましくは、エディタに連絡するには、アレックスHopmannよりむしろヤコブ・パルメに書いてください。
Jacob Palme Phone: +46-8-16 16 67 Stockholm University and KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden
ヤコブパルメPhone: +46-8-16 16 67のストックホルム大学とKTH Fax: +46-8-783 08 29琥珀金230メール: Kista、 jpalme@dsv.su.se S-164 40スウェーデン
Alex Hopmann E-mail: alexhop@microsoft.com Microsoft Corporation 3590 North First Street Suite 300 San Jose CA 95134 Working group chairman:
アレックスHopmannはメールします: alexhop@microsoft.com マイクロソフト社3590北部First通りSuite300サンノゼカリフォルニア95134Workingグループ議長:
Einar Stefferud <stef@nma.com>
Einar Stefferud <stef@nma.com 、gt。
Palme & Hopmann Standards Track [Page 19]
パルメとHopmann標準化過程[19ページ]
一覧
スポンサーリンク
