index prev

8. Usage of Links to Other Body Parts
　他のボディ部分へのリンクの用法

8.1 General principle
　一般原則

A body part, such as a text/html body part, may contain URIs that reference resources which are included as body parts in the same message -- in detail, as body parts within the same multipart/related structure. Often such URI linked resources are meant to be displayed inline to the viewer of the referencing body part; for example, objects referenced with the SRC attribute of the IMG element in HTML 2.0 [HTML2]. New elements and attributes with this property are proposed in the ongoing development of HTML (examples: applet, frame, profile, OBJECT, classid, codebase, data, SCRIPT). A sender might also want to send a set of HTML documents which the reader can traverse, and which are related with the attribute href of the A element.

text/html bodyの部分などのbodyの部分はbodyの部分として同じメッセージに詳細に含まれているリソースに参照をつけるURIを含むかもしれません、同じくらい中のbodyの部分がmultipart/related構造を、または関係づけたので。 しばしば、そのようなURI繋がっているリソースは参照をつけたbodyの部分のビューアーへの表示されたインラインであることが意味されます; 例えば、オブジェクトはHTML2.0[HTML2]における、IMG要素のSRC属性で参照をつけました。 この特性がある新しい要素と属性は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.

ユーザがtext/htmlリソース、およびそれが参照をつける補助のリソースから形成されたウェブページを検索して、表示して、単にtext/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.

完全なそのようなメッセージを送るか、または保存するために、あるbodyの部分のURIが別の身体の部分でどうリソースに参照をつけることができるかを指定する必要があります。

8.2 Resolution of URIs in text/html body parts
　text/htmlボディ部分のURIの解読

The resolution of inline, retrieval and other kinds of URIs in text/html body parts is performed in the following way:

text/html bodyの部分でのインライン、検索、および他の種類のURIの解決は以下の方法で実行されます。

  1. 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".

    URLBODYに従って、複数の系列ヘッダー値を繰り広げてください。 しかしながら、URLで説明された種類の文字符号化を翻訳しません。 例:「a%2eb/c%20d」を「a/b/c d」に変えないでください。

  2. Remove all MIME encodings, such as content-transfer encoding and header encodings as defined in MIME part 3 [MIME3] Do NOT however translate character encodings of the kind described in [URL]. Example: Do not transform "a%2eb/c%20d" into "a/b/c d".

    すべてのMIME encodingsを取り外してください、しかしながら、満足している転送コード化とMIMEパート3[MIME3]で定義されるヘッダーencodingsがURLで説明された種類の文字符号化を翻訳しないようなもの。 例: 「a%2eb/c%20d」を「a/b/c d」に変えないでください。

  3. Try to resolve all relative URIs in the HTML content and in Content-Location headers using the procedure described in chapter 5 above. The result of this resolution can be an absolute URI, or an absolute URI with the base "thismessage:/" as specified in chapter 5.

    上の第5章で説明された手順を用いることでHTML内容とContent-Locationのヘッダーのすべての相対的なURIを決議するようにしてください。この解決の結果は絶対URIであるかもしれません、またはベースがある絶対URIが第5章で指定される「thismessage:/」です。

  4. For each referencing URI in a text/html body part, compare the value of the referencing URI after resolution as described in (a) and (b), with the URI derived from Content-ID and Content-Location headers for other body parts within the same or a surrounding Multipart/related structure. If the strings are identical, octet by octet, then the referencing URI references that body part. This comparison will only succeed if the two URIs are identical. This means that if one of the two URIs to be compared was a fictitious absolute URI with the base "thismessage:/", the other must also be such a fictitious absolute URI, and not resolvable to a real absolute URI.

    text/html bodyの部分でそれぞれURIに参照をつけるには、同じくらい中の他の身体の部分か周囲のMultipart/related構造に得られたURIで、コンテントIDとContent-Locationのヘッダーから、解決の後に(a)と(b)で説明されるように参照箇所URIの値を比較してください。ストリングが同じであるなら、八進数による八進数、そして、ボディーが離れさせる参照をつけたURI参照します。2つのURIが同じである場合にだけ、この比較は成功するでしょう。また、比較されているのが、「thismessage:/」、他がそうしなければならないベースがある架空の絶対URIであったということである2つのURIの1つもそのような架空の絶対URIであって、全く絶対のURIに溶解性でないなら、これはそれを意味します。

  5. If (d) fails, try to retrieve the URI referenced resource hyperlink through ordinary Internet lookup. Resolution of URIs of the URL-types "mid" or "cid" to other content-parts, outside the same multipart/related structure, or in other separately sent messages, is not covered by this standard, and is thus neither encouraged nor forbidden.

    (d)が失敗するなら、普通のインターネットルックアップを通してURIの参照をつけられたリソースハイパーリンクを検索するようにしてください。 同じmultipart/related構造の外、または、他の満足している部分か、他の別々に送られたメッセージにおける、「中間URLタイプ」か「Cid」のURIの解決は、この規格でカバーされていなくて、このようにしてどちらも奨励されないで、禁じられます。

