RFC1806 日本語訳

1806 Communicating Presentation Information in Internet Messages: TheContent-Disposition Header. R. Troost, S. Dorner. June 1995. (Format: TXT=15548 bytes) (Obsoleted by RFC2183) (Status: EXPERIMENTAL)

RFC一覧
英語原文

Network Working Group                                          R. Troost
Request for Comments: 1806                           New Century Systems
Category: Experimental                                         S. Dorner
                                                   QUALCOMM Incorporated
                                                               June 1995


               Communicating Presentation Information in
                           Internet Messages:
                     The Content-Disposition Header

[この記述の状態]

  この記述はインターネットコミュニティに対する実験的なプロトコルを
  定義している。この記述はインターネット標準を何も記述していない。
  改善のための論議と提案が求められる。この記述の配布は無制限である。

[概要]

  この記述は [RFC 1521] ("MIME") に準拠しているメッセージが提示的な
  情報を運ぶためのメカニズムを提供する。どんな [RFC 1521] エンティ
  ティ ("message" や "body part") でも任意で正当な新しい
  "Content-Disposition" ヘッダを詳述する。この仕様書ではこのヘッダ
  に対して 2 つの値を記述する。ひとつは通常のボディパートのインライ
  ン提示であり、もうひとつはメールを使用してのファイル転送を容易に
  する。将来的により多くの値が定義されるだろうと思われる。そしてそ
  の値のセットを拡張するごとに手順が定義される。

  このドキュメントは [RFC 1521] の拡張を意図している。従って、読者
  は [RFC 1521] と [RFC 822] に精通していると想定する。情報はここで
  補足を与えているが、それらのドキュメントでの意味は置き換えない。

[1. イントロダクション]

  [RFC 1521] はひとつのインターネットメッセージ中に複数のデータをカ
  プセル化するための標準的な方法を提示しているが、そのドキュメント
  は提示形式の事項を扱っていない。それはメッセージ内容交換のための
  フレームワークを提供している。しかし、依然メールユーザエージェン
  ト (MUA) 実装者の手中に提示方法の問題を残す。

  複合電子メッセージを提示する 2 つの一般方法は、分かれている添付部
  品のリスト付きメインドキュメントと、インラインで展開 (表示) され
  るさまざまな部品を持つ単一のドキュメントである。インラインメッセー
  ジコンポーネントがメッセージを閲覧するときに自動的に表示されるの
  に対して、添付部品の表示は一般に受取人の側で明示的な動作を必要と
  すると解釈される。送り主がこの種類の提示形式情報を受取人に伝えら
  れるようなメカニズムが必要である。Content-Disposition ヘッダは、
  メッセージのコンポーネントそれぞれがその適切な提示形式の表示をタ
  グ付けできるようなメカニズムを供給している。

  この方法のでメッセージにタグをつけることは、基本的なメッセージ
  フォーマット化に対してしばしば十分であろう。しかしながら、多くの
  場合はより強力で柔軟なアプローチが必要であろう。このようなアプ
  ローチの定義はこの記述の範疇を超えている。しかしながら、このよう
  なアプローチが後日定義できるように、追加の Content-Type 値とパラ
  メータから利益を得ることができる。

  送り主がメッセージコンポーネントの提示形式を記述できることに加え
  て、デフォルトのアーカイブ属性 (ファイル名) を表示することができ
  れば望ましい。このため省略可能な "filename" パラメータが提供され
  る。

[2. Content-Disposition ヘッダフィールド]

  Content-Disposition は省略可能なヘッダである。それが存在しなけれ
  ば、MUA が妥当だと判断した提示方法を使うかもしれない。

  不必要な複雑化を回避するため、軽量でうまく定義された可能なディス
  ポジションタイプのセットを保持することが望ましい。それでも、使用
  法を発展させることはディスポジションタイプやパラメータの追加定義
  を必要とするであろう。そのためディスポジション値は拡張可能である。
  下記参照。

  [RFC 822] の拡張 BNF 表記で Content-Disposition ヘッダフィールド
  は以下のように定義される:

        disposition := "Content-Disposition" ":"
                       disposition-type
                       *(";" disposition-parm)

        disposition-type := "inline"
                          / "attachment"
                          / extension-token
                          ; values are not case-sensitive

        disposition-parm := filename-parm / parameter

        filename-parm := "filename" "=" value;

  `extension-token', `parameter', `value' は [RFC 822] と
  [RFC 1521] に準拠して定義される。

