This document "RFC-J 2110" was translated by Shige into Japanese (S-JIS). This is NOT official document but private memo. ---------------------------------------------------------------------- Network Working Group J. Palme Request for Comments: 2110 Stockholm University/KTH Category: Standards Track A. Hopmann Microsoft Corporation March 1997 HTML のような集合体的文書における MIME E-mail カプセル化（MHTML） このメモの位置づけ 　　この文書はインターネット・コミュニティーのためのインターネット標準 　運用プロトコルを定義し、改良のための議論と提案を要求している。標準化 　の様子や状況については最新の "Internet Official Protocol Standards" 　(STD 1) を参照すること。このメモの配布は無制限である。 要約 　　HTML [RFC 1866] は MIME の背景を含めて設計されているが、電子メール 　のユーザー・エージェントが文書形式として HTML を扱えるようにするには、 　RFC 1866 の中で定義されている HTML の仕様以上のものが要求される。これ 　らの問題は大抵は URI によって参照されるというオブジェクトの命名法を含 　んでおり、オブジェクトの集合化の方法と両立する。この文書は対応したメー 　ル・ユーザー・エージェントが、HTML のような、これらのオブジェクトを送 　信・配達・表示できるようにするガイドラインと、URI で表されるリンクを 　含めることが出来るようにするためのガイドラインのセットである。内部リ 　ンクされたオブジェクトを扱えるようにするために、その文書はMIMEタイプ 　multipart/related を使用し、MIMEコンテント・ヘッダで "Content-Location" 　と "Content-Base" を指定する。 目次 1. 序論 2. 用語 2.1 適合要求に関する用語 2.2 その他の用語 3. 概観 4. Content-Location 及び Content-Base MIME コンテント・ヘッダ 4.1 MIME コンテント・ヘッダ 4.2 Content-Base ヘッダ 4.3 Content-Location ヘッダ 4.4 電子メールのヘッダ内での URI のエンコーディング 5. 相対 URI の解決のための 基本 URI 6. リンクされたオブジェクトを含まない文書の送信 7. Content-Type: Multipart/related の使用 8. 他のボディ部分へのリンクの書式 8.1 一般規則 8.2 Content-Location ヘッダの使用 8.3 Content-ID ヘッダと CID URL の使用 9. 例 9.1 リンクされたオブジェクトを含まないHTMLボディの例 9.2 埋め込まれたGIF画像への絶対URIの例 9.3 埋め込まれたGIF画像への相対URIの例 9.4 埋め込まれたGIF画像への CID URL と Content-ID ヘッダの使用例 10. Content-Disposition ヘッダ 11. 文字のエンコードの問題と行末の問題 12. セキュリティの考慮 13. 謝辞 14. 参考文献 15. 著者の住所 メーリングリスト情報 　　この文書についてのさらなる議論はメーリングリスト 　MHTML@SEGATE.SUNET.SE を通して行われるべきである。 　　このメーリングリストに加入するには、 LISTSERV@SEGATE.SUNET.SE 　に次のような文を含むメールを送信すること。 SUB MHTML 　　このメーリングリストのアーカイブは FTP://SEGATE.SUNET.SE/lists/mHTML/ 　から Anonymous-FTP で入手できる。 　このアーカイブは電子メールでも入手できる。 LISTSERV@SEGATE.SUNET.SE 　に "INDEX MHTML" というメールを送信すればアーカイブファイルの一覧が入 　手できるし、"GET " という新たなメールを送信すればアーカイ 　ブ・ファイルを受け取れる。 　　重要でない論評は著者に送信することも出来る。 Jacob Palme . 　　さらなる情報は次のURLで得られる。 HTTP://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.HTML 1. 序論 　　URI を使用したリンクを与える文書形式には、例えば HTML [HTML2] や 　PDF [PDF] や VRML など数多く存在する。これらの形式の文書を電子メール 　[RFC821=SMTP, RFC822] で送信できることは明らかに必要である。この文書 　は MIME [RFC1521=MIME1] の電子メールでそれらの文書を送信するための付 　加的な仕様を与える。このバージョンのこの標準は、（RFC 1866 [HTML2] の 　中で定義されている）Text/HTML メディア・タイプのリンクを含むオブジェ 　クトにとっての必要性だけの考慮に基づいていた。しかしこの標準は URI で 　リンクされた内部リンクのオブジェクトのセットに対しても適用することが 　出来る。この標準が HTML 以外の文書形式の中の URI を扱えるようにするた 　めに実装を適応させるような要求は無い。 　　HTML文書のURIや他の類似の形式のオブジェクトやリソースの参照は、添付 　されることもハイパーテキスト・リンクを通して直接入手可能にすることの 　両方がある。このようなドキュメントが送られる時、その中で参照している 　全ての付加的なリソースもまた送られることが強く望まれる、すなわち初め 　のオブジェクトの完全な解釈にこれらの要素が必要な場合、がよくある。 　　URIを含むHTML文書や他のオブジェクトを電子メールで送る代わりの方法と 　してURLだけを送り、受信者が HTTP で文書を見つけられるようにするという 　ものがある。その方法は [URLBODY] の中で述べられており、この文書ではそ 　れについては述べない。 　　近いうちに informational RFC がこの標準の補足として発表されるであろ 　う。informatinal RFC では実装方法や実装上の問題について議論されるであ 　ろう。実装者には標準MHTMLを実装するアプリケーションを開発する時にこの 　informational RFC を読むことを勧める。このRFCが発表される時にはこの 　informational RFC はまだ IETF ドラフトの状態であり、発表前にさらなる 　実装経験を得るために少なくとも6ヶ月はかかるであろう。 2. 用語 2.1 適合要求に関する用語 　　この仕様書では特定の要求の重要性を定義するために RFC 1123 [HOSTS] 　と同じ単語をを使用している。それらの単語は次のようである。 　　MUST この単語と形容詞「required」はその項目が仕様にとって絶対に 要求されるということを意味する。 SHOULD この単語と形容詞「recommended」は特定の環境ではこの項目を無 視する正当な理由があることを意味する。しかし完全な実装では 理解すべきであるし、別の方法を選ぶ前に注意深く考えること。 MAY この単語と形容詞「optional」はこの項目が真に選択性であるこ とを意味する。例えば、あるベンダーは特定の市場の要求のため や製品の能力を上げるためにこの項目を含めることを選ぶかもし れないし、他のベンダーは同じ項目を除くかもしれない。 　　もし、プロトコルの MUST の要求をどれかひとつもしくはそれ以上満たす 　ことが出来ないのであれば、その実装は準拠ではない。もしプロトコルの 　MUST と SHOULD の要求の全てを満たしている実装は「文句なしの準拠 　（unconditionally compliant）」と言われる。また、プロトコルの MUST 　の要求をすべて満たしているが、SHOULD レベルの要求はすべて満たしてい 　ないようなものは「条件付き準拠（conditionally compliant）」と言われ 　る。 2.2 その他の用語 　　他のRFCで定義され、この文書で使用されている主な用語。 絶対URI RFC 1808 [RELURL] 参照。 CID [MIDCID] 参照。 Content-Base 下のセクション4.2を参照。 Content-ID [MIDCID] 参照。 Content-Location MIMEメッセージまたはMIMEメッセージのURIを持つコン テント・パート・ヘッダまたはコンテント・パート・ ボディ。下のセクション4.3で定義されている。 Content-Transfer-Encoding [MIME1] で述べられている 7-bit オクテットへのテキ スト変換。 CR RFC 822 参照。 CRLF RFC 822 参照。 表示可能テキスト ウェブ・ブラウザで読めるテキスト形式。これはHTML マークアップとは異なる可能性がある。下のHTMLマー クアップの定義を参照。 ヘッダ メッセージまたはコンテント・ヘッディングの中のフィー ルドまたは属性の値を指定するヘッディング。 ヘッディング 初めの CRLFCRLF の前のメッセージまたはコンテントの 一部で、メッセージまたはコンテントの属性によって整 えられたフィールドを含む。 HTML RFC 1866 [HTML2] 参照。 HTML Aggregate 一部もしくは全てのオブジェクトと一緒になったHTML オブジェクトで、HTMLオブジェクトはハイパーリンク を含む。 HTMLマークアップ [HTML] で規定されているHTMLエンコードを含むファ イルで、人間がブラウザを使って読む表示可能テキス トとは異なることがある。例えば、HTMLマークアップ は、表示可能テキストで "<" が含まれる部分に "<" を含むかもしれない。 LF [RFC822] 参照。 MIC Message Integrity Codes 。このコードはメッセージ が更新されていないことを確かめるために使われる。 MIME RFC 1521 [MIME1]、[MIME2] 参照。 MUA Messaging User Agent 。 PDF Portable Document Format 。[PDF] 参照。 相対URI RFC 1866 [HTML2] と RFC 1808 [RELURL] 参照。 URI、絶対と相対 RFC 1866 [HTML2] 参照。 URL RFC 1738 [URL] 参照。 URL、相対 [RELURL] 参照。 VRML Virtual Reality Markup Language 。 3. 概観 　　集合体的文書は、その文書を表示するために必要なほかのデータ（貼り付 　けられた画像、スタイルシート、アプレット等）はもちろん、基礎となる文 　書も含んだMIMEエンコードされたメッセージである。集合体的文書は初めの 　オブジェクトにリンクされた付加的な要素を含むことも出来る。いくらかの 　読者が求めているものは別であることを心にとめておくことは重要である。 　メール送信エージェントは集合体的文書を普通の日常的電子メールのエンコ 　ードとして送信するかもしれない。またユーザーが特定の文書をウェブから 　他の誰かに送りたいと思った時、メール送信エージェントは集合体的文書を 　送信するかもしれない。最後に、メール送信エージェントは非IP接続のクラ 　イアントにWWWリソースへのアクセスを提供するために自動的応答装置として 　集合体的文書を送信するかもしれない。 　　メール受信エージェントはまた別の要求を持つ。メール受信エージェント 　のいくつかは集合体的文書を受信し、表示できる種類のテキストとして表示 　することが出来るかもしれない。他のはブラウジング・プログラムにこの集 　合体的文書を渡さなくてはならないかもしれない。それでこの可能性に対す 　る用意が必要である。 　　最後に、問題の生じるいくつかの他の制限がある。文書に署名することが 　でき、署名の一部であるメッセージ完全性（MIC）チェックを壊す危険性を最 　小限にして受信者に送信し表示することが出来るということは重要である。 4. Content-Location 及び Content-Base MIME コンテント・ヘッダ 4.1 MIME コンテント・ヘッダ 　　他のボディ部分へのURI参照を解決するために、Content-Location と 　Content-Base の2つのMIMEコンテント・ヘッダが定義されている。これらの 　ヘッダはどのメッセージやコンテント・ヘッダにも見出すことができ、そし 　てこのヘッディング内とそのコンテントに対して有効である。 　　実際には、現在はそれらのURIとしてURLだけが使われているが、将来は他 　のURIの形式が用いられることが予想される。 　　これらのヘッダの文法は、[RFC822] の文法定義法を用いている content-location ::= "Content-Location:" ( absoluteURI | relativeURI ) content-base ::= "Content-Base:" absoluteURI 　現在（1996年6月）はURIは RFC 1738 [URL] の中で定義されているURLの文法 　で制限されている。 　　これら2つのヘッダは、それらが存在するコンテント・ヘッディングまたは 　メッセージ・ヘッディングの中とそのテキストだけに対して有効である。そ 　れゆえこれらはマルチパート・ヘッディングの中の部分に対しては無効であ 　るし、マルチパート・ヘッディングの中では意味を持たない。 　　これら2つのヘッダはマルチパート/リレーテッド・パートの内側と外側の 　両方に存在するかもしれない。 4.2 Content-Base ヘッダ 　　Content-Base は他のヘッディング・フィールドや、HTML文書の中のBASE 　要素の与えられてない相対URIのベースを指定する。この値は絶対URIでなけ 　ればならない（MUST）。 　　Content-Base が有効な例は次のようである。 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. --boundary-example-1 Part 1: Content-Type: Text/HTML; charset=US-ASCII Content-ID: 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. --boundary-example-1 Part 2: Content-Type: Text/HTML; charset=US-ASCII Content-ID: Content-Location: foo1.bar1 ; The Content-Base below applies to ; this relative URI Content-Base: http://www.ietf.cnri.reston.va.us/images/ --boundary-example-1-- 4.3 Content-Location ヘッダ 　　Content-Location ヘッダはそのヘッダが付けられているボディ・パートの 　コンテントに相当するURIを指定する。この値には絶対URIと相対URIのどちら 　も使用できる。どのようなURIやURLも使用することができるが、非標準的URI 　やURLの使用には受取人が正しく処理出来ないかも知れないという危険が伴う。 　　Content-Location ヘッダはこのURIを普通どうりに使うことでもまた同じ 　形式のデータを送信できるということを示すのにも使うことが出来る。この 　目的で使うならば、絶対URIを含むか、Content-Base ヘッダを利用して絶対 　URIに変換できなければならない。この場合メッセージとして送信された情報 　はオリジナル・データのキャッシュされたものとしてみることが出来る。 　　このヘッダはまた、メッセージの受取人が入手不可能なデータに対しても 　使用することが出来る。例えば、社内ウェブ・スペースのような制限された 　ドメイン内のURIを使ってのみ手に入るオブジェクトを参照しているような場 　合である。このヘッダは架空のURIを含むことが出来、世界的に特有である必 　要も無い。 　例: Content-Type: Multipart/related; boundary="boundary-example-1"; type=Text/HTML --boundary-example-1 Part 1: Content-Type: Text/HTML; charset=US-ASCII ... ... ... ... --boundary-example-1 Part 2: Content-Type: Text/HTML; charset=US-ASCII Content-Location: fiction1/fiction2 --boundary-example-1-- 4.4 電子メールのヘッダ内での URI のエンコーディング 　　MIME ヘッダ・フィールドの長さは制限されており、URIはかなり長くする 　ことも出来るのでこれらの行は折りたたまれる必要があるかもしれない。そ 　のような折りたたみが生じる場合は、 [URLBODY] のセクション 3.1 の中で 　定義されているアルゴリズムが使用されるべきである。 5. 相対 URI の解決のための 基本 URI 　　MIME ボディ・パートの内側のコンテントの相対URIは基本URIとの関係で解 　決される。この基本URIを決定するために、次のような適用方法が用意されて 　いる。 (a) MIME ボディ・パートの内側で相対URIを絶対URIに変換するためのベー スが指定が存在する。例えば、HTMLはこのためのBASE要素を与えてく れる。 (b) 使用するベースを指定する、（セクション 4.2 で定義された） Content-Base ヘッダが存在する。 (c) [HTTP] にあるHTTP経由でのファイル入手の時の相対URIのベースとし てリクエストURIが使えるのと同じように、Content-Location ヘッダ が存在する時はそれをベースとして使うことが出来る。 　　上の方法では絶対URIが作り出せない時は、相対URIを一致させるためにセ 　クション 8.2 にあるような手順で補わなければならない（MUST）。 6. リンクされたオブジェクトを含まない文書の送信 　　HTMLオブジェクトのような文書がリンクしている他のオブジェクトをつけ 　ずに送信される場合、それ自体を Text/HTML のボディ・パートとして送信す 　ることが出来る（MAY）。この場合は multipart/related を使う必要は無い。 　　そのような文書はどんなリンクも含まなくても良いし、受信者が一般のネ 　ット経由で見つけることが出来るリンクを含んでも良いし、受信者が解決出 　来ないリンクを含んでも良い。 　　受信者がネット経由で見つけなければならないリンクを含むのはいくつか 　の受信者の環境では動作しないかもしれない。なぜならば、全てのメール・ 　クライアントが完全にインターネットに接続できるわけではないからである。 　また、そのようなリンクは受信者でなくて送信者の環境では動作するかもし 　れない。例えばリンクが社外からアクセス出来ない社内ネットワークの中の 　URIを含むような時である。 　　がっかりさせられるけれども、受信者が解決出来ないリンクを含む文書を 　送信することも出来る（MAY）。例えば、新しいHTMLページを製作中の二人は 　不完全なバージョンのものをやり取りするかもしれない。 7. Content-Type: Multipart/related の使用 　　メッセージがリンクを含むMIMEボディ・パートをひとつもしくはそれ以上 　含み、それらの（例えば RFC 1866 [HTML2] の中で定義されているような） 　リンクから参照される分割されたボディ・パート、データもまた含んでいる 　ならば、この完全なボディ・パートの組（参照するボディ・パートと参照さ 　れるボディ・パート）は [REL] の中で定義されている multipart/related 　ボディ・パートで送信されるべきである（SHOULD）。 　　multipart/related ルート・ボディ・パートは text/html オブジェクト 　のようなオブジェクトを描画するためのオブジェクトで、他のボディ・パー 　トの中のオブジェクトへのリンクを含むか、そのようなオブジェクトへの代 　わりとなる少なくともひとつの参照を持つ multipart/alternative であるべ 　きである（SHOULD）。しかしながら実装者は、（MIME [MIME1] が 　multipart/alternative をサポートするように要求しているにもかかわらず） 　多くのメール・プログラムが multipart/alternative を multipart/mixed 　であるかのように振舞うことに注意しなければならない。 　　[REL] は "Content-Type: Multipart/related" ステートメントの種類の属 　性はルート・オブジェクトの種類であり、この値は "multipart/alternative" 　であるだろうと推測される。ルートが multipart/related の中の最初のボディ 　・パートでない場合、[REL] は "Content-Type: Multipart/related" ヘッダ 　が初期変数として Content-ID を与えなければならない（MUST）ということを 　さらに要求する。 　　ルート・ボディ・パートがユーザーに示された時、multipart/related の 　中の追加的なボディ・パートが次のように使用できるようになる。 (a) 電子メールは持っているけれども完全なインターネット・アクセスを 持たない受信者のために。 (b) ファイアーウォールや社内のリンクの使用などのようなほかの理由で、 ネット経由でリンクされたボディ・パートを入手出来ない受信者ため に。 このことは受信者が解決出来ないような、HTTP経由や他の通信能力を要 求するURIを含むHTMLを電子メールで送信することが可能であるというこ とを表している。 (c) ウェブで入手出来ない物のために。 (d) 全ての人のアクセスを速くするために。 　　"Content-Type: Multipart/related" のタイプ・パラメータはルートの 　Content-Type と同じでなければならない。 　　送信MUAがWWWから入手するオブジェクトを送信した時は、それらの WWW 　URI を維持管理するべきである（SHOULD）。転送前にURIを他のURIに変える 　べきではない（SHOULD not）。これは受信MUAが電子メールのメッセージに含 　まれるMICとWWW上の文書を対比させて確認出来るようにする。 　　元のHTML文書がオブジェクトやアプレットへのパラメータとしてURIを含む 　ような特殊な場合にはこれはうまく動作しないであろう。そのような場合は 　送信する前にその文書を書き直した方が良いかもしれない。この問題につい 　ては、この standerd タイプの補足として発表される informational RFC 　の中でより詳しく議論される。 　　この standerd では、その multipart/related の外側のMIMEボディ・パー 　トや他のMIMEメッセージへのリンクを含む multipart/related の場合は含ま 　ない。よく似た方法がこの文書の中でも使われているが。そのようなリンク 　を提供する実装者は、この standerd に基づいて実装されたメーラーはその 　ようなリンクを解決出来ないかもしれないことに気をつけること。 　　そのような multipart/related の中の、「全ての」異なるパートは異なる 　Content-Location または Content-ID の値を持たなくてはならない（MUST）。 8. 他のボディ部分へのリンクの書式 8.1 一般規則 　　text/html ボディ・パートのようなボディ・パートは、同じメッセージの 　中の同じ multipart/related コンテントの他のボディ・パートとして含まれ 　ているオブジェクトへのハイパーリンクを含むかもしれない。しばしばこれ 　らのリンクされたオブジェクトは中心的文書のなかで読者に見せることを意 　図している。例えば、HTML [RFC 1866=HTML2] の中の IMG タグによって参照 　されるオブジェクトなどである。このような特性をもったタグは継続中のHTML 　の開発の中で提案されている。（例: applet、frame） 　　そのようなメッセージを送信するためには、そのようなリンクによって参 　照されるほかのボディ・パートを示す必要がある。例えば、「Content-Type: 　Text/HTML」のボディ・パートはしばしば同じMIMEメッセージの他のボディ・ 　パートに含まれる他のオブジェクトへのリンクを持つ。他のボディ・パート 　の参照は次のようにして行われる。それぞれのボディ・パートは、同じMIME 　メッセージで含まれるデータを参照する、それぞれ異なったURIを持つリンク 　を含んでいる。それらはこのデータを含むメッセージのその時点の 　multipart/related パートの中の分割されたボディ・パートであるべきであ 　る（SHOULD）。そのようなそれぞれのボディ・パートは Content-Location 　ヘッダ（セクション 8.2 参照）または Content-ID ヘッダ（セクション 8.3 　参照）を含むべきである（SHOULD）。 　　この standerd 準拠を求める電子メールシステムは（セクション 8.2 で定 　義されている）Content-Location と（セクション 8.3 で定義されている） 　Content-ID の両方の方法で、ボディ・パート間のリンクを含む（セクション 　7 で定義されている）multipart/related の受信を出来なければいけない 　（MUST）。 8.2 Content-Location ヘッダの使用 　　Content-Base ヘッダが存在するならば、受信者はHTMLマークアップの中の 　ハイパーリンクを Content-Location ヘッダと組み合わせる前にHTMLマーク 　アップと Content-Location ヘッダの両方の相対URIに RFC 1808 [RELURL] 　で定義されている相対から絶対への変換を適用しなければならない（MUST）。 　Content-Location が絶対URIを含み、HTMLマークアップがBASE要素を含む場 　合は、相対URIはHTMLマークアップの中で解決できるので同じことになる。 　　Content-Base ヘッダが存在せず、Content-Location ヘッダが相対URIを含 　む場合は、相対から絶対への変換は行われるべき（SHOULD）でない。この場合 　の Content-Location ヘッダの相対URIとHTMLマークアップ・テキストのハイ 　パーリンクとの組み合わせは2段階の操作になる。まず初めに、セクション 　4.4 で詳しく紹介した相対URIから全ての LWSP を取り除く。それからHTMLの 　URIに対して正確なテキスト形式の組み合わせが行われる。この組み合わせの 　操作では、HTMLの中のBASE要素のようなBASEの指定は無視される。この操作 　は Content-Location ヘッダの組み合わせだけに働き、読むときにネットワー 　ク経由で見つけられるHTML文書のURLに対しては作用しないということに注意 　すること。 　　（訳注: LWSP とは Linear White SPace の略であると考えられる。空白文 字列とはスペース、水平タブ、改行文字、復帰文字などである。） 　　Content-Location ヘッダのURIは、（相対URIを解決した後）このURIを使 　用して実際にオブジェクトが手に入るようになったオブジェクトを参照する 　のには必要ない。しかしながら、Content-Location ヘッダのURIは（絶対も 　しくは絶対URIに解決した後は）世界的に唯一であるべきである（SHOULD）。 8.3 Content-ID ヘッダと CID URL の使用 　　RFC 1738 [URL] と RFC 1873 [MIDCID] の中で定義されている CID 　(Content-ID) URL がボディ・パート間のリンクに使用されるときは、 　Content-Location ステートメントは通常 Content-ID ヘッダに置き換わられ 　るだろう。それゆえに、次の2つのヘッダは意味の上では同一である。 Content-ID: foo@bar.net Content-Location: CID: foo@bar.net 　注: Content-ID は世界的に唯一 [MIME1] でなければならない（MUST）。 このメッセージやこの multipart/related の中だけで唯一となるよう に作ることは認められていない。 9. 例 9.1 リンクされたオブジェクトを含まないHTMLボディの例 　　初めの例は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

