standards tree

木 (IETF)

[2] IETF のいくつかの仕様では、名前空間. 区切りで分割し、 それぞれを (tree) と呼んでいます。 は、 IANA登録簿への登録手続きの種類により分類されています。

仕様書

MIME 型の木

[3] MIME型部分型には次のがあります。

[5] . を含まない部分型標準木 (standards tree) >>1 に属するとされ、 IETF の手続きに従い発行された RFC により、または IESG が承認した他の標準化団体の仕様書により定義される MIME型が使えることになっています。

[20] RFC 2048 よりも前の時代に登録された MIME型IANA登録簿に登録されていない MIME型は、 IETF の手続きに従っていなくても . を含まないことが大多数です。

[6] vnd. から始まる部分型が属するのは事業者木 (vendor tree) >>1 で、企業の製品や IETF が承認していない団体の仕様により用いられる MIME型が使うことになっています。 image/vnd.microsoft.iconmicrosoft のような事業者名も (IANA の管理により) 内の階層として使えることになっていますが、 text/vnd.abc のように事業者名のない形を登録することも認められています。

[22] Web における vendor prefix とは違って、 vnd. でも IANA への登録が必要です。

[7] prs. から始まる部分型が属するのは個人木 (personal tree) >>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 6638x- の特別扱いを廃してなぜ 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+jsonapplication/geo+json のように、後から他のに登録される事例もあります。

[30] こういうことがあると結局新旧MIME型が混在することになるので、 相互運用性に悪影響しか及ぼされないんですよねえ。。。

URL scheme の木

[23] URL scheme 参照。

媒体特徴タグの木

[25] IETF木の他に大域木 g., URI木 u. がありました。 媒体特徴タグ

FTP facts の木

[27] RFC 3659FTP facts は、とは呼んでいませんが、 類似の構造を持っていました。 x.私用実験用とされていました。 他に OS.OS の名前を使うことになっていました。

[28] rfc3659, https://datatracker.ietf.org/doc/html/rfc3659#section-7.5

歴史

[4] MIME型におけるRFC 2048 で導入され、以後の改訂でも引き継がれています。

MIME型の歴史の項を参照。

[21] draft-king-vnd-urlschemeURL schemeを導入することを提案していました。

[26] RFC 2244 - ACAP -- Application Configuration Access Protocol, , https://tools.ietf.org/html/rfc2244#section-7.4