インターネット技術タスクフォース (IETF) N. Freed
Request for Comments: 6838 Oracle
BCP: 13 J. Klensin
旧版: 4288
分類: 現行の最良慣行 T. Hansen
ISSN: 2070-1721 AT&T Laboratories
2013年1月
メディアタイプの仕様および登録手順
概要
この文書は、HTTP、MIME、およびその他のインターネット
プロトコルで使用するメディアタイプの仕様策定および
登録のための手順を定義する。
このメモの位置付け
このメモは、インターネットの現行の最良慣行を文書化したものである。
この文書は、インターネット技術タスクフォース
(IETF) の成果物である。これは IETF コミュニティの合意を
表している。公開レビューを受けており、
インターネット技術運営グループ (IESG) によって公開が承認されている。
BCP に関する詳細情報は、RFC 5741 のセクション 2に記載されている。
この文書の現在の状態、正誤表、および
フィードバックの提供方法に関する情報は、
http://www.rfc-editor.org/info/rfc6838 で入手できる。
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Freed, et al. 現行の最良慣行 [1ページ]
RFC 6838 メディアタイプ登録 2013年1月
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 歴史的注記 . . . . . . . . . . . . . . . . . . . . . 3
1.2. この文書で使用する規約 . . . . . . . . . . . . . . . 4
2. メディアタイプ登録の準備事項 . . . . . . . . . . . . . . 4
3. 登録ツリーとサブタイプ名 . . . . . . . . . . . . . . . . 4
3.1. 標準ツリー . . . . . . . . . . . . . . . . . . . . . . 4
3.2. ベンダーツリー . . . . . . . . . . . . . . . . . . . 6
3.3. 個人またはバニティツリー . . . . . . . . . . . . . . 6
3.4. 未登録 x. ツリー . . . . . . . . . . . . . . . . . . . 7
3.5. 追加の登録ツリー . . . . . . . . . . . . . . . . . . 7
4. 登録要件 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. 機能要件 . . . . . . . . . . . . . . . . . . . . . . 8
4.2. 命名要件 . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. テキストメディアタイプ . . . . . . . . . . . . . 9
4.2.2. 画像メディアタイプ . . . . . . . . . . . . . . . 10
4.2.3. 音声メディアタイプ . . . . . . . . . . . . . . . 10
4.2.4. 動画メディアタイプ . . . . . . . . . . . . . . . 10
4.2.5. アプリケーションメディアタイプ . . . . . . . . 11
4.2.6. Multipart および Message メディアタイプ . . . . 11
4.2.7. 追加のトップレベルタイプ . . . . . . . . . . . . 12
4.2.8. 構造化構文名サフィックス . . . . . . . . . . . . 12
4.2.9. 非推奨の別名 . . . . . . . . . . . . . . . . . . . 13
4.3. パラメーター要件 . . . . . . . . . . . . . . . . . . 13
4.4. 正規化および形式要件 . . . . . . . . . . . . . . . . 14
4.5. 相互交換に関する推奨事項 . . . . . . . . . . . . . . 15
4.6. セキュリティ要件 . . . . . . . . . . . . . . . . . . 15
4.7. XML メディアタイプ固有の要件 . . . . . . . . . . . . 16
4.8. エンコーディング要件 . . . . . . . . . . . . . . . . 16
4.9. 使用および実装の非要件 . . . . . . . . . . . . . . . 17
4.10. 公開要件 . . . . . . . . . . . . . . . . . . . . . . 18
4.11. フラグメント識別子要件 . . . . . . . . . . . . . . . 18
4.12. 追加情報 . . . . . . . . . . . . . . . . . . . . . . 19
5. メディアタイプ登録手順 . . . . . . . . . . . . . . . . . 19
5.1. 事前コミュニティレビュー . . . . . . . . . . . . . . 19
5.2. IANA への要求提出 . . . . . . . . . . . . . . . . . . 20
5.2.1. 暫定登録 . . . . . . . . . . . . . . . . . . . . 20
5.3. レビューと承認 . . . . . . . . . . . . . . . . . . . 21
5.4. メディアタイプ登録へのコメント . . . . . . . . . . . 21
5.5. 変更手順 . . . . . . . . . . . . . . . . . . . . . . 21
5.6. 登録テンプレート . . . . . . . . . . . . . . . . . . 22
6. 構造化構文サフィックス登録手順 . . . . . . . . . . . . . 23
6.1. 変更手順 . . . . . . . . . . . . . . . . . . . . . . 24
6.2. 構造化構文サフィックス登録テンプレート . . . . . . . 24
7. セキュリティに関する考慮事項 . . . . . . . . . . . . . 25
8. IANA に関する考慮事項 . . . . . . . . . . . . . . . . . 26
9. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . 27
Freed, et al. 現行の最良慣行 [2ページ]
RFC 6838 メディアタイプ登録 2013年1月
10. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. 規範的参考文献 . . . . . . . . . . . . . . . . . . . . 27
10.2. 参考情報 . . . . . . . . . . . . . . . . . . . . . . . 28
付録 A. 既得権のあるメディアタイプ . . . . . . . . . . . . . 30
付録 B. RFC 4288 以降の変更 . . . . . . . . . . . . . . . . 30
1. はじめに
最近のインターネットプロトコルは、特定の領域で容易に
拡張できるよう慎重に設計されている。特に、HTTP [RFC2616] や MIME [RFC2045] を
含むがこれらに限定されない多くのプロトコルは、任意のラベル付き
コンテンツを伝送できる。
このようなコンテンツにラベルを付けるために使用される仕組みがメディアタイプであり、
トップレベルタイプとサブタイプから構成され、さらに
ツリーとして構造化される。任意で、メディアタイプは
パラメーターと呼ばれる付随データを定義できる。
これらのラベルには登録プロセスが必要であり、その値の集合が
適度に秩序立ち、十分に仕様化され、かつ
公開された形で定義されるようにする。
この文書はメディアタイプ登録の基準を規定し、
Internet Assigned Numbers Authority (IANA) の中央レジストリにメディアタイプ (セクション 5)
およびメディアタイプの構造化サフィックス (セクション 6) を登録するために使用する
手順を定義する。
これらの手順によって管理されるメディアタイプレジストリの場所
は次のとおりである:
http://www.iana.org/assignments/media-types/
1.1. 歴史的注記
メディアタイプ登録プロセスは当初、
非同期インターネットメール環境の文脈で使用するメディアタイプを
登録するために定義された。このメール環境では、リモートの
メールシステムの能力が不明な場合の相互運用性の
可能性を高めるため、利用可能なメディアタイプの数を
制限する必要がある。メディアタイプが、
メディアタイプの増加が相互運用性の妨げとならない新しい
環境で使用されるようになるにつれ、当初の手順は
過度に制限的であることが判明し、一般化する必要が生じた。これは
当初 [RFC2048] で行われたが、そこで定義された手順は
依然として MIME 文書群の一部であった。メディアタイプの仕様
および登録手順は、現在では MIME から独立していることを
明確にするため、別個の文書となっている。
Freed, et al. 現行の最良慣行 [3ページ]
RFC 6838 メディアタイプ登録 2013年1月
メディアタイプの使用を特定の
環境に制限したり、他の環境での使用を禁止したりすることが望ましい場合がある。この
仕様は、そのような制限を体系的な方法でメディアタイプ
登録に組み込む。詳細については セクション 4.9 を
参照されたい。
1.2. この文書で使用する規約
この文書におけるキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、
"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、
すべて大文字で現れる場合、[RFC2119] に記述されているとおりに
解釈されるものとする。これらは小文字または大文字小文字混在で、
規範的な意味を持たない通常の英単語として現れる場合もある。
この仕様では、Augmented Backus-Naur Form (ABNF)
[RFC5234] 記法を使用し、同文書の 付録 B で定義される
コアルールも含む。
2. メディアタイプ登録の準備事項
新しいメディアタイプの登録は、
登録提案の作成から始まる。登録は、以下で説明するように
異なる要件を持つ複数の登録ツリーで行われる場合がある。一般に、
新しい登録提案は、関係するツリーに適した方法で
回覧され、レビューされる。その後、提案が
受け入れ可能であれば、メディアタイプが登録される。以下のセクションでは、
各種登録ツリーで使用される要件および
手順について説明する。
3. 登録ツリーとサブタイプ名
登録プロセスの効率性と柔軟性を
高めるため、さまざまな自然な要件に対応できるよう、
異なる構造のサブタイプ名を登録できる。
例えば、インターネットコミュニティによる広範なサポートと
実装が推奨されるサブタイプや、
独自ソフトウェアに関連するファイルを転送するために使用されるサブタイプなどである。以下の
サブセクションでは、ファセット付き名称の使用によって区別される
登録「ツリー」を定義する。例えば、"tree."
プレフィックスで始まるサブタイプ名である。この文書以前に定義された一部のメディアタイプは、
以下で説明する命名規則に準拠していないことに注意されたい。それらについては
付録
A を参照されたい。
3.1. 標準ツリー
標準ツリーは、インターネットコミュニティ全般に関心のあるタイプを
対象としている。標準ツリーへの登録は、次のいずれかでなければならない (MUST):
Freed, et al. 現行の最良慣行 [4ページ]
RFC 6838 メディアタイプ登録 2013年1月
1. IETF 仕様に関連する登録の場合、
IESG によって直接承認される、または
2. 認定された標準関連組織によって、
"Specification Required" IANA 登録ポリシー [RFC5226]
（これは Expert Review を意味する）を使用して登録される。
最初の手順は IETF Consensus
文書からの登録、またはまれに、既得権のある（
付録 A を参照）および／またはその他の点で不完全な登録を行うことが
インターネットコミュニティの利益となる場合に使用される。登録提案は
RFC として公開されなければならない (MUST)。登録 RFC が IETF
ストリームにある場合、IETF Consensus を得なければならず、これは
Standards Track、BCP、Informational、または Experimental の
ステータスによって達成できる。非 IETF RFC ストリームで公開される登録も許可され、
IESG の承認を必要とする。登録は、独立した
「登録のみ」の RFC とすることも、より一般的な
何らかの仕様に組み込むこともできる。
2 番目の場合、IESG は、登録申請者が認定された標準関連
組織を代表しているかどうかについて一度だけ判断する。
その後、Media Types Reviewer（Designated Expert
または Designated Experts のグループ）が、この文書で
規定されている Expert Review を実施する。同じ
申請元からの以後の提出には IESG は関与しない。形式は、
提出する標準関連組織が作成した正式な
標準仕様によって記述されなければならない (MUST)。
標準ツリー内のメディアタイプは、
付録 A で説明されるプロセスによって既得権を認められた場合を除き、
ファセット付き名称を持ってはならない (MUST NOT)。
標準ツリーに登録されたメディアタイプの「所有者」は、
標準関連組織そのものとみなされる。
仕様の修正または変更には、最初の登録に必要だったものと
同じレベルの処理を使用する（例えば、Standards Track で提出された登録は
別の Standards Track RFC で改訂できるが、
Informational RFC で改訂することはできない）。
認定された標準関連組織による標準ツリー登録は
IANA に直接提出され、承認前に
Expert Review [RFC5226] を受ける。この場合、
Expert Reviewer は、とりわけ、必要な
仕様が十分な文書を提供していることを確認する。
Freed, et al. 現行の最良慣行 [5ページ]
RFC 6838 メディアタイプ登録 2013年1月
3.2. ベンダーツリー
ベンダーツリーは、公に利用可能な製品に関連するメディアタイプに
使用される。この文脈では "Vendor" と "producer" は非常に
広い意味で解釈され、同等であるとみなされる。
認定された標準関連組織に該当しない
業界コンソーシアムや非営利団体も、
ベンダーツリーにメディアタイプを適切に登録できることに注意されたい。
何らかの製品または製品群に関連するファイルを
交換する必要がある者は、誰でもベンダーツリーに登録を置くことができる。
ただし、その登録は本来、登録されるタイプを使用する
ソフトウェアを製造するベンダーまたは組織に属するものであり、
そのベンダーまたは組織は、第三者によって行われた登録を
修正または更新するために、いつでもその所有権を
主張することを選択できる。詳細は セクション 5.5 を参照されたい。
第三者が他者に代わってタイプを登録する場合、
両方の主体を登録の Change Controller フィールドに
記載すべきである (SHOULD)。考えられる形式の一例は "Foo, on behalf
of Bar" である。
ベンダーツリーの登録は、先頭のファセット
"vnd." によって区別される。その後には、登録者の裁量により、
著名な製造者のメディアサブタイプ名（例えば
"vnd.mudpie"）、または IANA が承認した製造者名の識別子に続いて
メディアタイプまたは製品識別子を置くことができる（例えば
vnd.bigcompany.funnypictures）。
ベンダーツリーに登録されるメディアタイプの公開およびレビューは
必須ではないが、それらの仕様の品質を
改善するため、media-types@iana.org
メーリングリストをレビューに使用することが推奨される。
ベンダーツリーへの登録は IANA に直接提出でき、
承認前に Expert Review
[RFC5226] を受ける。
3.3. 個人またはバニティツリー
実験的に作成されたメディアタイプ、または
商業的に配布されない製品の一部として作成されたメディアタイプは、
個人またはバニティツリーに登録できる。登録は
先頭のファセット "prs." によって区別される。
「個人」登録および関連仕様の所有者は、
登録を行った個人または主体、あるいは以下で説明するように
責任が移管された者である。
Freed, et al. 現行の最良慣行 [6ページ]
RFC 6838 メディアタイプ登録 2013年1月
個人ツリーに登録されるメディアタイプの公開およびレビューは
必須ではないが、それらの仕様の品質を改善するため、
media-types@iana.org メーリングリスト（セクション 5.1 を参照）を
レビューに使用することが推奨される。個人
ツリーへの登録は IANA に直接提出でき、
承認前に Expert Review [RFC5226] を受ける。
3.4. 未登録 x. ツリー
最初のファセットが "x." であるサブタイプ名は、
私的なローカル環境でのみ使用することを意図したタイプに
使用できる。このツリーのタイプは登録できず、
交換当事者の積極的な合意がある場合にのみ
使用することを意図している。
ただし、上記で説明したベンダーツリーおよび個人ツリー向けの
簡略化された登録手順により、未登録タイプを使用する
必要が生じることは、仮にあったとしても極めてまれであるはずである。
したがって、"x." ツリー内のタイプの使用は強く推奨されない。
"x-" で始まる名称を持つタイプは、もはや
このツリーのメンバーとはみなされないことに注意されたい（[RFC6648] を参照）。
また、一般に有用で広く配備されたタイプが誤って
"x-" 名プレフィックスを持つに至った場合、
付録 A で定義された手順に従うことにより、
現在の名称のまま別のツリーへ登録してもよい (MAY)。
3.5. 追加の登録ツリー
必要に応じて、またコミュニティの要求に応じて、
IETF Standards Action によって新しいトップレベル
登録ツリーを作成できる。これらのツリーは、
著名な恒久的組織による外部登録および管理のために
作成される可能性があることが明示的に想定されている。
例えば、科学学会は、その学会が扱う科学分野固有の
メディアタイプを登録できる。一般に、これら追加の登録ツリーの
いずれかに対する仕様レビューの品質は、
認定された標準関連組織による標準ツリーへの
登録と同等であることが期待される。IETF が
このようなレビューを行う場合、対象メディアタイプに関する
申請組織のより高度な専門知識を考慮する必要がある。
4. 登録要件
すべてのメディアタイプ登録は、以下のセクションで定める
各種要件に準拠することが期待される。
要件の詳細は登録ツリーによって異なる場合があり、
これについても以下のセクションで詳述する。
Freed, et al. 現行の最良慣行 [7ページ]
RFC 6838 メディアタイプ登録 2013年1月
4.1. 機能要件
メディアタイプは実際のメディア形式として機能しなければならない (MUST)。
転送エンコーディング、文字集合、または
別タイプの個別エンティティの集合と考える方が適切なものを
登録することは許可されない。例えば、
base64 転送エンコーディング [RFC2045] をデコードするアプリケーションは存在するが、
base64 をメディアタイプとして登録することはできない。
この要件は、関係する登録ツリーにかかわらず適用される。
4.2. 命名要件
登録されるすべてのメディアタイプには、トップレベルタイプ名と
サブタイプ名を割り当てなければならない (MUST)。これらの名称の組み合わせは、
メディアタイプを一意に識別するために使用され、サブタイプ名のファセット
（またはその欠如）は登録ツリーを識別する。トップレベルタイプ名と
サブタイプ名はいずれも大文字小文字を区別しない。
タイプ名とサブタイプ名は、次の ABNF に準拠しなければならない (MUST):
type-name = restricted-name
subtype-name = restricted-name
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; 最初のドットより前の文字は常に
; ファセット名を指定する
restricted-name-chars =/ "+" ; 最後のプラスより後の文字は常に
; 構造化構文サフィックスを指定する
この構文は、[RFC2045] のセクション 5.1 または [RFC4288] の
セクション 4.2 の ABNF で許可されるものよりやや制限が厳しいことに注意されたい。
また、この構文では最大
127 文字の名称を許可しているが、実装上の制限により、そのような長い名称が
問題になる場合がある。そのため、<type-name> および <subtype-name> は
64 文字以内に制限すべきである (SHOULD)。
名称構文では "." を他の任意の文字と同等に
扱うが、最初の "." より前の文字は常に
登録ファセットを指定する。これは、ファセットを持たない標準
ツリー登録では、サブタイプ名にピリオドを使用できないことを意味する。
Freed, et al. 現行の最良慣行 [8ページ]
RFC 6838 メディアタイプ登録 2013年1月
同様に、サブタイプ名の最後の "+" は、構造化
構文指定子サフィックスを導入する。構造化構文サフィックスの要件は
セクション 4.2.8 で規定される。
特定のメディアタイプに追加の
名称を割り当てることは可能であるが、同じメディアタイプを識別するために
異なる名称を使用することは推奨されない。
これらの要件は、関係する登録ツリーにかかわらず
適用される。
トップレベルタイプの選択では、対象となる
メディアタイプの性質を考慮しなければならない (MUST)。トップレベルタイプの新しいサブタイプは、
そのトップレベルタイプに制限がある場合、それに準拠しなければならない (MUST)。
以下のセクションでは、最初に定義された各トップレベルタイプと、
それぞれに関連する制限について説明する。さらに、HTTP や MIME を
含むがこれらに限定されない各種プロトコルは、伝送できる
メディアタイプに追加の制限を課してもよい (MAY)。（MIME が課す制限の
詳細については [RFC2046]
を参照されたい。）
4.2.1. テキストメディアタイプ
"text" トップレベルタイプは、主としてテキスト形式の
素材を送信するためのものである。
多くの text サブタイプ、とりわけ [RFC2046] で定義される
プレーンテキストの汎用サブタイプ "text/plain" は、
"charset" パラメーターを定義する。特定の text サブタイプに
"charset" パラメーターが定義されている場合、
[RFC2978] に定める手順に従って定義された
文字集合名を指定するために使用しなければならない (MUST)。
[RFC6657] で規定されているように、文字集合情報が
ペイロード内で伝送される場合（例えば "text/xml" のような場合）、
"charset" パラメーターを指定すべきではない (SHOULD NOT)。
"charset" パラメーターを指定する場合、それを必須
パラメーターとし、既定値を指定する選択肢をなくすべきである (SHOULD)。
この助言にもかかわらず、パラメーターを任意にする強い理由がある場合、
各サブタイプは独自の既定値を指定してもよく (MAY)、
または既定値が存在しないことを指定してもよい (MAY)。
最後に、"UTF-8" 文字集合 [RFC3629] を
既定値として選択すべきである (SHOULD)。text サブタイプと組み合わせた
"charset" パラメーターの使用に関する詳細は
[RFC6657] を参照されたい。
どの方法を選択するかにかかわらず、すべての新しい text/* 登録は、
文字集合がどのように決定されるかを明確に規定しなければならない (MUST)。
[RFC2046] のセクション 4.1.2 で定義される US-ASCII の既定値に依存することは、もはや
Freed, et al. 現行の最良慣行 [9ページ]
RFC 6838 メディアタイプ登録 2013年1月
許可されない。説明文が必要な場合は、登録の
追加情報セクションに置くべきである (SHOULD)。
プレーンテキストは、書式設定コマンド、フォント
属性指定、処理命令、解釈
指示、またはコンテンツマークアップを提供も許可もしない。プレーンテキストは単純に、
改行や改ページによって中断される場合がある、文字の線形
シーケンスとみなされる。プレーンテキストでは、複数の文字を
テキスト内の同じ位置に重ねることを許可してもよい (MAY)。
アラビア語やヘブライ語のような文字体系のプレーンテキストには、
異なる書字方向を持つテキスト区間を任意に混在させるための
機能が含まれる場合もある。
プレーンテキスト以外にも、いわゆる
「リッチテキスト」を表現する形式は多数存在する。このような
表現の多くに見られる興味深い特徴は、それを解釈するソフトウェアが
なくても、ある程度は読めることである。これらを最上位レベルで、
画像、音声、あるいは読めない形式で表現された
テキストなどの読めないデータと区別することは有用である。
適切な解釈ソフトウェアがない場合でも、
"text" のサブタイプをユーザーに提示することは合理的だが、
大部分の非テキストデータについては合理的ではない。
このような書式付きテキストデータは
"text" のサブタイプを使用して表現できる。
4.2.2. 画像メディアタイプ
"image" トップレベルタイプは、コンテンツが 1 つ以上の
個別画像を指定することを示す。サブタイプは具体的な画像
形式を指定する。
4.2.3. 音声メディアタイプ
"audio" トップレベルタイプは、コンテンツに音声
データが含まれることを示す。サブタイプは具体的な音声形式を指定する。
4.2.4. 動画メディアタイプ
"video" トップレベルタイプは、コンテンツが、
色および同期音声を伴う可能性のある、時間とともに変化する画像を
指定することを示す。"video" という用語は、特定の
技術または形式を指すのではなく、最も一般的な意味で使用され、
コンパクトに符号化されたアニメーション描画のような
サブタイプを排除することを意図していない。
一般には単一の本文内で複数種類のメディアを
混在させることは推奨されない [RFC2046] が、多くの
動画形式が同期音声および／または
テキストの表現を含むことは認識されており、これは "video" のサブタイプについて
明示的に許可される。
Freed, et al. 現行の最良慣行 [10ページ]
RFC 6838 メディアタイプ登録 2013年1月
4.2.5. アプリケーションメディアタイプ
"application" トップレベルタイプは、他のどのタイプ名にも
当てはまらない個別データ、特に
何らかの種類のアプリケーションプログラムによって処理されるデータに使用される。
これは、ユーザーが表示または利用できるようになる前に
アプリケーションで処理しなければならない情報である。
"application" タイプ名の想定用途には、ファイル転送、表計算、
プレゼンテーション、スケジュールデータ、および「アクティブ」
（計算処理を行う）素材の言語などが含まれるが、これらに限定されない。
（特に最後のものは、
実装者が理解しておく必要のあるセキュリティ問題を引き起こす可能性がある。
[RFC2046] の "application/postscript" メディアタイプ登録は、
これらの問題をどのように扱うかの良い例を提供している。）
例えば、会議スケジューラーは、提案された会議日時に関する
情報の標準表現を定義できる。高度な
ユーザーエージェントは、この情報を使用してユーザーと
対話し、その対話に基づいて追加資料を
送信する場合がある。より一般的には、適切に特化された言語で
書かれたプログラムを遠隔地へ
転送し、受信者の環境で自動実行する複数の
「アクティブ」言語が開発されている。
このようなアプリケーションは、"application" トップレベルタイプの
サブタイプとして定義できる。
"application" のサブタイプは、多くの場合、
データの対象となるアプリケーションの名称そのものか、
その名称の一部を含む。ただしこれは、任意のアプリケーションプログラム名を
単に "application" のサブタイプとして自由に使用できるという意味ではない。
サブタイプは登録する必要がある。
4.2.6. Multipart および Message メディアタイプ
Multipart と message は複合タイプである。すなわち、
0 個以上のオブジェクトをカプセル化する手段を提供し、
それぞれが別個のメディアタイプである。
multipart および message のすべてのサブタイプは、
[RFC2046] で規定され、[RFC6532] のセクション 3.5 により
修正された構文規則およびその他の要件に準拠しなければならない (MUST)。
Freed, et al. 現行の最良慣行 [11ページ]
RFC 6838 メディアタイプ登録 2013年1月
4.2.7. 追加のトップレベルタイプ
場合によっては、新しいメディアタイプが現在定義されている
どのトップレベルタイプ名にも「当てはまらない」ことがある。
そのような場合は極めてまれであると予想される。しかし、
実際にそのような場合が生じた場合は、それに対応するため新しいタイプ名を
定義できる。新しいトップレベルタイプ名の定義は
Standards Track RFC を通じて行わなければならず (MUST)、追加のタイプ名を
定義するために他の仕組みを使用することはできない。
4.2.8. 構造化構文名サフィックス
MIME における XML [RFC3023] は、メディアタイプの
基礎となる構造を追加で指定するための、この種の最初の拡張を
定義した。引用すると:
この文書はまた、メディアタイプが
XML MIME (Multipurpose Internet Mail Extensions)
エンティティを表す場合に、それらのメディアタイプを命名するための規約
（サフィックス '+xml' を使用）を標準化する。
つまり、ベースとなるサブタイプ名に追加するサフィックス
（この場合 "+xml"）を規定した。
これが公開されて以降、他のよく知られた構造化構文についても
このサフィックス規約を使用することが事実上の慣行となっている。
特に、"+der"、"+fastinfoset"、"+json" などのサフィックスを
持つメディアタイプが登録されている。この仕様は
この慣行を正式なものとし、構造化タイプ名
サフィックス用のレジストリを設ける。
構造化タイプ名サフィックスを登録可能とするかどうかの
主な指針は、それが容易に入手可能な
説明によって記述されていること、できれば確立された
標準関連組織によって公開された文書内で記述されており、
RFC の Normative References セクションで使用できる参照が
存在することである。
名前付き構造化構文を使用するメディアタイプは、
登録時に、その構造化構文に対応する登録済みの
"+suffix" を使用すべきである (SHOULD)。同様に、実際には使用していない
構造化構文のサフィックスを含む名称を
メディアタイプに与えてはならない (MUST NOT)。
将来のサフィックス定義との競合の可能性があるため、
まだ登録されていない構造化構文に対する "+suffix" 構造は
使用すべきではない (SHOULD NOT)。
Freed, et al. 現行の最良慣行 [12ページ]
RFC 6838 メディアタイプ登録 2013年1月
4.2.9. 非推奨の別名
場合によっては、単一のメディアタイプが登録前に複数の名称で
広く配備されていることがある。その場合、そのメディアタイプについて
優先名称を選択しなければならず (MUST)、アプリケーションは
そのタイプの登録に準拠するため、その名称を使用しなければならない (MUST)。
ただし、そのタイプが知られている非推奨の別名一覧を、
アプリケーションがメディアタイプを適切に処理するのを支援するための
追加情報として提供してもよい (MAY)。
4.3. パラメーター要件
メディアタイプは、1 つ以上のメディアタイプパラメーターを使用することを
選択してもよく (MAY)、また、すべてのサブタイプに適用されるパラメーター集合を
定義するコンテンツタイプのサブタイプであることにより、
一部のパラメーターがそのメディアタイプで自動的に利用可能になる場合もある。
いずれの場合も、標準ツリーにメディアタイプを登録する際には、
すべてのパラメーターの名称、値、および意味を完全に
規定しなければならず (MUST)、ベンダーツリーまたは個人ツリーに
メディアタイプを登録する際には、可能な限り完全に
規定すべきである (SHOULD)。
パラメーター名は、メディアタイプ名および値と同様に次の構文を持つ:
parameter-name = restricted-name
この構文は、[RFC2045] の ABNF で許可され、
[RFC2231] によって修正されたものより、やや制限が厳しいことに注意されたい。
パラメーター名は大文字小文字を区別せず、
その出現順序に意味はない。同じ特定のパラメーターを
複数回指定することはエラーである。
パラメーター値には定義済みの構文が存在しない。したがって、
登録ではパラメーター値の構文を規定しなければならない (MUST)。
さらに、一部のトランスポートはパラメーター値構文に制限を課すため、
問題を起こす可能性のある構文の使用を
制限するよう注意する必要がある。例えば、純粋なバイナリ値のパラメーターは、
一部のプロトコルでは許可されるものの、避けることが望ましい。
プロトコルは、パラメーターをどのように表現するかに応じて、
パラメーター値構文にさらに制限を課すことができる。
MIME [RFC2045] [RFC2231] と HTTP [RFC2045] [RFC5987] はいずれも
バイナリパラメーターと、特定の
文字集合で表現されたパラメーター値を許可するが、他のプロトコルはそれほど柔軟ではない場合がある。
標準ツリーに登録されたタイプへ新しい機能を導入する方法として
新しいパラメーターを定義すべきではない (SHOULD NOT) が、
既存の機能を変更しない追加情報を伝えるために新しい
パラメーターを追加してもよい (MAY)。
Freed, et al. 現行の最良慣行 [13ページ]
RFC 6838 メディアタイプ登録 2013年1月
この例として、JPEG のような外部仕様の
リビジョンレベルを示す "revision" パラメーターが挙げられる。
ベンダーツリーまたは個人ツリーに登録されたメディアタイプについても
同様の振る舞いが推奨されるが、必須ではない。
パラメーターへの変更（新規パラメーターの導入を含む）は、
メディアタイプに対する他の変更と同じ方法で管理される。
セクション 5.5 を参照されたい。
4.4. 正規化および形式要件
登録ツリーにかかわらず、登録されるすべてのメディアタイプは
単一の正規データ形式を使用しなければならない (MUST)。
標準ツリーに登録されるすべてのタイプについて、
そのメディアタイプの形式を記述する恒久的かつ容易に利用可能な
公開仕様が存在しなければならない (MUST)。
この仕様は、そのメディアタイプを使用する独立した実装間で
相互運用が可能となる十分な詳細を提供しなければならない (MUST)。
少なくとも、その仕様がメディアタイプ登録提案そのものに
実際に含まれていない場合は、登録提案から参照されなければならない (MUST)。
ベンダーツリーおよび個人ツリーに登録されるメディアタイプでは、
形式および処理の詳細に関する仕様が公開されている場合も、
そうでない場合もある。このような登録では、
どのソフトウェアおよびバージョンがそのメディアタイプを
生成または処理するかだけに登録情報を限定することが
明示的に許可される。そのため、登録内で形式仕様を参照または
収録することは推奨されるが、必須ではない。
ただし、意味のある仕様が公開されているかどうかによって、
他の用途との競合を避けるため単に名称を予約しているだけなのか、
他の実装がそのメディアタイプを実装して
有用に相互運用できる可能性を持つのかが大きく異なる場合が多い。
一部のメディアタイプは特許技術を使用する。
特許技術を含むメディアタイプの登録は
明示的に許可される。ただし、メディアタイプの仕様が
Standards Track プロトコルの一部である場合、
IETF Standards Track プロトコルにおける特許技術の使用について
BCP
79 [RFC3979] および BCP 78 [RFC5378] に定められた制限を
遵守しなければならない。
また、標準ツリーを利用する他の標準関連組織には、
登録時に遵守しなければならない独自の
知的財産ルールが存在する場合がある。
ベンダーツリーおよび個人ツリーへの登録については、
知的財産権 (IPR) の開示が推奨されるが、必須ではない。
Freed, et al. 現行の最良慣行 [14ページ]
RFC 6838 メディアタイプ登録 2013年1月
4.5. 相互交換に関する推奨事項
理想的には、メディアタイプはできるだけ多くの
システムおよびアプリケーション間で相互運用できるよう定義される。
ただし、一部のメディアタイプは異なる
プラットフォーム間での相互運用に問題を抱えることが避けられない。
異なるバージョン、バイト順序、および
ゲートウェイ処理の詳細に関する問題が発生し得るし、実際に発生する。
メディアタイプの普遍的な相互運用性は必須ではないが、
既知の相互運用性の問題は可能な限り明示すべきである (SHOULD)。
メディアタイプの公開には相互運用性の網羅的なレビューは
必要なく、相互運用性に関する考慮事項のセクションは
継続的な評価の対象となる。
このサブセクションの推奨事項は、関係する
登録ツリーにかかわらず適用される。
4.6. セキュリティ要件
標準ツリーに登録されるすべてのタイプについて、
セキュリティ問題の分析を行わなければならない (MUST)。
ベンダーツリーまたは個人ツリーに登録されるメディアタイプについても
同様の分析が推奨されるが、必須ではない。
ただし、セキュリティ分析を実施したかどうかにかかわらず、
登録ツリーに関係なく、セキュリティ問題に関するすべての記述は
可能な限り正確でなければならない (MUST)。
特に、セキュリティに関する考慮事項に
「このタイプに関連するセキュリティ問題はない」と記載してはならない (MUST NOT)。
ベンダーツリーまたは個人ツリー内のタイプについては、
セキュリティに関する考慮事項として「このタイプに関連するセキュリティ問題は
評価されていない」と記載してもよい (MAY)。
どのツリーに登録されるメディアタイプについても、
安全であること、またはリスクが完全にないことを要求するものではまったくない。
ただし、登録ツリーに関係なく、既知の
セキュリティリスクはすべてメディアタイプ登録内で
明示しなければならない (MUST)。
すべての登録のセキュリティに関する考慮事項のセクションは
継続的な評価および変更の対象となり、特に、
以下の セクション 5.4 で説明する
「メディアタイプへのコメント」機構を使用して拡張してもよい (MAY)。
メディアタイプのセキュリティ分析で検討し、
記述する必要がある問題には、次のものがある:
o 複雑なメディアタイプには、受信者のファイルやその他の
リソースに対して動作を開始する指示を含める仕組みが存在する場合がある。
多くの場合、送信者が任意の
動作を無制限に指定できるようになっており、
それが壊滅的な影響をもたらす可能性がある。このような指示の例と、それを
Freed, et al. 現行の最良慣行 [15ページ]
RFC 6838 メディアタイプ登録 2013年1月
メディアタイプ登録でどのように記述できるかについては、
[RFC2046] の application/postscript メディアタイプ登録を参照されたい。
o すべてのセキュリティ分析は、そのような
「アクティブコンテンツ」を使用するかどうかを明記しなければならず (MUST)、
使用する場合は、そのメディアタイプのユーザーを
被害から保護するために、どのような手順が講じられているか、
またはそのメディアタイプを使用するアプリケーションが講じなければならないかを
明記しなければならない (MUST)。
o 複雑なメディアタイプには、受信者に
直接害を及ぼさないとしても、その後の攻撃を容易にする情報の
開示や、何らかの形で受信者のプライバシーを
侵害する結果となる動作を開始する指示を含める仕組みが
存在する場合がある。ここでも application/
postscript メディアタイプの登録は、そのような指示を
どのように扱えるかを示している。
o 圧縮を使用するメディアタイプは、少量のデータを送信し、
受信して評価した際に巨大に展開して
受信者のすべてのリソースを消費する攻撃の機会を
提供する場合がある。すべてのメディアタイプは、
圧縮を使用するかどうかを記載すべきであり (SHOULD)、
使用する場合、そのような攻撃を避けるために必要な手順について
議論すべきである (SHOULD)。
o メディアタイプが、何らかのセキュリティ保証を必要とするものの、
必要なセキュリティ機構そのものは提供しない
アプリケーションを対象としている場合がある。例えば、
機密性の高い医療情報を保存するためのメディアタイプが
定義され、その情報には外部の機密性および完全性保護
サービスが必要であったり、安全な環境内でのみ使用するよう
設計されていたりする場合がある。タイプは、そのような
サービスが必要かどうかをセキュリティに関する考慮事項に
常に記載すべきである (SHOULD)。
4.7. XML メディアタイプ固有の要件
XML メディアタイプの登録には、追加の要件が
いくつか存在する。これらの要件は
[RFC3023] で規定されている。
4.8. エンコーディング要件
一部のトランスポートは、伝送できるデータの種類に
制限を課す。例えば、インターネットメールは従来
7bit US-ASCII テキストに制限されていた。
このようなトランスポート上の制限を回避するために、
エンコーディング方式がよく使用される。
Freed, et al. 現行の最良慣行 [16ページ]
RFC 6838 メディアタイプ登録 2013年1月
したがって、メディアタイプの登録の一部として、
そのメディアタイプがどのような種類のデータで構成され得るかを
記載しておくことは有用である。この目的のために
"encoding considerations" フィールドが用意されている。このフィールドに指定可能な値
は次のとおりである:
7bit: メディアタイプのコンテンツは、CRLF で
区切られた 7bit US-ASCII テキストのみで構成される。
8bit: メディアタイプのコンテンツは、CRLF で
区切られた 8bit テキストのみで構成される。
binary: コンテンツは、制限のないオクテット列で構成される。
framed: コンテンツは、内部のフレーミングまたは
アラインメント指示子を持たない一連のフレームまたはパケットで構成される。
データを適切に解釈するためには追加の帯域外
情報が必要であり、これには連続するフレーム間の
境界に関する知識や、
トランスポート機構に関する知識などが含まれるが、必ずしもこれらに限定されない。
この種のメディアタイプは単純にファイルへ
保存したり、単純なオクテットストリームとして伝送したりできないことに
注意されたい。したがって、このようなメディアタイプは、多くの
従来型プロトコルでの使用には適さない。
framed エンコーディングで一般的に使用されるトランスポートは、
Real-time Transport Protocol、RTP である。
RTP を用いた伝送向けに定義される framed エンコーディングの追加規則は、
[RFC4855] に示されている。
7bit および 8bit テキストに対する追加の制限は、
[RFC2046] のセクション
4.1.1 に示されている。
4.9. 使用および実装の非要件
リモートメールエージェントの能力に関する情報が
送信者から利用できないことの多い非同期メール環境では、
広く実装されていると期待される「一般的な」形式に
使用するメディアタイプを制限することで、
最大限の相互運用性が得られる。これは以前、
利用可能なメディアタイプの数を制限する理由として主張され、
メディアタイプ登録者に対して大きな障壁と
遅延を伴う登録プロセスにつながった。
しかし、「一般的な」メディアタイプが必要だからといって、
新しいメディアタイプの登録を制限する必要はない。
特定のアプリケーションについて限定されたメディアタイプ集合を
推奨する場合は、そのアプリケーション
および／または環境に固有の別個の適用性宣言によって
その旨を示すべきである。
したがって、メディアタイプの普遍的なサポートおよび実装は、
登録の要件ではない (NOT)。ただし、メディアタイプが
Freed, et al. 現行の最良慣行 [17ページ]
RFC 6838 メディアタイプ登録 2013年1月
限定的な使用を明示的に意図する場合、その旨を登録に
記載しなければならない (MUST)。この目的のために
"Restrictions on Usage" フィールドが用意されている。
4.10. 公開要件
IETF 自身によって標準ツリーに登録されるメディアタイプは、
RFC として公開されなければならない (MUST)。
ベンダーおよび個人メディアタイプ登録を RFC として公開することは
許可されるが、必須ではない。すべての場合において、
IANA はすべてのメディアタイプ登録のコピーを保持し、
メディアタイプ登録ツリーそのものの一部として
「公開」する。
前述のとおり、他の標準関連組織が作成した
文書で定義されるメディアタイプの標準ツリー登録は、
その組織が作成した正式な標準仕様によって
記述されなければならない (MUST)。さらに、
登録テンプレートに対する著作権は、IANA がそれを
IANA レジストリへコピーすることを許可しなければならない (MUST)。
IETF による標準ツリー登録を除き、
メディアタイプの登録は、IANA または IETF による
承認、認可、推奨を意味せず、
仕様が十分であることを認証するものでもない。
IETF 標準となるには、プロトコルまたは
データオブジェクトは IETF 標準化プロセスを経なければならない。
適切な場合には追加の保証を提供するものの、
このプロセスはメディアタイプを便利に登録するためには
あまりにも困難で時間がかかる。
標準ツリーは、認定された標準関連組織における
実質的なレビューおよび承認プロセスを
必要とするメディアタイプのために存在する。
ベンダーツリーおよび個人ツリーは、
そのようなプロセスを必要としないメディアタイプのために存在する。
特定のアプリケーションについては、特に有用であることが
実証されたメディアタイプの実装およびサポートを推奨する
適用性宣言が、今後 IETF で随時
公開されることが期待される。
上記で説明したように、トップレベルタイプの登録には
IETF における Standards Action が必要であり、
したがって Standards Track の RFC の公開が必要である。
4.11. フラグメント識別子要件
メディアタイプ登録では、そのメディアタイプに関連付けられた
フラグメント識別子（[RFC3986] のセクション 3.5 で
規定）をアプリケーションがどのように解釈すべきかを指定できる。
Freed, et al. 現行の最良慣行 [18ページ]
RFC 6838 メディアタイプ登録 2013年1月
メディアタイプには、意味的に類似したメディアタイプで
使用されているフラグメント識別子方式を採用することが推奨される。
特に、登録済みの "+suffix" を持つ名前付き構造化構文を
使用するメディアタイプは、その構造化構文サフィックス登録に
記載されているフラグメント識別子規則に
従わなければならない (MUST)。
4.12. 追加情報
利用可能である場合、さまざまな種類の任意情報を
メディアタイプの仕様に含めるべきである (SHOULD):
o マジックナンバー（長さ、オクテット値）。マジックナンバーは、
ファイル内の所定位置に常に存在するバイト
シーケンスであり、それによってエンティティが特定のメディア
タイプであることを識別できる。
o ファイルが特定のメディアタイプを含むことを示すため、
1 つ以上のプラットフォームで一般的に使用される
ファイル名拡張子。
o 特定のメディアタイプを含むファイルにラベルを付けるために使用される
Mac OS ファイルタイプコード（4 オクテット）。
Macintosh ファイルタイプコードおよびその目的についての説明は、
[MacOSFileTypes] にある。
標準ツリーへの登録の場合、この追加
情報は、メディアタイプ形式の正式な仕様内で
提供してもよい (MAY)。これを行う方法として、
IANA メディアタイプ登録フォームを形式仕様
そのものに組み込むことが推奨される。
5. メディアタイプ登録手順
メディアタイプ登録手順は正式な標準化
プロセスではなく、過度な時間遅延を生じさせずに
コミュニティからのコメントと妥当性確認を可能にすることを意図した
管理手順である。
標準ツリーにおけるすべての IETF 登録では、
通常の IETF プロセスに従う必要がある。
Internet Draft の投稿が必要な最初の手順であり、
その後、以下で説明するように media-types@iana.org
リストへの投稿を行う。
5.1. 事前コミュニティレビュー
標準ツリーへのメディアタイプ登録候補の通知は、
レビューのため media-types@iana.org メーリングリストへ
送るべきである (SHOULD)。このメーリングリストは、
提案されたメディアタイプおよびアクセス型をレビューする目的で
設置されている。他のツリーへの登録も
レビューのためこのリストへ送ってもよく (MAY)、
これは完全に任意 (OPTIONAL) だが、強く推奨される。
Freed, et al. 現行の最良慣行 [19ページ]
RFC 6838 メディアタイプ登録 2013年1月
このリストに公開投稿する目的は、
タイプ／サブタイプ名の選択、
バージョンおよび外部プロファイリング情報に関する参照の
明確性、ならびに相互運用性またはセキュリティに関する
考慮事項についてコメントおよびフィードバックを求めることである。
申請者は、改訂した登録提案を提出することも、
いつでも登録を完全に取り下げることもできる。
5.2. IANA への要求提出
IETF 自身によって標準ツリーに登録されるメディアタイプは、
通常の標準化プロセスの一部として IESG による
レビューおよび承認を受けなければならない (MUST)。
認定された標準関連組織による標準ツリー登録、
およびベンダーツリーと個人ツリーへの登録は、
連携協定の一部として別の取り決めがなされていない限り、
IANA へ直接提出される。いずれの場合も、
提出前にレビューのため登録を media-types@iana.org リストへ
投稿することが強く推奨される。
登録要求は iana@iana.org へ送信できる。登録要求用の
Web フォームも利用可能である:
http://www.iana.org/form/media-types
5.2.1. 暫定登録
標準化プロセスは完了までにかなりの時間を要することが多い。
プロトタイプ作成およびテストを容易にするため、
メディアタイプを含むがこれに限定されない識別子を
プロセスの早い段階で割り当てることが役立つ場合が多い。
これにより、標準開発中に使用された識別子を
プロセス完了後も変更せずに済み、
実装および文書を更新する必要がなくなる。
したがって、標準ツリーにおけるメディアタイプ名の早期割り当てを
支援するため、暫定登録プロセスが設けられている。
標準ツリーのタイプについては暫定登録を
IANA に提出してもよい (MAY)。
このような登録で必須となるフィールドは、
メディアタイプ名と連絡先情報（標準関連組織名を含む）
のみである。
暫定登録を受領すると、IANA は名称と
連絡先情報を確認し、その登録を独立した
公開閲覧可能な暫定登録リストに掲載する。
暫定登録はいつでも更新または放棄してもよい (MAY)。
登録が放棄された場合、そのメディアタイプはいかなる意味でも
登録済みではなくなり、その後、他の未割り当てメディアタイプ名と
同様に登録できる。
Freed, et al. 現行の最良慣行 [20ページ]
RFC 6838 メディアタイプ登録 2013年1月
5.3. レビューと承認
標準ツリーの暫定登録を除き、
IANA に提出された登録は media
types reviewer に渡される。IETF Applications Area Director(s) によって
任命される media types reviewer は、
登録がこの文書に定める要件を満たしていることを確認するため
レビューを行う。これらの要件を満たさない登録は、
修正のため申請者へ返却される。
media types reviewer による決定は、
[RFC2026] のセクション 6.5.4 で規定される手順を使用して
IESG へ異議申立てできる。
メディアタイプ登録がレビューに合格すると、
IANA はそのメディアタイプを登録し、
メディアタイプ登録をコミュニティから利用可能にする。
他の標準関連組織による標準ツリー登録の場合、
IANA は、申請者が実際に認定された標準関連組織であることも
確認する。申請者が現在そのような組織として
認定されていない場合、IESG にその地位の
確認を求める。標準ツリー登録を進める前に、
IESG からの認定を取得しなければならない (MUST)。
5.4. メディアタイプ登録へのコメント
登録済みメディアタイプへのコメントは、
コミュニティのメンバーが iana@iana.org の IANA へ提出できる。
これらのコメントは media types reviewer によって
レビューされ、可能であればメディアタイプの「所有者」へ
転送される。コメントの提出者は、そのコメントを
メディアタイプ登録そのものに添付するよう求めることができ、
IANA が media types reviewer と協議のうえ
承認した場合、そのコメントはタイプ登録とともに
アクセス可能になる。
5.5. 変更手順
メディアタイプが IANA によって公開された後、
所有者はその定義の変更を要求できる。
上記の各登録ツリーの説明では、それぞれの登録タイプの
「所有者」を指定している。変更要求の処理には、
元の登録要求に適用されるものと同じ手順を使用する。
メディアタイプ登録を削除することはできない。
使用するのに適切でなくなったと考えられるメディアタイプは、
"intended use" フィールドを変更することで OBSOLETE と宣言でき、
そのようなメディアタイプは IANA が公開する一覧内で
明確に表示される。
Freed, et al. 現行の最良慣行 [21ページ]
RFC 6838 メディアタイプ登録 2013年1月
メディアタイプの定義への重大な変更は、
公開仕様に重大な欠落または誤りがある場合にのみ
要求すべきである。レビューが必要な場合、
以前の定義で有効だったエンティティが新しい定義で
無効になるような変更要求は拒否される場合がある。
メディアタイプの所有者は、IANA に通知することで
責任を別の個人または機関へ移管できる。
これは議論またはレビューなしに行うことができる。
IESG はメディアタイプに対する責任を再割り当てできる。
最も一般的なケースは、登録の著者が死亡した、
連絡不能になった、またはその他の理由で
コミュニティにとって重要な変更を行えない場合に、
そのタイプへの変更を可能にすることである。
5.6. 登録テンプレート
タイプ名:
サブタイプ名:
必須パラメーター:
任意パラメーター:
エンコーディングに関する考慮事項:
セキュリティに関する考慮事項:
相互運用性に関する考慮事項:
公開仕様:
このメディアタイプを使用するアプリケーション:
フラグメント識別子に関する考慮事項:
追加情報:
このタイプの非推奨の別名:
マジックナンバー:
ファイル拡張子:
Macintosh ファイルタイプコード:
詳細情報の連絡先となる人物およびメールアドレス:
Freed, et al. 現行の最良慣行 [22ページ]
RFC 6838 メディアタイプ登録 2013年1月
想定用途:
（COMMON、LIMITED USE、または OBSOLETE のいずれか。）
使用上の制限:
（メディアタイプを使用できる場所に関する制限があれば、ここに記載する。）
著者:
変更管理者:
暫定登録か?（標準ツリーのみ）:
（著者が有用と考えるその他の情報は、
この行より下に追加できる。）
適用されないこと、または質問を誤って省略したわけではないことを
強調したい場合、任意のフィールドで、正確に "N/A" と記述して
使用できる。応答と誤解される可能性がある 'none' その他の
単語を使用してはならない。
限定使用メディアタイプでは、アプリケーション一覧が
網羅的かどうかも記載すべきである。
6. 構造化構文サフィックス登録手順
新しいメディアタイプ登録で使用する構造化構文向けに
"+suffix" 名を定義しようとする者は、次を行うべきである (SHOULD):
1. IANA のメディアタイプ名サフィックスレジストリを確認し、
その明確に定義された構造化構文に対するエントリが
すでに存在するかどうかを確認する。
2. そのサフィックス方式のエントリがない場合、
テンプレート（セクション 6.2 で規定）に記入し、
メディアタイプ登録に含める。テンプレートは、
単独または他のプロトコル仕様の一部として
Internet Draft に含めてもよい。テンプレートは
別の形式（別文書の一部または独立文書）で
提出することもできるが、その内容は
BCP 78 [RFC5378] の指針に従い
"IETF Contribution" として扱われる。
3. テンプレートのコピー、またはそれを含む
文書へのポインター（テンプレートを含むセクションを
明示して）を、レビューを求めてメーリングリスト
media-types@iana.org へ送信する。
Freed, et al. 現行の最良慣行 [23ページ]
RFC 6838 メディアタイプ登録 2013年1月
これはメディアタイプ登録のレビュー要求と
組み合わせてもよい。議論およびコメントのために
妥当な時間を設ける。
4. レビューコメントに応答し、この文書に示す指針に
適合するよう必要に応じて提案された
登録を修正する。
5. （更新されている可能性のある）登録テンプレート
（またはそれを含む文書へのポインター）を
iana@iana.org の IANA へ提出する。
構造化構文サフィックス登録要求を受領すると、
1. IANA は提出内容が完全であることを確認し、
セクションが欠落しているか参照が正しくない場合、
IANA は登録要求を拒否する。
2. IANA は現在のレジストリに同じ名称のエントリがあるか確認し、
そのような登録が存在する場合、IANA は登録要求を拒否する。
3. IANA は、対応する指針に照らして登録要求の
Expert Review を依頼する。
4. Designated Expert は、必要に応じて追加のレビューまたは
議論を求める場合がある。
5. Expert Review が登録を推奨した場合、
IANA は登録を適切なレジストリへ追加する。
初期レジストリ内容の仕様 [RFC6839] は、
構造化構文サフィックス登録の例を提供している。
6.1. 変更手順
各レジストリ内の登録は、初回登録に必要だったものと
同じ仕組みによって更新できる。方式の元の定義が
IESG 承認済み文書に含まれる場合、
仕様の更新にも IESG の承認が必要である。
6.2. 構造化構文サフィックス登録テンプレート
このテンプレートは、構造化構文サフィックス登録要求で
提供しなければならないフィールドを記述する:
名称
明確に定義された構造化構文の完全な名称。
Freed, et al. 現行の最良慣行 [24ページ]
RFC 6838 メディアタイプ登録 2013年1月
+suffix
その構文への準拠を示すために使用するサフィックス。
参考文献
構造化構文を理解するために必要なすべての仕様について、
完全な引用を含める。
エンコーディングに関する考慮事項
この構文を使用するあらゆるタイプについての
エンコーディングに関する一般的な指針をここに記載する。
セクション 4.8 に示すメディアタイプのエンコーディングに関する考慮事項と
同じ要件がここでも適用される。
相互運用性に関する考慮事項
この構造化構文を使用するタイプの相互運用可能な使用に関する
問題があれば、ここに記載する。例としては、
構文の互換性のないバージョンの存在、
特定の文字集合と構文を組み合わせた場合の問題、または
他のタイプやプロトコルとの非互換性などがある。
フラグメント識別子に関する考慮事項
この構文を使用する任意のタイプについての
フラグメント識別子の汎用処理をここに記述する。
セキュリティに関する考慮事項
この構造化構文を使用するメディアタイプが共有する
セキュリティに関する考慮事項をここで規定しなければならない。
セクション 4.6 に示すメディアタイプのセキュリティに関する考慮事項と
同じ要件がここでも適用されるが、
サフィックス登録ではセキュリティに関する考慮事項を
評価しないという選択肢は利用できない。
連絡先
詳細情報の連絡先となる人物
（連絡先情報を含む）。
著者／変更管理者。
このサフィックス登録を変更する権限を持つ人物
（連絡先情報を含む）。
7. セキュリティに関する考慮事項
メディアタイプ登録およびメディアタイプサフィックス登録の
セキュリティ要件については、セクション 4.6 で説明している。
Freed, et al. 現行の最良慣行 [25ページ]
RFC 6838 メディアタイプ登録 2013年1月
8. IANA に関する考慮事項
この文書の目的は、メディアタイプおよび構造化構文サフィックス用の
IANA レジストリ、ならびにそれらのレジストリを
管理するための手順を定義することである。さらに、この文書は、
IESG が標準ツリーへのメディアタイプ登録を承認した
標準関連組織の一覧を IANA が
維持することを要求する。
既存のメディアタイプレジストリには、
暫定登録用セクションが追加された。
標準ツリーでは標準ツリー登録のみが許可され、
かつ IANA の標準関連組織一覧にある組織からの
要求による場合に限られる。暫定登録の詳細については
セクション 5.2.1 を参照されたい。
IANA はまた、暫定レジストリの先頭に
次の注記を追加した:
このレジストリは、他の一部の暫定 IANA レジストリとは異なり、
一時的な使用のみを目的とする。このレジストリのエントリは、
最終化されてメインのメディアタイプレジストリへ移動されるか、
放棄されて削除される。このレジストリのエントリは、
開発およびテスト目的での使用にのみ適している。
構造化構文名サフィックスレジストリは、
次のように作成された:
o 名称は "Structured Syntax Suffix" レジストリである。
o 登録プロセスは セクション 6 で規定される。
o レジストリエントリに必要な情報およびエントリ
形式は セクション 6.2 で規定される。
o レジストリの初期内容は [RFC6839] で規定される。
メディアタイプレジストリと構造化サフィックスレジストリの
両方のエントリには、IANA により、最初の登録日と
エントリの最新更新日の両方が付記される。
この仕様が実施される以前に行われた登録については、
必要に応じ、具体的な日付の代わりにその旨を
示してもよい。
登録エントリは複数回更新される可能性があるため、
IANA は各登録について、任意の時点における
登録状態を確認できるような方法で
変更履歴も維持する。
Freed, et al. 現行の最良慣行 [26ページ]
RFC 6838 メディアタイプ登録 2013年1月
最後に、この文書に従い、IANA はメディアタイプレビューリスト用に
新しいメールアドレス media-types@iana.org を作成し、
RFC 4288 で指定されていた ietf-types@iana.org アドレスを置き換えた。
ietf-types@iana.org は別名として維持されている。
9. 謝辞
現在の著者らは、故
Dr. Jon Postel に対する恩義をここに認めたい。彼による IANA 登録手順の
一般モデルおよび具体的な貢献が、この文書の前身
[RFC2048] [RFC4288] を形作った。
現在の版も彼が同意したであろう内容であることを願うが、
その同意を確認することは不可能であるため、
残念ながら共同著者としての彼の名前を削除した。
Randy Bush、Francis Dupont、Bjoern Hoehrmann、Barry Leiba、Murray
Kucherawy、Alexey Melnikov、S. Moonesamy、Mark Nottingham、Tom Petch、
Peter Saint-Andre、および Jeni Tennison は、多くの有益なレビュー
コメントおよび提案を提供した。
10. 参考文献
10.1. 規範的参考文献
[RFC2045] Freed, N. and N. Borenstein, "多目的インターネット
メール拡張 (MIME) 第1部: インターネット
メッセージ本文の形式", RFC 2045, 1996年11月.
[RFC2046] Freed, N. and N. Borenstein, "多目的インターネット
メール拡張 (MIME) 第2部: メディアタイプ",
RFC 2046, 1996年11月.
[RFC2119] Bradner, S., "要件レベルを示すために RFC で使用する
キーワード", BCP 14, RFC 2119, 1997年3月.
[RFC2978] Freed, N. and J. Postel, "IANA 文字集合登録
手順", BCP 19, RFC 2978, 2000年10月.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML
メディアタイプ", RFC 3023, 2001年1月.
[RFC3629] Yergeau, F., "UTF-8、ISO 10646 の変換形式",
STD 63, RFC 3629, 2003年11月.
[RFC3979] Bradner, S., "IETF 技術における知的財産権",
BCP 79, RFC 3979, 2005年3月.
Freed, et al. 現行の最良慣行 [27ページ]
RFC 6838 メディアタイプ登録 2013年1月
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): 汎用
構文", STD 66, RFC 3986, 2005年1月.
[RFC4855] Casner, S., "RTP ペイロード形式のメディアタイプ
登録", RFC 4855, 2007年2月.
[RFC5226] Narten, T. and H. Alvestrand, "RFC における
IANA Considerations セクション作成の指針",
BCP 26, RFC 5226, 2008年5月.
[RFC5234] Crocker, D. and P. Overell, "構文仕様のための
拡張 BNF: ABNF", STD 68, RFC 5234,
2008年1月.
[RFC5378] Bradner, S. and J. Contreras, "寄稿者が
IETF Trust に付与する権利", BCP 78, RFC 5378,
2008年11月.
[RFC6532] Yang, A., Steele, S., and N. Freed,
"国際化電子メールヘッダー", RFC 6532,
2012年2月.
[RFC6657] Melnikov, A. and J. Reschke, "テキスト
メディアタイプにおける "charset" パラメーター処理に関する MIME の更新",
RFC 6657, 2012年7月.
[RFC6839] Hansen, T. and A. Melnikov, "追加のメディアタイプ
構造化構文サフィックス", RFC 6839,
2013年1月.
10.2. 参考情報
[MacOSFileTypes] Apple Computer, Inc., "Mac OS: ファイルタイプおよび
作成者コード、ならびにファイル形式", Apple Knowledge
Base Article 55381, 1993年6月,
<http://www.info.apple.com/kbnum/n55381>.
[RFC2026] Bradner, S., "インターネット標準化プロセス --
改訂 3", BCP 9, RFC 2026, 1996年10月.
[RFC2048] Freed, N., Klensin, J., and J. Postel,
"多目的インターネットメール拡張 (MIME) 第
4部: 登録手順", BCP 13, RFC 2048,
1996年11月.
Freed, et al. 現行の最良慣行 [28ページ]
RFC 6838 メディアタイプ登録 2013年1月
[RFC2231] Freed, N. and K. Moore, "MIME パラメーター値および
符号化単語拡張:
文字集合、言語、および継続",
RFC 2231, 1997年11月.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"ハイパーテキスト転送プロトコル -- HTTP/1.1",
RFC 2616, 1999年6月.
[RFC4288] Freed, N. and J. Klensin, "メディアタイプの
仕様および登録手順",
BCP 13, RFC 4288, 2005年12月.
[RFC5987] Reschke, J., "ハイパーテキスト転送プロトコル (HTTP)
ヘッダーフィールドパラメーターの文字集合および言語
エンコーディング", RFC 5987, 2010年8月.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"アプリケーションプロトコルにおける "X-" プレフィックスおよび類似構造の
非推奨化", BCP 178, RFC 6648,
2012年6月.
Freed, et al. 現行の最良慣行 [29ページ]
RFC 6838 メディアタイプ登録 2013年1月
付録 A. 既得権のあるメディアタイプ
1996 年以前に登録された、ファセットを持たないサブタイプ名の
多くのメディアタイプは、この文書の指針に従って登録されたなら、
ファセット付き名称が与えられ、ベンダーツリーまたは
個人ツリーのいずれかに置かれることになる。
適切なツリーを反映するため、これらのタイプを再登録することが
推奨されるが、必須ではない。この文書に示す所有権および
変更管理の原則は、これらのタイプが上記のツリーに
登録されていたかのように適用される。
また、ファセットを持たないサブタイプ名のメディアタイプが、
登録されないまま広く配備されている場合も随時あり得る。
（これには "x-" プレフィックスで始まるサブタイプ名も含まれることに注意されたい。）
可能であれば、このようなメディアタイプは、
元の名称を識別するために非推奨の別名を使用する可能性も含め、
適切なファセット付きサブタイプ名で再登録すべきである (SHOULD)
（セクション 4.2.9 を参照）。
ただし、それが不可能な場合は、media types reviewer と IESG の
両方の承認を条件として、
ファセットを持たない名称のまま適切なツリーに登録できる。
付録 B. RFC 4288 以降の変更
o 特定の構造化構文の使用を示すサフィックスが
完全に規定され、サフィックス登録プロセスが
定義された。
o 広く配備されている未登録のファセットなしタイプ名を
ベンダーツリーまたは個人ツリーへ登録することが、
media types reviewer および IESG の承認を条件として
許可されるようになった。
o 標準ツリー登録プロセスは、
Expert Review を含むよう改訂され、非 IETF ストリーム文書内の
メディアタイプのようなケースに対応できるよう一般化された。
o フラグメント識別子用フィールドが
登録テンプレートに追加され、フラグメント識別子の指定に関する
簡潔な指示が追加された。
o 個人ツリー登録に対する仕様要件が、
ベンダーツリーと同じになるよう変更された。
仕様の利用可能性を推奨する（ただし必須とはしない）よう
テキストが変更された。
o 追加のツリーを定義するプロセスについて、
IETF Standards Action が必要であることを明記するよう明確化された。
o 広く配備された "x-" 名を持つタイプは、
例外としてベンダーツリーに登録できるようになった。
Freed, et al. 現行の最良慣行 [30ページ]
RFC 6838 メディアタイプ登録 2013年1月
o 登録変更に関する要件が緩和され、
軽微な変更を行いやすくなった。
o 登録プロセスが完全に再構成され、
標準ツリーにおける IETF 生成タイプを除き、
すべての要求が IESG ではなく IANA によって処理されるようになった。
o 標準ツリーのタイプを早期に割り当てるため、
暫定登録プロセスが追加された。
o この文書全体で、
記述される要件およびプロセスをより明確にし、
理解しやすくするため、多数の編集上の変更が行われた。
o メディアタイプについて非推奨の別名一覧を指定する機能が
追加された。
o "x-" で始まる名称を持つタイプは、もはや
未登録の "x." ツリーのメンバーとはみなされない。
他のファセットなしタイプと同様、そのようなタイプを
適切なツリーに登録できるよう特別な手順が追加された。
o 第三者によって登録されたタイプへの変更は、
指定された変更管理者が、そのタイプを作成したベンダーまたは
組織でなくても行えるようになった。
ただし、ベンダーまたは組織は、
いつでもそのタイプの所有権および変更管理者としての権限を
主張することを選択できる。
o 限定使用メディアタイプでは、そのメディアタイプを使用する
アプリケーションの提示一覧が網羅的かどうかを
記載するよう求められるようになった。
o メディアタイプ名の ABNF がさらに制限され、
名称が英数字で始まることを要求するようになった。
o メディアタイプ登録前のメーリングリストレビューは、
もはや必須ではない。さらに、
メディアタイプレビュー用メーリングリストのアドレスは
media-types@iana.org に変更された。
o text/* メディアタイプの規則は、
[RFC6657] で規定された変更を反映するよう更新された。
Freed, et al. 現行の最良慣行 [31ページ]
RFC 6838 メディアタイプ登録 2013年1月
著者の住所
Ned Freed
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
USA
メール: ned+ietf@mrochek.com
John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
メール: john+ietf@jck.com
Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
メール: tony+mtsuffix@maillennium.att.com
Freed, et al. 現行の最良慣行 [32ページ]