2.1 inline ディスポジションタイプ

  もしディスプレイ上にメッセージが自動的に表示される事を意図してい
  るなら、bodypart は `inline' としてマークされるべきである。マルチ
  パートメッセージの普通のセマンティクスから、inline bodypart が存
  在する順序で提示されるべきである。

2.2 attachment ディスポジションタイプ

  bodypart はメールメッセージのメインボディから分割されていることを
  示すために `attachment' として明示することができ、それらの表示は
  自動的ではなくユーザアクションしだいとすべきである。MUA はその代
  わりに、ビットマップ端末のユーザには添付データのアイコン表現を、
  キャラクタ端末には添付データの表示や保存を選択できるようにリスト
  を提示するかもしれない。

2.3 filename パラメータ

  送信元はエンティティが分離されて別のファイルに保存される時に使用
  されるファイル名を提案できる。もし受信した MUA がファイルにエン
  ティティを書きこむなら、可能なら提案されたファイル名が実際のファ
  イル名ベースとして使用されるべきである。

  受け取り側の MUA が闇雲に提案されたファイル名を使わないということ
  が重要である。提案されたファイル名はそれがローカルファイルシステ
  ムの規約に従うかどうかをチェック (可能であれば変更) されるべきで
  あり、既存のファイルに上書きすべきではなく、そしてセキュリティ問
  題を引き起こすべきではない (セキュリティ考察は下記参照)。

  受信側 MUA は filename パラメータに存在する可能性のあるどんなディ
  レクトリパス情報も尊重すべきではない。ファイル名は最終のコンポー
  ネントのみ取り扱われるべきである。ディレクトリパスのポータブルな
  仕様は将来の Content-Disposition パラメータによって行えるようにな
  るかもしれないが、その準備はこの仕様書で記述されない。

  現在の [RFC 1521] 文法はパラメータ値 (従って Content-Disposition
  ファイル名も) を US-ASCII に制限している。我々はファイル名に任意
  の文字セットをつかえるようにすることは大いに望ましいと考えている
  が、このメカニズムを定義することはドキュメントの範囲を超える。
  我々は基本となる [RFC 1521] 仕様の `value' がいずれ非 US-ASCII
  文字を使えるように改定されるだろうと思う。そしてそのときに
  Content-Disposition ファイル名パラメータで同じメカニズムを使用す
  べきである。

  US-ASCII の制限を越えて、送信側の MUA は共通のファイルシステムの
  制限を念頭に持つことを望むかもしれない。多くは厳格な文字数と文字
  セット制限を持っている。短い英数文字のファイル名は受信側システム
  によって修正される可能性が低い。

  ファイル名パラメータの存在は実装で別のファイルにエンティティを書
  き込むことを強いていない。さもなければ、ユーザの要求しなければ普
  通のメールストリームの一部としてエンティティを残しておくことは、
  実装に対してまったく適切である。結果として、パラメータはどんな
  MIME エンティティ (`inline' も) にも使うことができる。これらは通
  常ファイルに保存されないだろう。しかし、もし受信側のユーザーが
  ファイルに part を書き込むことを決めたなら、パラメータはファイル
  名を供給するために使われることができる。

2.4 将来の拡張と認識できないディスポジションタイプ

  新しいパラメータやディスポジションタイプが必要とされるような事象
  において、それらは [RFC 1521], 付録 E で述べられている方法で IANA
  に登録されるべきである。

  新しいディスポジションタイプとパラメータが提案されると、それらが
  理解できないディスポジションタイプやパラメータを実装が参照する可
  能性がもちろんある。さらに、x- トークンが許されるので、実装がもっ
  ぱら未登録のディスポジションタイプやパラメータを参照するかも知れ
  ない。

  認識できないパラメータは無視されるべきである。認識できないディス
  ポジションタイプは `attachment' として扱われるべきである。認識で
  きないタイプの `attachment' 選択は、新しいディスポジションタイプ
  を付けた Content-Disposition ヘッダの生成で問題に直面した送信側が、
  インライン提示よりももっと巧妙な何かを目指しているらしいために発
  生する。

  その他の点のパラメータ定義で気づく点がなければ、Content-Disposition
  パラメータは全てのディスポジションに対して正当である。([RFC 1521]
  Content-Type パラメータと対照的に、Content-Type ベースごとに定義
  される。) 従って、ディスポジション自身が認識されないとしても、例
  えば `filename' パラメータは依然 part を書き出すべきファイルの名
  前を意味している。

2.5 Content-Disposition とマルチパート

  もし Content-Disposition ヘッダがマルチパートボディ部分で使用され
  ているなら、個々のサブパートではなくマルチパート全体に適用される。
  サブパートのディスポジションタイプはマルチパート自身が与えられる
  まで調べる必要はない。マルチパートが表示されるとき、サブパートの
  ディスポジションが尊重されるべきである。

  もし `inline' ディスポジションが使われるなら、マルチパートは通常
  のように表示されるべきである。しかしながら、`attachment' サブパー
  トは表示するためにユーザからのアクションを必要とすべきである。

  もし `attachment' ディスポジションが使われるなら、マルチパートの
  提示は明確なユーザアクションなしに処理を行うべきではない。ユーザ
  がマルチパートを表示する事を選択したときに個々のサブパートディス
  ポジションがサブパートの提示方法を決定するために調べられるべきで
  ある。

