[6] disposition型 inline は、当該本体部分がメッセージの一部分として行内に表示されるべきことを表しています。

仕様書

意味

[2] MIME におけるdisposition型 inline は、 メッセージの表示の際に自動的に表示されるべき本体部分であることを示します >>1。

[4] RFC 2183 は Content-Disposition: ヘッダーが明示されていない場合の MUA の動作は規定せず MUA 依存としていますが、一般的には MUA が自身で処理できるMIME型であれば Content-Disposition: inline と同等として扱うようです。

[7] Content-Disposition: inline は MUA における添付ファイルを表す Content-Disposition: attachment と対になる扱いを表していて、利用者が意図的に操作することで (多くの場合) 外部アプリケーションで開いたりファイルシステムに保存したりする添付ファイルとしての表示ではなく、 MUA 内で直接表示されるメール本文を構成する一部分としての表示が望まれていることを示しています。

[11] HTTP におけるdisposition型 inline は、 既定の処理を表しています >>10。

[12] 従って inline を明示するのが有用なのは、 その後に引数が続く場合のみです >>10。[13] HTTP では Content-Disposition: 無指定は inline と等価ということになります。

文脈

[16] VPIM では、音声はすべて inline としなければなりません >>15。

[18] Content-Disposition: ヘッダーも必須となっています。

レンダリング

[3] inline の本体部分は元の順序のままで multipart/* メッセージの通常の意味に従って提示するべきshouldです >>1。

[5] Content-Disposition: inline と指定されていて、 MUA が通常の方法でレンダリングできない場合に、 どう処理するべきかは明らかではありません。 一般的には Content-Disposition: attachment と同じように添付ファイルとして扱われるようです。

歴史

[9] RFC 1806 で定義され、改訂された RFC 2183 にも引き継がれています。

[14] HTTP に関して RFC 2616 は inline を定義に含めていましたが、 RFC 6266 で復活しました >>17。

関連

[8] Content-Disposition: inline であっても、 filename などの引数を指定することが禁止されているわけではありません。

[19] SIP は、 inline と似ているが異なるとして、 Content-Disposition: render を別に定義し、 専らそちらを利用しています。 SDP も render を用いていますが、その用法は inline と同じように見えます。