Internet Engineering Task Force (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、およびその他のインターネット
プロトコルで使用するメディア型の仕様策定および
登録の手続きを定義する。
本文書の位置づけ
このメモは、インターネットの現行最良慣行を記録するものである。
本文書は、Internet Engineering Task Force（IETF）の成果物である。
これはIETFコミュニティの合意を表している。本文書は公開レビューを
受けており、Internet Engineering Steering Group（IESG）により
公開が承認されている。BCPに関する詳細情報は、
RFC 5741のSection 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 ほか Best Current Practice [Page 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. text メディア型 . . . . . . . . . . . . . . . . . 9
4.2.2. image メディア型 . . . . . . . . . . . . . . . . 10
4.2.3. audio メディア型 . . . . . . . . . . . . . . . . 10
4.2.4. video メディア型 . . . . . . . . . . . . . . . . 10
4.2.5. application メディア型 . . . . . . . . . . . . . 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 ほか Best Current Practice [Page 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）の中央レジストリにおいてメディア型
（Section 5）およびメディア型の構造化サフィックス（Section 6）を
登録するために使用する手続きを定義する。
これらの手続きによって管理されるメディア型レジストリの場所は
次のとおりである。
http://www.iana.org/assignments/media-types/
1.1. 歴史的注記
メディア型登録プロセスは、当初、非同期インターネットメール環境の
文脈で使用するメディア型を登録するために定義された。このメール
環境では、相手側メールシステムの能力が不明な場合に相互運用性の
可能性を高めるため、可能なメディア型の数を制限する必要がある。
メディア型が新しい環境で使用されるようになり、そこではメディア型の
増加が相互運用性の妨げにならないため、元の手続きは過度に制限的で
あることが判明し、一般化する必要が生じた。これは最初に[RFC2048]で
行われたが、そこで定義された手続きは依然としてMIME文書群の一部で
あった。メディア型仕様および登録手続きは、MIMEから独立していることを
明確にするため、現在は独立した文書である。
Freed ほか Best Current Practice [Page 3]
RFC 6838 メディア型登録 2013年1月
メディア型の使用を特定の環境に制限すること、または他の環境での
使用を禁止することが望ましい場合がある。本仕様は、そのような制限を
体系的な方法でメディア型登録に組み込む。追加の議論については
Section 4.9を参照すること。
1.2. 本文書で使用する規約
本文書におけるキーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、
"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、
および"OPTIONAL"は、すべて大文字で現れる場合、[RFC2119]に記述
されているとおりに解釈される。それらは、小文字または大文字小文字
混在で、規範的な意味を持たない通常の英語の語として現れることもある。
本仕様は、Augmented Backus-Naur Form（ABNF）[RFC5234]表記を使用する。
これには、同文書のAppendix Bで定義されるコアルールが含まれる。
2. メディア型登録の予備事項
新しいメディア型または複数のメディア型の登録は、登録提案の作成から
始まる。登録は、以下で説明するように、要件の異なる複数の登録
ツリー内で行われることがある。一般に、新しい登録提案は、関係する
ツリーに適した方法で配布され、レビューされる。その後、その提案が
受け入れ可能であれば、メディア型が登録される。以下の節では、
各種登録ツリーで使用される要件と手続きを説明する。
3. 登録ツリーとサブタイプ名
登録プロセスの効率と柔軟性を高めるため、サブタイプ名の異なる構造を
登録できる。これは、たとえばインターネットコミュニティによる広範な
サポートと実装が推奨されるサブタイプ、またはプロプライエタリ
ソフトウェアに関連するファイルを移動するために使用されるサブタイプ
など、異なる自然な要件に対応するためである。以下の小節では、
ファセット付き名前、たとえば"tree."接頭辞で始まるサブタイプ名の
使用によって区別される登録「ツリー」を定義する。なお、本文書より
前に定義された一部のメディア型は、以下で説明する命名規則に準拠して
いない。それらについてはAppendix
Aを参照すること。
3.1. 標準ツリー
標準ツリーは、インターネットコミュニティ全般の関心対象となる型を
意図している。標準ツリー内の登録は、次のいずれかでなければならない
（MUST）。
Freed ほか Best Current Practice [Page 4]
RFC 6838 メディア型登録 2013年1月
1. IETF仕様に関連付けられた登録の場合、IESGによって直接承認
されること。
2. "Specification Required" IANA登録ポリシー[RFC5226]（これは
Expert Reviewを意味する）を使用して、認知された標準関連組織に
よって登録されること。
最初の手続きは、IETF Consensus文書からの登録、またはまれな場合として、
既存扱い（Appendix A参照）および/またはその他の不完全な登録を
行うことがインターネットコミュニティの利益になる場合に使用される。
登録提案はRFCとして公開されなければならない（MUST）。登録RFCがIETF
streamにある場合、IETF Consensusを持たなければならない。これは
Standards Track、BCP、Informational、またはExperimentalの状態で
達成できる。非IETF RFC streamで公開される登録も許可されており、
IESGの承認が必要である。登録は、独立した「登録のみ」のRFCであっても、
何らかのより一般的な仕様に組み込まれていてもよい。
2番目の場合、IESGは、登録提出者が認知された標準関連組織を代表して
いるかどうかについて一度限りの決定を行う。その後、Media Types
Reviewer（Designated ExpertまたはDesignated Expertsのグループ）が、
本文書で規定されるExpert Reviewを実施する。同じ提出元からの後続の
提出にはIESGは関与しない。その形式は、提出する標準関連組織によって
作成された正式な標準仕様で記述されなければならない（MUST）。
標準ツリー内のメディア型は、Appendix Aで説明されるプロセスを使用して
既存扱いとされる場合を除き、ファセット付き名前を持ってはならない
（MUST NOT）。
標準ツリーに登録されたメディア型の「所有者」は、標準関連組織そのもの
であるとみなされる。仕様の変更または修正には、初期登録に必要とされた
処理と同じレベルの処理を使用する（たとえば、Standards Trackで提出
された登録は別のStandards Track RFCで改訂できるが、Informational
RFCで改訂することはできない）。
認知された標準関連組織からの標準ツリー登録は、IANAに直接提出され、
承認前にExpert Review [RFC5226]を受ける。この場合、Expert
Reviewer（複数可）は、必要な仕様が十分な文書化を提供していることなどを
確認する。
Freed ほか Best Current Practice [Page 5]
RFC 6838 メディア型登録 2013年1月
3.2. ベンダーツリー
ベンダーツリーは、公開されている製品に関連付けられたメディア型に
使用される。この文脈では「ベンダー」および「製作者」は非常に広く
解釈され、同等であるとみなされる。なお、業界コンソーシアムおよび
認知された標準関連組織には該当しない非営利団体も、ベンダーツリーに
メディア型を登録することが十分に適切である。
製品または製品群に関連するファイルを交換する必要がある者は誰でも、
登録をベンダーツリーに置くことができる。ただし、その登録は本来、
登録対象の型を使用するソフトウェアを製作するベンダーまたは組織に
属し、そのベンダーまたは組織は、第三者によって行われた登録を修正
または更新するため、いつでも所有権を主張することを選択できる。
追加情報についてはSection 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 ほか Best Current Practice [Page 6]
RFC 6838 メディア型登録 2013年1月
個人ツリーに登録されるメディア型について公開およびレビューは要求
されないが、それらの仕様の品質を高めるため、レビューに
media-types@iana.orgメーリングリスト（Section 5.1参照）を使用することが
推奨される。個人ツリー内の登録はIANAに直接提出でき、承認前に
Expert Review [RFC5226]を受ける。
3.4. 未登録 x. ツリー
最初のファセットとして"x."を持つサブタイプ名は、私的なローカル環境で
の排他的な使用を意図した型に使用できる。このツリー内の型は登録
できず、それらを交換する当事者の明示的な合意がある場合にのみ使用
されることを意図している。
しかしながら、上記で説明したベンダーツリーおよび個人ツリーの簡略化
された登録手続きにより、未登録型を使用する必要は、あるとしても
まれである。したがって、"x."ツリー内の型の使用は強く非推奨である。
なお、"x-"で始まる名前を持つ型は、もはやこのツリーのメンバーとは
みなされない（[RFC6648]参照）。また、一般に有用で広く配備
されている型が誤って"x-"名前接頭辞を持つことになった場合、Appendix Aで
定義される手続きに従って、その現在の名前を用いて代替ツリーに登録しても
よい（MAY）。
3.5. 追加登録ツリー
ときどき、またコミュニティによって必要とされる場合、新しいトップ
レベル登録ツリーがIETF Standards Actionによって作成されることがある。
これらのツリーは、よく知られた永続的な組織による外部登録および管理の
ために作成され得ることが明示的に想定されている。たとえば、科学団体は
自らが扱う科学分野に固有のメディア型を登録できる。一般に、これらの
追加登録ツリーのいずれかに対する仕様レビューの品質は、認知された標準
関連組織による標準ツリー内の登録と同等であることが期待される。IETFが
そのようなレビューを行う場合、対象となるメディア型の主題に関して
要求組織が有するより高い専門性を考慮する必要がある。
4. 登録要件
メディア型登録はすべて、以下の節で示されるさまざまな要件に準拠する
ことが期待される。要件の具体的内容は、以下の節で詳述されるように、
登録ツリーによって変わる場合があることに注意すること。
Freed ほか Best Current Practice [Page 7]
RFC 6838 メディア型登録 2013年1月
4.1. 機能要件
メディア型は、実際のメディア形式として機能しなければならない（MUST）。
転送符号化、charset、または別の型の個別エンティティの集合と考えた
方がよいものを登録することは許可されない。たとえば、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 =/ "." ; Characters before first dot always
; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
; specify a structured syntax suffix
この構文は、[RFC2045]のSection 5.1または[RFC4288]のSection 4.2の
ABNFで許可されているものよりもやや制限的であることに注意すること。
また、この構文は最大127文字の名前を許可するが、実装上の制限により
そのような長い名前は問題となる可能性がある。そのため、<type-name>と
<subtype-name>は64文字以内に制限するべきである（SHOULD）。
名前構文は"."を他の任意の文字と同等に扱うが、最初の"."より前の文字は
常に登録ファセットを指定する。これは、ファセットを持たない標準ツリー
登録がサブタイプ名にピリオドを使用できないことを意味する点に注意する
こと。
Freed ほか Best Current Practice [Page 8]
RFC 6838 メディア型登録 2013年1月
同様に、サブタイプ名内の最後の"+"は、構造化構文指定子サフィックスを
導入する。構造化構文サフィックス要件はSection 4.2.8で規定される。
あるメディア型に追加の名前を割り当てることは可能であるが、同じ
メディア型を識別するために異なる名前を使用することは推奨されない。
これらの要件は、関係する登録ツリーに関係なく適用される。
トップレベル型の選択では、関係するメディア型の性質を考慮しなければ
ならない（MUST）。トップレベル型の新しいサブタイプは、そのトップ
レベル型に制限がある場合、それに準拠しなければならない（MUST）。
以下の節では、初期のトップレベル型の集合と、それぞれに関連付けられた
制限を説明する。さらに、HTTPおよびMIMEを含むがそれらに限定されない
さまざまなプロトコルは、それらが転送できるメディア型に追加の制限を
課してもよい（MAY）。（MIMEが課す制限に関する追加情報については
[RFC2046]を参照すること。）
4.2.1. text メディア型
"text"トップレベル型は、主としてテキスト形式の素材を送信することを
意図している。
textの多くのサブタイプ、特に[RFC2046]で定義されたプレーンテキストの
汎用サブタイプである"text/plain"は、"charset"パラメータを定義する。
特定のtextサブタイプに対して"charset"パラメータが定義される場合、
それは[RFC2978]に示される手続きに従って定義されたcharset名を指定する
ために使用されなければならない（MUST）。
[RFC6657]で規定されているように、charset情報がペイロード内部で運ばれる
場合（例："text/xml"の場合）、"charset"パラメータは指定するべきでは
ない（SHOULD NOT）。
"charset"パラメータを指定する場合、それは必須パラメータであるべきで
あり（SHOULD）、既定値を指定する選択肢を排除する。この助言にもかかわらず
パラメータを任意にする強い理由がある場合、各サブタイプは独自の既定値を
指定してもよく（MAY）、または代わりに既定値が存在しないことを指定しても
よい（MAY）。最後に、"UTF-8" charset [RFC3629]を既定値として選択
するべきである（SHOULD）。textサブタイプと組み合わせた"charset"
パラメータの使用に関する追加情報については[RFC6657]を参照すること。
どの方法を選択するかに関係なく、すべての新しいtext/*登録は、
charsetがどのように決定されるかを明確に指定しなければならない（MUST）。
[RFC2046]のSection 4.1.2で定義されるUS-ASCII既定値に依存することは
もはや
Freed ほか Best Current Practice [Page 9]
RFC 6838 メディア型登録 2013年1月
許可されない。説明文が必要な場合、それは登録の追加情報節に置くべきで
ある（SHOULD）。
プレーンテキストは、整形コマンド、フォント属性指定、処理命令、解釈
指示、またはコンテンツマークアップを提供せず、また許容しない。
プレーンテキストは、単に文字の線形列として見なされ、場合によっては
改行または改ページによって中断される。プレーンテキストは、テキスト内の
同じ位置に複数の文字を重ねることを許してもよい（MAY）。アラビア語や
ヘブライ語などの書字体系におけるプレーンテキストは、異なる書字方向の
テキスト部分を任意に混在させる機能を含むこともある。
プレーンテキスト以外にも、「リッチテキスト」として知られるものを表現
する形式は多数存在する。そのような表現の多くに見られる興味深い特徴は、
それらを解釈するソフトウェアがなくても、ある程度は読むことができる
点である。それらを、画像、音声、または読めない形式で表現された
テキストのような読めないデータと、最上位レベルで区別することは有用で
ある。適切な解釈ソフトウェアが存在しない場合、"text"のサブタイプを
ユーザーに提示することは合理的であるが、ほとんどの非テキストデータに
対してそうすることは合理的ではない。そのような整形されたテキスト
データは、"text"のサブタイプを使用して表現できる。
4.2.2. image メディア型
"image"のトップレベル型は、コンテンツが1つ以上の個別の画像を指定する
ことを示す。サブタイプは特定の画像形式を命名する。
4.2.3. audio メディア型
"audio"のトップレベル型は、コンテンツが音声データを含むことを示す。
サブタイプは特定の音声形式を命名する。
4.2.4. video メディア型
"video"のトップレベル型は、コンテンツが時間変化する画像を指定し、
場合によっては色や同期された音声を伴うことを示す。'video'という用語は、
特定の技術や形式を指すものではなく、最も一般的な意味で使用される。
また、コンパクトに符号化されたアニメーション描画のようなサブタイプを
排除することを意図していない。
一般に、単一の本体内で複数種類のメディアを混在させることは
推奨されないが[RFC2046]、多くの動画形式が同期された音声および/または
テキストの表現を含むことが認識されており、これは"video"のサブタイプに
ついて明示的に許可される。
Freed ほか Best Current Practice [Page 10]
RFC 6838 メディア型登録 2013年1月
4.2.5. application メディア型
"application"トップレベル型は、他のいずれの型名にも該当しない離散
データに使用され、特に何らかの種類のアプリケーションプログラムに
よって処理されるデータに使用される。これは、ユーザーが閲覧または使用
できるようになる前に、アプリケーションによって処理されなければならない
情報である。"application"型名の想定される用途には、ファイル転送、
スプレッドシート、プレゼンテーション、スケジューリングデータ、および
「能動的」（計算的）素材のための言語が含まれるが、それらに限定されない。
（特に最後のものは、実装者が理解しなければならないセキュリティ問題を
引き起こす可能性がある。[RFC2046]の"application/postscript"
メディア型登録は、これらの問題をどのように扱うかの良い例を提供する。）
たとえば、会議スケジューラは、提案された会議日時に関する情報の標準的な
表現を定義することがある。知的なユーザーエージェントはこの情報を使用して
ユーザーとの対話を行い、その対話に基づいて追加の素材を送信することがある。
より一般的には、適切に特殊化された言語によるプログラムを遠隔地に転送し、
受信者の環境で自動的に実行する「能動的」言語がいくつか開発されている。
そのようなアプリケーションは、"application"トップレベル型のサブタイプ
として定義されることがある。
"application"のサブタイプは、多くの場合、そのデータが対象とする
アプリケーションの名前であるか、またはその名前の一部を含む。ただし、
これは任意のアプリケーションプログラム名を単に"application"の
サブタイプとして自由に使用してよいことを意味しない。サブタイプは
登録される必要がある。
4.2.6. multipart および message メディア型
multipartおよびmessageは複合型である。すなわち、それらは0個以上の
オブジェクトをカプセル化する手段を提供し、それぞれが別個のメディア型
である。
multipartおよびmessageのすべてのサブタイプは、[RFC2046]で規定され、
[RFC6532]のSection 3.5によって修正された構文規則およびその他の要件に
準拠しなければならない（MUST）。
Freed ほか Best Current Practice [Page 11]
RFC 6838 メディア型登録 2013年1月
4.2.7. 追加トップレベル型
場合によっては、新しいメディア型が現在定義されているどのトップレベル
型名にも「適合」しないことがある。そのような場合は極めてまれであると
期待される。しかし、そのような場合が発生した場合、それに対応するために
新しい型名を定義できる。新しいトップレベル型名の定義は、Standards
Track RFCによって行われなければならない（MUST）。追加の型名を定義する
ために他の仕組みを使用することはできない。
4.2.8. 構造化構文名サフィックス
XML in MIME [RFC3023]は、そのメディア型の基礎となる構造を追加で指定する
ために、メディア型定義に対する最初のそのような拡張を定義した。引用すると、
本文書はまた、それらのメディア型がXML MIME
（Multipurpose Internet Mail Extensions）エンティティを
表す場合に、メディア型を命名するための規約（サフィックス
'+xml'を使用する）を標準化する ...
つまり、基底サブタイプ名に付加されるサフィックス（その場合は"+xml"）を
指定した。
これが公開されて以来、このサフィックス規約を他のよく知られた構造化構文に
使用する事実上の慣行が生じた。特に、"+der"、"+fastinfoset"、および
"+json"などのサフィックスを持つメディア型が登録されている。本仕様は、
この慣行を正式化し、構造化型名サフィックスのためのレジストリを設ける。
構造化型名サフィックスが登録可能かどうかに関する主要な指針は、それが
容易に入手できる記述によって説明されていることであり、確立された標準
関連組織によって公開された文書内であることが望ましく、RFCのNormative
References節で使用できる参照が存在することである。
名前付き構造化構文を使用するメディア型は、登録時にその構造化構文に
対応する登録済みの"+suffix"を使用するべきである（SHOULD）。同様に、
メディア型には、実際には使用していない構造化構文のサフィックスを
組み込んだ名前を与えてはならない（MUST NOT）。将来のサフィックス定義との
競合の可能性があるため、まだ登録されていない構造化構文に対する
"+suffix"構文は使用するべきではない（SHOULD NOT）。
Freed ほか Best Current Practice [Page 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]はいずれも、バイナリパラメータおよび特定の
charsetで表現されたパラメータ値を許可するが、他のプロトコルはより柔軟性が
低い場合がある。
標準ツリーに登録された型に新しい機能を導入する手段として、新しい
パラメータを定義するべきではない（SHOULD NOT）。ただし、既存の機能を
変更しない追加情報を伝達するために、新しいパラメータを追加してもよい
（MAY）。
Freed ほか Best Current Practice [Page 13]
RFC 6838 メディア型登録 2013年1月
その一例は、JPEGのような外部仕様の改訂レベルを示す"revision"
パラメータである。同様の振る舞いは、ベンダーツリーまたは個人ツリーに
登録されたメディア型でも推奨されるが、要求されない。
パラメータの変更（新しいパラメータの導入を含む）は、メディア型に対する
他の変更と同じ方法で管理される。Section 5.5を参照すること。
4.4. 正規化および形式要件
すべての登録済みメディア型は、登録ツリーに関係なく、単一の正規データ
形式を採用しなければならない（MUST）。
標準ツリーに登録されるすべての型について、そのメディア型の形式に関する
永続的かつ容易に入手可能な公開仕様が存在しなければならない（MUST）。
この仕様は、そのメディア型を使用する独立した実装間の相互運用性が可能に
なるよう、十分な詳細を提供しなければならない（MUST）。この仕様は、少なく
とも、メディア型登録提案自体に含まれていない場合でも、そこから参照されて
いなければならない（MUST）。
ベンダーツリーおよび個人ツリーに登録されたメディア型については、形式および
処理の詳細に関する仕様が公開されている場合もあれば、そうでない場合もある。
そのような登録では、どのソフトウェアおよびバージョンがそのようなメディア型を
生成または処理するかに関する情報に登録内容を限定することが明示的に許可される。
そのため、登録内で形式仕様を参照または含めることは推奨されるが、要求されない。
ただし、有意味な仕様が公開されていることは、多くの場合、他の使用との衝突を
避けるために単に名前を予約するだけで終わるか、そのメディア型の他の実装および
それらとの有用な相互運用の可能性を持つかの違いを生むことに注意すること。
一部のメディア型は、特許技術の使用を伴う。特許技術を伴うメディア型の登録は
明示的に許可される。ただし、メディア型の仕様がStandards Trackプロトコルの
一部である場合、IETF Standards Trackプロトコルにおける特許技術の使用に関する
BCP
79 [RFC3979]およびBCP 78 [RFC5378]に定められた制限を
尊重しなければならない。さらに、標準ツリーを利用する他の標準関連組織には、
その登録において遵守すべき独自の知的財産に関する規則がある場合がある。
ベンダーツリーおよび個人ツリー内の登録に関する知的財産権（IPR）の開示は
推奨されるが、要求されない。
Freed ほか Best Current Practice [Page 14]
RFC 6838 メディア型登録 2013年1月
4.5. 交換に関する推奨事項
理想的には、メディア型は、可能な限り多くのシステムおよび
アプリケーション間で相互運用できるよう定義される。しかし、一部の
メディア型では、異なるプラットフォーム間での相互運用において
問題が避けられない。異なるバージョン、バイト順序、および
ゲートウェイ処理の詳細に関する問題は発生し得るし、実際に発生する。
メディア型の普遍的な相互運用性は要求されないが、既知の相互運用性上の
問題は、可能な場合には識別されるべきである（SHOULD）。メディア型の
公開は、相互運用性の網羅的レビューを要求するものではなく、相互運用性に
関する考慮事項の節は継続的な評価の対象となる。
本小節の推奨事項は、関係する登録ツリーに関係なく適用される。
4.6. セキュリティ要件
標準ツリーに登録されるすべての型について、セキュリティ問題の分析が
行われなければならない（MUST）。ベンダーツリーまたは個人ツリーに登録
されるメディア型についても同様の分析が推奨されるが、要求はされない。
ただし、どのようなセキュリティ分析が行われたか、または行われていないかに
関係なく、セキュリティ問題のすべての記述は、登録ツリーに関係なく、
可能な限り正確でなければならない（MUST）。特に、セキュリティに関する
考慮事項では、「この型に関連するセキュリティ問題はない」と述べては
ならない（MUST NOT）。ベンダーツリーまたは個人ツリー内の型に関する
セキュリティ考慮事項では、「この型に関連するセキュリティ問題は評価
されていない」と述べてもよい（MAY）。
いずれのツリーに登録されるメディア型についても、それが安全であること、
またはリスクから完全に自由であることを要求するものは一切ない。それでも、
既知のセキュリティリスクはすべて、登録ツリーに関係なく、メディア型の
登録において識別されなければならない（MUST）。
すべての登録のセキュリティに関する考慮事項の節は、継続的な評価および
修正の対象であり、特に以下のSection 5.4で説明する
「メディア型へのコメント」機構の使用によって拡張されてもよい（MAY）。
メディア型のセキュリティ分析で検討し、記述する必要がある問題には、
次のようなものがある。
o 複雑なメディア型には、受信者のファイルまたはその他のリソースに
対して動作を開始する指示のための規定が含まれる場合がある。多くの
場合、生成者が任意の動作を制限なく指定できるようになっており、
それが破壊的な影響を及ぼす可能性がある。そのような指示の例と、
それらをメディア型登録でどのように記述できるかについては、[RFC2046]における
application/postscriptメディア
Freed ほか Best Current Practice [Page 15]
RFC 6838 メディア型登録 2013年1月
型の登録を参照すること。
o いかなるセキュリティ分析も、そのような「能動的コンテンツ」を使用するか
どうかを述べなければならない（MUST）。使用する場合、メディア型の
利用者を害から保護するために、どのような措置が講じられているか、
またはそのメディア型のアプリケーションによって講じられなければ
ならないかを述べなければならない（MUST）。
o 複雑なメディア型には、受信者に直接害を与えないものの、後続の攻撃を
容易にする情報の開示、または何らかの形で受信者のプライバシーを
侵害する情報の開示につながる動作を開始する指示のための規定が含まれる
場合がある。ここでも、application/postscriptメディア型の登録は、
そのような指示をどのように扱うことができるかを示している。
o 圧縮を使用するメディア型は、少量のデータを送信し、それが受信されて
評価されると巨大に展開され、受信者のリソースをすべて消費する機会を
与える場合がある。すべてのメディア型は、圧縮を使用するかどうかを
述べるべきであり（SHOULD）、使用する場合、そのような攻撃を避けるために
どのような措置を講じる必要があるかを議論するべきである（SHOULD）。
o メディア型は、何らかの種類のセキュリティ保証を必要とするが、それ自体では
必要なセキュリティ機構を提供しないアプリケーションを対象とする場合がある。
たとえば、機密性の高い医療情報の保存用としてメディア型が定義され、
それが外部の機密性および完全性保護サービスを必要とする場合、または
安全な環境内でのみ使用されるよう設計されている場合がある。型は常に、
そのようなサービスを必要とするかどうかをセキュリティに関する考慮事項に
記録するべきである（SHOULD）。
4.7. XMLメディア型固有の要件
XMLメディア型の登録には、いくつかの追加要件がある。これらの要件は
[RFC3023]で規定されている。
4.8. 符号化要件
一部のトランスポートは、運べるデータの種類に制限を課す。たとえば、
インターネットメールは伝統的に7bit US-ASCIIテキストに限定されていた。
そのようなトランスポート上の制限を回避するため、符号化方式がよく
使用される。
Freed ほか Best Current Practice [Page 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]のSection
4.1.1に示されている。
4.9. 使用および実装上の非要件
非同期メール環境では、相手側メールエージェントの能力に関する情報が
送信者に頻繁には利用できないため、広く実装されることが期待される
「共通」形式に使用するメディア型を制限することで、最大限の相互運用性が
得られる。これは過去に、可能なメディア型の数を制限する理由として主張
され、メディア型を登録する者にとって大きな障害と遅延を伴う登録プロセスを
もたらした。
しかし、「共通」メディア型の必要性は、新しいメディア型の登録を制限する
ことを要求しない。特定のアプリケーションに対して限定されたメディア型の
集合が推奨される場合、それはそのアプリケーションおよび/または環境に固有の
別個の適用性声明によって主張されるべきである。
したがって、メディア型の普遍的なサポートおよび実装は、登録の要件では
ない（NOT）。ただし、メディア型が
Freed ほか Best Current Practice [Page 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]のSection 3.5で規定）をアプリケーションがどのように解釈すべきかを
指定できる。
Freed ほか Best Current Practice [Page 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 ほか Best Current Practice [Page 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 ほか Best Current Practice [Page 20]
RFC 6838 メディア型登録 2013年1月
5.3. レビューと承認
暫定的な標準ツリー登録を除き、IANAに提出された登録はメディア型レビューアに
転送される。IETF Applications Area Director（複数可）によって任命される
メディア型レビューアは、その登録が本文書で定められた要件を満たしているかを
確認するためレビューする。これらの要件を満たさない登録は、改訂のために
提出者へ返却される。
メディア型レビューアによる決定は、[RFC2026]のSection 6.5.4で規定される
手続きを使用してIESGへ上訴できる。
メディア型登録がレビューを通過すると、IANAはそのメディア型を登録し、
メディア型登録をコミュニティが利用できるようにする。
他の標準関連組織からの標準ツリー登録の場合、IANAは提出者が実際に認知された
標準関連組織であることも確認する。提出者が現在そのように認知されていない
場合、IESGにその地位の確認が求められる。標準ツリー登録を進める前に、IESGからの
認知を取得しなければならない（MUST）。
5.4. メディア型登録へのコメント
登録済みメディア型へのコメントは、コミュニティのメンバーによって
iana@iana.orgのIANAへ提出されてもよい。これらのコメントはメディア型
レビューアによってレビューされ、可能であればメディア型の「所有者」へ渡される。
コメント提出者は、自分のコメントをメディア型登録自体に添付するよう要求できる。
IANAがメディア型レビューアと協議のうえ承認した場合、そのコメントは型登録と
関連付けてアクセス可能にされる。
5.5. 変更手続き
メディア型がIANAによって公開された後、所有者はその定義の変更を要求できる。
上記の異なる登録ツリーの記述では、各種類の登録の「所有者」が指定されている。
変更要求の処理には、元の登録要求に適切であったものと同じ手続きが使用される。
メディア型登録は削除できない。使用に適さなくなったと考えられるメディア型は、
その"intended use"フィールドへの変更によりOBSOLETEと宣言できる。そのような
メディア型は、IANAが公開するリスト内で明確に表示される。
Freed ほか Best Current Practice [Page 21]
RFC 6838 メディア型登録 2013年1月
メディア型の定義に対する重大な変更は、公開された仕様に深刻な欠落または
誤りがある場合にのみ要求されるべきである。レビューが必要な場合、変更要求は、
以前の定義で有効であったエンティティを新しい定義では無効にするならば、
拒否されることがある。
メディア型の所有者は、IANAに通知することで、責任を別の人物または機関に
渡すことができる。これは議論またはレビューなしに行える。
IESGは、メディア型に関する責任を再割り当てしてもよい。最も一般的な場合は、
登録の著者が死亡した、連絡が取れなくなった、またはコミュニティにとって
重要な変更を行えないその他の状態にある型について、変更を可能にする場合である。
5.6. 登録テンプレート
型名:
サブタイプ名:
必須パラメータ:
任意パラメータ:
符号化に関する考慮事項:
セキュリティに関する考慮事項:
相互運用性に関する考慮事項:
公開仕様:
このメディア型を使用するアプリケーション:
フラグメント識別子に関する考慮事項:
追加情報:
この型の非推奨別名:
マジックナンバー:
ファイル拡張子:
Macintoshファイルタイプコード:
追加情報の連絡先となる人物およびメールアドレス:
Freed ほか Best Current Practice [Page 22]
RFC 6838 メディア型登録 2013年1月
意図される用途:
（COMMON、LIMITED USE、またはOBSOLETEのいずれか。）
使用上の制限:
（メディア型を使用できる場所に関する制限があればここに記載する。）
著者:
変更管理者:
暫定登録か?（標準ツリーのみ）:
（著者が興味深いと考えるその他の情報は、この行の下に追加してもよい。）
"N/A"は、適用されないこと、または質問が偶然省略されたわけではないことを
強調したい場合、任意のフィールドでそのまま正確に記述して使用できる。
回答と誤認される可能性のある'none'またはその他の語を使用してはならない。
限定使用のメディア型は、アプリケーション一覧において、その一覧が網羅的で
あるかどうかも記すべきである。
6. 構造化構文サフィックス登録手続き
新しいメディア型登録で使用する構造化構文のために"+suffix"名を定義したい者は、
次のことを行うべきである（SHOULD）。
1. IANAのメディア型名サフィックスレジストリを確認し、その十分に定義された
構造化構文について既に項目があるかどうかを確認する。
2. そのサフィックス方式の項目がない場合、テンプレート（Section 6.2で
規定）に記入し、それをメディア型登録に含める。テンプレートは、
単独で、または他のプロトコル仕様の一部としてInternet Draftに含めてもよい。
テンプレートは他の形式（別の文書の一部または独立した文書）で提出しても
よいが、その内容はBCP 78 [RFC5378]の指針の下で
"IETF Contribution"として扱われる。
3. テンプレートの写し、またはそれを含む文書へのポインタ（テンプレートを含む
節への具体的な参照を伴う）を、レビューを要求してメーリングリスト
media-types@iana.orgへ送信する。
Freed ほか Best Current Practice [Page 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. 構造化構文サフィックス登録テンプレート
このテンプレートは、構造化構文サフィックス登録要求で提供しなければならない
フィールドを説明する。
Name
十分に定義された構造化構文の完全な名前。
Freed ほか Best Current Practice [Page 24]
RFC 6838 メディア型登録 2013年1月
+suffix
その構文への適合を示すために使用されるサフィックス。
References
構造化構文を理解するために必要なすべての仕様について、完全な引用を
含める。
Encoding considerations
この構文を使用する任意の型に対する符号化に関する考慮事項の一般的指針を、
ここに示すべきである。Section 4.8で示されるメディア型符号化に関する
考慮事項と同じ要件がここにも適用される。
Interoperability considerations
この構造化構文を使用する型の相互運用可能な利用に関する問題があれば、
ここに示すべきである。例としては、その構文の互換性のないバージョンの存在、
特定のcharsetと構文を組み合わせる際の問題、または他の型やプロトコルとの
非互換性が含まれる。
Fragment identifier considerations
この構文を使用する任意の型に対するフラグメント識別子の汎用処理を、
ここに記述するべきである。
Security considerations
この構造化構文を使用するメディア型に共通するセキュリティ考慮事項は、
ここで指定されなければならない。Section 4.6で示されるメディア型
セキュリティ考慮事項と同じ要件がここにも適用される。ただし、
セキュリティ考慮事項を評価しないという選択肢は、サフィックス登録では
利用できない。
Contact
追加情報の連絡先となる人物（連絡先情報を含む）。
Author/Change controller.
このサフィックス登録を変更する権限を持つ人物（連絡先情報を含む）。
7. セキュリティに関する考慮事項
メディア型およびメディア型サフィックス登録の両方に対するセキュリティ要件は、
Section 4.6で議論されている。
Freed ほか Best Current Practice [Page 25]
RFC 6838 メディア型登録 2013年1月
8. IANAに関する考慮事項
本文書の目的は、メディア型および構造化構文サフィックスのIANAレジストリ、
ならびにこれらのレジストリを管理するための手続きを定義することである。
さらに、本文書はIANAに対し、IESGが標準ツリー内のメディア型登録を承認した
標準関連組織の一覧を維持することを要求する。
既存のメディア型レジストリは、暫定登録のための節を含むよう拡張されている。
標準ツリー内では標準ツリー登録のみが許可され、IANAの標準関連組織一覧にある
組織の要求による場合に限られる。暫定登録に関する追加情報については
Section 5.2.1を参照すること。
IANAは暫定レジストリの先頭に、次の注記も追加している。
このレジストリは、他の一部の暫定IANAレジストリとは異なり、
一時的な使用のみを目的とする。このレジストリ内の項目は、
最終化されて主要なメディア型レジストリへ移動されるか、
放棄されて削除される。このレジストリ内の項目は、開発および
試験目的での使用にのみ適している。
構造化構文名サフィックスレジストリは、次のように作成されている。
o 名称は"Structured Syntax Suffix"レジストリである。
o 登録プロセスはSection 6で規定される。
o レジストリ項目に必要な情報および項目形式はSection 6.2で規定される。
o レジストリの初期内容は[RFC6839]で規定される。
メディア型および構造化サフィックスの両方のレジストリ内の項目には、IANAにより
元の登録日と、その項目に対する直近の更新日の両方が注記される。本仕様の実装前に
行われた登録は、必要に応じて、特定の日付ではなく、その旨を示す印を付けてもよい。
登録項目は複数回更新される可能性があるため、IANAは、任意の時点における登録の
状態を判定できるよう、各登録に対する変更履歴も維持する。
Freed ほか Best Current Practice [Page 26]
RFC 6838 メディア型登録 2013年1月
最後に、本文書に従い、IANAはメディア型レビューリスト用に新しいメールアドレス
media-types@iana.orgを作成した。これはRFC 4288で規定された
ietf-types@iana.orgアドレスを置き換えるものである。ietf-types@iana.orgは
別名として保持されている。
9. 謝辞
現在の著者らは、故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, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML
Media Types", RFC 3023, January 2001.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
Freed ほか Best Current Practice [Page 27]
RFC 6838 メディア型登録 2013年1月
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic
Syntax", STD 66, RFC 3986, January 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234,
January 2008.
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors
Provide to the IETF Trust", BCP 78, RFC 5378,
November 2008.
[RFC6532] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers", RFC 6532,
February 2012.
[RFC6657] Melnikov, A. and J. Reschke, "Update to MIME
regarding "charset" Parameter Handling in Textual
Media Types", RFC 6657, July 2012.
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type
Structured Syntax Suffixes", RFC 6839,
January 2013.
10.2. 参考参照
[MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and
Creator Codes, and File Formats", Apple Knowledge
Base Article 55381, June 1993,
<http://www.info.apple.com/kbnum/n55381>.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2048] Freed, N., Klensin, J., and J. Postel,
"Multipurpose Internet Mail Extensions (MIME) Part
Four: Registration Procedures", BCP 13, RFC 2048,
November 1996.
Freed ほか Best Current Practice [Page 28]
RFC 6838 メディア型登録 2013年1月
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions:
Character Sets, Languages, and Continuations",
RFC 2231, November 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2616, June 1999.
[RFC4288] Freed, N. and J. Klensin, "Media Type
Specifications and Registration Procedures",
BCP 13, RFC 4288, December 2005.
[RFC5987] Reschke, J., "Character Set and Language Encoding
for Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs
in Application Protocols", BCP 178, RFC 6648,
June 2012.
Freed ほか Best Current Practice [Page 29]
RFC 6838 メディア型登録 2013年1月
Appendix A. 既存扱いのメディア型
1996年以前に登録された、ファセットなしのサブタイプ名を持つ多数の
メディア型は、本文書の指針の下で登録されるならば、ファセット付き名前が
与えられ、ベンダーツリーまたは個人ツリーのいずれかに置かれることになる。
適切なツリーを反映するためのそれらの型の再登録は推奨されるが、要求は
されない。本文書で概説される所有権および変更管理の原則は、それらの型が
上記で説明したツリーに登録されていたかのように適用される。
ときどき、ファセットなしのサブタイプ名を持つメディア型が、登録されないまま
広く配備されている場合もある。（これは"x-"接頭辞で始まるサブタイプ名を
含むことに注意すること。）可能であれば、そのようなメディア型は、元の名前を
識別するために非推奨別名を使用する可能性も含め、適切なファセット付き
サブタイプ名で再登録されるべきである（SHOULD）（Section 4.2.9参照）。
しかし、これが不可能な場合、その型は、メディア型レビューアとIESGの両方の
承認を条件として、ファセットなしの名前を用いて適切なツリーに登録できる。
Appendix B. RFC 4288以降の変更
o 特定の構造化構文の使用を示すサフィックスが、現在では完全に規定され、
サフィックス登録プロセスが定義された。
o 広く配備された未登録のファセットなし型名をベンダーツリーまたは個人ツリーに
登録することが、メディア型レビューアおよびIESGの承認を条件として、
現在では許可される。
o 標準ツリー登録プロセスは、Expert Reviewを含むよう改訂され、非IETF stream
文書内のメディア型のような場合に対応するよう一般化された。
o フラグメント識別子用のフィールドが登録テンプレートに追加され、
フラグメント識別子を指定するための簡潔な指示が追加された。
o 個人ツリー登録に対する仕様要件は、ベンダーツリーに対する要件と同じになるよう
変更された。仕様の可用性を推奨する（ただし要求しない）よう本文が変更された。
o 追加ツリーを定義するプロセスは、IETF Standards Actionが必要であることを
明記するよう明確化された。
o "x-"名を持つ広く配備された型は、現在ではベンダーツリーに例外として登録できる。
Freed ほか Best Current Practice [Page 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 ほか Best Current Practice [Page 31]
RFC 6838 メディア型登録 2013年1月
著者の住所
Ned Freed
Oracle
800 Royal Oaks
Monrovia, CA 91016-6347
USA
EMail: ned+ietf@mrochek.com
John C. Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
EMail: john+ietf@jck.com
Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ 07748
USA
EMail: tony+mtsuffix@maillennium.att.com
Freed ほか Best Current Practice [Page 32]