2.6 Content-Disposition とメインメッセージ

  [RFC 822] メッセージのメインボディ上で Content-Disposition を使う
  ことは許される。

[3. 例]

  直ちにユーザに表示したい JPEG イメージを含むボディパートの例:

         Content-Type: image/jpeg
         Content-Disposition: inline
         Content-Description: just a small picture of me

         <jpeg data>

  以下のボディパートはユーザが要求したときのみだけ表示すべき JPEG
  イメージを含んでいる。もし JPEG がファイルに書き出されるなら、
  ファイル名は "genome.jpg" という名前にすべきである:

         Content-Type: image/jpeg
         Content-Disposition: attachment; filename=genome.jpeg
         Content-Description: a complete map of the human genome

         <jpeg data>

  以下はマルチパートボディ部分の `attachment' ディスポジションの使
  用例である。ユーザは直ちに text-part-1 を見るべきであり、
  multipart-2 を見るために何らかのアクションをとる。multipart-2 を
  表示するためのアクションをとった後、ユーザはすぐに text-part-2 を
  見て、jpeg-1 を見るためにアクションをとる必要がある。明瞭化のため
  サブパートは字下げしてある。実際のメッセージでそれらは字下げされ
  ないだろう。

         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

             <jpeg data>
           --inner--
         --outer--

[4. 要約]

  Content-Disposition は二つの値 `inline' と `attachment' をとる。
  `inline' はエンティティが直ちにユーザに表示されるべきであることを
  示すのに対して、`attachment' はユーザがエンティティを表示するため
  にさらなる動作を取るべきであることを意味する。

  もしユーザがボディパートを外部ファイルに保存することを望むなら、
  `filename' パラメータはボディパートを保存するためのファイル名を提
  案するために使うことができる。

[5. セキュリティ考察]

  ユーザがデータを交換するどんなときでもセキュリティ問題に巻き込ま
  れることがある。これらは最小ではないはずだし、この記述はひとつの
  例外を除いてその点現状を変えない。

  この記述は送信側がファイル名を提案する方法を提供しているため、受
  信側 MUA は送信側の提案したファイル名が危険ではないことに注意しな
  ければならない。例として UNIX を使用する場合のいくつかの危険性を
  下記に示す:

    + セットアップファイルを作り出す (e.g., ".login")

    + システムファイルを作り出したり上書きする (e.g.,
      "/etc/passwd")

    + 既存のファイルを上書きする

    + コマンドサーチパス上に実行可能なファイルを配置する (e.g.,
      "~/bin/more")

    + パイプにファイルを送り出す (e.g., "| sh")

  一般的には、ユーザが明示的に行動を始めることなく翻訳されたり実行
  されないであろうように、受信側 MUA は決してファイル名をつけたり配
  置すべきではない。

  これが徹底したリストではないということを意識することは非常に重要
  である。これは例のみの小さなセットを意図している。実装者はこれら
  のターゲットシステム上の潜在的な危険を警戒しなければならない。

[6. 参照]

    [RFC 1521]
        Borenstein N., and N. Freed, "MIME (Multipurpose Internet
        Mail Extensions) Part One:  Mechanisms for Specifying and
        Describing the Format of Internet Message Bodies",
        RFC 1521, Bellcore, Innosoft, September 1993.

    [RFC 822]
        Crocker, D., "Standard for the Format of ARPA Internet
        Text Messages", STD 11, RFC 822, UDEL, August 1982.

[7. 謝辞]

We gratefully acknowledge the help these people provided
during the preparation of this draft:

            Nathaniel Borenstein
            Ned Freed
            Keith Moore
            Dave Crocker
            Dan Pritchett

[8. 著者のアドレス]

   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

スポンサーリンク

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ディレクトリ以下のファイル数、ファイル容量を調べる

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る