RFC4288 日本語訳
4288 Media Type Specifications and Registration Procedures. N. Freed,J. Klensin. December 2005. (Format: TXT=52667 bytes) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group N. Freed Request for Comments: 4288 Sun Microsystems BCP: 13 J. Klensin Obsoletes: 2048 December 2005 Category: Best Current Practice
ネットワークワーキンググループN.はコメントを求める要求を解放しました: 4288サン・マイクロシステムズBCP: 13 J.Klensinは以下を時代遅れにします。 2048 2005年12月のカテゴリ: 最も良い現在の習慣
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).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols.
このドキュメントはMIMEにおける使用と他のインターネットプロトコルのためにメディアタイプの仕様と登録のための手順を定義します。
Freed & Klensin Best Current Practice [Page 1] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[1ページ]RFC4288メディアは2005年12月に登録をタイプします。
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
1. 序論…3 2. メディアは登録予選をタイプします…4 3. 登録木とSubtype名…4 3.1. 規格木…4 3.2. ベンダー木…5 3.3. 個人的であるか虚栄木…5 3.4. 特別番組x。 木…5 3.5. 追加登録木…6 4. 登録要件…6 4.1. 機能性要件…6 4.2. 要件を命名します…6 4.2.1. テキストメディアタイプ…7 4.2.2. イメージメディアタイプ…8 4.2.3. オーディオメディアタイプ…8 4.2.4. ビデオメディアタイプ…8 4.2.5. アプリケーションメディアタイプ…9 4.2.6. 複合とメッセージメディアタイプ…9 4.2.7. 追加トップレベルタイプ…9 4.3. パラメタ要件…10 4.4. Canonicalizationと形式要件…10 4.5. 推薦を交換してください…11 4.6. セキュリティ要件…11 4.7. XMLメディアタイプに、特定の要件…13 4.8. 要件をコード化します…13 4.9. 用法と実装非要件…13 4.10. 公表要件…14 4.11. 追加情報…15 5. 登録手順…15 5.1. 予備の共同体は再検討されます…16 5.2. IESG承認…16 5.3. IANA登録…16 5.4. メディアは評論家をタイプします…16 6. メディアのコメントは登録証明書をタイプします…17 7. 登録されたメディア型の並びの位置…17 8. メディアタイプを示すためのIANA手順…17 9. 手順を変えてください…18 10. 登録テンプレート…19 11. セキュリティ問題…20 12. IANA問題…20 13. 承認…20 14. 参照…20 付録A.はメディアタイプを除外しました…22 RFC2048以来付録B.は変化します…22
Freed & Klensin Best Current Practice [Page 2] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[2ページ]RFC4288メディアは2005年12月に登録をタイプします。
1. Introduction
1. 序論
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.
このドキュメントは中央の登録としてインターネットAssigned民数記Authority(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を見てください。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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.
この仕様はAugmented BN記法(ABNF)[RFC4234]記法を利用します、そのドキュメントのAppendix Aで定義されたコア規則を含んでいて。
Freed & Klensin Best Current Practice [Page 3] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[3ページ]RFC4288メディアは2005年12月に登録をタイプします。
2. Media Type Registration Preliminaries
2. メディアは登録予選をタイプします。
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.
ニューメディアタイプかタイプの登録は登録提案の工事から始まります。 登録は以下で議論するように異なった要件を持っているいくつかの異なった登録木の中に起こるかもしれません。 一般に、新規登録提案は、かかわった木に適切なファッションで循環して、見直されます。 そして、提案が許容できるなら、メディアタイプは示されます。 以下のセクションはそれぞれの異なった登録木に用いられた要件と手順について説明します。
3. Registration Trees and Subtype Names
3. 登録木とSubtype名
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.
増加するように、登録の効率と柔軟性は処理されます、名前が異なった自然な要件を収容するために登録されるかもしれない「副-タイプ」の異なった構造、例えば幅広い支持と実装のためにインターネットコミュニティによって推薦される「副-タイプ」、または、ファイルを動かすのに使用される「副-タイプ」は独占ソフトウェアと交際しました。 以下の小区分はfaceted名前の使用で区別される登録「木」を定義します、例えば、フォーム"tree.subtree"の名前…"「副-タイプ」"。 このドキュメントの前で定義された何人かのメディアタイプが以下で説明された命名規則に従わないことに注意してください。 それらの議論に関してAppendix Aを見てください。
3.1. Standards Tree
3.1. 規格木
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として登録提案を発行しなければなりません。 規格木の登録RFCsはスタンドアロン「登録専用」RFCsであるかもしれませんかある種の、より一般的な仕様に彼らは組み入れることができます。
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.
通常、規格におけるタイプが木に追い上げるメディアが明らかにfacetedされない名前によって指示されて、すなわち、期間を含まないでください、(「」、終止符) キャラクタ。
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.
木が標準化団体自体であると思われる規格におけるメディアタイプの「所有者」登録。 仕様の変更か変更が新規登録に必要である処理(例えば、標準化過程)の同じレベルを必要とします。
Freed & Klensin Best Current Practice [Page 4] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[4ページ]RFC4288メディアは2005年12月に登録をタイプします。
3.2. Vendor Tree
3.2. ベンダー木
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に提出するかもしれません。
3.3. Personal or Vanity Tree
3.3. 個人的であるか虚栄木
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に提出するかもしれません。
3.4. Special x. Tree
3.4. 特別番組x。 木
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
この登録体系がある便利と対称において、最初の一面としての「x.」の「副-タイプ」名は「x」で始まる名前が使用されているのと同じ目的に使用されるかもしれません。 これらのタイプはそうです。
Freed & Klensin Best Current Practice [Page 5] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[5ページ]RFC4288メディアは2005年12月に登録をタイプします。
unregistered, experimental, and for use only with the active agreement of the parties exchanging them.
登録されていなく、実験的である、単にパーティーの活発な協定による使用と彼らを交換します。
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.
この木のタイプを示してはいけません。
3.5. Additional Registration Trees
3.5. 追加登録木
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.
時々、必要に応じて、助言と同意とIESGの助言と同意で、共同体のそばでは、IANAが新しいトップレベル登録木を作成するかもしれません。 これらの木が外部の登録と管理のためによく知られる永久的なボディーによって作成されるかもしれないと明らかに思われます。 例えば、科学的社会はそれらがカバーする科学に特定のメディアタイプを示すかもしれません。一般に、これらの追加登録木の1つの仕様のレビューの品質が規格木の登録証明書に相当させていると予想されます。 これらの新しい木の設立はIESGによって承認されたRFC公表を通して発表されるでしょう。
4. Registration Requirements
4. 登録要件
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.
メディアは以下のセクションで広げられた様々な要件に従わせる提案がすべて予想される登録をタイプします。 再び以下のセクションで詳しく述べられるように登録木によって、要件詳細が時々異なることに注意してください。
4.1. Functionality Requirement
4.1. 機能性要件
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.
メディアタイプは実際のメディア形式として機能しなければなりません。 charsetとして、または、別のタイプの別々の実体の収集としてコード化される転送として考えられるほうがよいものの登録は許されていません。 例えば、利用は[RFC2045]をコード化するbase64転送を解読するために存在していますが、メディアタイプとしてbase64を登録できません。
This requirement applies regardless of the registration tree involved.
この要件はかかわった登録木にかかわらず適用されます。
4.2. Naming Requirements
4.2. 要件を命名します。
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.
すべての登録されたメディアタイプにタイプと「副-タイプ」名を選任しなければなりません。 これらの名前の組み合わせは、唯一メディアタイプを特定するのに役立ちます、そして、「副-タイプ」名の形式は登録木を特定します。 両方がタイプされます、そして、「副-タイプ」名は大文字と小文字を区別しないです。
Freed & Klensin Best Current Practice [Page 6] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[6ページ]RFC4288メディアは2005年12月に登録をタイプします。
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」と共に始まるタイプと「副-タイプ」名を、実験用のために予約して、示してはいけません。 これはセクション3.4で議論するようにx.木の上で制限に沿います。
Type and subtype names MUST conform to the following ABNF:
タイプと「副-タイプ」名は以下のABNFに従わなければなりません:
type-name = reg-name
subtype-name = reg-name
型名=reg-名前「副-タイプ」-名はreg-名前と等しいです。
reg-name = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" /
"#" / "$" / "&" / "." /
"+" / "-" / "^" / "_"
reg-名前=1*127reg-名雑用reg名前雑用=アルファー/ 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]がでしゃばるのを確実にしてください。)
4.2.1. Text Media Types
4.2.1. テキストメディアタイプ
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"
「テキスト」メディアタイプはフォームで主に原文であることの送付の材料のために意図します。 "charset"パラメタは「テキスト」血液型亜型のために本文のcharsetを示すのに使用されるかもしれません、「副-タイプ」「テキスト/平野」(プレーンテキストのための「副-タイプ」が[RFC2046]で定義したジェネリックである)を著しく含んでいて。 定義されたaテキストであるなら「charset」
Freed & Klensin Best Current Practice [Page 7] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[7ページ]RFC4288メディアは2005年12月に登録をタイプします。
parameter MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978].
一致で[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
プレーンテキストは、書式付けコマンド、文字修飾仕様、処理命令、解釈指示、または満足しているマーク付けを備えもしませんし、許容もしません。 プレーンテキストは単にa直線的であるとみなされます。
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".
プレーンテキストを超えて、「豊かなテキスト」として知られているかもしれないことを表すための多くの形式がいます。 そのような多くの表現のおもしろい特性はそれらがそれらを解釈するソフトウェアがなくてもある程度読み込み可能であるということです。 それらを区別するのは役に立ちます、上層部によって、イメージ、オーディオ、またはテキストが読みにくいフォームに表したような読みにくいデータから。 適切な解釈ソフトウェアがないとき、「テキスト」の血液型亜型をユーザに提示するのは妥当です、したがって、ほとんどの非原文のデータを処理するのが妥当ではありませんが。 そのようなフォーマットされた原文のデータは、「テキスト」の血液型亜型を使用することで表されるべきです。
4.2.2. Image Media Types
4.2.2. イメージメディアタイプ
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.
「イメージ」のメディアタイプは、内容が指定するか、または以上が表示するために適切なハードウェアを必要とするイメージを切り離すのを示します。 「副-タイプ」は特定の画像形式を命名します。
4.2.3. Audio Media Types
4.2.3. オーディオメディアタイプ
A media type of "audio" indicates that the content contains audio data.
「オーディオ」のメディアタイプは、内容がオーディオデータを含むのを示します。
4.2.4. Video Media Types
4.2.4. ビデオメディアタイプ
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".
このドキュメントが単一のボディーでのマルチメディアの混合を一般に強くがっかりさせますが、多くのいわゆるビデオ形式が連動しているオーディオ、そして/または、テキストの表現を含んでいると認められて、これが「ビデオ」の血液型亜型のために明らかに許可されていることに注意してください。
Freed & Klensin Best Current Practice [Page 8] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[8ページ]RFC4288メディアは2005年12月に登録をタイプします。
4.2.5. Application Media Types
4.2.5. アプリケーションメディアタイプ
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".
「アプリケーション」の「副-タイプ」は、しばしば名前であるかデータが意図するアプリケーションの名前の一部を含むでしょう。 しかしながら、これは、どんな応用プログラム名も「アプリケーション」の「副-タイプ」として自由に使用されるかもしれないことを意味しません。
4.2.6. Multipart and Message Media Types
4.2.6. 複合とメッセージメディアタイプ
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.
複合、メッセージが合成型である、すなわち、彼らはゼロをカプセル化するa手段か、より多くのオブジェクト(それ自身のメディアタイプでラベルされたそれぞれ)を提供します。
All subtypes of multipart and message MUST conform to the syntax rules and other requirements specified in [RFC2046].
複合のすべての血液型亜型とメッセージは[RFC2046]で指定されたシンタックス・ルールと他の要件に従わなければなりません。
4.2.7. Additional Top-level Types
4.2.7. 追加トップレベルタイプ
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.
いくつかの場合、ニューメディアタイプはどんな現在定義されたトップレベルcontent typeの下でも「合わないかもしれません」。 そのような場合がかなりまれであると予想されます。 しかしながら、そのような場合が起こるなら、それを収容するために新しいトップレベルタイプを定義できます。 標準化過程RFCを通してそのような定義をしなければなりません。 追加トップレベルcontent typeを定義するのに他のメカニズムを全く使用できません。
Freed & Klensin Best Current Practice [Page 9] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[9ページ]RFC4288メディアは2005年12月に登録をタイプします。
4.3. Parameter Requirements
4.3. パラメタ要件
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つ以上のメディア型引数を使用するのを選ぶかもしれませんか、または自動的にいくつかのパラメタを血液型亜型のどれかに適切な状態で1セットのパラメタを定義するcontent typeの「副-タイプ」であることによるメディアタイプに利用可能にするかもしれません。 どちらの場合ではも、どんなパラメタの名前、値、および意味も完全に指定しなければなりません。
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.
メディアタイプがベンダーか個人的な木に示されるとき、aメディアがタイプされると、規格が木に追い上げる登録されたコネ、およびSHOULDはできるだけ完全に指定されていますか?
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.
パラメタ値のための定義された構文が全くありません。 したがって、登録証明書はパラメタ値の構文を指定しなければなりません。 さらに、いくつかの輸送がパラメタ値の構文に制限を課すので、潜在的に問題の多い構文の使用を制限するために注意するべきです。 例えば純粋な2進の評価されたパラメタはたぶんいくつかのプロトコルで受入れられている間、避けられるべきです。
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.
新しいパラメタSHOULD NOTが規格木に示されたタイプによる新しい機能性を紹介する方法と定義されて、新しいパラメタは追加情報を伝えるために加えられるかもしれませんが、そうでなければ、それは既存の機能性を変えません。 この例は、JPEGなどの外部仕様の改正レベルを示すためには「改正」パラメタでしょう。 同様の振舞いは、ベンダーで示されたメディアタイプか個人的な木のために奨励されますが、必要ではありません。
4.4. Canonicalization and Format Requirements
4.4. Canonicalizationと形式要件
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
形式と処理子細の仕様は公的にベンダー木に示されたメディアタイプ、および提案が明らかに受入れられるそのような登録に利用可能であるかもしれません。
Freed & Klensin Best Current Practice [Page 10] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[10ページ]RFC4288メディアは2005年12月に登録をタイプします。
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]に詳しく説明された制限を尊敬しなければなりません。 さらに、規格の使用を木にする他の標準化団体は彼らの登録証明書で観測しなければならない知的所有権に関するそれら自身の規則を持っているかもしれません。
4.5. Interchange Recommendations
4.5. 置き換え推薦
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.
SHOULDができるだけ多くのシステムとアプリケーションの向こう側に共同利用するメディアタイプ。 しかしながら、何人かのメディアタイプには、異なったプラットホームの向こう側に共同利用することにおける問題が必然的にあるでしょう。ゲートウェイ取り扱いの異なった見解、バイト順、および詳細に関する問題は、起きることができて、起きるでしょう。
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.
メディアの普遍的な相互運用性はタイプします。必要ではありませんが、可能であるときはいつも、相互運用性問題SHOULDが特定されるのを知っています。 メディアタイプの公表は相互運用性の徹底的なレビューを必要としません、そして、相互運用性問題部は継続する評価を受けることがあります。
These recommendations apply regardless of the registration tree involved.
これらの推薦はかかわった登録木にかかわらず適用されます。
4.6. Security Requirements
4.6. セキュリティ要件
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
規格Treeに示されたすべてのタイプのために安全保障問題の分析をしなければなりません。 ベンダーで示されたメディアタイプか個人的な木のための同様の分析は、奨励されますが、必要ではありません。 しかしながら、証券分析が持っているか、または行われていない何にかかわらず、安全保障問題のすべての記述が登録木にかかわらずできるだけ正確でなければならないか。 特に、「このタイプに関連している安全保障問題がありません」があるという声明はそうしなければなりません。
Freed & Klensin Best Current Practice [Page 11] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[11ページ]RFC4288メディアは2005年12月に登録をタイプします。
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 圧縮を使うメディアタイプは受け取られて、評価されると途方もないほど広がる少量のデータを送るのに受取人のリソースのすべてを消費する機会を与えるかもしれません。 彼らが圧縮を使って、そうするなら踏まれるものについて議論するべきであるか否かに関係なく、SHOULDが述べるすべてのメディアタイプが、そのような攻撃を避けるために取られる必要があります。
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
o メディアタイプはある種の安全保証を必要としますが、必要なセキュリティー対策自体を提供しないアプリケーションのために狙うかもしれません。 例えば、秘密の医療情報のストレージのためにメディアタイプを定義できた、そんなに順番に。
Freed & Klensin Best Current Practice [Page 12] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[12ページ]RFC4288メディアは2005年12月に登録をタイプします。
requires an external confidentiality service, or which is designed
for use only within a secure environment.
外部の秘密性サービス、または使用のために安全な環境だけの中で設計されているものを必要とします。
4.7. Requirements specific to XML media types
4.7. XMLメディアタイプに、特定の要件
There are a number of additional requirements specific to the registration of XML media types. These requirements are specified in [RFC3023].
XMLメディアタイプの登録に特定の多くの追加要件があります。 これらの要件は[RFC3023]で指定されます。
4.8. Encoding Requirements
4.8. 要件をコード化します。
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に噛み付きました: メディアタイプの内容は唯一7ビットのCRLFによって区切られた米国-ASCIIテキストから成ります。
8bit: The content of the media type consists solely of CRLF-delimited
8bit text.
8に噛み付きました: メディアタイプの内容は唯一8ビットのCRLFによって区切られたテキストから成ります。
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、縁どられたコード化による一般的に使用された輸送はレアル-時間Transportプロトコルです。 [RFC3555]で輸送のためにRTPを使用することで定義された縁どられたencodingsのための付則を与えます。
Additional restrictions on 7bit and 8bit text are given in [RFC2046].
[RFC2046]で7ビットにおける追加制限と8ビットのテキストを与えます。
4.9. Usage and Implementation Non-requirements
4.9. 用法と実装非要件
In the asynchronous mail environment, where information on the capabilities of the remote mail agent is frequently not available to
非同期なメール環境で。そこでは、リモートメールエージェントの能力の情報が頻繁に利用可能ではありません。
Freed & Klensin Best Current Practice [Page 13] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[13ページ]RFC4288メディアは2005年12月に登録をタイプします。
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.
したがって、メディアタイプの世界的支援と実装は登録のための要件ではありません。 しかしながら、メディアタイプが限られた使用のために明らかに意図するなら、登録でこれに注意しなければなりません。 このために「用法における制限」野原を供給します。
4.10. Publication Requirements
4.10. 公表要件
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.
RFCsとして規格木にIETF自身によって示されたメディアタイプのための提案を発行しなければなりません。 ベンダーと人的メディアタイプ提案の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または同等の証明による裏書き、承認、または推薦を含意しません。 インターネットStandards、プロトコルまたはデータ・オブジェクトになるのは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
規格は木に登られます。認識された標準化団体で実質的なレビューと承認審査方式を必要とするメディアタイプのために、存在しています。 ベンダーと個人的な木はそのようなプロセスを必要としないそれらのメディアタイプのために存在しています。 特定用途のための適用性証明が時間から発表されると予想されます。
Freed & Klensin Best Current Practice [Page 14] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[14ページ]RFC4288メディアは2005年12月に登録をタイプします。
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公表を必要とします。
4.11. Additional Information
4.11. 追加情報
Various sorts of optional information SHOULD be included in the specification of a media type if it is available:
含まれていて、メディアの仕様では、タイプがそれであるなら手があいているという任意の情報SHOULDの様々な種類:
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 File Typeコード(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を組み込むのによる仕様自体をこれにすることが提案されます。
5. Registration Procedure
5. 登録手順
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登録証明書のために続かれるべきです。 インターネットDraftの任命は 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.
ベンダーと個人的な木の登録証明書を直接IANAに提出するべきです、レビューのための ietf-types@iana.org リストへの最初の任命の理想的に後に。
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( iesg@ietf.org の)と、そして、ietf-タイプリスト( ietf-types@iana.org の)に伝えられるべきです。 先の任命
Freed & Klensin Best Current Practice [Page 15] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[15ページ]RFC4288メディアは2005年12月に登録をタイプします。
Internet Draft is not required for these registrations, but may be helpful to the IESG and is encouraged.
インターネットDraftはこれらの登録証明書に必要ではありませんが、IESGに役立つかもしれなくて、奨励されます。
5.1. Preliminary Community Review
5.1. 予備の共同体レビュー
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.
このリストへの公共の任命の意図はタイプ/「副-タイプ」名の選択、バージョンと外部のプロフィール情報に関する参照の「非-あいまいさ」、およびどんな相互運用性やセキュリティ問題のレビューのコメントとフィードバックにも請求することです。 submitterは改訂された登録を提出するか、または完全でいつでも、登録を捨てるかもしれません。
5.2. IESG Approval
5.2. IESG承認
Media types registered in the standards tree MUST be approved by the IESG prior to registration.
IESGは登録の前に規格木に示されたメディアタイプを承認しなければなりません。
5.3. IANA Registration
5.3. IANA登録
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 に送ることができます。 また、登録要求のためのウェブフォームも利用可能です:
http://www.iana.org/cgi-bin/mediatypes.pl
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に登録を提出することを意味します。 追加登録要求の必要は全くそのような場合ありません。
5.4. Media Types Reviewer
5.4. メディアは評論家をタイプします。
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 Applications Areaディレクターによって任命される)がそれが条件を満たすのを確信しているのに作るために登録を見直すメディアタイプは本書では旅に出ます。
Freed & Klensin Best Current Practice [Page 16] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[16ページ]RFC4288メディアは2005年12月に登録をタイプします。
Registrations that do not meet these requirements will be returned to the submitter for revision.
改正のためにこれらの必要条件を満たさない登録証明書をsubmitterに返すでしょう。
Decisions made by the media types reviewer may be appealed to the IESG using the procedure specified in [RFC2026] section 6.5.4.
メディアタイプによって作られていて、評論家が手順を用いることでIESGに上告されるかもしれないという決定は[RFC2026]セクション6.5.4で指定しました。
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はメディアタイプを示して、メディアに共同体に利用可能な登録をタイプさせるでしょう。
6. Comments on Media Type Registrations
6. メディアのコメントは登録証明書をタイプします。
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に提出されるかもしれません。 これらのコメントは評論家であって次に、できれば、メディアタイプの「所有者」に通っているメディアタイプによって見直されるでしょう。 コメントのSubmittersは、彼らのコメントがメディアタイプ登録自体に付けられているよう要求するかもしれません、そして、IANAがこれに賛成すると、コメントをタイプ登録に関連してアクセスしやすくするでしょう。
7. Location of Registered Media Type List
7. 登録されたメディア型の並びの位置
Media type registrations are listed by the IANA at:
メディアタイプ登録証明書は以下にIANAによって記載されています。
http://www.iana.org/assignments/media-types/
http://www.iana.org/assignments/media-types/
8. IANA Procedures for Registering Media Types
8. メディアタイプを示すためのIANA手順
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 メディアタイプは実際のメディア形式として機能しなければなりません。 特に、メディアタイプとしてcharsetsと転送encodingsを登録してはいけません。
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つに提供しなければなりません。
Freed & Klensin Best Current Practice [Page 17] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[17ページ]RFC4288メディアは2005年12月に登録をタイプします。
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には、明らかに脆い材料を特定して、改正のためにそれをsubmitterに返す権威があります。)
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自身、または、そういうものとして認識された別の標準化団体から起因するという追加要件を満たさなければなりません。
9. Change Procedures
9. 変化手順
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によって発表されたリストで明確にマークされるでしょう。
Freed & Klensin Best Current Practice [Page 18] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[18ページ]RFC4288メディアは2005年12月に登録をタイプします。
10. Registration Template
10. 登録テンプレート
To: ietf-types@iana.org Subject: Registration of media type XXX/YYY
To: ietf-types@iana.org Subject: メディアタイプXXX/YYYの登録
Type name:
型名:
Subtype name:
Subtypeは以下を命名します。
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): マッキントッシュファイルタイプは(s)をコード化します:
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス:
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:
コントローラを変えてください:
(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
[MacOSFileTypes]でマッキントッシュファイルの種類コードとそれらの目的の何らかの議論を見つけることができます。 さらに、書くのを控えてください。
Freed & Klensin Best Current Practice [Page 19] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[19ページ]RFC4288メディアは2005年12月に登録をタイプします。
"none" or anything similar when no file extension or Macintosh file type is specified, lest "none" be confused with an actual code value.
「なにも」、ファイル拡張子でないなら何か同様のものまたはマッキントッシュファイルの種類が指定されます、「なにも」が実際のコード値に混乱するといけないので。
11. Security Considerations
11. セキュリティ問題
Security requirements for media type registrations are discussed in Section 4.6.
メディアが登録証明書をタイプするので、セクション4.6でセキュリティ要件について議論します。
12. IANA Considerations
12. IANA問題
The purpose of this document is to define IANA registries for media types.
このドキュメントの目的はメディアタイプのためにIANA登録を定義することです。
13. Acknowledgements
13. 承認
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]の前任者を形成した故ジョン・ポステル博士に彼らの負債を承認したがっています。 最新版が彼が同意したでしょうが、その協定について確かめるのが不可能であるので私たちが残念ながら共著者として彼の名前を取り除いたものであることを願っています。
14. References
14. 参照
14.1. Normative References
14.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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、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を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
解放された[RFC2978]とN.とJ.ポステル、「IANA Charset登録手順」、BCP19、RFC2978、2000年10月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.
[RFC3023] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、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の種類登録」、RFC3555、2003年7月。
Freed & Klensin Best Current Practice [Page 20] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[20ページ]RFC4288メディアは2005年12月に登録をタイプします。
[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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[RFC4234] Crocker, D. Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October
2005.
D.エド[RFC4234]クロッカー、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
14.2. Informative References
14.2. 有益な参照
[MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and Creator
Codes, and File Formats", Apple Knowledge Base
Article 55381, June 1993,
<http://www.info.apple.com/kbnum/n55381>.
[MacOSFileTypes]アップル・コンピューターInc.、「Mac OS:」 「タイプ、創造者コード、およびファイル形式をファイルしてください」、第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] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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)は4を分けます」。 「登録手順」、BCP13、RFC2048、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.ムーア、「パラメタ値とコード化されたWord拡大をまねてください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
Freed & Klensin Best Current Practice [Page 21] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[21ページ]RFC4288メディアは2005年12月に登録をタイプします。
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年前に示された多くのメディアタイプがそうするでしょう、ガイドラインの下で本書では登録されて、ベンダーか個人的な木に置かれるなら。 適切な木を反映するそういったタイプの人のReregistrationは奨励されますが、必要ではありません。 まるで彼らが上で説明された木に登録されたかのように原則が概説した所有権と変化コントロールは本書ではそういったタイプの人に申請されます。
Appendix B. Changes Since RFC 2048
RFC2048以来の付録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.
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 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 XMLメディアの登録に関する追加情報の情報筋がタイプするようにRFC3023は現在、参照をつけられます。
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問題部は加えられます。
Freed & Klensin Best Current Practice [Page 22] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[22ページ]RFC4288メディアは2005年12月に登録をタイプします。
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 様々なトップレベルタイプのための基本の登録要件はRFC2046からこのドキュメントまで動かされました。
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 マッキントッシュTypeコードについて説明する参照は加えられます。
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
ネッドはサン・マイクロシステムズ3401Centrelakeドライブ、Suite410オンタリオ、カリフォルニア92761-1205米国を解放しました。
Phone: +1 909 457 4293 EMail: ned.freed@mrochek.com
以下に電話をしてください。 +1 4293年の909 457メール: ned.freed@mrochek.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
マサチューセッツAve、ジョンC.Klensin1770#322ケンブリッジ、MA 02140
EMail: klensin+ietf@jck.com
メール: klensin+ ietf@jck.com
Freed & Klensin Best Current Practice [Page 23] RFC 4288 Media Type Registration December 2005
解放されるのとKlensinの最も良い現在の習慣[23ページ]RFC4288メディアは2005年12月に登録をタイプします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Freed & Klensin Best Current Practice [Page 24]
解放されるのとKlensinの最も良い現在の習慣[24ページ]
一覧
スポンサーリンク