8.3 Use of the Content-ID header and CID URLs
　CIDとContent-IDヘッダーの用法

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 multipart/related構造の参照他の身体の部分に使用されるとき、CIDがあるContent-Locationのヘッダーではなく、コンテントIDヘッダー値に取り組ませるだけでよいです: 値。 したがって、以下の2個のヘッダーは意味が同じですが、コンテントID値だけが合わせられるでしょう、そして、Content-位置の値は無視されるでしょう。 

Content-ID: <foo@bar.net>
Content-Location: CID: foo@bar.net

Note: Content-IDs MUST be globally unique [MIME1]. It is thus not permitted to make them unique only within a message or within a single multipart/related structure.

メモ:コンテントIDはグローバルにユニークなMIME1であるに違いありません。それでメッセージ以内かだけ単一のmultipart/related構造の中でユニークになるのはこのようにして許可されていません。

9. Examples
　例

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.

記法:例は構造を見せるインデントを含んでいますが、実在の事物にこのようにインデントを付けさせるべきではありません。

9.1 Example of a HTML body without included linked objects
　含まれたリンクされたオブジェクトのない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

<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 &Eacute;.<p>
Try clicking <a href="http://www.ietf.cnri.reston.va.us/">
here.</a><p>
</body></HTML>

9.2 Example with an absolute URI to an embedded GIF picture
　埋め込まれたGIF画像への絶対のURIを持つ例

The second example is an HTML message which includes a single image, referenced using the Content-Location mechanism.

2番目の例はContent-Locationのメカニズムを使用することで参照をつけられるただ一つのイメージを含んでいるHTMLメッセージです。 

From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example";
        type="text/html"; start="<foo3@foo1@bar.net>"

--boundary-example
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3@foo1@bar.net>

... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
 ALT="IETF logo">

--boundary-example
Content-Location:
   http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example--

9.3 Example with relative URIs to embedded GIF pictures
　埋め込まれた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.

この例の中では、送られるHTMLテキストで、一番はずれの見出しのContent-Locationのヘッダーフィールドはすべての相対的なURLへのベースになるでしょう。 

From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Location: http://www.ietf.cnri.reston.va.us/
Content-Type: multipart/related; boundary="boundary-example";
        type="text/html"

--boundary-example
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE

... text of the HTML document, which might contain URIs
referencing resources in other body parts, for example through
statements such as:

<IMG SRC="images/ietflogo1.gif" ALT="IETF logo1">
<IMG SRC="images/ietflogo2.gif" ALT="IETF logo2">
<IMG SRC="images/ietflogo3.gif" ALT="IETF logo3">

Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: &#168;

--boundary-example
Content-Location:
         http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif
; Note - Absolute Content-Location does not require a
; base
; 注意--絶対Content-位置はベースを必要としません。

Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example
Content-Location: images/ietflogo2.gif
; Note - Relative Content-Location is resolved by base
; specified in the Multipart/Related Content-Location heading
; 注意--相対的なContent-位置はMultipart/RelatedのContent-Locationの
; 見出しで指定されたベースによって決議されています。
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example
Content-Location:
         http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example--

9.4 Example with a relative URI and no BASE available
　BASEがなく入手可能な相対的な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"

--boundary-example
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: QUOTED-PRINTABLE

... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="ietflogo.gif" ALT="IETF logo">
Example of a copyright sign encoded with Quoted-Printable: =A9
Example of a copyright sign mapped onto HTML markup: &#168;

--boundary-example
Content-Location: ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example--

9.5 Example using CID URL and Content-ID header to an embedded GIF picture
　埋め込まれた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"

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

... text of the HTML document, which might contain a URI
referencing a resource in another body part, for example
through a statement such as:
<IMG SRC="cid:foo4@foo1@bar.net" ALT="IETF logo">

--boundary-example
Content-Location: CID:something@else ; this header is disregarded
Content-ID: <foo4@foo1@bar.net>
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example--

9.6 Example showing permitted and forbidden references between nested body parts
　ネスティングされたボディ部分の間で許されて、禁じられた参照を示している例

