[6] disposition型 inline は、当該本体部分がメッセージの一部分として行内に表示されるべきことを表しています。
[2] MIME におけるdisposition型 inline は、
メッセージの表示の際に自動的に表示されるべき本体部分であることを示します >>1。
[4] RFC 2183 は Content-Disposition: ヘッダーが明示されていない場合の
MUA の動作は規定せず MUA 依存としていますが、一般的には MUA
が自身で処理できるMIME型であれば Content-Disposition: inline
と同等として扱うようです。
[3] inline の本体部分は元の順序のままで multipart/*
メッセージの通常の意味に従って提示するべきです >>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 と同じように見えます。
Content-Disposition: inlineは MUA における添付ファイルを表すContent-Disposition: attachmentと対になる扱いを表していて、利用者が意図的に操作することで (多くの場合) 外部アプリケーションで開いたりファイルシステムに保存したりする添付ファイルとしての表示ではなく、 MUA 内で直接表示されるメール本文を構成する一部分としての表示が望まれていることを示しています。