[45] MIME型の構造化構文接尾辞は、
そのMIME型が用いている一般的な構文 (構造化構文、メタ書式)
を表すものです。 MIME型の末尾に +
で区切って記述します。構造化構文接尾辞は、MIME型の一部です。
[46] 例えば MIME型 image/svg+xml では、末尾の
+xml が構造化構文接尾辞です。 MIME型全体では SVG
を表しますが、構造化構文接尾辞は XML を表しており、 SVG
としての処理に対応していなかったとしても、 XML としての処理には対応していれば、
そのレベルでこの MIME型を理解できることになります。
[2] >>1 は用語が長過ぎるとして+接尾辞と呼んでいます。
[6] MIME型の部分型部分の末尾に + と構造化構文の名前を記述できます。
[8] 名前のある構造化構文を使う MIME型は、構造化構文接尾辞を使うべきです >>53。
[32] MIME型は全体として意味を持つもので、 構造化構文接尾辞を除いた部分が一致したりしなかったりしても、 そのことに特別な意味はありません。
[36] ある仕様書で example/foo+xml が定義されたとしても、
example/foo+json が自動的に定義されることはありません。
両者がまったく異なる意味で用いられる可能性すらあります。
[12] 構造化構文接尾辞を複数連ねることができるのかどうかは不明瞭です。
[9] MIME型は実際に使っていない構造化構文接尾辞を含めてはなりません >>53。
[19] 構造化構文を表すために構造化構文接尾辞を使うことはできますが、 それが義務付けられているわけではありません。
[20] 動画や音声の container format は構造化構文の定義に当てはまりそうではありますが、
container format と codec の組み合わせに個別にMIME型を与えることはほとんどありません。
普通は container format ごとの一般的な MIME型を使い、
必要に応じて codecs 引数を補うことになっています。
[17] いつ構造化構文接尾辞付きMIME型を使うべきで、いつ一般的な MIME型を使うべきなのか、一般的な規則はなさそうです。
[18] 例えば XML に基づく言語である SVG は、
text/xml という一般的な MIME型と
image/svg+xml という専用の MIME型があります。
SVG に限れば image/svg+xml とした方が便利そうです。
しかしどちらを使うべきか (そもそも専用の MIME型を用意するべきか)
の一般的な規則はなさそうです。
[37] なお、構造化構文接尾辞付きMIME型は構造化構文接尾辞共通の素片識別子の規定に従わなければならない (そうでない場合は構造化構文接尾辞を使わない MIME型を使わなければならない) との規定があります。
[10] 構造化構文接尾辞の IANA登録簿 >>50 が (MIME型登録簿とは別に) あります >>53, >>14。
[11] 未登録の構造化構文接尾辞を使うべきではありません >>53。
[21] 構造化構文接尾辞は、未知の MIME型でも構造化構文がわかれば一般的な処理を適用できるはず、 という前提に基づいています。しかし実際にはその意図通りに実装されているとは限りません。
[13] multipart/* は、時代が異なれば構造化構文接尾辞だったかもしれません。
[40] application/senml+xml などのシリーズと
application/sensml+xml などのシリーズは、 EXI だけ
(構造化構文接尾辞がIANAに登録されていないためか)
application/senml-exi と application/sensml-exi
になっています。
+」の用法[48] MIME型の中で + という記号は当初から予約されていたものではありませんでしたから、
構造化構文接尾辞以外の意味で + が使われることもあります。
[34]
audio/amr-wb+ というのが登録されています。
application/xhtml+voice+xml には物言いがついたのに。
(名無しさん 2006-07-02 03:17:54 +00:00)
[35]
ちなみに巷で使われているものにはほかに application/x-xhtml+voice+xml なんてのもあります。
(名無しさん 2006-07-02 03:19:04 +00:00)
[44] application/x-dd+ext ってのもありますね。
[51] text/x-c++, text/x-c++hdr,
text/x-c++src,
text/x-objective-c++ などもあります。
[5] application/x-tar+gzip は圧縮形式を表しており、
厳密には構造化構文とはいえないかもしれません。
[24] application/rdf+xml+abbrev,
application/json+ld,
application/x-json+ld
なるものもあります。
+ が単なる語境界になってしまっています。
[25] CPHL は含まれる情報の種類を指定するためにいくつも + と種別を本来の
MIME型の後に続けられるとしています。
[28] Pygments は JavaScript と PHP を text/javascript+php
といったように言語の組み合わせを表すために + を使っています。
[30] text/x-h2h+html は HTML が混用されるモードを表していました。
[38] oEmbed は */*+oembed
を使っていますが、どちらかといえば xml や json
のように * の部分の方が構造化構文に見えるものです。
[39] その他 application/json+* で JSON
の応用を表す場合があるようです。
[33]
RFC 3023 の +xml
以来、 XML と XML応用のような関係を示すために、
媒体型の末尾に +書式名
のような文字列をつけるようになりました。
この接尾辞は、 RFC 3023 で +xml
が定義されているのと、 RFC 4288
で (将来同様な規定が他の書式に対してもなされることに対して)
注意が促されている他は、明確に定義されているわけではありませんでした。
[52] RFC 3023 - XML Media Types ( ( 版)) http://tools.ietf.org/html/rfc3023#appendix-A
[49] RFC 6838 で登録手続きが定義され、 RFC 6839 で用法が明確化されて初期状態での接尾辞の定義・登録が行われました。
[41] Media Types with Multiple Suffixes, https://rhiaro.github.io/draft-w3cdidwg-media-types-with-multiple-suffixes/
[42] draft-w3cdidwg-media-types-with-multiple-suffixes-00 - Media Types with Multiple Suffixes, , https://tools.ietf.org/html/draft-w3cdidwg-media-types-with-multiple-suffixes-00