[要約] RFC 4288は、メディアタイプの仕様と登録手続きに関する情報を提供する。その目的は、インターネット上でのメディアタイプの一貫性と相互運用性を確保することである。
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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].
「必須」、「必須」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
この仕様では、そのドキュメントの付録Aで定義されているコアルールを含む、拡張されたBackus-Naurフォーム（ABNF）[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 ... subtype」の名前。このドキュメントの前に定義されたいくつかのメディアタイプは、以下に説明する命名規則に準拠していないことに注意してください。それらの議論については、付録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として公開されなければなりません。Standards-Tree登録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」など）のいずれかによって、またはメディアタイプまたは製品指定（vnd.bigcompany.funnypicture）が続くプロデューサーの名前のIANAが承認した指定が続く場合があります。
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」のサブタイプ名。最初のファセットは、「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
type-name = reg-name subtype-name = reg-name
reg-name = 1*127reg-name-chars
reg-name-chars = 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" parameter MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978].
「テキスト」メディアタイプは、主に形式のテキストの資料を送信することを目的としています。「charset」パラメーターを使用して、「テキスト」サブタイプのボディテキストのcharsetを示すことができます。特に、[RFC2046]で定義されたプレーンテキストの汎用サブタイプであるサブタイプ「テキスト/プレーン」を含みます。定義されている場合、[RFC2978]に定義された手順に従って定義された炭化名を指定するために、テキスト「charset」パラメーターを使用する必要があります。
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
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.
各メディアタイプの形式の正確で公然と利用可能な仕様は、標準ツリーに登録されているすべてのタイプに対して存在する必要があり、実際に含まれていない場合は、メディアタイプの登録提案自体に少なくとも参照する必要があります。
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.
フォーマット仕様は、個人のツリーへの登録には引き続き必要ですが、RFCSとして公開されるか、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 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]のアプリケーション/PostScriptメディアタイプの登録を参照してください。
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 複雑なメディアタイプには、受信者に直接有害ではないが、その後の攻撃を促進するか、何らかの方法で受信者のプライバシーに違反する情報の開示をもたらす可能性があるという指示の規定が含まれる場合があります。繰り返しますが、アプリケーション/PostScriptメディアタイプの登録は、そのような指令の処理方法を示しています。
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.
一部のトランスポートは、携帯できるデータの種類に制限を課しています。たとえば、インターネットメールは従来、7ビットの米国ASCIIテキストに制限されていました。エンコーディングスキームは、多くの場合、このような輸送制限を回避するために使用されます。
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自体によって標準ツリーに登録されているメディアタイプの提案は、RFCSとして公開する必要があります。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.
上記で説明したように、トップレベルのタイプの登録には、IETF、したがってRFC出版物での標準トラック処理が必要です。
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 マジック番号（長さ、オクテット値）。マジック番号は、ファイル内の特定の場所に常に存在するバイトシーケンスであり、したがって、特定のメディアタイプのエンティティを識別するために使用できます。
o File name extension(s) commonly used on one or more platforms to indicate that some file contains a given media type.
o 1つ以上のプラットフォームで一般的に使用されるファイル名の拡張機能は、一部のファイルに特定のメディアタイプが含まれていることを示します。
o Mac OS File Type code(s) (4 octets) used to label files containing a given media type.
o 特定のメディアタイプを含むファイルのラベルに使用されるMac OSファイルタイプコード（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 Internet Draft is not required for these registrations, but may be helpful to the IESG and is encouraged.
他の標準団体による標準ツリーの提案された登録は、IESG（IESG@ietf.org）およびIETF-Typesリスト（IETF-Types@iana.org）に伝える必要があります。これらの登録にはインターネットドラフトとしての事前の投稿は必要ありませんが、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.
登録がIESGに提出された標準ツリーへのRFC出版リクエストの一部である場合、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アプリケーションエリアディレクターによって任命されたメディアタイプのレビューアは、登録を確認して、このドキュメントに記載されている要件を満たしていることを確認します。
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.
メディアタイプの登録は削除されない場合があります。使用に適していないと考えられているメディアタイプは、「意図した使用」フィールドの変更によって時代遅れと宣言できます。このようなメディアタイプは、IANAが発行したリストに明確にマークされます。
To: ietf-types@iana.org Subject: Registration of media type XXX/YYY
宛先：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):
マジック番号：ファイル拡張子：Macintoshファイルタイプコード：
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Intended usage:
意図された使用法：
(One of COMMON, LIMITED USE or OBSOLETE.)
（一般的な、限られた使用または時代遅れの1つ。）
Restrictions on usage:
使用に関する制限：
(Any restrictions on where the media type can be used go here.)
（メディアタイプを使用できる場所の制限はこちらに移動します。）
Author:
著者：
Change controller:
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]。現在のバージョンが彼が同意したものであることを願っていますが、その合意を確認することは不可能であるため、彼の名前を共著者として残念に削除しました。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046] Freed、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978] Freed、N。およびJ. Postel、「Iana Charset登録手順」、BCP 19、RFC 2978、2000年10月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、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] Berners-Lee、T.、Fielding、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] Crocker、D。Ed。、および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] Apple Computer、Inc。、「Mac OS：ファイルタイプおよび作成者コード、およびファイル形式」、Apple Knowledge Base第55381条、1993年6月、<http://www.info.apple.com/kbnum/n55381>。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメールエクステンション（MIME）パート4：登録手順」、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] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、継続」、RFC 2231、1997年11月。
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年より前に登録された多くのメディアタイプは、このドキュメントのガイドラインに登録された場合、ベンダーまたは個人のツリーに配置されます。適切な木を反映するためにこれらのタイプの再登録が奨励されますが、必要ありません。このドキュメントで概説されている所有権および変更制御原則は、上記の木に登録されているかのように、これらのタイプに適用されます。
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.
o このドキュメントのさまざまなURLとアドレスは変更されているため、すべてがisi.eduではなくiana.orgを参照しています。さらに、HTTPを使用するためにURLの多くが変更されています。以前は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 現在、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 Macintoshタイプのコードを説明するリファレンスが追加されました。
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
Ned Freed Sun Microsystems 3401 Centrelake Drive、Suite 410 Ontario、CA 92761-1205 USA
Phone: +1 909 457 4293
EMail: ned.freed@mrochek.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
ジョンC.クレンシン1770マサチューセッツアベニュー、＃322ケンブリッジ、マサチューセッツ州02140
EMail: klensin+ietf@jck.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。