[2] IETF のいくつかの仕様では、名前空間を . 区切りで分割し、
それぞれを木と呼んでいます。
木は、 IANA登録簿への登録手続きの種類により分類されています。
[5] . を含まない部分型は標準木
>>1 に属するとされ、 IETF の手続きに従い発行された RFC
により、または IESG が承認した他の標準化団体の仕様書により定義される
MIME型が使えることになっています。
[6] vnd. から始まる部分型が属するのは事業者木
>>1 で、企業の製品や IETF が承認していない団体の仕様により用いられる
MIME型が使うことになっています。 image/vnd.microsoft.icon
の microsoft のような事業者名も (IANA の管理により)
木内の階層として使えることになっていますが、 text/vnd.abc
のように事業者名のない形を登録することも認められています。
[7] prs. から始まる部分型が属するのは個人木 >>1 で、
実験的なものや非営利製品で用いる MIME型が使うことになっています。
[8] vnd. や prs. は、 IANA への申請のみで
(IETF での手続きなしで) 登録できることになっています。
また引数に関する要件も標準木より緩和されています。
[9] x. から始まる部分型が属するのは私的な利用 >>1
のための MIME型の木です。 IANA に登録することはできず、
登録なしで利用できることになっています。
[10] IETF は、 vnd.
や prs. に簡単に登録できるのだから x.
はほとんど使うことは無いはずだ >>1 としています。確かに x.
は滅多にみかけませんが、 x- は極めてよく見かけます。
[11] x- は当初から私用のために割り当てられており、 IANA
に登録できないことになっていましたが、
有害であるとして廃止する方針となり (RFC 6648)、 RFC 6838
以後通常の MIME型として登録できることになっています。
[14] 実際には vnd. の登録は多くなされていますし、
prs. もたまに登録されていますが、それ以上に多くの MIME型が
(x- つき、あるいは x- なしで) 未登録で用いられています。
[15] 新しい木を将来的に規定することも一応は想定されています >>1 が、前例はなく、今後も追加されるとは考え難い状況です。
[16] なお vnd. のような木を表す部分は facet >>17
と呼ばれており、標準木は「facet-less」と表現されています。
[18] MIME型における最初の . より前の部分は facet
を表すことになっています >>17。標準木の部分型は .
を含めることはできません。2つ目以降の . の意味は >>6
以外は明確に規定されておらず、木以外の用法も禁止はされていません。
部分型でなく型については . の解釈は不明です。
現実には部分型と同じように vnd. で始まるような (登録されていない)
型も利用されています。
[29]
application/vnd.geo+json と application/geo+json
のように、後から他の木に登録される事例もあります。
[23] URL scheme 参照。
[27]
RFC 3659 の FTP facts は、木とは呼んでいませんが、
類似の構造を持っていました。
x. は私用、実験用とされていました。
他に OS. や OS の名前を使うことになっていました。
[28] rfc3659, https://datatracker.ietf.org/doc/html/rfc3659#section-7.5
[4] MIME型における木は RFC 2048 で導入され、以後の改訂でも引き継がれています。
[21] draft-king-vnd-urlscheme は URL scheme に木を導入することを提案していました。
[26] RFC 2244 - ACAP -- Application Configuration Access Protocol, , https://tools.ietf.org/html/rfc2244#section-7.4
.を含まないことが大多数です。