This example shows in which cases references are allowed between multiple multipart/related body parts in a message.

この例は、参照がメッセージの複数のmultipart/related bodyの部分の間でどの場合に許されているかを示します。 

From: foo1@bar.net
To: foo2@bar.net
Subject: A simple example
Mime-Version: 1.0
Content-Type: multipart/related; boundary="boundary-example-1";
          type="text/html"

--boundary-example-1
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo3@foo1@bar.net>

The image reference below will be resolved with the image
in the next body part.
<IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
ALT="IETF logo with white background">

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">

The anchor reference immediately below will be resolved with
the nested text/html body part below:
<A HREF="http://www.ietf.cnri.reston.va.us/more-info>
More info</A>

The anchor reference immediately below will be resolved with
the nested text/html body part below:
<A HREF="http://www.ietf.cnri.reston.va.us/even-more-info>
Even more info</A>

--boundary-example-1
Content-Location:
         http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
etc...

--boundary-example-1
Content-Location:
     http://www.ietf.cnri.reston.va.us/more-info
Content-Type: multipart/related; boundary="boundary-example-2";
           type="text/html"
--boundary-example-2
Content-Type: text/html;charset="US-ASCII"
Content-ID: <foo4@foo1@bar.net>

The image reference below will be resolved with the image
in the surrounding multipart/related above.
<IMG SRC="images/ietflogo.gif"
ALT="IETF logo with white background">

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">

--boundary-example-2
Content-Location: http:images/ietflogo2.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4
SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa
etc...

--boundary-example-2--
--boundary-example-1
Content-Location:
           http://www.ietf.cnri.reston.va.us/even-more-info
Content-Type: multipart/related; boundary="boundary-example-3";
           type="text/html"
--boundary-example-3
Content-Type: text/html;charset="US-ASCII"
Content-ID: <4@foo@bar.net>

The image reference below will be resolved with the image
inside the current nested multipart/related below.
<IMG SRC=images/ietflogo2d.gif"
ALT="IETF logo with shadows">

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">

--boundary-example-3
Content-Location: http:images/ietflogo2d.gif
Content-Type: IMAGE/GIF
Content-Transfer-Encoding: BASE64

R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz
c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v
etc...

--boundary-example-3--
--boundary-example-1--

10. Character encoding issues and end-of-line issues
　文字符号化問題と行末問題

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ドキュメントと他のテキストドキュメントにおける、キャラクタのコード化において、以下のメカニズムは関連しています:

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:

また、以下のことに注意してください。

Note that this might cause problems with integrity checks based on checksums, which might not be preserved when moving a document from the HTTP to the MIME environment. If a document has to be converted in such a way that a checksum based message integrity check becomes invalid, then this integrity check header SHOULD be removed from the document.

これがチェックサムに基づいた完全性チェックについての問題を起こすかもしれないことに注意してください(それは文書がHTTPからMIME環境に移動する時に保存されないかもしれません)。 文書が、チェックサムベースメッセージの完全性チェックが無効になるそのような方法で変換される必要があるならば、この完全性チェックヘッダーは文書から取り除かれるべきです。

Other sources of problems are Content-Encoding used in HTTP but not allowed in MIME, and character sets that are not able to represent line breaks as CRLF. A good overview of the differences between HTTP and MIME with regards to Content-Type: "text" can be found in [HTTP], appendix C.

他の問題の原因はHTTPの中で使われたけれどもMIMEの中で許されなかった内容エンコーディングであり、表すことができない文字セットはCRLFとして破壊に線を引きます。内部形式についてのHTTPとMIMEの違いのよい概要：「テキスト」は[HTTP]、付録C中で発見されることができます。

Some transport mechanisms may specify a default "charset" parameter if none is supplied [HTTP, MIME1]. Because the default differs for different mechanisms, when HTML is transferred through e-mail, the charset parameter SHOULD be included, rather than relying on the default.

いくつかがメカニズムを輸送します デフォルトを指定できる 「charset」パラメータ 誰も、供給された[HTTP、MIME1]ではありません。HTMLが電子メールを通して転送される時に、デフォルトが違うメカニズムのために異なるので、charsetパラメータはデフォルトを信頼しているというよりも含まれるべきです。

11. Security Considerations
　セキュリティ考慮

11.1 Security considerations not related to caching
　キャッシュすることと関連しなかったセキュリティ考慮

