日本語翻訳版覚書 [ホーム <../../index.html>] [RFC 1468(jp) ] [RFC 822(jp) ] [MIMEへの過程 <../mime.html>] [RFC 2045(jp) ] [RFC 2046(jp) ] [RFC 2047(jp) ] [RFC 2049(jp) ] が原著。 翻訳版は、翻訳からくる間違いがあり得ます。 message メッセージ:通信(交流) * a communication passed or sent by speech, in writing, by signals etc. * a official communication/the President's message to Congress * RFC 822:messages (mail) By 1977, the Arpanet employed several informal standards for the text messages (mail) sent among its host computers. ------------------------------------------------------------------------ (Updates RFC1806) (Updated by RFC2184, RFC2231) (Status: PROPOSED STANDARD) ------------------------------------------------------------------------ Yasutaka Kato 加藤泰孝 ------------------------------------------------------------------------ rfc2183 [rfc ディレクトリーのトップへ ] Network Working Group R. Troost Request for Comments: 2183 New Century Systems Updates: 1806 S. Dorner Category: Standards Track QUALCOMM Incorporated K. Moore, Editor University of Tennessee August 1997 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field インターネットメッセージの情報交流表現: Content-Disposition ヘッダーフィールド この覚書の位置付け この文書はインターネット交流のためのインターネット標準トラックプロト コールを特定し、改善への議論と示唆を求めています。この文書の標準化状況 と位置付けについては、最新の"Internet Official Protocol Standards" (STD 1) を参照してください。この覚書の配布には、制限はありません。 概要 この覚書は、MIME仕様 [RFC 2045,RFC 2046,RFC 2047,RFC 2048,RFC 2049] に適合するメッセージが表現的な情報を運ぶ機構、を提供します。そ れは、"Content-Disposition" header 、如何なるMIME実体("message" も しくは "body part")においても任意で正しいもので、を特定します。この 覚書に記載されているヘッダーフィールド用の二つの値;ボディ部分の普通 のインライン表現ようのものとファイルを転送するようにメールを装備する 別のものの二つです。将来はもっと多くの値が定義され、値のこのセットを 拡張するよう定義されると思われます。 この文書は、MIMEの拡張として意図されています。そのようなので、読者は MIME仕様書と[RFC 822] に馴染んでいるものと仮定しています。ここで表現 されている情報は、それらの文書に見られる情報に補足しますが、それを置 き換えません。 この文書は、 RFC 1806 で定義された試験的なプロトコールの改訂版です。 RFC 1806 に比べて、この文書は、マイナーな編集上の更新を内容とし、 ファイル転送ボディ部分をサポートするのに必要な新しいパラメーターを追 加し、非ASCIIと非常に長いパラメーター値を取り扱う個別仕様書を参照し ています。 Troost, et. al. Standards Track [Page 1]  RFC 2183 Content-Disposition August 1997 1. はじめに MIMEは、データーの多元部分を単一インターネットメッセージにカプセル化 する標準書式を特定しています。その文書は表現様式問題には近づいていま せん;メッセージ内容の交換の枠組みを提供していますが、表現問題をただ メール表示代行手段(MUA)装備の手に任せたままにしています。 多元部分電子メッセージを表現する一般的な方法は、別途の添付リストを付 ける主文書ととしてと直線的にを拡張した(表示される)色々な部分からな る単一文書としての二つがあります。添付の表示は一般的に受信者側での積 極的な行動を要求するように構成され、一方インラインメッセージ構成は、 メッセージを閲覧する際、自動的に表示されます。送信者がこの種の表現上 の情報を受信者に転送することができるような機構が必要です;Content- Disposition ヘッダーフィールドは、この機構を提供し、ケッセージの各要 素を欲しい表現構文の指標でタグ付け(名札付け)します。 この方法でのタグ付けされたメッセージは、基本的なメッセージ書式として 十分です。しかし、多くの例でより強力で柔軟なアプローチが必要です。そ のようなアプローチの定義はこの覚書の位置付けを越えます;しかし、その ようなアプローチは、後のデーターで定義されるべである、補足的な Content- Disposition 値とパラメーターによって利益を得ることができます。 送信者がメッセージ要素の表現上の配置の特定を可能にすることに加えて、 デフォルトの記録保管の配置を指定できることが望ましい;ファイル名。こ の任意(選択性)の"filename"パラメーターがこれを提供します。更に、 creation-date, modification-date そして read-date parameter が、ファ イルがMIMEメールで転送される場合、これらのファイル属性の維持を可能に します。 よく注意(NB):キワード、MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY そして OPTIONALは、この文 書に現われる場合、[RFC 2119]に記載説明されている通りに解釈されるべき です。 2. The Content-Disposition ヘッダーフィールド Content-Dispositionは、任意選択性のヘッダーフィールドです。これがな い場合メール代行手段(MUA)は、適切と思われる表現手段ならどんなもの でも使うかもしれません。 可能な配置タイプ一式を小さくよく定義されたものにすることが、不必要な 複雑さを避けるために、望まれます。そうであっても、発展する使用は、こ の配置値一式は以下にみるように拡張可能なので、追加配置タイプもしくは パラメーターの定義の必要がありそうに思われます。 Troost, et. al. Standards Track [Page 2]  RFC 2183 Content-Disposition August 1997 [RFC 822] の拡張されたBNF命名法で、the Content-Disposition ヘッダ ーフィールドは以下のように定義されます: disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type := "inline" / "attachment" / extension-token ; values are not case-sensitive disposition-parm := filename-parm / creation-date-parm / modification-date-parm / read-date-parm / size-parm / parameter filename-parm := "filename" "=" value creation-date-parm := "creation-date" "=" quoted-date-time modification-date-parm := "modification-date" "=" quoted-date-time read-date-parm := "read-date" "=" quoted-date-time size-parm := "size" "=" 1*DIGIT quoted-date-time := quoted-string ; contents MUST be an RFC 822 `date-time' ; numeric timezones (+HHMM or -HHMM) MUST be used パラメーター値の長さについての注意: 非`tspecials'文字だけを内容と している短い(長さ <=78 文字)パラメーター値は、単一トークン `token' として表現されるべきです。ASCIIだけを内容としているが 'tspecials' 文 字を含んでいるものを内容にするパラーメーター値は、[RFC 2184]で特定さ れたように符号化されなければなりません。 `Extension-token', `parameter', `tspecials'そして`value'はRFC 2045] (これらのトークン(字句)の定義によっては [RFC 822]を照合しているも のもあります)に従って定義され、`quoted-string' と`DIGIT'は[RFC 822] で定義されています。 Troost, et. al. Standards Track [Page 3]  RFC 2183 Content-Disposition August 1997 2.1 インライン配置タイプ(The Inline Disposition Type) ボディ部分は、メッセージ表示に際し自動的に表示されることが意図される 場合、インラインマーク付けされるべきです。インラインボディ部分は配置 順に、多元メッセージの普通の構文に従って表現されるべきです。 2.2 添付配置タイプ(The Attachment Disposition Type) ボディ部分で、メールメッセージの主ボディとは別で、表示は自動的である べきだが、利用者側のさらなるなんらかの行動を条件としていることを示唆 するように、`attachment'を設計することが可能です。メール表示代行手段 は、添付のアイコン表現もしくは利用者が閲覧か保存の選択ができる添付リ ストで、ビットマップ端末の使用を代わりに表現するかもしれません。 2.3 ファイル名パラメーター(The Filename Parameter) 送信者は、実体が切り離され別のファイルへ保存される場合に使用される ファイル名を指定したいと思うかもしれません。受信メール代行手段がファ イルの実体を書き込む場合、指定されたファイル名が、実際のファイル名の 基本として、何処ででも使用されるべきです。 受信メール代行手段は指定されたファイル名を盲目的に使用しないことは大 切なことです。指定されたファイル名は、それがローカルファイルシステム 慣例に適合しているかを見み、既存のファイルを上書きしないで安全問題 (以下の安全性への配慮を参照)を持ち込まないために、チェック(そして 可能な変更)されるべきです。 受信メール代行手段は、ファイル名パラメーターにあると思われる如何なる 階層経路情報に関わるべきではありません。ファイル名は、端末としてだけ で処理されるべきです。階層経路の移動仕様は、将来別個のContent- Dispositionパラメーター経由で可能になるかもしれませんが、この候補で それようにはなんら規定はなされていません。 最新の[RFC 2045]文法は、パラメーター値(そしてそれ故にContent- Dispositionファイル名)をUS-ASCIIに限定しています。ファイル名に任意 の文字セットを許すことの大きな要望を認めますが、必要な機構を定義する ことはこの仕様書の位置付けを越えています。基本的な[RFC 1521]値= `value' 仕様は何時か、その時は同じ機構がContent-Dispositionファイル 名パラメーターで使用され、非ASCII文字の使用を許すように改善されるこ とを期待しています。 Troost, et. al. Standards Track [Page 4]  RFC 2183 Content-Disposition August 1997 US-ASCIIへの制限を越えて、送信メール代行手段は普通のファイルシステム の限界を覚えておいて欲しいかもしれません。ファイルシステムの多くは、 厳しい長さや文字セット制限を持っています。短い英数字のファイル名が受 信システムよる修正の要求が最小ですみそうです。 ファイル名パラメーターの存在は別のファイルへ実体を書き写すことを装備 に強制するものではありません。装備は、利用者が別に請求しないなら、装 備が普通のメール文字列の一部として実体を許すことを完全に受け入れます。 その結果、そのパラメーターは、如何なるMIME実体、例え「インライン」で あっても、で使用されるかもしれません。これらは普通ファイルにかきこま れませんが、そのパアラメーターが、受信利用者がファイルにその一部を書 き込むことを選んだ場合、ファイル名を提供するために使用されることがで きます。 2.4 制作日付パラメーター(The Creation-Date parameter) creation-dateパラメーターはファイルが制作された日付を指すために使用 されるかもしれません。このパアラメータがあれば、そのパラメーターは引 用符で囲われた文字列で、ファイル制作日付を[RFC 822]の `date-time' 書 式で表現したものが内容にならなければなりません。 UNIXとPOSIX装備は、`stat'構造の`st_ctime'ファイル属性はファイルの制 作時間でないと警告されます;従って制作日付パラメータ値の資源として適 切でありません。 2.5 更新日付パラメーター(The Modification-Date parameter) modification-dateパラメーターはファイルの最終修正日付を指すために使 用されるかもしれません。修正日付パアラメータがあれば、そのパラメー ターは引用符で囲われた文字列で、ファイルの修正日付を[RFC 822]の `date-time' 書式で表現したものが内容にならなければなりません。 2.6 既読日付(The Read-Date parameter) read-dateパラメーターはファイルの最終既読日付を指すために使用される かもしれません。最終既読日付パアラメータがあれば、そのパラメーターは 引用符で囲われた文字列で、ファイルの最終既読日付を[RFC 822]の `date-time' 書式で表現したものが内容にならなければなりません。 2.7 サイズパラメータ(The Size parameter) サイズパラメーターはクテットでファイルのおおよそのサイズを指します。 例えば、そのファイルを保存する試みの前に位置をきめたりもしくは既存の 空間がじゅうぶんであるかを決定するために、使用することができます。 Troost, et. al. Standards Track [Page 5]  RFC 2183 Content-Disposition August 1997 2.8 将来の拡張と認識されない配置タイプ (Future Extensions and Unrecognized Disposition Types) 新しいパラメーターもしくは配置タイプが必要になりそうな場合、この覚書 のセクション9で特定された方法でInternet Assigned Numbers Authority (IANA)に登録されなければなりません。 一旦新しい配置タイプやパラメーターが定義されたら、勿論、装備は理解出 来ない配置タイプやパラメーターにお目にかかることもありえます。更に、 X-トークンが許されるので、装備も全く認識しない配置タイプやパラメー ターをみるかもしれません。 認識されないパラメーターは無視されるべきです。認識されない配置タイプ は「添付=`attachment'」として処理されるべきです。新しい配列タイプを 伴うContent-Dispositionヘッダーを生成することの支障に行く送信者は、 インライン表現よりより複雑な何者かに照準を定めそうです。 パラメーターの定義で特に別のやり方で言及されないなら、Content- Disposition パラメーターは全ての配置で妥当なものです。(内容タイプ毎 の基盤で定義されるMIME内容タイプパラメーターと対照的です)かくて、例 えば、`filename'パラメーターは、配置自体が認識されなくてもその部分が 書き込まれるべき、ファイルの名前をやはり意味しています。 2.9 内容配置と多元部分(Content-Disposition and Multipart) Content-Disposition ヘッダーが多元部分ボディ部で使用される場合全体と して、個々のサブパートでなく、多元部分に摘要されます。サブパートの配 置タイプは、多元部分そのものが供されるまで、参照される必要はありませ ん。多元部分が表示される際その時サブパートのは配置が念頭におかれるべ きです。 「インライン=`inline'」配置が使われるなら、多元部分は普通のように表 示されます;しかし、「添付=`attachment' 」サブパートは、表示するに は、利用者からの行動を要求すべきです。 「添付=`attachment'」配置が使われるなら、多元部分の表現は明確な利用 者の行動なしには先行されるべきではありません。一旦利用者がそのサブ パートをどのように表現するかを決めるために参照されるべきです。 Troost, et. al. Standards Track [Page 6]  RFC 2183 Content-Disposition August 1997 2.10 内容配置と主メッセージ(Content-Disposition and the Main Message) [RFC 822]の主ボディに Content-Disposition を使用することが、許されて います。 3. 事例(Examples) 利用者が直ちに閲覧できるように意図されたJPEF画像を内容としているボ ディ部分の例をここにあげています: Content-Type: image/jpeg Content-Disposition: inline Content-Description: just a small picture of me 以下のボディ部分は利用者、利用者が必要な場合だけ、に表示されるべき JPEG画像を内容にしています。JPEGがファイルに書き込まれていりなら、そ のファイルは"genome.jpg"と命名されるべきです。受信利用者は、保存され たファイルの最新更新日付をmodification-dateパラメーターの日付に設定 することも選択するかもしれません: Content-Type: image/jpeg Content-Disposition: attachment; filename=genome.jpeg; modification-date="Wed, 12 Feb 1997 16:29:51 -0500"; Content-Description: a complete map of the human genome 以下は、多元ボディ部分の`attachment'配置(添付配置)の利用例です。利 用者は、直ちtext-part-1 をに見、次いでmultipart-2を閲覧するために何 らかの行動をとります。multipart-2を閲覧する行動をとった後、その利用 者はtext-part-2を右に見て、jpeg-1を閲覧する行動をとるよう要求されま す。サブパートは明確にするために字下げされています:これらが実際の メッセージでそのように字下げされません。 Troost, et. al. Standards Track [Page 7]  RFC 2183 Content-Disposition August 1997 Content-Type: multipart/mixed; boundary=outer Content-Description: multipart-1 --outer Content-Type: text/plain Content-Disposition: inline Content-Description: text-part-1 Some text goes here --outer Content-Type: multipart/mixed; boundary=inner Content-Disposition: attachment Content-Description: multipart-2 --inner Content-Type: text/plain Content-Disposition: inline Content-Description: text-part-2 Some more text here. --inner Content-Type: image/jpeg Content-Disposition: attachment Content-Description: jpeg-1 --inner-- --outer-- 4. 要約(Summary) Content-Dispositionは、「インライン」と「添付」の二つの値をとりま す。「インライン」は実体は利用者に直ちに表示されることを指し、それと 違って「添付」は利用者が実体を閲覧するのに追加行動をとるべきです。 `filename' パラメーターは、利用者が外部ファイルにそれを保存したい場 合、保存ボディ部分用のファイル名を示唆するのに利用出来ます。 Troost, et. al. Standards Track [Page 8]  RFC 2183 Content-Disposition August 1997 5. 安全性配慮(Security Considerations) 利用者がデーターを交換時は何時でも生じる安全性問題があります。これらは最小限にされないけれども、この覚書はその状況を There are security issues involved any time users exchange data. While these are not to be minimized, neither does this memo change the status quo in that regard, except in one instance. Since this memo provides a way for the sender to suggest a filename, a receiving MUA must take care that the sender's suggested filename does not represent a hazard. Using UNIX as an example, some hazards would be: + Creating startup files (e.g., ".login"). + Creating or overwriting system files (e.g., "/etc/passwd"). + Overwriting any existing file. + Placing executable files into any command search path (e.g., "~/bin/more"). + Sending the file to a pipe (e.g., "| sh"). In general, the receiving MUA should not name or place the file such that it will get interpreted or executed without the user explicitly initiating the action. It is very important to note that this is not an exhaustive list; it is intended as a small set of examples only. Implementors must be alert to the potential hazards on their target systems. 6. 参照(References) [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC 2184] Freed, N. and K. Moore, "MIME Parameter value and Encoded Words: Character Sets, Lanaguage, and Continuations", RFC 2184, August 1997. [RFC 2045] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part One: Format of Internet Message Bodies", RFC 2045, December 1996. Troost, et. al. Standards Track [Page 9]  RFC 2183 Content-Disposition August 1997 [RFC 2046] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Two: Media Types", RFC 2046, December 1996. [RFC 2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for non-ASCII Text", RFC 2047, December 1996. [RFC 2048] Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose Internet Mail Extensions) Part Four: Registration Procedures", RFC 2048, December 1996. [RFC 2049] Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996. [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. 7. 謝辞(Acknowledgements) We gratefully acknowledge the help these people provided during the preparation of this draft: Nathaniel Borenstein Ned Freed Keith Moore Dave Crocker Dan Pritchett Troost, et. al. Standards Track [Page 10]  RFC 2183 Content-Disposition August 1997 8. 著者への連絡(Authors' Addresses) You should blame the editor of this version of the document for any changes since RFC 1806: Keith Moore Department of Computer Science University of Tennessee, Knoxville 107 Ayres Hall Knoxville TN 37996-1301 USA Phone: +1 (423) 974-5067 Fax: +1 (423) 974-8296 Email: moore@cs.utk.edu The authors of RFC 1806 are: Rens Troost New Century Systems 324 East 41st Street #804 New York, NY, 10017 USA Phone: +1 (212) 557-2050 Fax: +1 (212) 557-2049 EMail: rens@century.com Steve Dorner QUALCOMM Incorporated 6455 Lusk Boulevard San Diego, CA 92121 USA EMail: sdorner@qualcomm.com 9. 新しいContent-Disposition値とパラメータの登録 (Registration of New Content-Disposition Values and Parameters) New Content-Disposition values (besides "inline" and "attachment") may be defined only by Internet standards-track documents, or in Experimental documents approved by the Internet Engineering Steering Group. Troost, et. al. Standards Track [Page 11]  RFC 2183 Content-Disposition August 1997 New content-disposition parameters may be registered by supplying the information in the following template and sending it via electronic mail to IANA@IANA.ORG: To: IANA@IANA.ORG Subject: Registration of new Content-Disposition parameter Content-Disposition parameter name: Allowable values for this parameter: (If the parameter can only assume a small number of values, list each of those values. Otherwise, describe the values that the parameter can assume.) Description: (What is the purpose of this parameter and how is it used?) 10. Changes since RFC 1806 The following changes have been made since the earlier version of this document, published in RFC 1806 as an Experimental protocol: + Updated references to MIME documents. In some cases this involved substituting a reference to one of the current MIME RFCs for a reference to RFC 1521; in other cases, a reference to RFC 1521 was simply replaced with the word "MIME". + Added a section on registration procedures, since none of the procedures in RFC 2048 seemed to be appropriate. + Added new parameter types: creation-date, modification-date, read-date, and size. + Incorporated a reference to draft-freed-pvcsc-* for encoding long or non-ASCII parameter values. + Added reference to RFC 2119 to define MUST, SHOULD, etc. keywords. [翻訳版 ] Troost, et. al. Standards Track [Page 12]