1. はじめに (Introduction)
最近のインターネットプロトコルは、特定の領域で容易に拡張できるように注意深く設計されています。特に、HTTP [RFC2616] や MIME [RFC2045] を含む多くのプロトコルは、任意のラベル付きコンテンツを運ぶことができます。
このようなコンテンツにラベルを付けるために使用されるメカニズムは、メディアタイプ (Media Type) です。メディアタイプは、トップレベルタイプ (Top-Level Type) とサブタイプ (Subtype) で構成され、さらにツリー構造に構造化されます。オプションとして、メディアタイプはパラメータ (Parameters) として知られる付随データを定義することができます。
これらのラベルには登録プロセスが必要であり、そのような値のセットが合理的に秩序正しく、明確に仕様化され、公開された方法で定義されるようにします。
本文書は、メディアタイプ登録の基準を規定し、Internet Assigned Numbers Authority (IANA) 中央レジストリにメディアタイプ (セクション5) およびメディアタイプの構造化サフィックス (Structured Suffixes, セクション6) を登録するために使用される手続きを定義します。
これらの手続きによって管理されるメディアタイプレジストリの場所は次のとおりです:
http://www.iana.org/assignments/media-types/
1.1 歴史的な注記 (Historical Note)
メディアタイプ登録プロセスは、当初、非同期インターネットメール環境のコンテキストで使用するためのメディアタイプを登録するために定義されました。このメール環境では、リモートメールシステムの機能が不明な場合に相互運用性の可能性を高めるために、可能なメディアタイプの数を制限する必要があります。メディアタイプの普及が相互運用性の妨げにならない新しい環境でメディアタイプが使用されるようになると、元の手続きは過度に制限的であることが判明し、一般化する必要がありました。これは最初に [RFC2048] で行われましたが、そこで定義された手続きはまだ MIME 文書セットの一部でした。メディアタイプの仕様と登録手続きは現在、MIME から独立していることを明確にするために、別個の文書となっています。
メディアタイプの使用を特定の環境に制限したり、他の環境での使用を禁止したりすることが望ましい場合があります。本仕様は、そのような制限をメディアタイプ登録に体系的な方法で組み込んでいます。詳細については、セクション 4.9 を参照してください。
1.2 本文書で使用される規約 (Conventions Used in This Document)
本文書のキーワード "MUST" (しなければならない)、"MUST NOT" (してはならない)、"REQUIRED" (必須である)、"SHALL" (しなければならない)、"SHALL NOT" (してはならない)、"SHOULD" (すべきである)、"SHOULD NOT" (すべきでない)、"RECOMMENDED" (推奨される)、"MAY" (してもよい)、"OPTIONAL" (任意である) は、全て大文字で表記される場合、[RFC2119] に記述されているように解釈されるものとします (MUST)。これらの単語は、小文字または混在ケースで平易な英語の単語として表示されることもありますが、その場合は規範的な意味を持ちません。
本仕様は、拡張バッカス・ナウア記法 (Augmented Backus-Naur Form, ABNF) [RFC5234] 表記を使用します。これには、その文書の付録 B で定義されているコアルールが含まれます。