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
一覧
スポンサーリンク
