[要約] RFC 5334は、Oggメディアタイプの定義と使用方法に関する標準化ドキュメントです。このRFCの目的は、Oggコンテナ形式でのメディアデータの交換と相互運用性を向上させることです。
Network Working Group I. Goncalves
Request for Comments: 5334 S. Pfeiffer
Obsoletes: 3534 C. Montgomery
Category: Standards Track Xiph
September 2008
Ogg Media Types
OGGメディアタイプ
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534.
このドキュメントでは、OGGコンテナ形式のメディアタイプの登録と、これらのタイプの実装に関する適合要件について説明します。このドキュメントは、RFC 3534を廃止します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2. Changes Since RFC 3534 . . . . . . . . . . . . . . . . . . 2
3. Conformance and Document Conventions . . . . . . . . . . . 3
4. Deployed Media Types and Compatibility . . . . . . . . . . 3
5. Relation between the Media Types . . . . . . . . . . . . . 5
6. Encoding Considerations . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . 6
8. Interoperability Considerations . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 7
10.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 7
10.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
12. Copying Conditions . . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . . 11
This document describes media types for Ogg, a data encapsulation format defined by the Xiph.Org Foundation for public use. Refer to "Introduction" in [RFC3533] and "Overview" in [Ogg] for background information on this container format.
このドキュメントでは、Xiph.org Foundation for Public使用のためのデータカプセル化形式であるOGGのメディアタイプについて説明しています。このコンテナ形式の背景情報については、[rfc3533]の[rfc3533]の「概要」と[ogg]の「概要」を参照してください。
Binary data contained in Ogg, such as Vorbis and Theora, has historically been interchanged using the application/ogg media type as defined by [RFC3534]. This document obsoletes [RFC3534] and defines three media types for different types of content in Ogg to reflect this usage in the IANA media type registry, to foster interoperability by defining underspecified aspects, and to provide general security considerations.
VorbisやTheoraなどのOGGに含まれるバイナリデータは、[RFC3534]で定義されているアプリケーション/OGGメディアタイプを使用して歴史的に交換されてきました。このドキュメントは、OGGのさまざまな種類のコンテンツの3つのメディアタイプを廃止し[RFC3534]、IANAメディアタイプレジストリでのこの使用を反映し、識別されていない側面を定義することで相互運用性を促進し、一般的なセキュリティに関する考慮事項を提供するために定義します。
The Ogg container format is known to contain [Theora] or [Dirac] video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC] audio, and [CMML] timed text/metadata. As Ogg encapsulates binary data, it is possible to include any other type of video, audio, image, text, or, generally speaking, any time-continuously sampled data.
OGGコンテナ形式には、[Theora]または[DIRAC]ビデオ、[SPEEX]（ナローバンドおよびワイドバンド）スピーチ、[Vorbis]または[FLAC]オーディオ、[CMML]タイミングテキスト/メタデータが含まれていることが知られています。OGGはバイナリデータをカプセル化するため、他のタイプのビデオ、オーディオ、画像、テキスト、または一般的に言えば、時間のかかるサンプリングされたデータを含めることができます。
While raw packets from these data sources may be used directly by transport mechanisms that provide their own framing and packet-separation mechanisms (such as UDP datagrams or RTP), Ogg is a solution for stream based storage (such as files) and transport (such as TCP streams or pipes). The media types defined in this document are needed to correctly identify such content when it is served over HTTP, included in multi-part documents, or used in other places where media types [RFC2045] are used.
これらのデータソースからの生のパケットは、独自のフレーミングおよびパケット分離メカニズム（UDPデータグラムやRTPなど）を提供するトランスポートメカニズムによって直接使用できますが、OGGはストリームベースのストレージ（ファイルなど）およびトランスポートのソリューションです（TCPがストリーミングまたはパイプとして）。このドキュメントで定義されているメディアタイプは、HTTPを介して提供される場合、マルチパートドキュメントに含まれる、またはメディアタイプ[RFC2045]が使用される他の場所で使用される場合に、そのようなコンテンツを正しく識別するために必要です。
o The type "application/ogg" is redefined.
o タイプ「アプリケーション/OGG」が再定義されます。
o The types "video/ogg" and "audio/ogg" are defined.
o タイプ「ビデオ/OGG」と「オーディオ/OGG」が定義されています。
o New file extensions are defined.
o 新しいファイル拡張子が定義されています。
o New Macintosh file type codes are defined.
o 新しいMacintoshファイルタイプコードが定義されています。
o The codecs parameter is defined for optional use.
o コーデックパラメーターは、オプションの使用のために定義されています。
o The Ogg Skeleton extension becomes a recommended addition for content served under the new types.
o OGGスケルトン拡張は、新しいタイプの下で提供されるコンテンツの推奨される追加になります。
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 BCP 14, [RFC2119] and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、[RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。特に明記しない限り、要件はすべての実装に適用されます。
An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types, but conformance is considered individually for each type.
実装は、このドキュメントで定義されているメディアタイプの1つをサポートするソフトウェアモジュールです。ソフトウェアモジュールは複数のメディアタイプをサポートする場合がありますが、各タイプの適合性は個別に考慮されます。
Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant. Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant". All other implementations are "unconditionally compliant".
1つまたは複数の「マスト」要件を満たさない実装は、非準拠と見なされます。すべての「必須」の要件を満たすが、1つ以上の「要件は「要件」が必要である必要がある」と言われる実装は、「条件付きで準拠している」と言われています。他のすべての実装は「無条件に準拠」です。
The application/ogg media type has been used in an ad hoc fashion to label and exchange multimedia content in Ogg containers.
アプリケーション/OGGメディアタイプは、OGGコンテナのマルチメディアコンテンツのラベル付けと交換のために、アドホックな方法で使用されています。
Use of the "application" top-level type for this kind of content is known to be problematic, in particular since it obfuscates video and audio content. This document thus defines the media types,
この種のコンテンツに「アプリケーション」トップレベルのタイプを使用することは、特にビデオとオーディオコンテンツを難読化するため、問題があることが知られています。したがって、このドキュメントはメディアタイプを定義します。
o video/ogg
o ビデオ/ogg
o audio/ogg
o オーディオ/ogg
which are intended for common use and SHOULD be used when dealing with video or audio content, respectively. This document also obsoletes the [RFC3534] definition of application/ogg and marks it for complex data (e.g., multitrack visual, audio, textual, and other time-continuously sampled data), which is not clearly video or audio data and thus not suited for either the video/ogg or audio/ogg types. Refer to the following section for more details.
一般的な使用を目的としており、それぞれビデオまたはオーディオコンテンツを扱うときに使用する必要があります。このドキュメントはまた、アプリケーション/OGGの[RFC3534]定義を廃止し、複雑なデータ（たとえば、マルチラックビジュアル、オーディオ、テキスト、およびその他の時期型のサンプリングされたデータ）に対してそれをマークします。ビデオ/OGGまたはオーディオ/OGGタイプのいずれか。詳細については、次のセクションを参照してください。
An Ogg bitstream generally consists of one or more logical bitstreams that each consist of a series of header and data pages packetising time-continuous binary data [RFC3533]. The content types of the logical bitstreams may be identified without decoding the header pages of the logical bitstreams through use of a [Skeleton] bitstream. Using Ogg Skeleton is REQUIRED for content served under the application/ogg type and RECOMMENDED for video/ogg and audio/ogg, as Skeleton contains identifiers to describe the different encapsulated data.
OGGビットストリームは、一般に、それぞれが時間を連続したバイナリデータをパケット化する一連のヘッダーとデータページで構成される1つ以上の論理的なビットストリームで構成されています[RFC3533]。[スケルトン]ビットストリームを使用して、論理ビットストリームのヘッダーページをデコードせずに、論理ビットストリームのコンテンツタイプを識別できます。Skeletonにはさまざまなカプセル化されたデータを説明する識別子が含まれているため、アプリケーション/OGGタイプの下で提供され、ビデオ/OGGおよびオーディオ/OGGに推奨されるコンテンツにはOGGスケルトンを使用する必要があります。
Furthermore, it is RECOMMENDED that implementations that identify a logical bitstream that they cannot decode SHOULD ignore it, while continuing to decode the ones they can. Such precaution ensures backward and forward compatibility with existing and future data.
さらに、デコードできない論理的なビットストリームを識別する実装は、できる限りデコードし続けながら無視することをお勧めします。このような予防措置により、既存および将来のデータとの前後の互換性が保証されます。
These media types can optionally use the "codecs" parameter described in [RFC4281]. Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page, hence a machine-readable method to identify the encapsulated codecs would be through this header. The following table illustrates how those header values map into strings that are used in the "codecs" parameter when dealing with Ogg media types.
これらのメディアタイプは、[RFC4281]で説明されている「コーデック」パラメーターをオプションで使用できます。OGGにカプセル化されたコーデックは、最初のヘッダーページの先頭にテキスト識別子が必要であるため、カプセル化されたコーデックを識別するための機械読み取り可能な方法は、このヘッダーを介して行われます。次の表は、これらのヘッダー値がOGGメディアタイプを扱うときに「コーデック」パラメーターで使用される文字列にどのようにマッピングされるかを示しています。
Codec Identifier | Codecs Parameter
-----------------------------------------------------------
char[5]: 'BBCD\0' | dirac
char[5]: '\177FLAC' | flac
char[7]: '\x80theora' | theora
char[7]: '\x01vorbis' | vorbis
char[8]: 'CELT ' | celt
char[8]: 'CMML\0\0\0\0' | cmml
char[8]: '\213JNG\r\n\032\n' | jng
char[8]: '\x80kate\0\0\0' | kate
char[8]: 'OggMIDI\0' | midi
char[8]: '\212MNG\r\n\032\n' | mng
char[8]: 'PCM ' | pcm
char[8]: '\211PNG\r\n\032\n' | png
char[8]: 'Speex ' | speex
char[8]: 'YUV4MPEG' | yuv4mpeg
An up-to-date version of this table is kept at Xiph.org (see [Codecs]).
このテーブルの最新バージョンはxiph.orgに保持されます（[コーデック]を参照）。
Possible examples include:
考えられる例は次のとおりです。
o application/ogg; codecs="theora, cmml, ecmascript"
o アプリケーション/ogg;codecs = "theora、cmml、ecmascript"
o video/ogg; codecs="theora, vorbis"
o ビデオ/ogg;Codecs = "Theora、Vorbis"
o audio/ogg; codecs=speex
o オーディオ/ogg;Codecs = speex
As stated in the previous section, this document describes three media types that are targeted at different data encapsulated in Ogg. Since Ogg is capable of encapsulating any kind of data, the multiple usage scenarios have revealed interoperability issues between implementations when dealing with content served solely under the application/ogg type.
前のセクションで述べたように、このドキュメントでは、OGGにカプセル化された異なるデータをターゲットにした3つのメディアタイプについて説明します。OGGはあらゆる種類のデータをカプセル化できるため、複数の使用法シナリオは、アプリケーション/OGGタイプのみで提供されるコンテンツを扱う際に、実装間の相互運用性の問題を明らかにしました。
While this document does redefine the earlier definition of application/ogg, this media type will continue to embrace the widest net possible of content with the video/ogg and audio/ogg types being smaller subsets of it. However, the video/ogg and audio/ogg types take precedence in a subset of the usages, specifically when serving multimedia content that is not complex enough to warrant the use of application/ogg. Following this line of thought, the audio/ogg type is an even smaller subset within video/ogg, as it is not intended to refer to visual content.
このドキュメントでは、アプリケーション/OGGの以前の定義を再定義しますが、このメディアタイプは、ビデオ/OGGおよびオーディオ/OGGタイプがその小さなサブセットであるコンテンツの最も広いネットを引き続き受け入れます。ただし、特にアプリケーション/OGGの使用を保証するほど複雑ではないマルチメディアコンテンツを提供する場合、ビデオ/OGGおよびオーディオ/OGGタイプは、使用のサブセットで優先されます。この考え方に続いて、オーディオ/OGGタイプは、視覚コンテンツを参照することを意図していないため、ビデオ/OGG内のさらに小さなサブセットです。
As such, the application/ogg type is the recommended choice to serve content aimed at scientific and other applications that require various multiplexed signals or streams of continuous data, with or without scriptable control of content. For bitstreams containing visual, timed text, and any other type of material that requires a visual interface, but that is not complex enough to warrant serving under application/ogg, the video/ogg type is recommended. In situations where the Ogg bitstream predominantly contains audio data (lyrics, metadata, or cover art notwithstanding), it is recommended to use the audio/ogg type.
そのため、アプリケーション/OGGタイプは、コンテンツのスクリプト可能な制御の有無にかかわらず、科学的およびその他のアプリケーションを対象としたコンテンツやその他のアプリケーションを対象としたコンテンツを提供するための推奨選択です。視覚的でタイミングのあるテキスト、および視覚的なインターフェイスを必要とするその他の種類の素材を含むビットストリームの場合、それはアプリケーション/OGGの下でサービスを提供するのに十分なほど複雑ではありません。ビデオ/OGGタイプが推奨されます。OGGビットストリームに主にオーディオデータ（歌詞、メタデータ、またはカバーアート）が含まれている状況では、オーディオ/OGGタイプを使用することをお勧めします。
Binary: The content consists of an unrestricted sequence of octets.
バイナリ：コンテンツは、無制限のオクテットのシーケンスで構成されています。
Note:
ノート：
o Ogg encapsulated content is binary data and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping, etc.; base64 [RFC4648] is generally preferred for binary-to-text encoding.
o OGGカプセル化されたコンテンツはバイナリデータであり、CR/LF変換、7ビットストリッピングなどなしで適切なエンコードで送信する必要があります。Base64 [RFC4648]は、一般的にバイナリ間エンコードに好まれます。
o Media types described in this document are used for stream based storage (such as files) and transport (such as TCP streams or pipes); separate types are used to identify codecs such as in real-time applications for the RTP payload formats of Theora [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well as for identification of encapsulated data within Ogg through Skeleton.
o このドキュメントで説明されているメディアタイプは、ストリームベースのストレージ（ファイルなど）やトランスポート（TCPストリームやパイプなど）に使用されます。個別のタイプは、Theora [THRTP]ビデオ、Vorbis [RFC5215]、またはSPEEX [SPRTP]オーディオのRTPペイロード形式のリアルタイムアプリケーションなどのコーデックを識別するために使用されます。。
Refer to [RFC3552] for a discussion of terminology used in this section.
このセクションで使用されている用語の議論については、[RFC3552]を参照してください。
The Ogg encapsulation format is a container and only a carrier of content (such as audio, video, and displayable text data) with a very rigid definition. This format in itself is not more vulnerable than any other content framing mechanism.
OGGカプセル化形式はコンテナであり、非常に厳格な定義を備えたコンテンツ（オーディオ、ビデオ、表示可能なテキストデータなど）のみのキャリアです。この形式自体は、他のコンテンツフレーミングメカニズムよりも脆弱ではありません。
Ogg does not provide for any generic encryption or signing of itself or its contained bitstreams. However, it encapsulates any kind of binary content and is thus able to contain encrypted and signed content data. It is also possible to add an external security mechanism that encrypts or signs an Ogg bitstream and thus provides content confidentiality and authenticity.
OGGは、それ自体またはその含まれたビットストリームの一般的な暗号化または署名を提供していません。ただし、あらゆる種類のバイナリコンテンツをカプセル化するため、暗号化および署名されたコンテンツデータを含めることができます。また、OGGビットストリームを暗号化または署名してコンテンツの機密性と信頼性を提供する外部セキュリティメカニズムを追加することも可能です。
As Ogg encapsulates binary data, it is possible to include executable content in an Ogg bitstream. Implementations SHOULD NOT execute such content without prior validation of its origin by the end-user.
OGGはバイナリデータをカプセル化するため、実行可能なコンテンツをOGGビットストリームに含めることができます。実装は、エンドユーザーによる起源を事前に検証することなく、そのようなコンテンツを実行しないでください。
Issues may arise on applications that use Ogg for streaming or file transfer in a networking scenario. In such cases, implementations decoding Ogg and its encapsulated bitstreams have to ensure correct handling of manipulated bitstreams, of buffer overflows, and similar issues.
Networkingシナリオでのストリーミングまたはファイル転送にOGGを使用するアプリケーションで問題が発生する場合があります。そのような場合、OGGとそのカプセル化されたビットストリームを解読する実装は、操作されたビットストリーム、バッファーオーバーフロー、および同様の問題の正しい取り扱いを確保する必要があります。
It is also possible to author malicious Ogg bitstreams, which attempt to call for an excessively large picture size, high sampling-rate audio, etc. Implementations SHOULD protect themselves against this kind of attack.
また、非常に大きな画像サイズ、高いサンプリングレートのオーディオなどを求めようとする悪意のあるOGGビットストリームを承認することも可能です。実装は、この種の攻撃から身を守る必要があります。
Ogg has an extensible structure, so that it is theoretically possible that metadata fields or media formats might be defined in the future which might be used to induce particular actions on the part of the recipient, thus presenting additional security risks. However, this type of capability is currently not supported in the referenced specification.
OGGには拡張可能な構造があるため、理論的にはメタデータフィールドまたはメディア形式が将来定義される可能性があり、受信者側の特定のアクションを誘導するために使用される可能性があり、したがって追加のセキュリティリスクを提示します。ただし、このタイプの機能は現在、参照される仕様ではサポートされていません。
Implementations may fail to implement a specific security model or other means to prevent possibly dangerous operations. Such failure might possibly be exploited to gain unauthorized access to a system or sensitive information; such failure constitutes an unknown factor and is thus considered out of the scope of this document.
実装は、おそらく危険な操作を防ぐための特定のセキュリティモデルまたはその他の手段を実装できない場合があります。このような障害は、システムまたは機密情報への不正アクセスを得るために悪用される可能性があります。このような障害は未知の要因を構成するため、このドキュメントの範囲外であると見なされます。
The Ogg container format is device-, platform-, and vendor-neutral and has proved to be widely implementable across different computing platforms through a wide range of encoders and decoders. A broadly portable reference implementation [libogg] is available under the revised (3-clause) BSD license, which is a Free Software license.
OGGコンテナ形式は、デバイス、プラットフォーム、およびベンダーの中立であり、幅広いエンコーダーとデコーダーを通じてさまざまなコンピューティングプラットフォームで広く実装できることが証明されています。広くポータブルな参照実装[libogg]は、フリーソフトウェアライセンスである改訂（3節）BSDライセンスの下で入手できます。
The Xiph.Org Foundation has defined the specification, interoperability, and conformance and conducts regular interoperability testing.
Xiph.org Foundationは、仕様、相互運用性、適合性を定義し、定期的な相互運用性テストを実施しています。
The use of the Ogg Skeleton extension has been confirmed to not cause interoperability issues with existing implementations. Third parties are, however, welcome to conduct their own testing.
OGGスケルトン拡張の使用は、既存の実装で相互運用性の問題を引き起こさないことが確認されています。ただし、第三者は独自のテストを実施することを歓迎します。
In accordance with the procedures set forth in [RFC4288], this document registers two new media types and redefines the existing application/ogg as defined in the following section.
[RFC4288]に記載されている手順に従って、このドキュメントは2つの新しいメディアタイプを登録し、次のセクションで定義されている既存のアプリケーション/OGGを再定義します。
Type name: application
タイプ名：アプリケーション
Subtype name: ogg
サブタイプ名：ogg
Required parameters: none
必要なパラメーター：なし
Optional parameters: codecs, whose syntax is defined in RFC 4281. See section 4 of RFC 5334 for a list of allowed values.
オプションのパラメーター：構文がRFC 4281で定義されているコーデック。許容値のリストについては、RFC 5334のセクション4を参照してください。
Encoding considerations: See section 6 of RFC 5334.
考慮事項のエンコード：RFC 5334のセクション6を参照してください。
Security considerations: See section 7 of RFC 5334.
セキュリティ上の考慮事項：RFC 5334のセクション7を参照してください。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
相互運用性の考慮事項：なし、RFC 5334のセクション8に記載されているように。
Published specification: RFC 3533
公開された仕様：RFC 3533
Applications which use this media type: Scientific and otherwise that require various multiplexed signals or streams of data, with or without scriptable control of content.
このメディアタイプを使用するアプリケーション：科学的およびその他の方法では、コンテンツのスクリプト可能な制御の有無にかかわらず、さまざまな多重化された信号またはデータのストリームを必要とします。
Additional information:
追加情報：
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string "OggS".
マジック番号：最初の4バイト、0x4f 0x67 0x67 0x53、文字列「oggs」に対応します。
File extension(s): .ogx
ファイル拡張子：.ogx
RFC 3534 defined the file extension .ogg for application/ogg, which RFC 5334 obsoletes in favor of .ogx due to concerns where, historically, some implementations expect .ogg files to be solely Vorbis-encoded audio.
RFC 3534は、アプリケーション/OGGのファイル拡張子.oggを定義しました。これは、歴史的にいくつかの実装が.oggファイルがVorbisエンコードオーディオのみであると予想している懸念のために.ogxを支持するRFC 5334廃止を支持します。
Macintosh File Type Code(s): OggX
Macintoshファイルタイプコード：OGGX
Person & Email address to contact for further information: See "Authors' Addresses" section.
詳細については、連絡先への個人およびメールアドレス：「著者のアドレス」セクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: The type application/ogg SHOULD only be used in situations where it is not appropriate to serve data under the video/ogg or audio/ogg types. Data served under the application/ogg type SHOULD use the .ogx file extension and MUST contain an Ogg Skeleton logical bitstream to identify all other contained logical bitstreams.
使用に関する制限：タイプアプリケーション/OGGは、ビデオ/OGGまたはオーディオ/OGGタイプの下でデータを提供することが適切でない状況でのみ使用する必要があります。アプリケーション/OGGタイプで提供されるデータは、.OGXファイル拡張子を使用し、OGGスケルトンの論理ビットストリームを含めて、他のすべての含まれる論理ビットストリームを識別する必要があります。
Author: See "Authors' Addresses" section.
著者：「著者のアドレス」セクションを参照してください。
Change controller: The Xiph.Org Foundation.
Change Controller：Xiph.org Foundation。
Type name: video
タイプ名：ビデオ
Subtype name: ogg
サブタイプ名：ogg
Required parameters: none
必要なパラメーター：なし
Optional parameters: codecs, whose syntax is defined in RFC 4281. See section 4 of RFC 5334 for a list of allowed values.
オプションのパラメーター：構文がRFC 4281で定義されているコーデック。許容値のリストについては、RFC 5334のセクション4を参照してください。
Encoding considerations: See section 6 of RFC 5334.
考慮事項のエンコード：RFC 5334のセクション6を参照してください。
Security considerations: See section 7 of RFC 5334.
セキュリティ上の考慮事項：RFC 5334のセクション7を参照してください。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
相互運用性の考慮事項：なし、RFC 5334のセクション8に記載されているように。
Published specification: RFC 3533
公開された仕様：RFC 3533
Applications which use this media type: Multimedia applications, including embedded, streaming, and conferencing tools.
このメディアタイプを使用するアプリケーション：組み込み、ストリーミング、および会議ツールを含むマルチメディアアプリケーション。
Additional information:
追加情報：
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string "OggS".
マジック番号：最初の4バイト、0x4f 0x67 0x67 0x53、文字列「oggs」に対応します。
File extension(s): .ogv
ファイル拡張子：.ogv
Macintosh File Type Code(s): OggV
Macintoshファイルタイプコード：oggv
Person & Email address to contact for further information: See "Authors' Addresses" section.
詳細については、連絡先への個人およびメールアドレス：「著者のアドレス」セクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg bitstreams containing visual, audio, timed text, or any other type of material that requires a visual interface. It is intended for content not complex enough to warrant serving under "application/ ogg"; for example, a combination of Theora video, Vorbis audio, Skeleton metadata, and CMML captioning. Data served under the type "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream. Implementations interacting with the type "video/ogg" SHOULD support multiplexed bitstreams.
使用法の制限：視覚、オーディオ、タイミングテキスト、または視覚インターフェイスを必要とするその他のタイプの素材を含むOGGビットストリームには、タイプ「ビデオ/OGG」を使用する必要があります。「Application/ OGG」の下でサービスを提供するのに十分なほど複雑ではないコンテンツを目的としています。たとえば、Theoraビデオ、Vorbisオーディオ、Skeletonメタデータ、CMMLキャプションの組み合わせ。タイプ「ビデオ/OGG」で提供されるデータには、OGGスケルトンの論理的なビットストリームが含まれている必要があります。タイプ「ビデオ/OGG」と対話する実装は、多重化されたビットストリームをサポートする必要があります。
Author: See "Authors' Addresses" section.
著者：「著者のアドレス」セクションを参照してください。
Change controller: The Xiph.Org Foundation.
Change Controller：Xiph.org Foundation。
Type name: audio
タイプ名：オーディオ
Subtype name: ogg
サブタイプ名：ogg
Required parameters: none
必要なパラメーター：なし
Optional parameters: codecs, whose syntax is defined in RFC 4281. See section 4 of RFC 5334 for a list of allowed values.
オプションのパラメーター：構文がRFC 4281で定義されているコーデック。許容値のリストについては、RFC 5334のセクション4を参照してください。
Encoding considerations: See section 6 of RFC 5334.
考慮事項のエンコード：RFC 5334のセクション6を参照してください。
Security considerations: See section 7 of RFC 5334.
セキュリティ上の考慮事項：RFC 5334のセクション7を参照してください。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
相互運用性の考慮事項：なし、RFC 5334のセクション8に記載されているように。
Published specification: RFC 3533
公開された仕様：RFC 3533
Applications which use this media type: Multimedia applications, including embedded, streaming, and conferencing tools.
このメディアタイプを使用するアプリケーション：組み込み、ストリーミング、および会議ツールを含むマルチメディアアプリケーション。
Additional information:
追加情報：
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string "OggS".
マジック番号：最初の4バイト、0x4f 0x67 0x67 0x53、文字列「oggs」に対応します。
File extension(s): .oga, .ogg, .spx
ファイル拡張子：.oga、.ogg、.spx
Macintosh File Type Code(s): OggA
Macintoshファイルタイプコード：ogga
Person & Email address to contact for further information: See "Authors' Addresses" section.
詳細については、連絡先への個人およびメールアドレス：「著者のアドレス」セクションを参照してください。
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: The type "audio/ogg" SHOULD be used when the Ogg bitstream predominantly contains audio data. Content served under the "audio/ogg" type SHOULD have an Ogg Skeleton logical bitstream when using the default .oga file extension. The .ogg and .spx file extensions indicate a specialization that requires no Skeleton due to backward compatibility concerns with existing implementations. In particular, .ogg is used for Ogg files that contain only a Vorbis bitstream, while .spx is used for Ogg files that contain only a Speex bitstream.
使用に関する制限：OGG BitStreamに主にオーディオデータが含まれている場合、タイプ「Audio/OGG」を使用する必要があります。「Audio/OGG」タイプで提供されるコンテンツには、デフォルトの.ogaファイル拡張子を使用する場合、OGGスケルトンの論理的なビットストリームが必要です。.oggおよび.spxファイル拡張機能は、既存の実装との逆方向の互換性の懸念のためにスケルトンを必要としない専門化を示します。特に、.oggはVorbis BitStreamのみを含むOGGファイルに使用され、.spxはSpeexビットストリームのみを含むOGGファイルに使用されます。
Author: See "Authors' Addresses" section.
著者：「著者のアドレス」セクションを参照してください。
Change controller: The Xiph.Org Foundation.
Change Controller：Xiph.org Foundation。
The authors gratefully acknowledge the contributions of Magnus Westerlund, Alfred Hoenes, and Peter Saint-Andre.
著者は、マグナス・ウェスターランド、アルフレッド・ホーネス、ピーター・サン・アンドレの貢献に感謝しています。
The authors agree to grant third parties the irrevocable right to copy, use and distribute the work, with or without modification, in any medium, without royalty, provided that, unless separate permission is granted, redistributed modified works do not contain misleading author, version, name of work, or endorsement information.
著者は、別々の許可が付与されていない限り、再配布された修正作業には誤解を招く著者、バージョンを含むことなく、どの程度でも、修正の有無にかかわらず、修正の有無にかかわらず、修正の有無にかかわらず、修正の有無にかかわらず、作業をコピー、使用、および配布するための取消不能の権利を第三者に付与することに同意します。、仕事の名前、または承認情報。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[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月。
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, May 2003.
[RFC3533] Pfeiffer、S。、「OGGカプセル化形式バージョン0」、RFC 3533、2003年5月。
[RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs Parameter for "Bucket" Media Types", RFC 4281, November 2005.
[RFC4281] Gellens、R.、Singer、D。、およびP. Frojdh、「「バケット」メディアタイプのコーデックパラメーター」、RFC 4281、2005年11月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous Media Markup Language (CMML)", Work in Progress, March 2006.
[CMML] Pfeiffer、S.、Parker、C。、およびA. Pang、「連続メディアマークアップ言語（CMML）」、2006年3月、進行中の作業。
[Codecs] Pfeiffer, S. and I. Goncalves, "Specification of MIME types and respective codecs parameter", July 2008, <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
[Codecs] Pfeiffer、S。およびI. Goncalves、「MIMEタイプとそれぞれのコーデックパラメーターの仕様」、2008年7月、<http://wiki.xiph.org/index.php/mimeTypescodecs>。
[Dirac] Dirac Group, "Dirac Specification", <http://diracvideo.org/specifications/>.
[dirac] diracグループ、「dirac仕様」、<http://diracvideo.org/specifications/>。
[FLAC] Coalson, J., "The FLAC Format", <http://flac.sourceforge.net/format.html>.
[FLAC] Coalson、J。、「FLAC形式」、<http://flac.sourceforge.net/format.html>。
[libogg] Xiph.Org Foundation, "The libogg API", June 2000, <http://xiph.org/ogg/doc/libogg>.
[libogg] xiph.org財団、「libogg api」、2000年6月、<http://xiph.org/doc/libogg>。
[Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg logical and physical bitstream overview, Ogg logical bitstream framing, Ogg multi-stream multiplexing", <http://xiph.org/ogg/doc>.
[OGG] Xiph.org Foundation、「OGG BitStream Documentation：OGG Logical and Physical BitStreamの概要、OGG Logical BitStream Framing、OGG Multi-Stream Multiplexing "、<http://xiph.org/ogg/doc>。
[RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534, May 2003.
[RFC3534] Walleij、L。、「アプリケーション/OGGメディアタイプ」、RFC 3534、2003年5月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded Audio", RFC 5215, August 2008.
[RFC5215] Barbato、L。、「Vorbis Encoded AudioのRTPペイロード形式」、RFC 5215、2008年8月。
[Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata Bitstream", November 2007, <http://xiph.org/ogg/doc/skeleton.html>.
[Skeleton] Pfeiffer、S。およびC. Parker、「The Ogg Skeleton Metadata Bitstream」、2007年11月、<http://xiph.org/ogg/doc/skeleton.html>。
[Speex] Valin, J., "The Speex Codec Manual", February 2002, <http://speex.org/docs/manual/speex-manual>.
[Speex] Valin、J。、「The Speex Codec Manual」、2002年2月、<http://speex.org/docs/manual/spex-manual>。
[SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard, "RTP Payload Format for the Speex Codec", Work in Progress, February 2008.
[SPRTP] Herlein、G.、Valin、J.、Heggestad、A。、およびA. Moizard、「SPEEX CodecのRTPペイロード形式」、2008年2月、Work in Progress。
[Theora] Xiph.Org Foundation, "Theora Specification", October 2007, <http://theora.org/doc/Theora.pdf>.
[Theora] Xiph.org Foundation、「Theora仕様」、2007年10月、<http://theora.org/doc/theora.pdf>。
[ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded Video", Work in Progress, June 2006.
[THRTP] Barbato、L。、「TheoraエンコードビデオのRTPペイロード形式」、2006年6月の作業。
[Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004, <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
[Vorbis] Xiph.org Foundation、「Vorbis I Specification」、2004年7月、<http://xiph.org/vorbis/doc/vorbis_i_spec.html>。
Authors' Addresses
著者のアドレス
Ivo Emanuel Goncalves Xiph.Org Foundation 21 College Hill Road Somerville, MA 02144 US
Ivo Emanuel Goncalves Xiph.org Foundation 21 College Hill Road Somerville、MA 02144 US
EMail: justivo@gmail.com
URI: xmpp:justivo@gmail.com
Silvia Pfeiffer Xiph.Org Foundation
Silvia Pfeiffer Xiph.org Foundation
EMail: silvia@annodex.net
URI: http://annodex.net/
Christopher Montgomery Xiph.Org Foundation
クリストファー・モンゴメリーXiph.org Foundation
EMail: monty@xiph.org
URI: http://xiph.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。