It is possible for a message sender to misrepresent the source of a multipart/related body part to a message recipient by labeling it with a Content-Location URI that references another resource. Therefore, message recipients should only interpret Content-Location URIs as labeling a body part for the resolution of references from body parts in the same multipart/related message structure, and not as the source of a resource, unless this can be verified by other means.

別の資源を参照する内容位置URIによってそれにラベルを貼ることによってメッセージ送信側がメッセージ受領者へのmultipart/relatedボディ部分のソースを誤り伝えることは可能です。従って、これが他の方法によって確認されることができない限り、メッセージ受領者は、内容位置URIを、資源のソースとではなく、同じmultipart/relatedメッセージ構造の中のボディ部分から参照の解像度のためにボディ部分にラベルを貼ることと解釈するだけであるべきであります。

URIs, especially File URIs, if used without change in a message, may inadvertently reveal information that was not intended to be revealed outside a particular security context. Message senders should take care when constructing messages containing the new header fields, defined in this standard, that they are not revealing information outside of any security contexts to which they belong.

URI、特にファイル URIsは、メッセージの変化なしで使われるならば、不注意に、特定のセキュリティ文脈の外で明らかにされることを意図していなかった情報を明らかにするかもしれません。彼らが、彼らが所属しているどのようなセキュリティ文脈の外でも情報を明らかにしていないというこの標準の中で定義された新しいヘッダーフィールドを含んでいるメッセージを構成する時に、メッセージ送信側は注意するべきです。

Some resource servers hide passwords and tickets (access tokens to information which should not be reveled to others) and other sensitive information in non-visible fields or URIs within a text/html resource. If such a text/html resource is forwarded in an email message, this sensitive information may be inadvertently revealed to others.

いくつかの資源サーバーは、パスワードと切符(他に明らかにされるべきでない情報へのアクセストークン)とtext/html資源の中の非可視フィールドまたはURIの他の機密情報を隠します。そのようなtext/html資源がEメールメッセージの中で転送されるならば、この機密情報は他に不注意に明らかにされるかもしれません。

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における「INSERT」指定)を参照することができるので。受け取っているユーザーエージェントがその実行可能な内容の機能における制限への慎重な注意なしでメールメッセージの中で受け取られた内容を実行することは非常に危険です。

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
　キャッシュすることと関連したセキュリティ考慮

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.

直接取り戻されたウェブ資源のキャッシュについての有名な問題があります。キャッシュから取り戻された資源はそのソースから再び取り出されたそれと異なるかもしれません。この問題(資源のコピーがmultipart/related構造の中に送られる積荷目録自身)も。

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.

テキスト/htmlを処理する(表現)時に、MHTML multipart/related構造の中の部分(同じmultipart/related構造の中の参照子会社資源がどのような別のローカルな、または遠い源泉からでも資源によってではなくそれらの資源によって満たされていることとするそのtext/htmlボディ部分のすべてのURI)を具体化してください。

Therefore, if a sender wishes a recipient to always retrieve an URI referenced resource from its source, an URI labeled copy of that resource MUST NOT be included in the same multipart/related structure.

従って、送信側が、いつもURIを取り出す受領者がそのソースから資源を参照するのを願うならば、その資源のコピーというラベルを貼られたURIは同じmultipart/related構造に含められていてはなりません。