Hi there!

An example of an HTML message.

Try clicking here.

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 --boundary-example-1 Content-Type: Text/HTML;charset=US-ASCII Content-ID: ... text of the HTML document, which might contain a hyperlink to the other body part, for example through a statement such as: IETF logo --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-- 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 --boundary-example-1 Content-Type: Text/HTML; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE ... text of the HTML document, which might contain a hyperlink to the other body part, for example through a statement such as: IETF logo Example of a copyright sign encoded with Quoted-Printable: =A9 Example of a copyright sign mapped onto HTML markup: ¨ --boundary-example-1 Content-Location: /images/ietflogo.gif Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example-1-- 9.4 埋め込まれたGIF画像への CID URL と Content-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 --boundary-example-1 Content-Type: Text/HTML; charset=US-ASCII ... text of the HTML document, which might contain a hyperlink to the other body part, for example through a statement such as: IETF logo --boundary-example-1 Content-ID: Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example-1-- 10. Content-Disposition ヘッダ 　　[REL] の仕様の中で Content-Disposition と multipart/related の関係 　について述べられている。 11. 文字のエンコードの問題と行末の問題 　　HTML文書中での文字のエンコードや、その他のテキスト文書のMIME互換オ 　クテット・ストリームへの変換については次のようなメカニズムと関連があ 　る。 - HTML [HTML2, HTML-I18N] は SGML [SGML] のアプリケーションがHTMLマー 　　クアップの中で数字による参照だけでなく文字による参照によっても文字 　　を示すことが出来る（例: 「acute accent の付いたラテン小文字」は 　　"á" または "á" で表される）ようにする。 - HTML文書は他の MIME "Content-Type text" 文書と同じく、いくつかの文 　　字エンコードのひとつを用いてMIMEで表すことができる。MIMEの 　　Content-Type の "charset" パラメータの値は特定のエンコードが使用さ 　　れていることを示す。"charset" パラメータの正確な意味と使用法につい 　　ては [MIME-IMB セクション 4.2] を参照。 　　"charset" パラメータはMIME文字エンコーディングにだけ適用されること 　　に注意すること。例えば、「acute accent の付いたラテン小文字」その 　　ものでは不可能だけれども、文字列 "á" は "charset=US-ASCII" 　　でMIMEで送信することが出来る。 　　上のメカニズムはうまく定義され文書化されているので、さらに説明はし 　ない。メッセージの送信中に上で述べられたメカニズムの全てを使用するこ 　とが出来る（MAY）し、文書を電子メール経由で送信するときにこれらを複合 　的に使用することも出来る（MAY）。受信メール・ユーザ・エージェント（と 　文書を表示するために使用するウェブ・ブラウザ）はこれらのメカニズムの 　組み合わせを処理することが出来なければならない（MUST）。 　次のことにも注意 - HTML文書も含めて、7-bit 範囲を越えるオクテット値を含む文書はどれも 　　ある転送プロトコル上では転送前に content-transfer-encoding を行う必 　　要がある。[MIME, chapter 5] - MIME standerd [MIME1] は "Content-Type: Text" の文書は 　　Content-Transfer-Encoding の前は正準形式でなくてはならない（MUST） 　　と要求している。例えば、改行は CRLF であり、CR だけや LF だけやそ 　　の他のものではない。これは他の改行表現も認めているセクション 3.6.1 　　の [HTTP] とは対照的である。 　　これは文書がHTTPからMIMEの環境に移された時に保護されないチェックサ 　ムをもとに完全性のチェックに問題を引き起こすかも知れない。このように 　チェックサムによる完全性チェックが無効になるならば、この完全性チェッ 　ク・ヘッダは文書から取り除かれるべきである（SHOULD）。 　　他の問題の元はMIMEでは認められていない Content-Encoding のHTTPでの 　使用と、改行文字を CRLF で表せない文字コードである。"Content-Type: 　TEXT" に対するHTTPとMIMEの解釈の相違についての良い概略が付録Cの [HTTP] 　の中にある。 　　もし元の文書が正準形式の改行（CRLF）を持っているならば、完全性のチ 　ェックサムは無効でないので、その文書は変換されることなく残されるべき 　である（SHOULD）。 　　チェックサムによる完全性チェックが無効になることなく、HTTPとSMTPの 　両方を経由して送信できるように願うHTML文書の提供者は、もともとの文書 　を改行に CRLF を用いた正準形式で提供するべきである。 　　いくつかの転送機構は、"charset" パラメータ値が与えられなかった場合 　はデフォルトの値を指定するかもしれない。[HTTP, MIME1] 機構によってデ 　フォルトの値は異なるので、メールを通してHTMLを転送する時には、デフォ 　ルトで中継するよりは "charset" パラメータを含むべきである（SHOULD）。 12. セキュリティの考慮 　　（Content-Location ヘッダで与えられる）特定のURIで表されるオブジェ 　クトを誰かにメールで送信する潜在能力にはセキュリティ上の考慮がいくつ 　かある。普通は同じURIへのWWWリクエストが同じオブジェクトを生じること 　は保証出来ない。他のメッセージやメッセージ・パートから Content- 　Location ヘッダとして同じメッセージに含まれるこのURIでの検索に使える 　ようにするこのような方法はデータをキャッシュするのに適していない。こ 　の問題のために、受信ユーザー・エージェントはこのデータを、HTTPやFTP 　のリクエストを通して検索されるデータのキャッシュと同じ方法でキャッシ 　ュされるべきではない（SHOULD）。 　　URL、特に File URL は文書の受信者にうっかり知らせてしまう社内情報を 　その中に含んでいるかもしれない。 　　リンクされたボディ・パートを伴うメッセージを提供する方法のひとつは 　メールとWWWの複合型プロキシ・サーバーでリンクされたボディ・パートを処 　理することである。メール・クライアントは初めのボディ・パートだけを受 　け取り、それをウェブ・ブラウザに渡す。このブラウザはリンクされたパー 　トのリクエストをプロキシ・サーバーに出す。もしもこの方式を使用し、こ 　の複合型サーバーが複数のユーザーに使用されるならば、この方式はある人 　へのメッセージのボディ・パートが他の人に検索されないようにしなくては 　ならない。（チケットやマジック・クッキーとしても知られている）パスワ 　ードの使用はこれを達成するひとつの方法である。キャッシングWWWプロキシ 　の中には電子メールとHTTPのどちらからキャッシュされたオブジェクトなの 　か区別することが出来ないものもあり、セキュリティ・リスクとなるかもし 　れないことに注意すること。 　　それに加えて、人々が集合体的文書をメールで送ることが出来るようにす 　ることで、今まではWWWユーザーだけのものであった他の潜在的なセキュリ 　ティ問題の扉を開く。例えば、HTML文書は今では実行可能なコンテント（ 　JavaScript）と実行可能なコンテント（"INSERT" で指定される JAVA）への 　リンクを含む。受信ユーザー・エージェントにとって、メールのメッセージ 　を通して受け取った実行可能コンテントを注意深い能力の制限なしに実行す 　ることは非常に危険である。 　　いくつかのWWWアプリケーションは（誰もが入手出来るわけではない情報に 　アクセスするためのトークンである）パスワードやチケットを隠し、他の機 　密情報をウェブ文書や動的に作られるURLの隠れたフィールドの中に隠す。 　そのような文書を受け取った人がこれを電子メール経由で転送すると、その 　人はうっかりと機密情報をばらしてしまうかもしれない。 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 そしてその他の幾人もの方々がこの文書の 　作成を手伝ってくださいました。この文書に残っているかもしれない誤りは 　私一人の責任です。 14. 参考文献 Ref. Author, title --------- -------------------------------------------------------- [CONDISP] R. Troost, S. Dorner: "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995. [HOSTS] R. Braden (editor): "Requirements for Internet Hosts -- Application and Support", STD-3, RFC 1123, October 1989. [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, & M. Duerst: "Internationalization of the Hypertext Markup Language". RFC 2070, January 1997. [HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language - 2.0", RFC 1866, November 1995. [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996. [MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [MIDCID] E. Levinson: "Content-ID and Message-ID Uniform Resource Locators". RFC 2111, February 1997. [MIME-IMB] N. Freed & N. Borenstein: "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bedies". RFC 2045, November 1996. [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. [MIME2] N. Borenstein & N. Freed: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types". RFC 2046, November 1996. [NEWS] M.R. Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987. [PDF] Bienz, T., Cohn, R. and Meehan, J.: "Portable Document Format Reference Manual, Version 1.1", Adboe Systems Inc. [REL] Edward Levinson: "The MIME Multipart/Related Content- Type". RFC 2112, February 1997. [RELURL] R. Fielding: "Relative Uniform Resource Locators", RFC 1808, June 1995. [RFC822] D. Crocker: "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982. [SGML] ISO 8879. Information Processing -- Text and Office - Standard Generalized Markup Language (SGML), 1986. [SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [URL] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform Resource Locators (URL)", RFC 1738, December 1994. [URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME External-Body Access-Type", RFC 2017, October 1996. 15. 著者の住所 　　著者と連絡を取る時は、できれば Alex Hopmann より Jacob Palme のほ 　うに書いてほしい。 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 Alex Hopmann E-mail: alexhop@microsoft.com Microsoft Corporation 3590 North First Street Suite 300 San Jose CA 95134 Working group chairman: Einar Stefferud ---------------------------------------------------------------------- この翻訳について 　この翻訳はShigeが個人的に翻訳したもので、公式なものではありません。 　あくまでも参考程度にし、公式な場では英語の原文を使用してください。 　翻訳の正しさは一切保証しませんし、断りなく変更されることがあります。 　最新版やその他の文書については http://home.hiroshima-u.ac.jp/u1079009/ 　を見てください。 再配布の条件 　公式な翻訳でないことを明記すること。 　翻訳の正しさは一切保証されないことを明記すること。 　この文書の内容を書き換えないこと。