MIME 型の木
[3] MIME型の部分型には次の木があります。
[5] . を含まない部分型は標準木
>>1 に属するとされ、 IETF の手続きに従い発行された RFC
により、または IESG が承認した他の標準化団体の仕様書により定義される
MIME型が使えることになっています。
[20] RFC 2048 よりも前の時代に登録された MIME型や IANA登録簿に登録されていない
MIME型は、 IETF の手続きに従っていなくても .
を含まないことが大多数です。[6] vnd. から始まる部分型が属するのは事業者木
>>1 で、企業の製品や IETF が承認していない団体の仕様により用いられる
MIME型が使うことになっています。 image/vnd.microsoft.icon
の microsoft のような事業者名も (IANA の管理により)
木内の階層として使えることになっていますが、 text/vnd.abc
のように事業者名のない形を登録することも認められています。
[22] Web における vendor prefix とは違って、 vnd.
木でも IANA への登録が必要です。[7] prs. から始まる部分型が属するのは個人木 >>1 で、
実験的なものや非営利製品で用いる MIME型が使うことになっています。
[8] vnd. や prs. は、 IANA への申請のみで
(IETF での手続きなしで) 登録できることになっています。
また引数に関する要件も標準木より緩和されています。
MIME型参照。[9] x. から始まる部分型が属するのは私的な利用 >>1
のための MIME型の木です。 IANA に登録することはできず、
登録なしで利用できることになっています。
[10] IETF は、 vnd.
や prs. に簡単に登録できるのだから x.
はほとんど使うことは無いはずだ >>1 としています。確かに x.
は滅多にみかけませんが、 x- は極めてよく見かけます。
[11] x- は当初から私用のために割り当てられており、 IANA
に登録できないことになっていましたが、
有害であるとして廃止する方針となり (RFC 6648)、 RFC 6838
以後通常の MIME型として登録できることになっています。
[12] RFC 2048 時点で既に x- があったのにわざわざ x.
を追加したのは何のためなのかよくわかりませんが。。。[13] RFC 6638 で x- の特別扱いを廃してなぜ x.
は残したのかは謎です。 RFC 6648 の意図に沿うなら両方廃止するべきだと思いますが。。。[14] 実際には vnd. の登録は多くなされていますし、
prs. もたまに登録されていますが、それ以上に多くの MIME型が
(x- つき、あるいは x- なしで) 未登録で用いられています。
MIME型も参照。[15] 新しい木を将来的に規定することも一応は想定されています >>1
が、前例はなく、今後も追加されるとは考え難い状況です。
[16] なお vnd. のような木を表す部分は facet >>17
と呼ばれており、標準木は「facet-less」と表現されています。
[18] MIME型における最初の . より前の部分は facet
を表すことになっています >>17。標準木の部分型は .
を含めることはできません。2つ目以降の . の意味は >>6
以外は明確に規定されておらず、木以外の用法も禁止はされていません。
部分型でなく型については . の解釈は不明です。
現実には部分型と同じように vnd. で始まるような (登録されていない)
型も利用されています。
[19] こうした制約は IANA登録簿に登録する MIME型に対するもので、
未登録の MIME型の扱いは明確ではありません。
[29]
application/vnd.geo+json と application/geo+json
のように、後から他の木に登録される事例もあります。
[30] こういうことがあると結局新旧MIME型が混在することになるので、
相互運用性に悪影響しか及ぼされないんですよねえ。。。歴史
[4] MIME型における木は RFC 2048 で導入され、以後の改訂でも引き継がれています。
MIME型の歴史の項を参照。[21] draft-king-vnd-urlscheme は URL scheme に木を導入することを提案していました。
[26] RFC 2244 - ACAP -- Application Configuration Access Protocol, , https://tools.ietf.org/html/rfc2244#section-7.4