In addition, since the source of a resource received in a multipart/related structure can be misrepresented (see 11.1 above), if a resource received in multipart/related structure is stored in a cache, it MUST NOT be retrieved from that cache other than by a reference contained in a body part of the same multipart/related structure. Failure to honor this directive will allow a multipart/related structure to be employed as a Trojan Horse. For example, to inject bogus resources (i.e. a misrepresentation of a competitor's Web site) into a recipient's generally accessible Web cache.

さらに、multipart/related構造の中で受け取られた資源がキャッシュの中に蓄えられるならば、multipart/related構造の中で受け取られた資源のソースが、説明を誤る(11.1の上記を見てください)ことができるので、それは同じmultipart/related構造のボディ一部の中に含まれている参照による以外そのキャッシュから取り戻されてはなりません。この指令を尊重する失敗は、multipart/related構造がトロイの木馬として利用されることを可能にするでしょう。例えばにせの資源(すなわち競争相手のウェブサイトの誤伝)を受領者の一般にアクセス可能なWebキャッシュに注入するため。

12. Differences as compared to the previous version of this proposed standard in RFC 2110
　RFC 2110でこの提案された規格の旧バージョンと比較される違い

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.

仕様書は、説明されたフォーマットが、Eメールの中の複数パートMIMEにだけでなくMIMEがHTTPまたはFTPなどの他のプロトコルを通して転送した複数パートにもあてはまることを示すために交換されています。

In order to agree with [RELURL], Content-Location headers in multipart Content-Headings can now be used as a base to resolve relative URIs in their component parts, but only if no base URI can be derived from the component part itself. Base URIs in Content-Location header fields in inner headings have precedence over base URIs in outer multipart headings.

[RELURL]と合致するために、複数パート内容表題の中の内容位置ヘッダーは、現在、どの基本のURIも構成部品自身から引き出されることができないならばそれらの構成部品で相対的なURIを解決するためにベースとして使われることができます。内側の表題の中の内容位置ヘッダーフィールドの基本URIは外の複数パート表題の中に基本のURIへの優位を持っています。

The Content-Base header, which was present in RFC 2110, has been removed. A conservative implementor may choose to accept this header in input for compatibility with implementations of RFC 2110, but MUST never send any Content-Base header, since this header is not any more a part of this standard.

RFC 2110に存在した内容ベースヘッダーは取り除かれています。保守的な作成者は、RFC 2110のインプリメンテーションとの互換性としてインプットにおけるこのヘッダーを認めることに決めることができるけれども、このヘッダーがこの標準のより以上の一部ではないので、決してどのような内容ベースヘッダーも送ってはなりません。

A section 4.4.1 has been added, specifying how to handle the case of sending a body part whose URI does not agree with the correct URI syntax.

セクション4.4.1は、どのように、URIが正しいURIシンタックスと合致していないボディ部分を送るケースを処理するかを指定して、追加されています。

The handling of relative and absolute URIs for matching between body parts have been merged into a single description, by specifying that relative URIs, which cannot be resolved otherwise, should be handled as if they had been given the URL "thismessage:/".

親族の取り扱いとボディ部分の間でマッチするための絶対のURIは、それらがURL「thismessage:/」を与えられたかのように、違った形で決定されることができない相対的なURIが処理されるべきであると指定することによって1つの説明の中に合併されています。

13. Acknowledgments
　謝辞

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.

上記の人々は、この文書を準備することについて私達を援助しました。私達だけが、まだ文書の中にあるかもしれないどのようなエラーについての責任でも取ります。

14. References
　参考文献

15. Authors' Addresses
　奥付

For contacting the editors, preferably write to Jacob Palme.

著者に連絡するために、好ましくは、Jacob Palmeに手紙を書いてください。

Jacob Palme
Stockholm University and KTH
Electrum 230
S-164 40 Kista, Sweden

Phone: +46-8-16 16 67
Fax: +46-8-783 08 29
EMail: jpalme@dsv.su.se
Alex Hopmann
Microsoft Corporation
One Microsoft Way
Redmond WA 98052

Phone: +1-425-703-8238
EMail: alexhop@microsoft.com
Nick Shelness
Lotus Development Corporation
55 Cambridge Parkway
Cambridge MA 02142-1295

EMail: Shelness@lotus.com

Working group chairman:

ワーキンググループ会長：

Einar Stefferud
EMail: stef@nma.com

16. Full Copyright Statement
　著作権について

Copyright (C) The Internet Society (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.

この文書およびその翻訳は他のものおよび派生的な工場にコピーされ供給されるかもしれません、そのコメント、の上で、あるいはそうでなければそれについて説明するか、そのインプリメンテーションを助ける、もし上記の著作権通知およびこのパラグラフがすべてのそのようなコピーおよび派生的な工場に含まれていれば、どんな種類の制限なしでも、全体の中で、あるいは一部が、準備されており、コピーされるかもしれないし、公表されるかもしれないし、分配されるかもしれない。しかしながら、この文書はそれ自身著作権のある通知あるいはインターネット学会あるいは他のインターネット組織への言及の削除によってのように任意の方法で修正されないかもしれません、以外は、求められるような、インターネット基準を開発する目的で、その場合には、インターネット基準プロセスの中で定義された著作権のための手続きに続くに違いありません、あるいは求められるような、それを英語以外の言語に翻訳するために

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.

ここに含まれていたこの文書および情報は、「AS IS」方式およびTHE INTERNET SOCIETY AND THE INTERNET ENGINEERINGで提供されます。特別対策本部は保証、急行をすべて放棄するか、あるいは含めて意味しましたしかしない、株式会社、任意の保証に、それ、情報の使用 ここに、権利あるいは市場性あるいは特別の目的に対する適格性のどんな暗黙の保証も侵害しないでしょう。

top page

RFCの部屋

index

インターネットメールに関して

MIMEに関して

文字に関して

アルゴリズム

フォーマット