[要約] RFC 6838は、メディアタイプの仕様と登録手続きに関する情報を提供する。その目的は、インターネット上でのメディアの一貫性と相互運用性を確保するためのガイドラインを提供することである。
Internet Engineering Task Force (IETF) N. Freed
Request for Comments: 6838 Oracle
BCP: 13 J. Klensin
Obsoletes: 4288
Category: Best Current Practice T. Hansen
ISSN: 2070-1721 AT&T Laboratories
January 2013
Media Type Specifications and Registration Procedures
メディアタイプの仕様と登録手順
Abstract
概要
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols.
このドキュメントでは、HTTP、MIME、およびその他のインターネットプロトコルで使用するメディアタイプの仕様と登録の手順を定義しています。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化しています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6838.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6838で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Media Type Registration Preliminaries . . . . . . . . . . . . 4
3. Registration Trees and Subtype Names . . . . . . . . . . . . . 4
3.1. Standards Tree . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Vendor Tree . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Personal or Vanity Tree . . . . . . . . . . . . . . . . . 6
3.4. Unregistered x. Tree . . . . . . . . . . . . . . . . . . . 7
3.5. Additional Registration Trees . . . . . . . . . . . . . . 7
4. Registration Requirements . . . . . . . . . . . . . . . . . . 7
4.1. Functionality Requirement . . . . . . . . . . . . . . . . 8
4.2. Naming Requirements . . . . . . . . . . . . . . . . . . . 8
4.2.1. Text Media Types . . . . . . . . . . . . . . . . . . . 9
4.2.2. Image Media Types . . . . . . . . . . . . . . . . . . 10
4.2.3. Audio Media Types . . . . . . . . . . . . . . . . . . 10
4.2.4. Video Media Types . . . . . . . . . . . . . . . . . . 10
4.2.5. Application Media Types . . . . . . . . . . . . . . . 11
4.2.6. Multipart and Message Media Types . . . . . . . . . . 11
4.2.7. Additional Top-Level Types . . . . . . . . . . . . . . 12
4.2.8. Structured Syntax Name Suffixes . . . . . . . . . . . 12
4.2.9. Deprecated Aliases . . . . . . . . . . . . . . . . . . 13
4.3. Parameter Requirements . . . . . . . . . . . . . . . . . . 13
4.4. Canonicalization and Format Requirements . . . . . . . . . 14
4.5. Interchange Recommendations . . . . . . . . . . . . . . . 15
4.6. Security Requirements . . . . . . . . . . . . . . . . . . 15
4.7. Requirements Specific to XML Media Types . . . . . . . . . 16
4.8. Encoding Requirements . . . . . . . . . . . . . . . . . . 16
4.9. Usage and Implementation Non-Requirements . . . . . . . . 17
4.10. Publication Requirements . . . . . . . . . . . . . . . . . 18
4.11. Fragment Identifier Requirements . . . . . . . . . . . . . 18
4.12. Additional Information . . . . . . . . . . . . . . . . . . 19
5. Media Type Registration Procedures . . . . . . . . . . . . . . 19
5.1. Preliminary Community Review . . . . . . . . . . . . . . . 19
5.2. Submit Request to IANA . . . . . . . . . . . . . . . . . . 20
5.2.1. Provisional Registrations . . . . . . . . . . . . . . 20
5.3. Review and Approval . . . . . . . . . . . . . . . . . . . 21
5.4. Comments on Media Type Registrations . . . . . . . . . . . 21
5.5. Change Procedures . . . . . . . . . . . . . . . . . . . . 21
5.6. Registration Template . . . . . . . . . . . . . . . . . . 22
6. Structured Syntax Suffix Registration Procedures . . . . . . . 23
6.1. Change Procedures . . . . . . . . . . . . . . . . . . . . 24
6.2. Structured Syntax Suffix Registration Template . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. Grandfathered Media Types . . . . . . . . . . . . . . 30
Appendix B. Changes since RFC 4288 . . . . . . . . . . . . . . . 30
Recent Internet protocols have been carefully designed to be easily extensible in certain areas. In particular, many protocols, including but not limited to HTTP [RFC2616] and MIME [RFC2045], are capable of carrying arbitrary labeled content.
最近のインターネットプロトコルは、特定の領域で簡単に拡張できるように注意深く設計されています。特に、HTTP [RFC2616]およびMIME [RFC2045]を含むがこれらに限定されない多くのプロトコルは、任意のラベル付きコンテンツを運ぶことができます。
The mechanism used to label such content is a media type, consisting of a top-level type and a subtype, which is further structured into trees. Optionally, media types can define companion data, known as parameters.
このようなコンテンツのラベル付けに使用されるメカニズムは、最上位のタイプとサブタイプで構成されるメディアタイプであり、さらにツリーに構造化されます。オプションで、メディアタイプは、パラメーターと呼ばれるコンパニオンデータを定義できます。
A registration process is needed for these labels, so that the set of such values are defined in a reasonably orderly, well-specified, and public manner.
これらのラベルには登録プロセスが必要です。そのため、そのような値のセットは、合理的に秩序立って、十分に指定された、パブリックな方法で定義されます。
This document specifies the criteria for media type registrations and defines the procedures to be used to register media types (Section 5) as well as media type structured suffixes (Section 6) in the Internet Assigned Numbers Authority (IANA) central registry.
このドキュメントでは、メディアタイプ登録の基準を指定し、メディアタイプ（セクション5）とメディアタイプ構造化サフィックス（セクション6）をInternet Assigned Numbers Authority（IANA）中央レジストリに登録するために使用する手順を定義します。
The location of the media type registry managed by these procedures is:
これらの手順で管理されるメディアタイプレジストリの場所は次のとおりです。
http://www.iana.org/assignments/media-types/
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 is now a 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 specification incorporates 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] when they appear in ALL CAPS. They may also appear in lower or mixed case as plain English words, without any normative meaning.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、それらがすべて大文字で現れる場合、[RFC2119]で説明されているように解釈されます。それらはまた、規範的な意味なしに、プレーンな英語の単語として小文字または大文字と小文字が混在して表示される場合があります。
This specification makes use of the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of that document.
この仕様は、そのドキュメントの付録Bで定義されているコアルールを含むAugmented Backus-Naur Form（ABNF）[RFC5234]表記を利用しています。
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 can 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., subtype names that begin with a "tree." prefix. 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.
登録プロセスの効率と柔軟性を高めるために、サブタイプ名のさまざまな構造を登録して、たとえば、インターネットコミュニティによる幅広いサポートと実装に推奨されるサブタイプ、またはサブタイプのさまざまな自然要件に対応できます。専用ソフトウェアに関連するファイルを移動するために使用されます。次のサブセクションでは、ファセット名の使用によって区別される登録「ツリー」を定義します（例：「ツリー」で始まるサブタイプ名）。接頭辞。このドキュメントの前に定義された一部のメディアタイプは、以下で説明する命名規則に準拠していないことに注意してください。それらの説明については、付録Aを参照してください。
The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be either: 1. in the case of registrations associated with IETF specifications, approved directly by the IESG, or
標準ツリーは、インターネットコミュニティの一般的な関心のタイプを対象としています。標準ツリーの登録は次のいずれかでなければなりません：1. IETF仕様に関連する登録の場合、IESGによって直接承認されている、または
2. registered by a recognized standards-related organization using the "Specification Required" IANA registration policy [RFC5226] (which implies Expert Review).
2. 「Specification Required」IANA登録ポリシー[RFC5226]（エキスパートレビューを意味する）を使用して、認められた標準関連組織によって登録されている。
The first procedure is used for registrations from IETF Consensus documents, or in rare cases when registering a grandfathered (see Appendix A) and/or otherwise incomplete registration is in the interest of the Internet community. The registration proposal MUST be published as an RFC. When the registration RFC is in the IETF stream, it must have IETF Consensus, which can be attained with a status of Standards Track, BCP, Informational, or Experimental. Registrations published in non-IETF RFC streams are also allowed and require IESG approval. A registration can be either in a stand-alone "registration only" RFC or incorporated into a more general specification of some sort.
最初の手順は、IETFコンセンサスドキュメントからの登録に使用されます。まれに、祖父母（付録Aを参照）を登録する場合や、インターネットコミュニティの利益になるように不完全な登録が行われる場合もあります。登録提案はRFCとして公開する必要があります。登録RFCがIETFストリームにある場合、IETFコンセンサスが必要です。これは、Standards Track、BCP、Informational、またはExperimentalのステータスで達成できます。非IETF RFCストリームで公開された登録も許可されており、IESGの承認が必要です。登録は、スタンドアロンの「登録のみ」のRFCにすることも、ある種のより一般的な仕様に組み込むこともできます。
In the second case, the IESG makes a one-time decision on whether the registration submitter represents a recognized standards-related organization; after that, a Media Types Reviewer (Designated Expert or a group of Designated Experts) performs the Expert Review as specified in this document. Subsequent submissions from the same source do not involve the IESG. The format MUST be described by a formal standards specification produced by the submitting standards-related organization.
2番目のケースでは、IESGは、登録提出者が認められた標準関連組織を代表するかどうかについて一度の決定を行います。その後、メディアタイプレビューアー（指定エキスパートまたは指定エキスパートのグループ）が、このドキュメントで指定されているようにエキスパートレビューを実行します。同じソースからの後続の提出には、IESGは含まれません。このフォーマットは、提出する標準関連組織によって作成された正式な標準仕様で記述されている必要があります。
Media types in the standards tree MUST NOT have faceted names, unless they are grandfathered in using the process described in Appendix A.
標準ツリーのメディアタイプは、付録Aで説明されているプロセスを使用する際に祖父である場合を除き、ファセット名を使用してはなりません。
The "owner" of a media type registered in the standards tree is assumed to be the standards-related organization itself. Modification or alteration of the specification uses the same level of processing (e.g., a registration submitted on Standards Track can be revised in another Standards Track RFC, but cannot be revised in an Informational RFC) required for the initial registration.
標準ツリーに登録されているメディアタイプの「所有者」は、標準関連組織自体であると見なされます。仕様の変更または変更は、最初の登録に必要な同じレベルの処理を使用します（たとえば、Standards Trackで送信された登録は別のStandards Track RFCで変更できますが、Informational RFCでは変更できません）。
Standards-tree registrations from recognized standards-related organizations are submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval. In this case, the Expert Reviewer(s) will, among other things, ensure that the required specification provides adequate documentation.
認定された規格関連組織からの規格ツリー登録は、IANAに直接送信され、承認前に専門家レビュー[RFC5226]を受けます。この場合、エキスパートレビューアは、とりわけ、必要な仕様が適切な文書を提供することを確認します。
The vendor tree is used for media types associated with publicly available products. "Vendor" and "producer" are construed very broadly in this context and are considered equivalent. Note that industry consortia as well as non-commercial entities that do not qualify as recognized standards-related organizations can quite appropriately register media types in the vendor tree.
ベンダーツリーは、公開されている製品に関連付けられているメディアタイプに使用されます。 「ベンダー」と「プロデューサー」は、この文脈では非常に広く解釈され、同等と見なされます。業界団体や、認定された標準関連組織としての資格がない非営利団体は、メディアタイプをベンダーツリーに非常に適切に登録できることに注意してください。
A registration may be placed in the vendor tree by anyone who needs to interchange files associated with some product or set of products. However, the registration properly belongs to the vendor or organization producing the software that employs the type being registered, and that vendor or organization can at any time elect to assert ownership of a registration done by a third party in order to correct or update it. See Section 5.5 for additional information.
登録は、一部の製品または製品のセットに関連付けられているファイルを交換する必要がある人がベンダーツリーに配置できます。ただし、登録は、登録されているタイプを使用するソフトウェアを製造しているベンダーまたは組織に適切に属しており、そのベンダーまたは組織は、いつでもそれを修正または更新するために、第三者が行った登録の所有権を主張することを選択できます。詳細については、セクション5.5を参照してください。
When a third party registers a type on behalf of someone else, both entities SHOULD be noted in the Change Controller field in the registration. One possible format for this would be "Foo, on behalf of Bar".
第三者が他の誰かに代わってタイプを登録するとき、両方のエンティティは登録のChange Controllerフィールドに記されるべきです（SHOULD）。このための1つの可能な形式は、「フー、バーに代わって」です。
Vendor-tree registrations 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 are not required, using the media-types@iana.org mailing list for review is encouraged, to improve the quality of those specifications. Registrations in the vendor tree may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval.
ベンダーツリーに登録されるメディアタイプの公開とレビューは必要ありませんが、これらの仕様の品質を向上させるために、レビューにmedia-types@iana.orgメーリングリストを使用することをお勧めします。ベンダーツリーの登録はIANAに直接送信でき、承認の前にエキスパートレビュー[RFC5226]を受けます。
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 are not required, using the media-types@iana.org mailing list (see Section 5.1) for review is encouraged, to improve the quality of those specifications. Registrations in the personal tree may be submitted directly to the IANA, where they will undergo Expert Review [RFC5226] prior to approval.
個人ツリーに登録されるメディアタイプの公開とレビューは必要ありませんが、これらの仕様の品質を向上させるために、レビューにmedia-types@iana.orgメーリングリスト（セクション5.1を参照）を使用することをお勧めします。個人ツリーの登録はIANAに直接送信でき、承認の前にエキスパートレビュー[RFC5226]を受けます。
Subtype names with "x." as the first facet may be used for types intended exclusively for use in private, local environments. Types in this tree cannot be registered and are intended for use only with the active agreement of the parties exchanging them.
「x」を含むサブタイプ名。最初のファセットは、プライベートなローカル環境での使用のみを目的としたタイプに使用できるため。このツリーのタイプは登録できません。タイプを交換する当事者の積極的な合意がある場合にのみ使用することを目的としています。
However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered types. Therefore, use of types in the "x." tree is strongly discouraged.
ただし、上記のベンダーツリーとパーソナルツリーの簡単な登録手順では、登録されていないタイプを使用する必要はほとんどありません。したがって、「x」でのタイプの使用。ツリーは強く非推奨です。
Note that types with names beginning with "x-" are no longer considered to be members of this tree (see [RFC6648]). Also note that if a generally useful and widely deployed type incorrectly ends up with an "x-" name prefix, it MAY be registered using its current name in an alternative tree by following the procedure defined in Appendix A.
名前が「x-」で始まる型は、このツリーのメンバーとは見なされないことに注意してください（[RFC6648]を参照）。また、一般的に有用で広く展開されているタイプが「x-」という名前のプレフィックスで誤って終わる場合は、付録Aで定義されている手順に従って、現在の名前を使用して代替ツリーに登録できます。
From time to time and as required by the community, new top-level registration trees may be created by IETF Standards Action. It is explicitly assumed that these trees may be created for external registration and management by well-known permanent organizations; 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 by a recognized standards-related organization. When the IETF performs such review, it needs to consider the greater expertise of the requesting organization with respect to the subject media type.
時折、コミュニティの要求に応じて、IETF標準アクションによって新しいトップレベルの登録ツリーが作成される場合があります。これらのツリーは、よく知られた永続的な組織による外部登録および管理のために作成される可能性があることが明示的に想定されています。たとえば、科学団体は、対象とする科学に固有のメディアタイプを登録する場合があります。一般に、これらの追加の登録ツリーの1つに対する仕様のレビューの質は、承認された標準関連組織による標準ツリーの登録と同等であると予想されます。 IETFがそのようなレビューを実行するときは、対象のメディアタイプに関して要求側組織のより大きな専門知識を考慮する必要があります。
Media type registrations 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 actual media formats. 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 top-level type and subtype names. The combination of these names serves to uniquely identify the media type, and the subtype name facet (or the absence of one) identifies the registration tree. Both top-level type and subtype names are case-insensitive.
登録されたすべてのメディアタイプには、トップレベルのタイプとサブタイプの名前を割り当てる必要があります。これらの名前の組み合わせは、メディアタイプを一意に識別するのに役立ち、サブタイプ名ファセット（または存在しないこと）は、登録ツリーを識別します。トップレベルのタイプとサブタイプの名前はどちらも大文字と小文字が区別されません。
Type and subtype names MUST conform to the following ABNF:
タイプとサブタイプの名前は、次のABNFに準拠している必要があります。
type-name = restricted-name subtype-name = restricted-name
タイプ名=制限名サブタイプ名=制限名
restricted-name = restricted-name-first *126restricted-name-chars
restricted-name-first = ALPHA / DIGIT
restricted-name-chars = ALPHA / DIGIT / "!" / "#" /
"$" / "&" / "-" / "^" / "_"
restricted-name-chars =/ "." ; Characters before first dot always
; specify a facet name
restricted-name-chars =/ "+" ; Characters after last plus always
; specify a structured syntax suffix
Note that this syntax is somewhat more restrictive than what is allowed by the ABNF in Section 5.1 of [RFC2045] or Section 4.2 of [RFC4288]. Also note that while this syntax allows names of up to 127 characters, implementation limits may make such long names problematic. For this reason, <type-name> and <subtype-name> SHOULD be limited to 64 characters.
この構文は、[RFC2045]のセクション5.1または[RFC4288]のセクション4.2でABNFによって許可されている構文よりもいくらか制限的であることに注意してください。また、この構文では127文字までの名前を使用できますが、実装の制限により、このような長い名前が問題になる場合があります。このため、<type-name>と<subtype-name>は64文字に制限する必要があります。
Although the name syntax treats "." as equivalent to any other character, characters before any initial "." always specify the registration facet. Note that this means that facet-less standards-tree registrations cannot use periods in the subtype name.
名前の構文は "。"を扱いますが他の任意の文字、任意の最初の「。」の前の文字と同等。常に登録ファセットを指定します。これは、ファセットのない標準ツリーの登録ではサブタイプ名にピリオドを使用できないことを意味することに注意してください。
Similarly, the final "+" in a subtype name introduces a structured syntax specifier suffix. Structured syntax suffix requirements are specified in Section 4.2.8.
同様に、サブタイプ名の最後の「+」は、構造化構文指定子のサフィックスを導入します。構造化構文の接尾辞の要件は、セクション4.2.8で指定されています。
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 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 HTTP and MIME, MAY impose additional restrictions on the media types they can transport. (See [RFC2046] for additional information on the restrictions MIME imposes.)
トップレベルのタイプの選択は、関与するメディアタイプの性質を考慮に入れなければなりません。トップレベルタイプの新しいサブタイプは、もしあれば、トップレベルタイプの制限に準拠する必要があります。以下のセクションでは、トップレベルタイプの初期セットと、それに関連する制限のそれぞれについて説明します。さらに、HTTPおよびMIMEを含むがこれらに限定されないさまざまなプロトコルは、転送できるメディアタイプに追加の制限を課してもよい（MAY）。 （MIMEが課す制限の詳細については、[RFC2046]を参照してください。）
The "text" top-level type is intended for sending material that is principally textual in form.
「テキスト」トップレベルタイプは、主にテキスト形式の素材を送信するためのものです。
Many subtypes of text, notably including the subtype "text/plain", which is a generic subtype for plain text defined in [RFC2046], define a "charset" parameter. If a "charset" parameter is defined for a particular subtype of text, it MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978].
テキストの多くのサブタイプ、特に[RFC2046]で定義されているプレーンテキストの一般的なサブタイプであるサブタイプ "text / plain"を含め、 "charset"パラメータを定義します。 「charset」パラメータがテキストの特定のサブタイプに対して定義されている場合、[RFC2978]で説明されている手順に従って定義された文字セット名を指定するために使用する必要があります。
As specified in [RFC6657], a "charset" parameter SHOULD NOT be specified when charset information is transported inside the payload (e.g., as in "text/xml").
[RFC6657]で指定されているように、文字セット情報がペイロード内で転送される場合（「text / xml」など）、「charset」パラメータを指定してはなりません（SHOULD NOT）。
If a "charset" parameter is specified, it SHOULD be a required parameter, eliminating the options of specifying a default value. If there is a strong reason for the parameter to be optional despite this advice, each subtype MAY specify its own default value, or alternatively, it MAY specify that there is no default value. Finally, the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See [RFC6657] for additional information on the use of "charset" parameters in conjunction with subtypes of text.
「charset」パラメーターが指定されている場合、それは必須パラメーターである必要があり（SHOULD）、デフォルト値を指定するオプションが除去されます。このアドバイスにもかかわらず、パラメーターがオプションであるという強い理由がある場合、各サブタイプは独自のデフォルト値を指定してもよい（MAY）、あるいは、デフォルト値がないことを指定してもよい（MAY）。最後に、「UTF-8」文字セット[RFC3629]をデフォルトとして選択する必要があります（SHOULD）。テキストのサブタイプと組み合わせた「charset」パラメータの使用に関する追加情報については、[RFC6657]を参照してください。
Regardless of what approach is chosen, all new text/* registrations
MUST clearly specify how the charset is determined; relying on the
US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer
permitted. If explanatory text is needed, this SHOULD be placed in
the additional information section of the registration.
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 different 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 can be represented using subtypes of "text".
プレーンテキスト以外にも、「リッチテキスト」と呼ばれるものを表すための多くの形式があります。そのような多くの表現の興味深い特徴は、それらを解釈するソフトウェアがなくてもある程度読めることです。それらを最高レベルで、判読不能な形式で表された画像、音声、またはテキストなどの判読不能なデータと区別することは有用です。適切な解釈ソフトウェアがない場合、「テキスト」のサブタイプをユーザーに提示することは妥当ですが、ほとんどの非テキストデータでそれを行うことは妥当ではありません。このようなフォーマットされたテキストデータは、「テキスト」のサブタイプを使用して表すことができます。
A top-level type of "image" indicates that the content specifies one or more individual images. The subtype names the specific image format.
最上位タイプの「画像」は、コンテンツが1つ以上の個別の画像を指定していることを示します。サブタイプは特定の画像フォーマットを指定します。
A top-level type of "audio" indicates that the content contains audio data. The subtype names the specific audio format.
最上位タイプの「オーディオ」は、コンテンツにオーディオデータが含まれていることを示します。サブタイプは特定のオーディオ形式を指定します。
A top-level 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 the mixing of multiple kinds of media in a single body is discouraged [RFC2046], it is recognized that many video formats include a representation for synchronized audio and/or text, and this is explicitly permitted for subtypes of "video".
一般的に、単一のボディで複数の種類のメディアを混合することは推奨されませんが[RFC2046]、多くのビデオ形式には同期されたオーディオやテキストの表現が含まれることが認識されており、これは「ビデオのサブタイプに対して明示的に許可されています。 」
The "application" top-level type is to be used for discrete data that do not fit under any of the other type names, 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" type name include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material. (The last, in particular, can pose security problems that must be understood by implementors. The "application/postscript" media type registration in [RFC2046] provides a good example of how to handle these issues.)
「アプリケーション」トップレベルタイプは、他のタイプ名のいずれにも当てはまらない個別のデータ、特にあるタイプのアプリケーションプログラムによって処理されるデータに使用されます。これは、ユーザーが表示または使用する前にアプリケーションで処理する必要がある情報です。 「アプリケーション」タイプ名の予想される用途には、ファイル転送、スプレッドシート、プレゼンテーション、スケジュールデータ、および「アクティブ」（計算）マテリアルの言語が含まれますが、これらに限定されません。 （特に、最後は、実装者が理解する必要があるセキュリティの問題を引き起こす可能性があります。[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" top-level type.
たとえば、会議のスケジュール担当者は、提案された会議の日付に関する情報の標準的な表現を定義できます。インテリジェントなユーザーエージェントは、この情報を使用してユーザーとダイアログを行い、そのダイアログに基づいて追加の資料を送信する場合があります。より一般的には、適切に専門化された言語のプログラムが遠隔地に転送され、受信者の環境で自動的に実行されるいくつかの「アクティブ」言語が開発されました。このようなアプリケーションは、「アプリケーション」トップレベルタイプのサブタイプとして定義できます。
The subtype of "application" will often either be 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 simply be used freely as a subtype of "application"; the subtype needs to be registered.
「アプリケーション」のサブタイプは、多くの場合、名前であるか、データが対象とするアプリケーションの名前の一部を含みます。ただし、これは、アプリケーションプログラム名を単に「アプリケーション」のサブタイプとして自由に使用できることを意味するものではありません。サブタイプを登録する必要があります。
Multipart and message are composite types; that is, they provide a means of encapsulating zero or more objects, each one a separate media type.
マルチパートとメッセージは複合型です。つまり、それらは0個以上のオブジェクトをカプセル化する手段を提供し、それぞれが個別のメディアタイプです。
All subtypes of multipart and message MUST conform to the syntax rules and other requirements specified in [RFC2046] and amended by Section 3.5 of [RFC6532].
マルチパートとメッセージのすべてのサブタイプは、[RFC2046]で指定され、[RFC6532]のセクション3.5で修正された構文規則とその他の要件に準拠する必要があります。
In some cases, a new media type may not "fit" under any currently defined top-level type names. Such cases are expected to be quite rare. However, if such a case does arise, a new type name can be defined to accommodate it. Definition of a new top-level type name MUST be done via a Standards Track RFC; no other mechanism can be used to define additional type names.
場合によっては、新しいメディアタイプは、現在定義されているどのトップレベルタイプ名にも適合しないことがあります。このようなケースは非常にまれであると予想されます。ただし、そのようなケースが発生した場合は、それに対応するために新しいタイプ名を定義できます。新しいトップレベルのタイプ名の定義は、Standards Track RFCを介して行う必要があります。追加の型名を定義するために他のメカニズムを使用することはできません。
XML in MIME [RFC3023] defined the first such augmentation to the media type definition to additionally specify the underlying structure of that media type. To quote:
XML in MIME [RFC3023]は、メディアタイプ定義の最初の拡張を定義して、そのメディアタイプの基礎となる構造をさらに指定しました。引用するには：
This document also standardizes a convention (using the suffix '+xml') for naming media types ... when those media types represent XML MIME (Multipurpose Internet Mail Extensions) entities.
このドキュメントは、メディアタイプの名前付けに関する規則（サフィックス「+ xml」を使用）も標準化します...それらのメディアタイプがXML MIME（多目的インターネットメール拡張）エンティティを表す場合。
That is, it specified a suffix (in that case, "+xml") to be appended to the base subtype name.
つまり、ベースサブタイプ名に追加するサフィックス（この場合は「+ xml」）を指定しました。
Since this was published, the de facto practice has arisen for using this suffix convention for other well-known structuring syntaxes. In particular, media types have been registered with suffixes such as "+der", "+fastinfoset", and "+json". This specification formalizes this practice and sets up a registry for structured type name suffixes.
これが公開されてから、このサフィックスの規則を他のよく知られた構造化構文に使用するという事実上の慣習が生じてきました。特に、メディアタイプは「+ der」、「+ fastinfoset」、「+ json」などのサフィックスで登録されています。この仕様はこの慣習を形式化し、構造化タイプ名のサフィックスのレジストリを設定します。
The primary guideline for whether a structured type name suffix is registrable is that it be described by a readily available description, preferably within a document published by an established standards-related organization, and for which there's a reference that can be used in a Normative References section of an RFC.
構造化タイプ名のサフィックスが登録可能かどうかの主要なガイドラインは、容易に入手できる説明によって、できれば確立された標準関連組織によって発行されたドキュメント内に記述され、規範的な参照で使用できる参照があることです。 RFCのセクション。
Media types that make use of a named structured syntax SHOULD use the appropriate registered "+suffix" for that structured syntax when they are registered. By the same token, media types MUST NOT be given names incorporating suffixes for structured syntaxes they do not actually employ. "+suffix" constructs for as-yet unregistered structured syntaxes SHOULD NOT be used, given the possibility of conflicts with future suffix definitions.
名前付きの構造化構文を利用するメディアタイプは、登録時にその構造化構文に適切な登録済みの「+サフィックス」を使用する必要があります（SHOULD）。同様に、メディアタイプには、実際に使用しない構造化構文のサフィックスを組み込んだ名前を付けてはなりません（MUST NOT）。将来のサフィックス定義と競合する可能性があるため、まだ登録されていない構造化構文の「+ suffix」コンストラクトは使用しないでください。
In some cases, a single media type may have been widely deployed prior to registration under multiple names. In such cases, a preferred name MUST be chosen for the media type, and applications MUST use this to be compliant with the type's registration. However, a list of deprecated aliases by which the type is known MAY be supplied as additional information in order to assist applications in processing the media type properly.
場合によっては、複数の名前で登録する前に、1つのメディアタイプが広く導入されていることがあります。このような場合、メディアタイプの優先名を選択する必要があり、アプリケーションはタイプの登録に準拠するためにこれを使用する必要があります。ただし、アプリケーションがメディアタイプを適切に処理するのを支援するために、タイプがわかっている非推奨のエイリアスのリストを追加情報として提供できます。
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 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.
メディアタイプは、1つ以上のメディアタイプパラメータを使用することを選択してもよいし、一部のパラメータは、そのサブタイプに適用可能なパラメータのセットを定義するコンテンツタイプのサブタイプであることにより、メディアタイプで自動的に利用可能になります。どちらの場合でも、メディアタイプが標準ツリーに登録されている場合は、パラメーターの名前、値、および意味を完全に指定する必要があります。メディアタイプがベンダーツリーまたはパーソナルツリーに登録されている場合は、可能な限り完全に指定する必要があります。
Parameter names have the syntax as media type names and values:
パラメータ名には、メディアタイプの名前と値の構文があります。
parameter-name = restricted-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]で修正された構文よりもいくらか制限的であることに注意してください。
Parameter names are case-insensitive and no meaning is attached to the order in which they appear. It is an error for a specific parameter to be specified more than once.
パラメータ名は大文字と小文字を区別せず、表示される順序に意味はありません。特定のパラメーターを複数回指定するとエラーになります。
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 needs be taken to limit the use of potentially problematic syntaxes; e.g., pure binary valued parameters, while permitted in some protocols, are best avoided.
パラメータ値の定義された構文はありません。したがって、登録ではパラメーター値の構文を指定する必要があります。さらに、一部のトランスポートはパラメーター値の構文に制限を課しているため、問題のある可能性のある構文の使用を制限するように注意する必要があります。たとえば、純粋なバイナリ値のパラメータは、一部のプロトコルでは許可されていますが、回避するのが最善です。
Note that a protocol can impose further restrictions on parameter value syntax, depending on how it chooses to represent parameters. Both MIME [RFC2045] [RFC2231] and HTTP [RFC2045] [RFC5987] allow binary parameters as well as parameter values expressed in a specific charset, but other protocols may be less flexible.
プロトコルは、パラメーターの表現方法の選択に応じて、パラメーター値の構文にさらに制限を課す可能性があることに注意してください。 MIME [RFC2045] [RFC2231]とHTTP [RFC2045] [RFC5987]はどちらも、特定の文字セットで表されたパラメーター値だけでなく、バイナリパラメーターも許可しますが、他のプロトコルは柔軟性が低い場合があります。
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などの外部仕様の改訂レベルを示す「改訂」パラメーターです。同様の動作は、ベンダーまたは個人ツリーに登録されているメディアタイプに対して推奨されますが、必須ではありません。
Changes to parameters (including the introduction of new ones) is managed in the same manner as other changes to the media type; see Section 5.5.
パラメータの変更（新しいパラメータの導入を含む）は、メディアタイプの他の変更と同じ方法で管理されます。セクション5.5を参照してください。
All registered media types MUST employ a single, canonical data format, regardless of registration tree.
登録されているすべてのメディアタイプは、登録ツリーに関係なく、単一の正規データ形式を使用する必要があります。
A permanent and readily available public specification of the format for the media type MUST exist for all types registered in the standards tree. This specification MUST provide sufficient detail so that interoperability between independent implementations using the media type is possible. This specification MUST at a minimum be referenced by, if it is not 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 and personal trees. Such registrations are explicitly permitted to limit the information in the registration to which software and version produce or process such media types. As such, references to or inclusion of format specifications in registrations is encouraged but not required. Note, however, that the public availability of a meaningful specification will often make the difference between simply having a name reserved so that there are no conflicts with other uses and having the potential for other implementations of the media type and useful interoperation with them.
フォーマットおよび処理の詳細の仕様は、ベンダーおよびパーソナルツリーに登録されているメディアタイプについては、公開されている場合と公開されていない場合があります。そのような登録は、ソフトウェアおよびバージョンがそのようなメディアタイプを生成または処理する登録の情報を制限することを明示的に許可されています。そのため、登録にフォーマット仕様を参照または含めることは推奨されますが、必須ではありません。ただし、意味のある仕様が公開されていることで、他の用途との競合が発生しないように名前を予約することと、メディアタイプの他の実装やそれらとの有用な相互運用の可能性とを区別できることがよくあります。
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 BCP 79 [RFC3979] and BCP 78 [RFC5378] 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-related organizations making use of the standards tree may have their own rules regarding intellectual property that must be observed in their registrations.
一部のメディアタイプは、特許技術の使用を伴います。特許技術を含むメディアタイプの登録は特に許可されています。ただし、メディアタイプの仕様がStandards Trackプロトコルの一部である場合は、IETF Standards Trackプロトコルでの特許取得済みテクノロジーの使用に関するBCP 79 [RFC3979]およびBCP 78 [RFC5378]で規定された制限を遵守する必要があります。さらに、標準ツリーを利用している他の標準関連組織は、登録で遵守しなければならない知的財産に関する独自のルールを持っている場合があります。
Intellectual Property Rights (IPR) disclosures for registrations in the vendor and personal trees are encouraged but not required.
ベンダーおよび個人ツリーへの登録に関する知的財産権（IPR）の開示は推奨されますが、必須ではありません。
Ideally, media types will be defined so they 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.
メディアタイプの普遍的な相互運用性は必須ではありませんが、既知の相互運用性の問題は可能な限り特定する必要があります（SHOULD）。メディアタイプの公開は、相互運用性の徹底的なレビューを必要とせず、相互運用性に関する考慮事項のセクションは継続的な評価の対象となります。
The recommendations in this subsection 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, the security considerations MUST NOT state that there are "no security issues associated with this type". Security considerations for types in the vendor or personal tree MAY say that "the security issues associated 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 5.4 below.
すべての登録のセキュリティに関する考慮事項のセクションは、継続的な評価と変更の対象となります。特に、以下のセクション5.4で説明する「メディアタイプに関するコメント」メカニズムを使用することで拡張できます。
Some of the issues that need to be examined and described 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 can be described in a media type registration.
o複雑なメディアタイプには、受信者のファイルまたはその他のリソースに対してアクションを実行するディレクティブの規定が含まれる場合があります。多くの場合、オリジネーターが無制限の方法で任意のアクションを指定できるようになっています。そのようなディレクティブの例と、それらがメディアタイプ登録でどのように記述されるかについては、[RFC2046]のapplication / postscriptメディアタイプの登録を参照してください。
o Any security analysis MUST state whether or not they employ such "active content"; if they do, they MUST state what steps have been taken, or MUST be taken by applications of the media type, 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; 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 don't provide the necessary security mechanisms themselves. For example, a media type could be defined for storage of sensitive medical information that in turn requires external confidentiality and integrity protection services, or which is designed for use only within a secure environment. Types SHOULD always document whether or not they need such services in their security considerations.
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ビットのUS-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 an 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 [RFC4855].
framed：コンテンツは、内部フレーミングまたはアライメントインジケーターのない一連のフレームまたはパケットで構成されます。データを適切に解釈するには、連続するフレーム間の境界の知識やトランスポートメカニズムの知識など、追加の帯域外情報が必要です。この種類のメディアタイプは、単にファイルに格納したり、オクテットの単純なストリームとして転送したりすることはできません。したがって、このようなメディアタイプは、多くの従来のプロトコルでの使用には適していません。フレームエンコーディングで一般的に使用されるトランスポートは、リアルタイムトランスポートプロトコル、RTPです。 RTPを使用したトランスポート用に定義されたフレームエンコーディングの追加ルールは、[RFC4855]で提供されています。
Additional restrictions on 7bit and 8bit text are given in Section 4.1.1 of [RFC2046].
7ビットおよび8ビットのテキストに関する追加の制限は、[RFC2046]のセクション4.1.1に記載されています。
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 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 are 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.
したがって、メディアタイプのユニバーサルサポートと実装は、登録の要件ではありません。ただし、メディアタイプが明示的に制限された使用を目的としている場合は、そのことを登録時に注記する必要があります。 「使用上の制限」フィールドは、この目的のために提供されています。
Media types registered in the standards tree by the IETF itself MUST be published as RFCs. RFC publication of vendor and personal media type registrations is allowed but not required. In all cases, the IANA will retain copies of all media type registrations and "publish" them as part of the media types registration tree itself.
IETF自体によって標準ツリーに登録されたメディアタイプは、RFCとして公開する必要があります。ベンダーおよび個人のメディアタイプ登録のRFC公開は許可されていますが、必須ではありません。すべての場合において、IANAはすべてのメディアタイプ登録のコピーを保持し、メディアタイプ登録ツリー自体の一部として「公開」します。
As stated previously, standards-tree registrations for media types defined in documents produced by other standards-related organizations MUST be described by a formal standards specification produced by that organization. Additionally, any copyright on the registration template MUST allow the IANA to copy it into the IANA registry.
前述のように、他の標準関連組織によって作成されたドキュメントで定義されたメディアタイプの標準ツリー登録は、その組織によって作成された正式な標準仕様によって記述されている必要があります。さらに、登録テンプレートの著作権では、IANAがそれをIANAレジストリにコピーできるようにする必要があります。
Other than IETF registrations in the standards tree, the registration of a media type does not imply endorsement, approval, or recommendation by the IANA or the IETF or even certification that the specification is adequate. To become an IETF standard, a protocol or data object must go through the IETF standards process. While it provides additional assurances when it is appropriate, this is too difficult and too lengthy a process for the convenient registration of media types.
標準ツリーでのIETF登録以外のメディアタイプの登録は、IANAまたはIETFによる承認、承認、推奨、または仕様が適切であることの証明を意味するものではありません。 IETF標準になるには、プロトコルまたはデータオブジェクトがIETF標準プロセスを通過する必要があります。必要に応じて追加の保証が提供されますが、これはメディアタイプを簡単に登録するにはプロセスが難しすぎ、時間がかかりすぎます。
The standards tree exists for media types that do require a substantive review and approval process in a recognized standards-related organization. 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 Action in the IETF and, hence, the publication of a RFC on the Standards Track.
上記で説明したように、最上位タイプの登録には、IETFでの標準アクション、つまり標準トラックでのRFCの公開が必要です。
Media type registrations can specify how applications should interpret fragment identifiers (specified in Section 3.5 of [RFC3986]) associated with the media type.
メディアタイプの登録では、メディアタイプに関連付けられたフラグメント識別子（[RFC3986]のセクション3.5で指定）をアプリケーションが解釈する方法を指定できます。
Media types are encouraged to adopt fragment identifier schemes that are used with semantically similar media types. In particular, media types that use a named structured syntax with a registered "+suffix" MUST follow whatever fragment identifier rules are given in the structured syntax suffix registration.
メディアタイプは、意味的に類似したメディアタイプで使用されるフラグメント識別子スキームを採用することをお勧めします。特に、登録された「+ suffix」で名前付きの構造化構文を使用するメディアタイプは、構造化構文のサフィックス登録で指定されたフラグメント識別子の規則に従う必要があります。
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. Some discussion of Macintosh file type codes and their purpose can be found in [MacOSFileTypes].
o 特定のメディアタイプを含むファイルのラベル付けに使用されるMac OSファイルタイプコード（4オクテット）。 Macintoshファイルタイプコードとその目的についての議論は、[MacOSFileTypes]にあります。
In the case of a registration in the standards tree, this additional information MAY be provided in the formal specification of the media type format. It is suggested that this be done by incorporating the IANA media type registration form into the format 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.
メディアタイプの登録手順は正式な標準プロセスではなく、過度の遅延なしにコミュニティのコメントと健全性チェックを可能にすることを目的とした管理手順です。
Normal IETF processes need to 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 media-types@iana.org list as discussed below.
標準ツリーのすべてのIETF登録について、通常のIETFプロセスに従う必要があります。インターネットドラフトの投稿は最初に必要なステップであり、次に説明するように、media-types @ iana.orgリストに投稿します。
Notice of a potential media type registration in the standards tree SHOULD be sent to the media-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; doing so is entirely OPTIONAL, but is strongly encouraged.
標準ツリーでの潜在的なメディアタイプ登録の通知は、レビューのためにmedia-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 proposal or abandon the registration completely and at any time.
このリストへの公開投稿の目的は、タイプ/サブタイプ名の選択、バージョンと外部プロファイリング情報に関する参照のあいまいさ、および相互運用性またはセキュリティの考慮事項のレビューに関するコメントとフィードバックを求めることです。提出者は、改訂された登録提案を提出するか、いつでも完全に登録を破棄することができます。
Media types registered in the standards tree by the IETF itself MUST be reviewed and approved by the IESG as part of the normal standards process. Standards-tree registrations by recognized standards-related organizations as well as registrations in the vendor and personal trees are submitted directly to the IANA, unless other arrangements were made as part of a liaison agreement. In either case, posting the registration to the media-types@iana.org list for review prior to submission is strongly encouraged.
IETF自体によって標準ツリーに登録されたメディアタイプは、通常の標準プロセスの一部としてIESGによって確認および承認される必要があります。承認された標準関連組織による標準ツリーの登録、およびベンダーと個人ツリーの登録は、連絡協定の一環として他の取り決めが行われていない限り、IANAに直接送信されます。どちらの場合も、提出前に審査のために登録をmedia-types@iana.orgリストに投稿することを強くお勧めします。
Registration requests can be sent to iana@iana.org. A web form for registration requests is also available:
登録リクエストは、iana @ iana.orgに送信できます。登録リクエスト用のWebフォームも利用できます。
http://www.iana.org/form/media-types
Standardization processes often take considerable time to complete. In order to facilitate prototyping and testing, it is often helpful to assign identifiers, including but not limited to media types, early in the process. This way, identifiers used during standards development can remain unchanged once the process is complete, and implementations and documentation do not have to be updated.
標準化プロセスは、完了までにかなりの時間がかかることがよくあります。プロトタイピングとテストを容易にするために、メディアタイプを含むがこれに限定されない識別子をプロセスの早い段階で割り当てると役立つことがよくあります。このように、標準の開発中に使用される識別子は、プロセスが完了しても変更されないままで済み、実装とドキュメントを更新する必要はありません。
Accordingly, a provisional registration process is provided to support early assignment of media type names in the standards tree. A provisional registration MAY be submitted to IANA for standards-tree types. The only required fields in such registrations are the media type name and contact information (including the standards-related organization name).
したがって、標準ツリーでのメディアタイプ名の早期割り当てをサポートするための仮登録プロセスが提供されます。標準ツリータイプの仮登録をIANAに提出できます。このような登録で必要なフィールドは、メディアタイプ名と連絡先情報（規格関連の組織名を含む）だけです。
Upon receipt of a provisional registration, IANA will check the name and contact information, then publish the registration in a distinct publicly visible provisional registration list.
IANAは仮登録を受け取ると、名前と連絡先情報を確認し、公開されている個別の仮登録リストに登録を公開します。
Provisional registrations MAY be updated or abandoned at any time. When the registration is abandoned, the media type is no longer registered in any sense; it can subsequently be registered just like any other unassigned media type name.
仮登録はいつでも更新または中止される場合があります。登録が破棄されると、メディアタイプはいかなる意味でも登録されなくなります。その後、割り当てられていない他のメディアタイプ名と同じように登録できます。
With the exception of provisional standards-tree registrations, 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. Registrations that do not meet these requirements will be returned to the submitter for revision.
暫定的な標準ツリー登録を除いて、IANAに送信された登録はメディアタイプレビューアに渡されます。 IETF Applications Area Director（s）によって任命されたメディアタイプレビューアは、登録をレビューして、このドキュメントに記載されている要件を満たしていることを確認します。これらの要件を満たさない登録は、修正のために提出者に返されます。
Decisions made by the media types reviewer may be appealed to the IESG using the procedure specified in Section 6.5.4 of [RFC2026].
メディアタイプのレビューアが下した決定は、[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はメディアタイプを登録し、コミュニティがメディアタイプの登録を利用できるようにします。
In the case of standards-tree registrations from other standards-related organizations, IANA will also check that the submitter is in fact a recognized standards-related organization. If the submitter is not currently recognized as such, the IESG will be asked to confirm their status. Recognition from the IESG MUST be obtained before a standards-tree registration can proceed.
他の標準関連組織からの標準ツリー登録の場合、IANAは、提出者が実際に認められた標準関連組織であることも確認します。提出者が現在そのように認識されていない場合、IESGはそのステータスを確認するよう求められます。標準ツリーの登録を進める前に、IESGからの承認を得る必要があります。
Comments on registered media types may be submitted by members of the community to the IANA at iana@iana.org. 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; if the IANA, in consultation with the media types reviewer, approves, the comment will be made accessible in conjunction with the type registration.
登録されたメディアタイプに関するコメントは、コミュニティのメンバーがIANAのiana@iana.orgに提出できます。これらのコメントはメディアタイプレビュアーによってレビューされ、可能であればメディアタイプの「所有者」に渡されます。コメントの提出者は、コメントをメディアタイプ登録自体に添付するように要求できます。 IANAがメディアタイプレビューアと協議して承認した場合、タイプ登録とともにコメントにアクセスできるようになります。
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によって公開されると、所有者はその定義の変更を要求できます。上記のさまざまな登録ツリーの説明は、各タイプの登録の「所有者」を示しています。変更リクエストの処理には、元の登録リクエストに適したものと同じ手順が使用されます。
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が発行するリストで明確にマークされます。
Significant changes to a media type's definition 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; this can be done without discussion or review.
メディアタイプの所有者は、IANAに通知することにより、責任を別の人または機関に渡すことができます。これは、ディスカッションやレビューなしで行うことができます。
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は、メディアタイプの責任を再割り当てする場合があります。この最も一般的なケースは、登録の作成者が死亡した、連絡が取れなくなった、またはコミュニティにとって重要な変更を行うことができないタイプに変更を加えることができるようにすることです。
Type name:
タイプ名：
Subtype name:
サブタイプ名：
Required parameters:
必須パラメーター：
Optional parameters:
オプションのパラメーター：
Encoding considerations:
エンコードに関する考慮事項：
Security considerations:
セキュリティに関する考慮事項：
Interoperability considerations:
相互運用性に関する考慮事項：
Published specification:
公開された仕様：
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Fragment identifier considerations:
フラグメント識別子の考慮事項：
Additional information:
追加情報：
Deprecated alias names for this type: 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.)
（共通、限定使用、または廃止のいずれか。）
Restrictions on usage:
使用上の制限：
(Any restrictions on where the media type can be used go here.)
（メディアタイプを使用できる場所に関する制限は、ここにあります。）
Author:
著者：
Change controller:
コントローラを変更：
Provisional registration? (standards tree only):
仮登録？ （標準ツリーのみ）：
(Any other information that the author deems interesting may be added below this line.)
（著者が興味深いと考えるその他の情報は、この行の下に追加できます。）
"N/A", written exactly that way, can be used in any field if desired to emphasize the fact that it does not apply or that the question was not omitted by accident. Do not use 'none' or other words that could be mistaken for a response.
「N / A」は正確にそのように記述されており、適用されない、または質問が誤って省略されなかったという事実を強調するために、必要に応じて任意のフィールドで使用できます。 「なし」または応答と間違われる可能性のある他の単語を使用しないでください。
Limited-use media types should also note in the applications list whether or not that list is exhaustive.
用途が限定されたメディアタイプは、そのリストが網羅的であるかどうかにかかわらず、アプリケーションリストにも記載する必要があります。
Someone wishing to define a "+suffix" name for a structured syntax for use with a new media type registration SHOULD:
新しいメディアタイプの登録で使用するための構造化構文の「+ suffix」名を定義したい人は、SHOULD：
1. Check IANA's registry of media type name suffixes to see whether or not there is already an entry for that well-defined structured syntax.
1. メディアタイプ名サフィックスのIANAのレジストリを確認して、その明確に定義された構造化構文のエントリがすでに存在するかどうかを確認してください。
2. If there is no entry for their suffix scheme, fill out the template (specified in Section 6.2) and include that with the media type registration. The template may be contained in an Internet Draft, alone or as part of some other protocol specification. The template may also be submitted in some other form (as part of another document or as a stand-alone document), but the contents will be treated as an "IETF Contribution" under the guidelines of BCP 78 [RFC5378].
2. サフィックススキームのエントリがない場合は、テンプレートに入力し（セクション6.2で指定）、メディアタイプ登録にそのテンプレートを含めます。テンプレートは、単独で、または他のプロトコル仕様の一部として、インターネットドラフトに含めることができます。テンプレートは他の形式（別のドキュメントの一部として、またはスタンドアロンのドキュメントとして）で提出することもできますが、その内容はBCP 78 [RFC5378]のガイドラインに基づいて「IETF寄稿」として扱われます。
3. Send a copy of the template or a pointer to the containing document (with specific reference to the section with the template) to the mailing list media-types@iana.org, requesting review. This may be combined with a request to review the media type registration. Allow a reasonable time for discussion and comments.
3.テンプレートのコピーまたは含まれているドキュメントへのポインタ（特にテンプレートのセクションを参照）をメーリングリストmedia-types@iana.orgに送信し、レビューを要求します。これは、メディアタイプ登録の確認要求と組み合わせることができます。ディスカッションとコメントのために適切な時間を与えてください。
4. Respond to review comments and make revisions to the proposed registration as needed to bring it into line with the guidelines given in this document.
4. このドキュメントに記載されているガイドラインに沿うようにするために、必要に応じて、レビューコメントに返信し、提案された登録を修正します。
5. Submit the (possibly updated) registration template (or pointer to the document containing it) to IANA at iana@iana.org.
5. （おそらく更新された）登録テンプレート（またはそれを含むドキュメントへのポインター）をiana@iana.orgのIANAに送信します。
Upon receipt of a structured syntax suffix registration request,
構造化構文のサフィックス登録リクエストを受信すると、
1. IANA checks the submission for completeness; if sections are missing or citations are not correct, IANA rejects the registration request.
1. IANAは提出物の完全性をチェックします。セクションが欠落しているか、引用が正しくない場合、IANAは登録要求を拒否します。
2. IANA checks the current registry for an entry with the same name; if such a registry exists, IANA rejects the registration request.
2. IANAは、現在のレジストリで同じ名前のエントリをチェックします。そのようなレジストリが存在する場合、IANAは登録要求を拒否します。
3. IANA requests Expert Review of the registration request against the corresponding guidelines.
3. IANAは、対応するガイドラインに照らして登録要求のエキスパートレビューを要求します。
4. The Designated Expert may request additional review or discussion, as necessary.
4. 指定専門家は、必要に応じて、追加のレビューまたはディスカッションを要求できます。
5. If Expert Review recommends registration, IANA adds the registration to the appropriate registry.
5. Expert Reviewが登録を推奨する場合、IANAは適切なレジストリに登録を追加します。
The initial registry content specification [RFC6839] provides examples of structured syntax suffix registrations.
初期のレジストリコンテンツ仕様[RFC6839]には、構造化構文のサフィックス登録の例が記載されています。
Registrations may be updated in each registry by the same mechanism as required for an initial registration. In cases where the original definition of the scheme is contained in an IESG-approved document, update of the specification also requires IESG approval.
登録は、最初の登録に必要なのと同じメカニズムで各レジストリで更新できます。スキームの元の定義がIESG承認のドキュメントに含まれている場合、仕様の更新にはIESGの承認も必要です。
This template describes the fields that must be supplied in a structured syntax suffix registration request:
このテンプレートでは、構造化構文のサフィックス登録リクエストで提供する必要があるフィールドについて説明しています。
Name Full name of the well-defined structured syntax.
名前明確に定義された構造化構文の完全な名前。
+suffix Suffix used to indicate conformance to the syntax.
+ suffix構文への適合を示すために使用されるサフィックス。
References Include full citations for all specifications necessary to understand the structured syntax.
参照には、構造化された構文を理解するために必要なすべての仕様の完全な引用が含まれています。
Encoding considerations General guidance regarding encoding considerations for any type employing this syntax should be given here. The same requirements for media type encoding considerations given in Section 4.8 apply here.
エンコーディングに関する考慮事項この構文を使用するすべてのタイプのエンコーディングに関する考慮事項に関する一般的なガイダンスをここに示します。セクション4.8で示したメディアタイプエンコーディングの考慮事項と同じ要件がここでも適用されます。
Interoperability considerations Any issues regarding the interoperable use of types employing this structured syntax should be given here. Examples would include the existence of incompatible versions of the syntax, issues combining certain charsets with the syntax, or incompatibilities with other types or protocols.
相互運用性に関する考慮事項この構造化構文を使用する型の相互運用可能な使用に関する問題は、ここに記載する必要があります。例には、構文の互換性のないバージョンの存在、特定の文字セットと構文の組み合わせの問題、または他のタイプやプロトコルとの非互換性が含まれます。
Fragment identifier considerations Generic processing of fragment identifiers for any type employing this syntax should be described here.
フラグメント識別子の考慮事項この構文を使用する任意のタイプのフラグメント識別子の一般的な処理について、ここで説明する必要があります。
Security considerations Security considerations shared by media types employing this structured syntax must be specified here. The same requirements for media type security considerations given in Section 4.6 apply here, with the exception that the option of not assessing the security considerations is not available for suffix registrations.
セキュリティに関する考慮事項この構造化された構文を使用するメディアタイプで共有されるセキュリティに関する考慮事項は、ここで指定する必要があります。セキュリティの考慮事項を評価しないオプションをサフィックスの登録に使用できないことを除いて、セクション4.6で示したメディアタイプのセキュリティの考慮事項と同じ要件がここに適用されます。
Contact Person (including contact information) to contact for further information.
詳細について連絡する連絡先（連絡先情報を含む）。
Author/Change controller. Person (including contact information) authorized to change this suffix registration.
作成者/変更コントローラ。このサフィックスの登録を変更する権限を持つ人（連絡先情報を含む）。
Security requirements for both media type and media type suffix registrations are discussed in Section 4.6.
メディアタイプとメディアタイプのサフィックス登録の両方のセキュリティ要件については、セクション4.6で説明します。
The purpose of this document is to define IANA registries for media types and structured syntax suffixes as well as the procedures for managing these registries. Additionally, this document requires IANA to maintain a list of standards-related organizations for which the IESG has approved media type registrations in the standards tree.
このドキュメントの目的は、メディアタイプと構造化構文のサフィックスのIANAレジストリ、およびこれらのレジストリを管理するための手順を定義することです。さらに、このドキュメントでは、IEANAが標準ツリーでメディアタイプの登録を承認した標準関連組織のリストを維持する必要があります。
The existing media type registry has been extended to include a section for provisional registrations. Only standards-tree registrations are allowed in the standards tree and only at the request of an organization on the IANA list of standards-related organizations. See Section 5.2.1 for additional information on provisional registrations.
既存のメディアタイプレジストリが拡張され、仮登録のセクションが追加されました。標準ツリーでは、標準ツリーの登録のみが許可されており、標準関連組織のIANAリストにある組織の要求に応じてのみ許可されています。仮登録の詳細については、セクション5.2.1を参照してください。
IANA has also added the following note at the top of the provisional registry:
IANAはまた、暫定レジストリの上部に次のメモを追加しました。
This registry, unlike some other provisional IANA registries, is only for temporary use. Entries in this registry are either finalized and moved to the main media types registry, or are abandoned and deleted. Entries in this registry are suitable for use for development and test purposes only.
このレジストリは、他のいくつかの暫定的なIANAレジストリとは異なり、一時的な使用のみを目的としています。このレジストリのエントリは、確定されてメインのメディアタイプレジストリに移動されるか、破棄されて削除されます。このレジストリのエントリは、開発およびテスト目的での使用にのみ適しています。
The structured syntax name suffix registry has been created as follows:
構造化構文名のサフィックスレジストリは、次のように作成されています。
o The name is the "Structured Syntax Suffix" registry.
o 名前は、「構造化構文サフィックス」レジストリです。
o The registration process is specified in Section 6.
o 登録プロセスはセクション6で指定されています。
o The information required for a registry entry as well as the entry format are specified in Section 6.2.
o レジストリエントリに必要な情報とエントリの形式は、セクション6.2で指定されています。
o The initial content of the registry is specified in [RFC6839].
o レジストリの初期内容は[RFC6839]で指定されています。
Entries in both the media type and structured suffix registries will be annotated by IANA with both the original registration date as well as the date of the most recent update to the entry. Registrations made prior to the implementation of this specification may, if necessary, be marked as such, rather than with a specific date.
メディアタイプと構造化されたサフィックスレジストリの両方のエントリには、IANAによって、元の登録日とエントリの最新の更新日の両方で注釈が付けられます。この仕様の実装前に行われた登録には、必要に応じて、特定の日付ではなく、そのようにマークを付けることができます。
Since registration entries can be updated multiple times, IANA will also maintain the history of changes to each registration in such a way that the state of the registration at any given time can be determined.
登録エントリは複数回更新できるため、IANAは各登録の変更履歴も維持し、いつでも登録の状態を判別できるようにします。
Finally, per this document, IANA has created a new email address, media-types@iana.org, for the media type review list, which replaces the ietf-types@iana.org address specified in RFC 4288. ietf-types@iana.org has been retained as an alias.
最後に、このドキュメントに従って、IANAはメディアタイプレビューリスト用に新しい電子メールアドレスmedia-types@iana.orgを作成しました。これは、RFC 4288で指定されているietf-types@iana.orgアドレスに代わるものです。ietf-types @ iana .orgはエイリアスとして保持されています。
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] [RFC4288]. 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] [RFC4288]を形作った故ジョンポステル博士への負債を認めたいと思います。現在のバージョンが彼の同意したものであることを願っていますが、その同意を確認することは不可能であるため、残念ながら共著者として彼の名前を削除しました。
Randy Bush, Francis Dupont, Bjoern Hoehrmann, Barry Leiba, Murray Kucherawy, Alexey Melnikov, S. Moonesamy, Mark Nottingham, Tom Petch, Peter Saint-Andre, and Jeni Tennison provided many helpful review comments and suggestions.
Randy Bush、Francis Dupont、Bjoern Hoehrmann、Barry Leiba、Murray Kucherawy、Alexey Melnikov、S。Moonesamy、Mark Nottingham、Tom Petch、Peter Saint-Andre、Jeni Tennisonは、多くの有益なレビューコメントと提案を提供しました。
[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、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、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、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、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 Registration Procedures」、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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] Bradner、S。、「IETFテクノロジーの知的財産権」、BCP 79、RFC 3979、2005年3月。
[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、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007.
[RFC4855] Casner、S。、「RTPペイロード形式のメディアタイプ登録」、RFC 4855、2007年2月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008.
[RFC5378] Bradner、S。およびJ. Contreras、「IETFトラストに提供する権利の貢献者」、BCP 78、RFC 5378、2008年11月。
[RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[RFC6532] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、2012年2月。
[RFC6657] Melnikov, A. and J. Reschke, "Update to MIME regarding "charset" Parameter Handling in Textual Media Types", RFC 6657, July 2012.
[RFC6657] Melnikov、A。およびJ. Reschke、「テキストメディアタイプの「charset」パラメータ処理に関するMIMEの更新」、RFC 6657、2012年7月。
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, January 2013.
[RFC6839] Hansen、T。およびA. Melnikov、「Additional Media Type Structured Syntax Suffixes」、RFC 6839、2013年1月。
[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：File Type and Creator Codes、and File Formats」、Apple Knowledge Base Article 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、「Multipurpose Internet Mail Extensions（MIME）Part Four：Registration Procedures」、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月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 4288、2005年12月。
[RFC5987] Reschke, J., "Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters", RFC 5987, August 2010.
[RFC5987] Reschke、J。、「ハイパーテキスト転送プロトコル（HTTP）ヘッダーフィールドパラメーターの文字セットと言語エンコード」、RFC 5987、2010年8月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[RFC6648]セントアンドレ、P。、クロッカー、D。、およびM.ノッティンガム、「アプリケーションプロトコルでの「X-」プレフィックスと同様の構成の非推奨」、BCP 178、RFC 6648、2012年6月。
A number of media types with unfaceted subtype names, registered prior to 1996, would, if registered under the guidelines in this document, be given a faceted name and 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年より前に登録された、ファセットされていないサブタイプ名を持つ多くのメディアタイプは、このドキュメントのガイドラインに基づいて登録されている場合、ファセット名が付けられ、ベンダーツリーまたはパーソナルツリーに配置されます。適切なツリーを反映するようにこれらのタイプを再登録することは推奨されますが、必須ではありません。このドキュメントで説明されている所有権と変更管理の原則は、上記のツリーに登録されているかのように、これらのタイプに適用されます。
From time to time there may also be cases where a media type with an unfaceted subtype name has been widely deployed without being registered. (Note that this includes subtype names beginning with the "x-" prefix.) If possible, such a media type SHOULD be reregistered with a proper faceted subtype name, possibly using a deprecated alias to identify the original name (see Section 4.2.9). However, if this is not possible, the type can, subject to approval by both the media types reviewer and the IESG, be registered in the proper tree with its unfaceted name.
ときどき、サブタイプ名のないメディアタイプが登録されずに広く展開されている場合もあります。 （これには、「x-」プレフィックスで始まるサブタイプ名が含まれることに注意してください。）可能であれば、そのようなメディアタイプは、適切なファセットサブタイプ名で再登録する必要があります。 ）。ただし、これが不可能な場合は、メディアタイプレビューアとIESGの両方の承認を条件として、タイプを適切なツリーにその無名の名前で登録できます。
o Suffixes to indicate the use of a particular structured syntax are now fully specified and a suffix registration process has been defined.
o 特定の構造化構文の使用を示すサフィックスが完全に指定され、サフィックス登録プロセスが定義されました。
o Registration of widely deployed unregistered unfaceted type names in the vendor or personal trees is now allowed, subject to approval by the media types reviewer and the IESG.
o メディアタイプレビューアーおよびIESGによる承認を条件として、広く展開されている未登録のファセットのないタイプ名をベンダーまたは個人ツリーに登録できるようになりました。
o The standards-tree registration process has been revised to include Expert Review and generalized to address cases like media types in non-IETF stream documents.
o 標準ツリーの登録プロセスは、エキスパートレビューを含むように改訂され、非IETFストリームドキュメントのメディアタイプのようなケースに対処するために一般化されました。
o A field for fragment identifiers has been added to the registration template and brief directions for specifying fragment identifiers have been added.
o フラグメント識別子のフィールドが登録テンプレートに追加され、フラグメント識別子を指定するための簡単な指示が追加されました。
o The specification requirements for personal-tree registrations have been changed to be the same as those for the vendor tree. The text has been changed to encourage (but not require) specification availability.
o 個人ツリー登録の仕様要件は、ベンダーツリーの仕様要件と同じになるように変更されました。テキストは、仕様の可用性を促進する（ただし必須ではない）ように変更されました。
o The process for defining additional trees has been clarified to state that an IETF Standards Action is required.
o 追加のツリーを定義するプロセスが明確になり、IETF標準アクションが必要であることを述べました。
o Widely deployed types with "x-" names can now be registered as an exception in the vendor tree.
o 「x-」という名前で広く展開されているタイプを、例外としてベンダーツリーに登録できるようになりました。
o The requirements on changes to registrations have been loosened so minor changes are easier to make.
o 登録の変更に関する要件が緩和されたため、軽微な変更が容易になりました。
o The registration process has been completely restructured so that with the exception of IETF-generated types in the standards tree, all requests are processed by IANA and not the IESG.
o 登録プロセスは完全に再構成されたため、標準ツリーでIETFによって生成されたタイプを除き、すべての要求はIESGではなくIANAによって処理されます。
o A provisional registration process has been added for early assignment of types in the standards tree.
o 標準ツリーでタイプを早期に割り当てるための仮登録プロセスが追加されました。
o Many editorial changes have been made throughout the document to make the requirements and processes it describes clearer and easier to follow.
o ドキュメント全体に多くの編集上の変更が加えられ、ドキュメントに記述されている要件とプロセスがより明確でわかりやすくなりました。
o The ability to specify a list of deprecated aliases for a media type has been added.
o メディアタイプの非推奨エイリアスのリストを指定する機能が追加されました。
o Types with names beginning with "x-" are no longer considered to be members of the unregistered "x." tree. As with any unfaceted type, special procedures have been added to allow registration of such types in an appropriate tree.
o 名前が「x-」で始まるタイプは、未登録の「x」のメンバーとは見なされなくなりました。木。ファセットされていないタイプと同様に、適切なツリーにそのようなタイプを登録できるようにする特別な手順が追加されています。
o Changes to a type registered by a third party may now be made by the designated change controller even if that isn't the vendor or organization that created the type. However, the vendor or organization may elect to assert ownership and change controller over the type at any time.
o サードパーティによって登録されたタイプへの変更は、そのタイプを作成したベンダーまたは組織でなくても、指定された変更コントローラによって行われるようになりました。ただし、ベンダーまたは組織は、いつでも所有権を主張し、タイプを介してコントローラーを変更することを選択できます。
o Limited-use media types are now asked to note whether or not the supplied list of applications employing the media type is exhaustive.
o 使用制限付きのメディアタイプは、メディアタイプを使用するアプリケーションの提供されたリストが完全かどうかを確認するように求められます。
o The ABNF for media type names has been further restricted to require that names begin with an alphanumeric character.
o メディアタイプ名のABNFは、名前が英数字で始まる必要があるようにさらに制限されています。
o Mailing list review is no longer required prior to registration of media types. Additionally, the address associated with the media type review mailing list has been changed to media-types@iana.org.
o メディアタイプを登録する前に、メーリングリストを確認する必要がなくなりました。さらに、メディアタイプレビューメーリングリストに関連付けられたアドレスがmedia-types@iana.orgに変更されました。
o The rules for text/* media types have been updated to reflect the changes specified in [RFC6657].
o text / *メディアタイプのルールは、[RFC6657]で指定された変更を反映するように更新されました。
Authors' Addresses
著者のアドレス
Ned Freed Oracle 800 Royal Oaks Monrovia, CA 91016-6347 USA
Ned Freed Oracle 800 Royal Oaks Monrovia、CA 91016-6347 USA
EMail: ned+ietf@mrochek.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
John C. Klensin 1770 Massachusetts Ave、＃322 Cambridge、MA 02140 USA
EMail: john+ietf@jck.com
Tony Hansen AT&T Laboratories 200 Laurel Ave. Middletown, NJ 07748 USA
Tony Hansen AT＆T Laboratories 200 Laurel Ave. Middletown、NJ 07748 USA
EMail: tony+mtsuffix@maillennium.att.com