Network Working Group N. Freed
Request for Comments: 4288 Sun Microsystems
BCP: 13 J. Klensin
Obsoletes: 2048 December 2005
Category: Best Current Practice
Media Type Specifications and Registration Procedures
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols.
この文書は、MIMEやその他のインターネットプロトコルで使用するためのメディアタイプの仕様と登録のための手続きを定義します。
Table of Contents
目次
1. Introduction ....................................................3
2. Media Type Registration Preliminaries ...........................4
3. Registration Trees and Subtype Names ............................4
3.1. Standards Tree .............................................4
3.2. Vendor Tree ................................................5
3.3. Personal or Vanity Tree ....................................5
3.4. Special x. Tree ............................................5
3.5. Additional Registration Trees ..............................6
4. Registration Requirements .......................................6
4.1. Functionality Requirement ..................................6
4.2. Naming Requirements ........................................6
4.2.1. Text Media Types ......................................7
4.2.2. Image Media Types .....................................8
4.2.3. Audio Media Types .....................................8
4.2.4. Video Media Types .....................................8
4.2.5. Application Media Types ...............................9
4.2.6. Multipart and Message Media Types .....................9
4.2.7. Additional Top-level Types ............................9
4.3. Parameter Requirements ....................................10
4.4. Canonicalization and Format Requirements ..................10
4.5. Interchange Recommendations ...............................11
4.6. Security Requirements .....................................11
4.7. Requirements specific to XML media types ..................13
4.8. Encoding Requirements .....................................13
4.9. Usage and Implementation Non-requirements .................13
4.10. Publication Requirements .................................14
4.11. Additional Information ...................................15
5. Registration Procedure .........................................15
5.1. Preliminary Community Review ..............................16
5.2. IESG Approval .............................................16
5.3. IANA Registration .........................................16
5.4. Media Types Reviewer ......................................16
6. Comments on Media Type Registrations ...........................17
7. Location of Registered Media Type List .........................17
8. IANA Procedures for Registering Media Types ....................17
9. Change Procedures ..............................................18
10. Registration Template .........................................19
11. Security Considerations .......................................20
12. IANA Considerations ...........................................20
13. Acknowledgements ..............................................20
14. References ....................................................20
Appendix A. Grandfathered Media Types ............................22
Appendix B. Changes Since RFC 2048 ...............................22
Recent Internet protocols have been carefully designed to be easily extensible in certain areas. In particular, many protocols, including but not limited to MIME [RFC2045], are capable of carrying arbitrary labeled content. A mechanism is needed to label such content and a registration process is needed for these labels, to ensure that the set of such values is developed in an orderly, well-specified, and public manner.
最近のインターネットプロトコルは、慎重に特定の領域に容易に拡張できるように設計されています。具体的には、MIME [RFC2045]を含むがこれらに限定されない多くのプロトコルは、任意の標識されたコンテンツを運ぶことが可能です。機構は、そのようなコンテンツにラベルを付けるために必要とされると、登録プロセスは、そのような値のセットが、秩序よく指定され、公共の方法で展開されることを保証するために、これらのラベルのために必要とされます。
This document defines media type specification and registration procedures that use the Internet Assigned Numbers Authority (IANA) as a central registry.
この文書は、中央レジストリとしてインターネット割り当て番号機関（IANA）を使用してメディアタイプ仕様と登録手続きを定義します。
Historical Note
ヒストリカルノート
The media type registration process was initially defined for registering media types for use in the context of the asynchronous Internet mail environment. In this mail environment there is a need to limit the number of possible media types, to increase the likelihood of interoperability when the capabilities of the remote mail system are not known. As media types are used in new environments in which the proliferation of media types is not a hindrance to interoperability, the original procedure proved excessively restrictive and had to be generalized. This was initially done in [RFC2048], but the procedure defined there was still part of the MIME document set. The media type specification and registration procedure has now been moved to this separate document, to make it clear that it is independent of MIME.
メディアタイプの登録プロセスは、最初の非同期インターネットメール環境のコンテキストで使用するためにメディアタイプを登録するために定義されました。このメール環境でのリモートメールシステムの能力が知られていない場合は、相互運用性の可能性を高めるために、可能なメディアタイプの数を制限する必要があります。メディアタイプは、メディアタイプの増殖が相互運用性に支障ないような新しい環境で使用されると、元のプロシージャは過度に制限的証明し、一般化されなければなりませんでした。これは、最初に[RFC2048]で行われましたが、手続きは、MIMEドキュメントセットの一部が残っていた定義されました。メディアタイプの仕様と登録手続きは今それを明確にそれがMIMEとは独立していることを確認するために、この別の文書に移動されました。
It may be desirable to restrict the use of media types to specific environments or to prohibit their use in other environments. This revision attempts for the first time to incorporate such restrictions into media type registrations in a systematic way. See Section 4.9 for additional discussion.
特定の環境にメディアタイプの使用を制限したり、他の環境での使用を禁止することが望ましいことがあります。この改正は、体系的な方法でメディアタイプの登録にかかる制限を組み込むために初めて試みます。追加の議論については、セクション4.9を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This specification makes use of the Augmented Backus-Naur Form (ABNF) [RFC4234] notation, including the core rules defined in Appendix A of that document.
この仕様は、拡張バッカス・ナウアフォーム（ABNF）そのドキュメントの付録Aで定義されたコア・ルールを含む[RFC4234]表記を使用します。
Registration of a new media type or types starts with the construction of a registration proposal. Registration may occur within several different registration trees that have different requirements, as discussed below. In general, a new registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The media type is then registered if the proposal is acceptable. The following sections describe the requirements and procedures used for each of the different registration trees.
新しいメディアの種類やタイプの登録は、登録提案の建設を開始します。登録は以下に述べるように、異なる要件を持っているいくつかの異なる登録木の中に発生する可能性があります。一般的には、新規登録の提案が関与ツリーへの適切な方法で循環して見直されています。提案が受け入れ可能であるならば、メディアタイプは、登録されています。以下のセクションでは、異なる登録木のそれぞれのために使用要件および手順を記載しています。
In order to increase the efficiency and flexibility of the registration process, different structures of subtype names may be registered to accommodate the different natural requirements for, e.g., a subtype that will be recommended for wide support and implementation by the Internet community, or a subtype that is used to move files associated with proprietary software. The following subsections define registration "trees" that are distinguished by the use of faceted names, e.g., names of the form "tree.subtree...subtype". Note that some media types defined prior to this document do not conform to the naming conventions described below. See Appendix A for a discussion of them.
登録プロセスの効率性と柔軟性を高めるためには、サブタイプ名の異なる構造は、例えばのための異なる自然な要件に対応するためにインターネットコミュニティによって幅広い支持と実装のために推奨されるサブタイプ、またはサブタイプを登録することができますそれは、独自のソフトウェアに関連するファイルを移動するために使用されます。以下のサブセクションでは、ファセット名の使用によって区別され、登録「木」、フォーム「tree.subtree ...サブタイプ」の、例えば、名前を定義します。以前このドキュメントに定義されたいくつかのメディアタイプは、以下の命名規則に準拠していないことに注意してください。それらの議論については、付録Aを参照してください。
The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be approved by the IESG and MUST correspond to a formal publication by a recognized standards body. In the case of registration for the IETF itself, the registration proposal MUST be published as an RFC. Standards-tree registration RFCs can either be standalone "registration only" RFCs, or they can be incorporated into a more general specification of some sort.
規格木は、インターネットコミュニティへの一般的な関心のタイプを対象としています。規格木の登録はIESGによって承認されなければならないと認識し標準化団体によって正式な出版物に対応しなければなりません。 IETF自体の登録の場合、登録提案は、RFCとして公開する必要があります。標準ツリー登録RFCは、スタンドアロンの「登録のみ」のRFCのいずれかであることができる、または、彼らはある種のより一般的な仕様に組み込むことができます。
Media types in the standards tree are normally denoted by names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters.
規格木におけるメディアタイプは、通常、すなわち、（「」、フルストップ）文字ピリオドが含まれていない、明示的に多面的でない名前が付されています。
The "owner" of a media type registration in the standards tree is assumed to be the standards body itself. Modification or alteration of the specification requires the same level of processing (e.g., standards track) required for the initial registration.
規格木におけるメディアタイプ登録の「所有者」は標準化団体そのものであると仮定されます。仕様の変更や改変は、初期登録に必要な処理と同じレベル（例えば、基準トラック）を必要とします。
The vendor tree is used for media types associated with commercially available products. "Vendor" or "producer" are construed as equivalent and very broadly in this context.
ベンダー・ツリーは、市販の製品に関連したメディアタイプのために使用されています。 「ベンダー」または「プロデューサー」は、等価物として、非常に広く、この文脈で解釈されます。
A registration may be placed in the vendor tree by anyone who needs to interchange files associated with the particular product. However, the registration formally belongs to the vendor or organization producing the software or file format being registered. Changes to the specification will be made at their request, as discussed in subsequent sections.
登録は、特定の製品に関連するファイルを交換する必要がある人で、ベンダツリーに配置することができます。ただし、登録が正式に登録されているソフトウェアやファイル形式を生成するベンダーや組織に属しています。後続のセクションで説明したように仕様への変更は、それらの要求に応じて行われます。
Registrations in the vendor tree will be distinguished by the leading facet "vnd.". That may be followed, at the discretion of the registrant, by either a media subtype name from a well-known producer (e.g., "vnd.mudpie") or by an IANA-approved designation of the producer's name that is followed by a media type or product designation (e.g., vnd.bigcompany.funnypictures).
ベンダ木の登録は大手面で区別されます「VND。」。それは、（例えば、「vnd.mudpie」）またはメディアが続いているプロデューサの名前のIANAが承認した指定によって、よく知られている生産者からのメディアサブタイプ名のいずれかにより、登録者の裁量で、続いてもよいですタイプまたは製品名称（例えば、vnd.bigcompany.funnypictures）。
While public exposure and review of media types to be registered in the vendor tree is not required, using the ietf-types@iana.org mailing list for review is strongly encouraged to improve the quality of those specifications. Registrations in the vendor tree may be submitted directly to the IANA.
公共の暴露とベンダ木に登録するメディアタイプの見直しは必須ではありませんが、レビューのためにietf-types@iana.orgメーリングリストを使って強く、これらの仕様の品質を向上することが奨励されます。ベンダ木の登録はIANAに直接提出することができます。
Registrations for media types created experimentally or as part of products that are not distributed commercially may be registered in the personal or vanity tree. The registrations are distinguished by the leading facet "prs.".
メディアタイプの登録は、実験的または商業的に配布されていない個人や虚栄心、ツリーに登録することができる製品の一部として作成されました。登録は主要な面で区別されている「PRS。」。
The owner of "personal" registrations and associated specifications is the person or entity making the registration, or one to whom responsibility has been transferred as described below.
「個人」の登録と関連仕様の所有者は、個人または団体の登録を行うか、後述のように責任が転送されてきた人に一つです。
While public exposure and review of media types to be registered in the personal tree is not required, using the ietf-types list for review is strongly encouraged to improve the quality of those specifications. Registrations in the personal tree may be submitted directly to the IANA.
公共露出、個人ツリーに登録するメディアタイプのレビューはレビューのために、IETFの種類のリストを使用して、必要とされていないが強く、これらの仕様の品質を向上することが奨励されます。個人的なツリー内の登録はIANAに直接提出することができます。
For convenience and symmetry with this registration scheme, subtype names with "x." as the first facet may be used for the same purposes for which names starting in "x-" are used. These types are unregistered, experimental, and for use only with the active agreement of the parties exchanging them.
この登録制度、サブタイプ名の利便性と対称性のために「×」。第一の端面は、「X-」で始まる名前が使用されるため、同じ目的のために使用することができるように。これらのタイプは、未登録の実験、およびそれらだけを交換する当事者の積極的合意で使用します。
However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged.
しかし、ベンダーとの個人的な木のため、上記の簡略化され、登録手続きと、ほとんど、これまでであれば、未登録の実験のタイプを使用する必要があってはなりません。したがって、「x方向」との両方を使用する「X」。フォームは推奨されません。
Types in this tree MUST NOT be registered.
このツリー内の種類が登録されてはなりません。
From time to time and as required by the community, the IANA may, by and with the advice and consent of the IESG, create new top-level registration trees. It is explicitly assumed that these trees may be created for external registration and management by well-known permanent bodies; for example, scientific societies may register media types specific to the sciences they cover. In general, the quality of review of specifications for one of these additional registration trees is expected to be equivalent to registrations in the standards tree. Establishment of these new trees will be announced through RFC publication approved by the IESG.
時々、コミュニティの要求に応じて、IANAは、IESGの助言と同意でとして、新しいトップレベル登録木を作成することができます。明示的にこれらの木は、よく知られた永久機関によって外部の登録と管理のために作成されることが想定されます。例えば、科学的社会は、彼らがカバー科学に特定のメディアタイプを登録することもできます。一般的に、これらの追加登録木の一つの仕様の見直しの品質が規格木での登録と同等であることが期待されています。これらの新しい木の設立はIESGによって承認されたRFCの公表を通じて発表されます。
Media type registration proposals are all expected to conform to various requirements laid out in the following sections. Note that requirement specifics sometimes vary depending on the registration tree, again as detailed in the following sections.
メディアタイプ登録提案はすべて、次のセクションでレイアウトの様々な要件に適合することが期待されます。以下のセクションで詳述するようにその要件の詳細は、時には再度、登録ツリーに依存して変化に留意されたいです。
Media types MUST function as an actual media format. Registration of things that are better thought of as a transfer encoding, as a charset, or as a collection of separate entities of another type, is not allowed. For example, although applications exist to decode the base64 transfer encoding [RFC2045], base64 cannot be registered as a media type.
メディアタイプは、実際のメディアフォーマットとして機能しなければなりません。より良い文字セットとして、または別の種類の別々のエンティティのコレクションとして、転送エンコーディングとして考えられているものの登録は、許可されていません。アプリケーションがBASE64転送エンコード[RFC2045]をデコードするために存在するが、例えば、BASE64は、メディアタイプとして登録することができません。
This requirement applies regardless of the registration tree involved.
この要件はかかわった登録木にかかわらず適用されます。
All registered media types MUST be assigned type and subtype names. The combination of these names serves to uniquely identify the media type, and the format of the subtype name identifies the registration tree. Both type and subtype names are case-insensitive.
登録されているすべてのメディアタイプは、タイプとサブタイプ名を割り当てなければなりません。これらの名前の組み合わせが一意のメディアタイプを識別するためのものであり、サブタイプ名の形式は、登録ツリーを識別する。どちらのタイプとサブタイプ名は大文字と小文字を区別しません。
Type and subtype names beginning with "X-" are reserved for experimental use and MUST NOT be registered. This parallels the restriction on the x. tree, as discussed in Section 3.4.
「X-」で始まるタイプとサブタイプ名は、実験的な使用のために予約されており、登録されてはなりません。これは、xの制限に匹敵します。 3.4節で述べたように木、。
Type and subtype names MUST conform to the following ABNF:
タイプとサブタイプ名は、次のABNFに従わなければなりません。
type-name = reg-name
subtype-name = reg-name
reg-name = 1*127reg-name-chars reg-name-chars = ALPHA / DIGIT / "!" / "#" / "$" / "&" / "." / "+" / "-" / "^" / "_"
REG-名= 1 * 127reg名・文字のREG-名-文字の= ALPHA / DIGIT / "！" / "＃" / "$" / "＆" / "" / "+" / " - " / "^" / "_"
Note that this syntax is somewhat more restrictive than what is allowed by the ABNF in [RFC2045].
この構文は、[RFC2045]でABNFによって許可されているものよりもいくらか制限的であることに注意してください。
In accordance with the rules specified in [RFC3023], media subtypes that do not represent XML entities MUST NOT be given a name that ends with the "+xml" suffix. More generally, "+suffix" constructs should be used with care, given the possibility of conflicts with future suffix definitions.
[RFC3023]で指定されたルールに従い、XMLエンティティを表すものではありませんメディアサブタイプは「+ xml」で接尾辞で終わる名前を与えてはなりません。より一般的には、「+接尾辞」の構築物は、将来の接尾辞の定義との競合の可能性が与えられ、注意して使用する必要があります。
While it is possible for a given media type to be assigned additional names, the use of different names to identify the same media type is discouraged.
それは追加の名前を割り当てる所与のメディアタイプのために可能であるが、同一のメディアタイプを識別するために異なる名前を使用することが推奨されます。
These requirements apply regardless of the registration tree involved.
これらの要件はかかわった登録木にかかわらず適用されます。
The choice of top-level type name MUST take into account the nature of media type involved. New subtypes of top-level types MUST conform to the restrictions of the top-level type, if any. The following sections describe each of the initial set of top-level types and their associated restrictions. Additionally, various protocols, including but not limited to MIME, MAY impose additional restrictions on the media types they can transport. (See [RFC2046] for additional information on the restrictions MIME imposes.)
トップレベルの型名の選択は、アカウントに関連するメディアタイプの性質を取る必要があります。いずれかの場合には、トップレベルの型の新しいサブタイプは、トップレベルタイプの制限に従わなければなりません。以下のセクションでは、トップレベルのタイプおよびその関連の制約の初期セットの各々を記述する。また、MIMEを含むがこれらに限定されない様々なプロトコルが、彼らは輸送することができるメディアの種類の追加の制限を課すことができます。 （MIMEを課し制限の詳細については、[RFC2046]を参照してください。）
The "text" media type is intended for sending material that is principally textual in form. A "charset" parameter MAY be used to indicate the charset of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text defined in [RFC2046]. If defined, a text "charset"
「テキスト」メディアタイプは、主フォームでテキスト形式で情報を送信するためのものです。 「文字セット」パラメータは、特に、[RFC2046]で定義されたプレーンテキストのための一般的なサブタイプであるサブタイプ「text / plainの」など、「テキスト」サブタイプのために本文の文字セットを示すために使用され得ます。定義されている場合、テキストは、「文字セット」
parameter MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978].
パラメータは、[RFC2978]にレイアウトされた手順に基づいて定義された文字セット名を指定するために使用されなければなりません。
Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear
プレーンテキストは、のために提供するか、またはコマンド、フォント属性の仕様、処理命令、解釈ディレクティブ、またはコンテンツのマークアップをフォーマットすることはできません。プレーンテキストは単に線形と見られています
sequence of characters, possibly interrupted by line breaks or page breaks. Plain text MAY allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilities that allow the arbitrary mixing of text segments with opposite writing directions.
文字のシーケンスが、おそらく改行や改ページによって中断します。プレーンテキストは、テキスト内の同じ位置に複数の文字の積み重ねを可能にすることができます。アラビア語、ヘブライ語などのスクリプトにプレーンテキストはまた、反対の書込方向とテキストセグメントの任意の混合を可能にする設備を含むことができます。
Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to present subtypes of "text" to the user, while it is not reasonable to do so with most non-textual data. Such formatted textual data should be represented using subtypes of "text".
プレーンテキストを越えて、「リッチテキスト」として知られているかもしれないもの表すための多くのフォーマットがあります。多くのそのような表現の興味深い特徴は、彼らもそれを解釈するソフトウェアを使用せずに、ある程度まで読み取り可能であるということです。読めない形で表される画像、音声、テキストなどの読めないデータから、最高のレベルで、それらを区別するために有用です。適切な解釈ソフトウェアがない場合には、ほとんどの非テキストデータと、そうすることは合理的ではないが、利用者に「テキスト」のサブタイプを提示するのが合理的です。このようなフォーマットされたテキストデータは、「テキスト」のサブタイプを使用して表現する必要があります。
A media type of "image" indicates that the content specifies or more separate images that require appropriate hardware to display. The subtype names the specific image format.
「画像」のメディア・タイプは、適切なハードウェアを必要とするコンテンツを指定以上の別々の画像を表示することを示しています。サブタイプ名特定の画像フォーマット。
A media type of "audio" indicates that the content contains audio data.
「オーディオ」のメディアタイプは、コンテンツがオーディオデータが含まれていることを示しています。
A media type of "video" indicates that the content specifies a time-varying-picture image, possibly with color and coordinated sound. The term 'video' is used in its most generic sense, rather than with reference to any particular technology or format, and is not meant to preclude subtypes such as animated drawings encoded compactly.
「ビデオ」のメディアタイプは、コンテンツは、おそらく色と協調音と、時間的に変化する映像画像を指定していることを示しています。用語「ビデオ」はなく、任意の特定の技術またはフォーマットを参照してより、その最も一般的な意味で使用され、そしてそのようなコンパクトに符号化されたアニメーションの図面としてサブタイプを排除するものではありません。
Note that although in general this document strongly discourages the mixing of multiple media in a single body, it is recognized that many so-called video formats include a representation for synchronized audio and/or text, and this is explicitly permitted for subtypes of "video".
一般的にこの文書は強く単体での複数のメディアの混合を阻止するものの、多くのいわゆるビデオフォーマットが同期オーディオおよび/またはテキストの表現が含まれていることを認識し、これは明示的に「ビデオのサブタイプのために許可されていることに注意してください」。
The "application" media type is to be used for discrete data that do not fit in any of the media types, and particularly for data to be processed by some type of application program. This is information that must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" media type include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material. (The latter, in particular, can pose security problems that must be understood by implementors, and are considered in detail in the discussion of the "application/ PostScript" media type in [RFC2046].)
「アプリケーション」メディアタイプは、メディアタイプのいずれかに適合し、特にアプリケーションプログラムのいくつかの種類によって処理されるデータのためにしていない離散データのために使用されるべきです。これは、ユーザによって視認可能または使用可能になる前に、アプリケーションによって処理されなければならない情報です。 「アプリケーション」メディアタイプの予想用途としては、「アクティブ」（計算）材料のために転送、スプレッドシート、プレゼンテーション、スケジュールデータ、および言語をファイルに限定されるものではありません。 （後者は、特に、実装者によって理解されなければならないセキュリティ上の問題を提起することができ、および[RFC2046]に「アプリケーション/ポストスクリプト」メディアタイプの議論で詳細に考察されています。）
For example, a meeting scheduler might define a standard representation for information about proposed meeting dates. An intelligent user agent would use this information to conduct a dialog with the user, and might then send additional material based on that dialog. More generally, there have been several "active" languages developed in which programs in a suitably specialized language are transported to a remote location and automatically run in the recipient's environment. Such applications may be defined as subtypes of the "application" media type.
例えば、会議のスケジュール担当者は、提案された会議の日付については、標準的な表現を定義できます。インテリジェントユーザーエージェントは、ユーザーとの対話を行うために、この情報を使用し、その後、そのダイアログに基づいて追加の材料を送信することがあります。より一般的には、適当に特化した言語でプログラムが遠隔地に輸送し、自動的に受信者の環境で実行されている開発されたいくつかの「アクティブ」な言語がありました。そのようなアプリケーションは、「アプリケーション」メディアタイプのサブタイプとして定義することができます。
The subtype of "application" will often be either the name or include part of the name of the application for which the data are intended. This does not mean, however, that any application program name may be used freely as a subtype of "application".
「アプリケーション」のサブタイプは、多くの場合、名前のいずれかであるか、データが意図されるアプリケーションの名前の一部が含まれます。これは、任意のアプリケーションプログラム名は「アプリケーション」のサブタイプとして自由に使用できることは、意味するものではありません。
Multipart and message are composite types, that is, they provide a means of encapsulating zero or more objects, each labeled with its own media type.
マルチパートメッセージは、独自のメディアの種類で標識された各々、即ち、それらはゼロ以上のオブジェクトをカプセル化する手段を提供する、複合型です。
All subtypes of multipart and message MUST conform to the syntax rules and other requirements specified in [RFC2046].
マルチパートとメッセージのすべてのサブタイプは、構文規則と[RFC2046]で指定されたその他の要求事項に従わなければなりません。
In some cases a new media type may not "fit" under any currently defined top-level content type. Such cases are expected to be quite rare. However, if such a case does arise a new top-level type can be defined to accommodate it. Such a definition MUST be done via standards-track RFC; no other mechanism can be used to define additional top-level content types.
いくつかのケースでは、新たなメディアタイプは、任意の現在定義されているトップレベルのコンテンツ・タイプの下に「フィット」しない場合があります。このようなケースは非常にまれであると予想されます。しかしながら、このような場合は、新しいトップレベルタイプを生じない場合、それに適応するように定義することができます。このような定義は標準トラックRFCを介して行われなければなりません。他の機構は、付加的なトップレベルのコンテンツタイプを定義するために使用することができません。
Media types MAY elect to use one or more media type parameters, or some parameters may be automatically made available to the media type by virtue of being a subtype of a content type that defines a set of parameters applicable to any of its subtypes. In either case, the names, values, and meanings of any parameters MUST be fully specified
メディアタイプは、1つまたは複数のメディアタイプパラメータを使用することを選択することができる、またはいくつかのパラメータが自動的にそのサブタイプのいずれかに適用可能なパラメータのセットを定義するコンテンツ・タイプのサブタイプであることによって、メディアタイプに利用可能にすることができます。いずれの場合においても、名前、値、および任意のパラメータの意味は完全に指定されなければなりません
when a media type is registered in the standards tree, and SHOULD be specified as completely as possible when media types are registered in the vendor or personal trees.
メディアタイプは時に規格木に登録されており、メディアタイプは、ベンダーや個人の木々に登録されているとき、できるだけ完全に指定する必要があります。
Parameter names have the syntax as media type names and values:
パラメータ名は、メディアタイプの名前と値のような構文を持っています：
parameter-name = reg-name
パラメータ名= REG名
Note that this syntax is somewhat more restrictive than what is allowed by the ABNF in [RFC2045] and amended by [RFC2231].
この構文は、[RFC2045]でABNFによって許可され、[RFC2231]によって改正されたものよりもいくらか制限的であることに注意してください。
There is no defined syntax for parameter values. Therefore registrations MUST specify parameter value syntax. Additionally, some transports impose restrictions on parameter value syntax, so care should be taken to limit the use of potentially problematic syntaxes; e.g., pure binary valued parameters, while permitted in some protocols, probably should be avoided.
パラメータ値には定義されている構文はありません。したがって、登録は、パラメータ値の構文を指定しなければなりません。ケアは、潜在的に問題の構文の使用を制限するために取られるべきであるので、また、いくつかのトランスポートは、パラメータ値の構文上の制限を課します。いくつかのプロトコルで許可しながら、例えば、純粋なバイナリ値パラメータは、おそらく避けるべきです。
New parameters SHOULD NOT be defined as a way to introduce new functionality in types registered in the standards tree, although new parameters MAY be added to convey additional information that does not otherwise change existing functionality. An example of this would be a "revision" parameter to indicate a revision level of an external specification such as JPEG. Similar behavior is encouraged for media types registered in the vendor or personal trees but is not required.
新しいパラメータは、そうでない場合は、既存の機能を変更しない付加的な情報を伝えるために添加してもよいが、新しいパラメータは、規格木に登録種類の新機能を導入する方法として定義されるべきではありません。この例は、JPEGなどの外部仕様の改訂レベルを示すために、「改訂」パラメーターであろう。同様の挙動は、ベンダーや個人的なツリーに登録されたメディアタイプのために奨励されるが、必須ではありません。
All registered media types MUST employ a single, canonical data format, regardless of registration tree.
登録されているすべてのメディアタイプは、登録木にかかわらず、単一の標準的なデータ形式を採用しなければなりません。
A precise and openly available specification of the format of each media type MUST exist for all types registered in the standards tree and MUST at a minimum be referenced by, if it isn't actually included in, the media type registration proposal itself.
各メディアタイプのフォーマットを正確にかつ公然と利用可能な仕様は、それが実際には、メディアタイプ登録提案自体に含まれていない場合、によって参照することが最低限の基準木とMUSTに登録されているすべてのタイプのために存在しなければなりません。
The specifications of format and processing particulars may or may not be publicly available for media types registered in the vendor tree, and such registration proposals are explicitly permitted to limit specification to which software and version produce or process such media types. References to or inclusion of format specifications in registration proposals is encouraged but not required.
フォーマット及び処理細目の仕様またはベンダーツリーに登録されたメディアタイプのために公に利用可能であってもなくてもよく、そのような登録提案は、明示的にそのソフトウェアバージョン農産物又はプロセス、メディアタイプ仕様を制限することが許可されています。参照または登録提案でフォーマット仕様を含めることが奨励さが、必須ではありません。
Format specifications are still required for registration in the personal tree, but may be either published as RFCs or otherwise deposited with the IANA. The deposited specifications will meet the same criteria as those required to register a well-known TCP port and, in particular, need not be made public.
フォーマット仕様はまだ個人的な木での登録のために必要とされるが、いずれかのRFCとして公開、あるいはIANAで堆積させることができます。堆積仕様は、特に、公表される必要はなく、よく知られたTCPポートを登録するために必要なものと同じ基準を満たしております。
Some media types involve the use of patented technology. The registration of media types involving patented technology is specifically permitted. However, the restrictions set forth in [RFC2026] on the use of patented technology in IETF standards-track protocols must be respected when the specification of a media type is part of a standards-track protocol. In addition, other standards bodies making use of the standards tree may have their own rules regarding intellectual property that must be observed in their registrations.
一部のメディアタイプは、特許技術の使用を含みます。特許技術を含むメディアタイプの登録を具体的に許可されています。メディアタイプの仕様が標準トラックプロトコルの一部である場合しかし、IETF標準トラックプロトコルにおける特許技術の使用に[RFC2026]に記載された制限は尊重されなければなりません。また、規格木を利用して、他の標準化団体は、その登録に観察する必要があり、知的財産に関する独自のルールを持っていることがあります。
Media types SHOULD interoperate across as many systems and applications as possible. However, some media types will inevitably have problems interoperating across different platforms. Problems with different versions, byte ordering, and specifics of gateway handling can and will arise.
メディアタイプは、できるだけ多くのシステムとアプリケーション間の相互運用すべきです。しかし、いくつかのメディアタイプは、必然的に、異なるプラットフォーム間で相互運用問題が発生します。異なるバージョン、バイト順序、およびゲートウェイ操作の詳細と問題が発生するとされますすることができます。
Universal interoperability of media types is not required, but known interoperability issues SHOULD be identified whenever possible. Publication of a media type does not require an exhaustive review of interoperability, and the interoperability considerations section is subject to continuing evaluation.
メディアタイプのユニバーサル相互運用性が必要とされていませんが、知られている相互運用性の問題は、可能な限り特定されるべきです。メディアタイプの公表は、相互運用性の徹底的な見直しを必要としない、との相互運用性の考慮事項のセクションでは、継続的な評価の対象となります。
These recommendations apply regardless of the registration tree involved.
これらの勧告はかかわった登録木にかかわらず適用されます。
An analysis of security issues MUST be done for all types registered in the standards Tree. A similar analysis for media types registered in the vendor or personal trees is encouraged but not required. However, regardless of what security analysis has or has not been done, all descriptions of security issues MUST be as accurate as possible regardless of registration tree. In particular, a statement that there are "no security issues associated with this type" MUST
セキュリティ問題の分析は、規格木に登録されているすべてのタイプのために行われなければなりません。ベンダーや個人的なツリーに登録されたメディアタイプについて同様の分析が奨励さが、必須ではありません。しかし、関係なく、セキュリティ分析が持っているか行われていないものの、セキュリティ問題のすべての記述は、登録木にかかわらず、可能な限り正確でなければなりません。具体的には、「この種類に関連付けられたセキュリティ上の問題」が存在しないという声明MUST
NOT be confused with "the security issues associates with this type have not been assessed".
「このタイプのセキュリティ問題の仲間が評価されていない」と混同しないように。
There is absolutely no requirement that media types registered in any tree be secure or completely free from risks. Nevertheless, all known security risks MUST be identified in the registration of a media type, again regardless of registration tree.
任意のツリーに登録されたメディアタイプが安全やリスクから完全に自由である必要は全くありません。それにもかかわらず、すべての既知のセキュリティリスクは、再び登録木にかかわらず、メディアタイプの登録で識別されなければなりません。
The security considerations section of all registrations is subject to continuing evaluation and modification, and in particular MAY be extended by use of the "comments on media types" mechanism described in Section 6 below.
すべての登録のセキュリティ問題部は継続的評価及び修正の対象であり、特に以下のセクション6で説明されたメカニズム「メディアタイプのコメント」を使用することによって拡張することができます。
Some of the issues that should be looked at in a security analysis of a media type are:
メディアタイプのセキュリティ分析で見れるべき問題のいくつかは以下のとおりです。
o Complex media types may include provisions for directives that institute actions on a recipient's files or other resources. In many cases provision is made for originators to specify arbitrary actions in an unrestricted fashion that may then have devastating effects. See the registration of the application/postscript media type in [RFC2046] for an example of such directives and how they should be described in a media type registration.
O複雑なメディアタイプは、受信者のファイルや他のリソースに対するアクションを提起ディレクティブの規定を含んでいてもよいです。多くの場合、引当金は、壊滅的な影響を与えることが無制限の方法で任意のアクションを指定するにはオリジネーターのために作られています。そのような指示の例およびそれらがどのようにメディアタイプ登録に記載されなければならないために[RFC2046]でアプリケーション/追記メディアタイプの登録を参照してください。
o All registrations MUST state whether or not they employ such "active content", and if they do, they MUST state what steps have been taken to protect users of the media type from harm.
Oすべての登録は、彼らがそのような「アクティブコンテンツ」を採用し、彼らがしなければ、彼らは害からメディアタイプのユーザを保護するために取られてきたどのような手順述べる必要があるかどうかを述べなければなりません。
o Complex media types may include provisions for directives that institute actions that, while not directly harmful to the recipient, may result in disclosure of information that either facilitates a subsequent attack or else violates a recipient's privacy in some way. Again, the registration of the application/postscript media type illustrates how such directives can be handled.
O複雑なメディアタイプは、受信者に直接有害ではないが、いずれかのその後の攻撃を容易にしたり、他の何らかの方法で、受信者のプライバシーを侵害する情報の開示をもたらすことができる、というアクションを提起ディレクティブの規定を含んでいてもよいです。再度、アプリケーション/追記メディアタイプの登録は、そのような指示を扱うことができる方法を示す図です。
o A media type that employs compression may provide an opportunity for sending a small amount of data that, when received and evaluated, expands enormously to consume all of the recipient's resources. All media types SHOULD state whether or not they employ compression, and if they do they should discuss what steps need to be taken to avoid such attacks.
受信されたと評価されたとき、受信者のすべてのリソースを消費する非常に膨張し、少量のデータを送信するための機会を提供することができる圧縮を用いたメディアタイプをO。すべてのメディアタイプは、彼らが圧縮を採用し、彼らがしなければ、彼らはこのような攻撃を避けるように注意する必要がどのような手順話し合う必要があるかどうかを必ず明記してください。
o A media type might be targeted for applications that require some sort of security assurance but not provide the necessary security mechanisms themselves. For example, a media type could be defined for storage of confidential medical information that in turn requires an external confidentiality service, or which is designed for use only within a secure environment.
Oメディアタイプは、セキュリティ保証のいくつかの並べ替えを必要としますが、必要なセキュリティ機構そのものを提供していないアプリケーションを対象とされる可能性があります。例えば、メディアタイプが順番に外部の機密性サービスを必要とすることが機密の医療情報の保存のために定義することができ、または唯一のセキュアな環境で使用するために設計されています。
There are a number of additional requirements specific to the registration of XML media types. These requirements are specified in [RFC3023].
XMLのメディアタイプの登録に特有の追加要件がいくつかあります。これらの要件は[RFC3023]で指定されています。
Some transports impose restrictions on the type of data they can carry. For example, Internet mail traditionally was limited to 7bit US-ASCII text. Encoding schemes are often used to work around such transport limitations.
いくつかのトランスポートは、彼らが運ぶことができるデータの種類に制限を課します。たとえば、インターネットメールは、伝統的にUS-ASCIIテキストを7ビットに制限されていました。符号化方式は、多くの場合、輸送制限を回避するために使用されています。
It is therefore useful to note what sort of data a media type can consist of as part of its registration. An "encoding considerations" field is provided for this purpose. Possible values of this field are:
メディアタイプがその登録の一部として構成することができ、データの種類を注意することは有用です。 「エンコーディングの考慮事項」の欄は、この目的のために提供されます。このフィールドの可能な値は以下のとおりです。
7bit: The content of the media type consists solely of CRLF-delimited 7bit US-ASCII text.
7ビット：メディアタイプのコンテンツは、単にCRLFで区切られた7ビットUS-ASCIIテキストで構成されています。
8bit: The content of the media type consists solely of CRLF-delimited 8bit text.
8ビット：メディアタイプのコンテンツは、単にCRLFで区切られた8ビットのテキストで構成されています。
binary: The content consists of unrestricted sequence of octets.
バイナリ：内容はオクテットの無制限の配列からなります。
framed: The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out-of-band information is needed to interpret the data properly, including but not necessarily limited to, knowledge of the boundaries between successive frames and knowledge of the transport mechanism. Note that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets; therefore, such media types are unsuitable for use in many traditional protocols. A commonly used transport with framed encoding is the Real-time Transport Protocol, RTP. Additional rules for framed encodings defined for transport using RTP are given in [RFC3555].
フレーム：コンテンツが内部フレーミングまたは整列インジケータなしにフレーム又は一連のパケットから成ります。追加のアウトオブバンド情報は、以下を含むが、必ずしも連続したフレームと輸送機構の知識間の境界の知識、これらに限定されない、適切にデータを解釈するために必要とされます。この種のメディアタイプは、単にファイルに保存されているか、オクテットの簡単な流れとして輸送することができないことに注意してください。したがって、このようなメディアタイプは、多くの伝統的なプロトコルでの使用には適していません。額入りのエンコーディングで一般的に使用されるトランスポートは、リアルタイムトランスポートプロトコル、RTPです。 RTPを使用して輸送するための定義されたフレームのエンコーディングのための追加の規則は、[RFC3555]に記載されています。
Additional restrictions on 7bit and 8bit text are given in [RFC2046].
7ビットおよび8ビットのテキストの追加制限は、[RFC2046]に記載されています。
In the asynchronous mail environment, where information on the capabilities of the remote mail agent is frequently not available to the sender, maximum interoperability is attained by restricting the media types used to those "common" formats expected to be widely implemented. This was asserted in the past as a reason to limit the number of possible media types, and it resulted in a registration process with a significant hurdle and delay for those registering media types.
リモートメールエージェントの能力に関する情報を頻繁に送信者に利用できない非同期メール環境では、最大の相互運用性を広く実装することが予想される「共通」フォーマットに使用されるメディアの種類を制限することによって達成されます。これは、可能なメディアタイプの数を制限する理由として、過去にアサートされ、それは、それらの登録メディアタイプのための重要なハードルと遅延の登録処理が生じました。
However, the need for "common" media types does not require limiting the registration of new media types. If a limited set of media types is recommended for a particular application, that should be asserted by a separate applicability statement specific for the application and/or environment.
しかし、「一般的な」メディアタイプの必要性は、新たなメディアタイプの登録を制限する必要はありません。メディアタイプの限られたセットは、特定のアプリケーションのために推奨されている場合、それはアプリケーションおよび/または環境のための具体的な個別の適用性声明によって表明されなければなりません。
Therefore, universal support and implementation of a media type is NOT a requirement for registration. However, if a media type is explicitly intended for limited use, this MUST be noted in its registration. The "Restrictions on Usage" field is provided for this purpose.
そのため、ユニバーサルサポートとメディアタイプの実装では、登録の要件ではありません。メディアタイプが明示的に限られた使用のために意図されている場合しかし、これは、その登録に留意しなければなりません。 「使用上の制限」フィールドは、この目的のために提供されます。
Proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs. RFC publication of vendor and personal media type proposals is encouraged but not required. In all cases the IANA will retain copies of all media type proposals and "publish" them as part of the media types registration tree itself.
IETF自身で規格木に登録されたメディアタイプのための提案は、RFCとして公開する必要があります。ベンダーとパーソナルメディアタイプ提案のRFC公表は、奨励が、必須ではありません。すべての場合においてIANAは、すべてのメディアタイプ提案のコピーを保持し、メディアタイプ登録木自体の一部としてそれらを「公開します」。
As stated previously, standards tree registrations for media types defined in documents produced by other standards bodies MUST be described by a formal standards specification produced by that body. Such specifications MUST contain an appropriate media type registration template taken from Section 10. Additionally, the copyright on the registration template MUST allow the IANA to copy it into the IANA registry.
先に述べたように、他の標準化団体によって作成されたドキュメントで定義されたメディアタイプの標準規格木の登録は、体内で生成正式な標準仕様で記述されなければなりません。このような仕様はさらに、セクション10から取られた適切なメディアタイプ登録テンプレートを含まなければならない、登録テンプレートの著作権は、IANAがIANAレジストリにコピーすることができなければなりません。
Other than IETF registrations in the standards tree, the registration of a data type does not imply endorsement, approval, or recommendation by the IANA or the IETF or even certification that the specification is adequate. To become Internet Standards, a protocol or data object must go through the IETF standards process. This is too difficult and too lengthy a process for the convenient registration of media types.
規格木でIETFの登録以外に、データ型の登録は、IANAまたはIETFや仕様が適切であることも、認証による承認、承認、または推奨を意味するものではありません。インターネット標準になるためには、プロトコルやデータオブジェクトは、IETF標準化プロセスを経なければなりません。これは、メディアタイプの便利な登録のためにあまりにも難しい、あまりにも長いプロセスです。
The standards tree exists for media types that do require a substantive review and approval process in a recognized standards body. The vendor and personal trees exist for those media types that do not require such a process. It is expected that applicability statements for particular applications will be published from time to time in the IETF, recommending implementation of, and support for, media types that have proven particularly useful in those contexts.
規格木が認められた標準ボディに実質的なレビューと承認プロセスを必要としないメディアタイプのために存在します。ベンダーとの個人的な木は、このようなプロセスを必要としないメディアタイプのために存在します。特定のアプリケーションのための適用性の文は、それらの文脈で特に有用であることが証明されているメディアタイプ、のための実装、およびサポートを推薦、時間からIETFの時間に公開されることが期待されます。
As discussed above, registration of a top-level type requires standards-track processing in the IETF and, hence, RFC publication.
上述したように、トップレベルタイプの登録は、したがって、RFC文書をIETFで標準化過程の処理を必要とします。
Various sorts of optional information SHOULD be included in the specification of a media type if it is available:
それが利用可能である場合、オプションの各種の情報は、メディアタイプの仕様に含まれるべきです。
o Magic number(s) (length, octet values). Magic numbers are byte sequences that are always present at a given place in the file and thus can be used to identify entities as being of a given media type.
Oマジックナンバー（S）（長さ、オクテット値）。魔法の数字は常にファイル内の指定された場所に存在しているため、特定のメディアタイプのものとしてエンティティを識別するために使用することができ、バイト配列です。
o File name extension(s) commonly used on one or more platforms to indicate that some file contains a given media type.
一般的に、いくつかのファイルが指定されたメディアタイプが含まれていることを示すために、1つ以上のプラットフォームで使用Oファイル名の拡張子（複数可）。
o Mac OS File Type code(s) (4 octets) used to label files containing a given media type.
特定のメディアタイプを含むファイルにラベルを付けるために使用されるO Mac OSのファイルタイプコード（S）（4つのオクテット）。
o Information about how fragment/anchor identifiers [RFC3986] are constructed for use in conjunction with this media type.
Oどのようにフラグメント/アンカー識別子に関する情報は[RFC3986]はこのメディアタイプと組み合わせて使用するために構築されています。
In the case of a registration in the standards tree, this additional information MAY be provided in the formal specification of the media type. It is suggested that this be done by incorporating the IANA media type registration form into the specification itself.
規格木の登録の場合には、この追加情報は、メディアタイプの正式な仕様で提供されてもよいです。仕様自体にIANAメディアタイプ登録フォームを組み込むことによって行われることが示唆されています。
The media type registration procedure is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay.
メディアタイプ登録手続きは、正式な標準化プロセスではなく、行政手続は、コミュニティのコメントと正気が過度の時間遅れなしにチェックできるようにするためのもの。
The normal IETF processes should be followed for all IETF registrations in the standards tree. The posting of an Internet Draft is a necessary first step, followed by posting to the ietf-types@iana.org list as discussed below.
通常のIETFのプロセスが標準化ツリー内のすべてのIETFの登録のために従うべきです。インターネットドラフトの転記は、後述するようにietf-types@iana.orgリストに掲載することにより、その後必要に応じて最初のステップです。
Registrations in the vendor and personal tree should be submitted directly to the IANA, ideally after first posting to the ietf-types@iana.org list for review.
ベンダーとの個人的なツリーでの登録は、理想的に最初のレビューのためにietf-types@iana.orgリストに投稿した後に、IANAに直接提出してください。
Proposed registrations in the standards tree by other standards bodies should be communicated to the IESG (at iesg@ietf.org) and to the ietf-types list (at ietf-types@iana.org). Prior posting as an
他の標準化団体によって規格木で提案登録が（iesg@ietf.orgで）及び（ietf-types@iana.orgで）IETF-typesリストにIESGに伝達されなければなりません。前の投稿
Internet Draft is not required for these registrations, but may be helpful to the IESG and is encouraged.
インターネットドラフトは、これらの登録のために必要とされていませんが、IESGに役立つかもしれないし、奨励されます。
Notice of a potential media type registration in the standards tree MUST be sent to the "ietf-types@iana.org" mailing list for review. This mailing list has been established for the purpose of reviewing proposed media and access types. Registrations in other trees MAY be sent to the list for review as well.
規格木の潜在的なメディアタイプ登録のお知らせは、レビューのために、「ietf-types@iana.org」メーリングリストに送らなければなりません。このメーリングリストは、提案されたメディアおよびアクセスタイプを検討する目的で設立されました。他の木での登録は、同様にレビューのためにリストに送ってもよいです。
The intent of the public posting to this list is to solicit comments and feedback on the choice of type/subtype name, the unambiguity of the references with respect to versions and external profiling information, and a review of any interoperability or security considerations. The submitter may submit a revised registration or abandon the registration completely and at any time.
このリストへの公共の投稿の意図は、タイプ/サブタイプ名の選択、バージョンに関して、外部のプロファイリング情報を参照の曖昧、および任意の相互運用性やセキュリティの考慮のレビューにコメントやフィードバックを求めることです。提出者は、改訂された登録を提出したり、完全に、いつでも登録を放棄することができます。
Media types registered in the standards tree MUST be approved by the IESG prior to registration.
規格木に登録されたメディアタイプは、登録前にIESGによって承認されなければなりません。
Provided that the media type meets all of the relevant requirements and has obtained whatever approval is necessary, the author may submit the registration request to the IANA. Registration requests can be sent to iana@iana.org. A web form for registration requests is also available:
メディアタイプが関連要件のすべてを満たし、必要なものは何でも承認を得たことを提供し、作者はIANAに登録要求を提出することができます。登録要求がiana@iana.orgに送信することができます。登録要求のためのWebフォームも利用可能です：
http://www.iana.org/cgi-bin/mediatypes.pl
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／ｃぎーびん／めぢあｔｙぺｓ。ｐｌ
Sending to ietf-types@iana.org does not constitute submitting the registration to the IANA.
ietf-types@iana.orgに送信すると、IANAに登録を提出するものではありません。
When the registration is either part of an RFC publication request or a registration in the standards tree submitted to the IESG, close coordination between the IANA and the IESG means IESG approval in effect submits the registration to the IANA. There is no need for an additional registration request in such cases.
登録はRFC公開要求の一部またはIESGに提出規格木の登録のどちらかである場合には、IANAとIESGの間の緊密な連携が有効なIESGの承認がIANAに登録を提出すること。このような場合の追加登録申請の必要はありません。
Registrations submitted to the IANA will be passed on to the media types reviewer. The media types reviewer, who is appointed by the IETF Applications Area Director(s), will review the registration to make sure it meets the requirements set forth in this document.
IANAに提出登録はメディアタイプ投稿者に渡されます。 IETFアプリケーションエリアディレクター（S）によって任命されたメディアタイプ投稿者は、それがこの文書に記載された要件を満たしていることを確認するために登録を検討します。
Registrations that do not meet these requirements will be returned to the submitter for revision.
これらの要件を満たしていない登録が改正のための提出者に返却されます。
Decisions made by the media types reviewer may be appealed to the IESG using the procedure specified in [RFC2026] section 6.5.4.
メディアタイプ投稿者によって行われた決定は、[RFC2026]セクション6.5.4で指定された手順を使用して、IESGにアピールすることができます。
Once a media type registration has passed review, the IANA will register the media type and make the media type registration available to the community.
メディアタイプの登録は審査を通過した後は、IANAはメディアタイプを登録し、地域社会へのメディアタイプの登録が利用できるようになります。
Comments on registered media types may be submitted by members of the community to the IANA. These comments will be reviewed by the media types reviewer and then passed on to the "owner" of the media type if possible. Submitters of comments may request that their comment be attached to the media type registration itself, and if the IANA approves of this, the comment will be made accessible in conjunction with the type registration.
登録されたメディアタイプのコメントは、IANAへのコミュニティのメンバーによって提出することができます。これらのコメントは、レビューアメディアタイプによって審査した後、可能な場合はメディアタイプの「所有者」に渡されます。コメントの提出者は、彼らのコメントがメディアタイプ登録自体に添付され、IANAは、この承認した場合、コメントはタイプ登録と併せてアクセスできるようになることを要求することができます。
Media type registrations are listed by the IANA at:
メディアタイプの登録はIANAによってでリストされています。
http://www.iana.org/assignments/media-types/
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／めぢあーｔｙぺｓ／
The IANA will only register media types in the standards tree in response to a communication from the IESG stating that a given registration has been approved. Vendor and personal types will be registered by the IANA automatically and without any formal approval process as long as the following minimal conditions are met:
IANAは、唯一与えられた登録が承認されたことを知らせるIESGからの通信に対応して規格木にメディアタイプを登録します。ベンダーとの個人的なタイプが自動的に限り、以下の最小限の条件が満たされたとして正式な承認プロセスなしでIANAによって登録されます。
o Media types MUST function as an actual media format. In particular, charsets and transfer encodings MUST NOT be registered as media types.
Oメディアタイプは、実際のメディアフォーマットとして機能しなければなりません。具体的には、文字セットと転送エンコーディングは、メディアタイプとして登録してはなりません。
o All media types MUST have properly formed type and subtype names. All type names MUST be defined by a standards-track RFC. All type/subtype name pairs MUST be unique and MUST contain the proper tree prefix.
Oすべてのメディアタイプが適切に形成タイプとサブタイプの名前を持たなければなりません。すべてのタイプの名前は、標準トラックRFCで定義されなければなりません。すべてのタイプ/サブタイプ名のペアは一意である必要があり、適切な木の接頭辞を含まなければなりません。
o Types registered in the personal tree MUST either provide a format specification or a pointer to one.
個人的なツリーに登録されたOタイプは、形式仕様や1へのポインタを提供する必要があります。
o All media types MUST have a reasonable security considerations section. (It is neither possible nor necessary for the IANA to conduct a comprehensive security review of media type registrations. Nevertheless, the IANA has the authority to identify obviously incompetent material and return it to the submitter for revision.)
Oすべてのメディアタイプは、合理的なセキュリティ上の考慮事項のセクションを持たなければなりません。 （IANAメディアタイプ登録の包括的なセキュリティレビューを実施することは不可能ですし、不必要でしょう。それでも、IANAは明らかに無能な材料を特定し、改正のために提出者に返却する権限を持っています。）
Registrations in the standards tree MUST satisfy the additional requirement that they originate from the IETF itself or from another standards body recognized as such by the IETF.
規格木の登録は、彼らがIETF自体からか、IETFによってそのように認識し、他の標準化団体から発信追加の要件を満たさなければなりません。
Once a media type has been published by the IANA, the owner may request a change to its definition. The descriptions of the different registration trees above designate the "owners" of each type of registration. The same procedure that would be appropriate for the original registration request is used to process a change request.
メディアタイプがIANAによって公表された後、所有者はその定義への変更を要求することができます。異なる登録木の記述は、上記の登録の各タイプの「所有者」を指定します。オリジナルの登録要求のために適切であるのと同じ手順が変更要求を処理するために使用されます。
Changes should be requested only when there are serious omissions or errors in the published specification. When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition.
変更は、公開された仕様に重大な欠落や誤りがある場合にのみ、要求されるべき。見直しが必要とされる場合、それは新しい定義の下で前の定義の下で無効有効であったエンティティをレンダリングする場合は、変更要求が拒否されることがあります。
The owner of a media type may pass responsibility to another person or agency by informing the IANA and the ietf-types list; this can be done without discussion or review.
メディアタイプの所有者は、IANAとIETF-種類のリストを通知することにより、他の人や機関に責任を渡すこと。これは、議論や検討せずに行うことができます。
The IESG may reassign responsibility for a media type. The most common case of this will be to enable changes to be made to types where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community.
IESGはメディアタイプの責任を再割り当てすることができます。この最も一般的な場合は、登録の作者が死亡したタイプに行われる変更を可能にすることであろう、接触の外に移動したり、コミュニティへの重要な変更を行うことがそれ以外の場合はできません。
Media type registrations may not be deleted; media types that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such media types will be clearly marked in the lists published by the IANA.
メディアタイプの登録が削除されないことがあります。もはや使用するのに適したと考えられているメディアの種類は、彼らの「意図する使用」フィールドに変更することによりOBSOLETEと宣言することができます。そのような媒体の種類は明らかにIANAによって公表リストにマークされます。
To: ietf-types@iana.org Subject: Registration of media type XXX/YYY
To：ietf-types@iana.org件名：メディアタイプXXX / YYYの登録
Type name:
名前を入力します。
Subtype name:
サブタイプ名：
Required parameters:
必須パラメータ：
Optional parameters:
オプションのパラメータ：
Encoding considerations:
エンコードの考慮事項：
Security considerations:
セキュリティの考慮事項：
Interoperability considerations:
相互運用性の考慮事項：
Published specification:
公開された仕様：
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Additional information:
追加情報：
Magic number(s): File extension(s): Macintosh file type code(s):
マジックナンバー（S）：ファイルの拡張子（S）：Macintoshのファイルタイプコード（S）：
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
Intended usage:
意図している用法：
(One of COMMON, LIMITED USE or OBSOLETE.)
（COMMON、限定使用の一つまたはOBSOLETE。）
Restrictions on usage:
使用に関する制限事項：
(Any restrictions on where the media type can be used go here.)
（メディアタイプが使用できる場所上の任意の制限がここに入ります。）
Author:
著者：
Change controller:
コントローラを変更します。
(Any other information that the author deems interesting may be added below this line.)
（著者が面白いと判断する任意の他の情報は、この行の下に追加されてもよいです。）
Some discussion of Macintosh file type codes and their purpose can be found in [MacOSFileTypes]. Additionally, please refrain from writing
Macintoshファイルタイプコードとその目的のいくつかの議論は[MacOSFileTypes]で見つけることができます。また、書き込みをご遠慮ください
"none" or anything similar when no file extension or Macintosh file type is specified, lest "none" be confused with an actual code value.
「なし」または類似のものファイル拡張子またはMacintoshファイルタイプが「なし」が実際のコードの値と混同しないことがないように、指定されていません。
Security requirements for media type registrations are discussed in Section 4.6.
メディアタイプ登録のためのセキュリティ要件は、4.6節で議論されています。
The purpose of this document is to define IANA registries for media types.
このドキュメントの目的は、メディアタイプのIANAレジストリを定義することです。
The current authors would like to acknowledge their debt to the late Dr. Jon Postel, whose general model of IANA registration procedures and specific contributions shaped the predecessors of this document [RFC2048]. We hope that the current version is one with which he would have agreed but, as it is impossible to verify that agreement, we have regretfully removed his name as a co-author.
現在の著者は、その一般的なモデルIANA登録手順と具体的な貢献のこのドキュメント[RFC2048]の前任者を形作っ故博士ジョン・ポステル、に借金を認めたいと思います。その合意を確認することは不可能であると私たちは、現在のバージョンは、彼が合意したことになると1であることを願っていますが、我々は残念ながら共著者として彼の名前を削除しました。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555] Casner、S.とP. Hoschka、 "RTPペイロード形式のMIMEタイプ登録"、RFC 3555、2003年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[RFC4234] Crocker, D. Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、D.エド、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"。、RFC 4234、2005年10月。
[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>.
[MacOSFileTypes]アップルコンピュータ社の "Mac OS：ファイルタイプとクリエータコード、およびファイル形式"、<http://www.info.apple.com/kbnum/n55381>アップルサポート技術情報55381、1993年6月、 。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[RFC2048]解放され、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、BCP 13、RFC 2048、1996年11月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。
Appendix A. Grandfathered Media Types
付録A.適用除外メディアタイプ
A number of media types, registered prior to 1996, would, if registered under the guidelines in this document, be placed into either the vendor or personal trees. Reregistration of those types to reflect the appropriate trees is encouraged but not required. Ownership and change control principles outlined in this document apply to those types as if they had been registered in the trees described above.
前1996年に登録されたメディアタイプの数は、この文書のガイドラインの下で登録されている場合、ベンダーや個人的な木のいずれかに配置されることになります。適切な木を反映するために、これらのタイプの再登録が奨励さが、必須ではありません。このドキュメントで概説所有権と変更管理の原則は、彼らは、上述の木に登録されたかのように、これらのタイプに適用されます。
Appendix B. Changes Since
付録B.変化するため
o Media type specification and registration procedures have been moved out of the MIME document set to this separate specification.
Oメディアタイプ仕様と登録手順は、この個別の仕様に設定されたMIME文書の外に移動されました。
o The various URLs and addresses in this document have been changed so they all refer to iana.org rather than isi.edu. Additionally, many of the URLs have been changed to use HTTP; formerly they used FTP.
この文書に記載されているさまざまなURLやアドレスがそれほど変更されたoを彼らはすべてisi.eduではなくiana.orgを参照してください。また、URLの多くは、HTTPを使用するように変更されました。かつて彼らは、FTPを使用していました。
o Much of the document has been clarified in the light of operational experience with these procedures.
O文書の多くは、これらの手順と運用経験に照らして明らかにされています。
o The unfaceted IETF tree is now called the standards tree, and the registration rules for this tree have been relaxed to allow use by other standards bodies.
O unfaceted IETFツリーは現在、規格木と呼ばれ、このツリーの登録ルールは、他の標準化団体による使用を許可するように緩和されました。
o The text describing the media type registration procedure has clarified.
Oメディアタイプの登録手順を説明するテキストを明らかにしました。
o The rules and requirements for constructing security considerations sections have been extended and clarified.
セキュリティの考慮事項を構築するための規則と要件oをセクションが拡張され、明らかにされています。
o RFC 3023 is now referenced as the source of additional information concerning the registration of XML media types.
O RFC 3023は、現在のXMLメディアタイプの登録に関する追加情報のソースとして参照されます。
o Several of the references in this document have been updated to refer to current versions of the relevant specifications.
Oこの文書の参照のいくつかは、関連する仕様の現在のバージョンを参照するように更新されました。
o A note has been added discouraging the assignment of multiple names to a single media type.
Oノートは単一のメディアタイプに複数の名前の割り当てを落胆追加されています。
o Security considerations and IANA considerations sections have been added.
Oセキュリティ上の考慮事項とIANAの考慮事項のセクションが追加されました。
o Concerns regarding copyrights on media type registration templates produced by other standards bodies have been dealt with by requiring that the IANA be allowed to copy the registration template into the registry.
他の標準化団体によって生成メディアタイプ登録テンプレート上の著作権についてはOの懸念はIANAがレジストリに登録テンプレートをコピーするために許可されることを要求することによって対処されています。
o The basic registration requirements for the various top-level types have been moved from RFC 2046 to this document.
oを様々なトップレベルのタイプのための基本的な登録要件は、この文書にRFC 2046から移動されました。
o A syntax is now specified for media type, subtype, and parameter names.
O構文は今、メディアタイプ、サブタイプ、およびパラメータ名に指定されています。
o Imposed a maximum length of 127 on all media type and subtype names.
Oすべてのメディアタイプとサブタイプ名に127の最大長さを課しました。
o A note has been added to caution against excessive use of "+suffix" constructs in subtype names.
Oノートでは、サブタイプ名に「+接尾辞」の構築物の過度の使用を警戒するために追加されました。
o The encoding considerations field has been extended to allow the value "framed".
Oエンコーディングの考慮事項欄には、値「枠」を許可するように拡張されました。
o A reference describing Macintosh Type codes has been added.
Oマッキントッシュタイプコードを記述基準が追加されました。
o Ietf-types list review of registrations in the standards tree is now required rather than just recommended.
O規格木における登録のIETF-種類のリストの見直しは、現在必要なだけではなく、推奨されます。
Authors' Addresses
著者のアドレス
Ned Freed Sun Microsystems 3401 Centrelake Drive, Suite 410 Ontario, CA 92761-1205 USA
ネッドフリードSun Microsystemsの3401 Centrelakeドライブ、スイート410、オンタリオ、カリフォルニア州92761から1205 USA
Phone: +1 909 457 4293 EMail: ned.freed@mrochek.com
電話：+1 909 457 4293 Eメール：ned.freed@mrochek.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
ジョンC. Klensin 1770マサチューセッツアベニュー、＃322ケンブリッジ、MA 02140
EMail: klensin+ietf@jck.com
メールアドレス：klensin+ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。