Network Working Group I. Goncalves
Request for Comments: 5334 S. Pfeiffer
Obsoletes: 3534 C. Montgomery
Category: Standards Track Xiph
September 2008
Ogg Media Types
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.
この文書では、これらのタイプの実装のためのオッグコンテナフォーマットとの適合性要件については、メディアタイプの登録について説明します。この文書は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.
この文書では、OGG、公共の使用のためのXiph.Org財団によって定義されたデータのカプセル化フォーマットのためのメディアタイプを示します。 「はじめに」[RFC3533]このコンテナフォーマットの背景情報について[オッグ]で「概要」を参照してください。
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.
[RFC3534]で定義されるようなVorbisのとTheoraのようオッグに含まれるバイナリデータは、歴史的にアプリケーション/ oggのメディアタイプを使用して交換されています。この文書では、[RFC3534]を廃止し、不足の側面を定義することによって、相互運用性を促進するため、および一般的なセキュリティ上の考慮事項を提供するために、IANAメディアタイプレジストリでこの使用を反映するためにはOgg内のコンテンツの種類ごとに3つのメディアタイプを定義します。
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.
オッグコンテナフォーマットは、[Theoraの]または[ディラック]ビデオ、[Speexの（狭帯域及び広帯域）音声、[Vorbisの]または[FLAC]オーディオ、および[CMML]時限テキスト/メタデータを含むことが知られています。オッグは、バイナリデータをカプセル化するように、ビデオ、オーディオ、画像、テキスト、または、一般的に言えば、いつでも連続的にサンプリングされたデータの任意の他のタイプを含むことが可能です。
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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
実装は、この文書で定義されたメディアタイプのいずれかをサポートするソフトウェアモジュールです。ソフトウェア・モジュールは、複数のメディアタイプをサポートするかもしれないが、適合は種類ごとに個別に考えられています。
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".
一つ以上を満たすことができない実装は、要件は非準拠とみなされ、「しなければなりません」。すべて満たす「MUST」要件が、1つ以上の「SHOULD」の要件を満たさない実装は、「条件付きで対応」であると言われています。他のすべての実装は、「無条件に対応」しています。
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 audio/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.
オッグビットストリームは、一般に、それぞれが時間的に連続のバイナリデータ[RFC3533]をpacketisingヘッダとデータページの系列から成る一つ以上の論理ビットストリームから成ります。論理ビットストリームのコンテンツタイプは、[スケルトン]ビットストリームの使用を介して論理ビットストリームのヘッダページを復号化せずに識別することができます。スケルトンは、識別子が含まれているとして、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]に記載された「コーデック」パラメータを使用することができます。オッグにカプセル化されたコーデックが、従って最初のヘッダページの先頭にテキスト識別子、カプセル化されたコーデックは、このヘッダを介してであろう識別するために機械読み取り可能な方法を必要とします。次の表は、これらのヘッダ値がオッグメディアタイプを扱うときに「コーデック」パラメータで使用されている文字列にマッピングする方法を示しています。
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。コーデック= "Theoraの、CMML、ECMAScriptの"
o video/ogg; codecs="theora, vorbis"
ビデオ/ OGG O;コーデック= "Theoraの、Vorbisの"
o audio/ogg; codecs=speex
Oオーディオ/ OGG。コーデック=スピード
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.
前節で述べたように、本書はオッグにカプセル化されたさまざまなデータを対象としている3つのメディアタイプについて説明します。オッグは、あらゆる種類のデータをカプセル化することができるので、コンテンツを扱うことはアプリケーション/ 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のタイプを使用することをお勧めします。
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オッグは、カプセル化されたコンテンツは、バイナリデータであり、7ビットなど、ストリッピングCR / LF変換せずに適切なエンコーディングで送信されるべきです; 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 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.
オッグは、バイナリデータをカプセル化するように、オッグビットストリーム内の実行可能なコンテンツを含むことが可能です。実装は、エンドユーザがその起源の事前検証なしに、このようなコンテンツを実行すべきではありません。
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.
問題は、ネットワーキングのシナリオでストリーミングやファイル転送のための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.
メタデータフィールドまたはメディアフォーマットは、このように、追加のセキュリティリスクを提示し、受信者の一部に特定のアクションを誘導するために使用されるかもしれない将来に定義されるかもしれないことを理論的に可能であるようにオッグは、拡張可能な構造を有しています。しかし、機能のこのタイプは、現在参照仕様でサポートされていません。
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.
オッグコンテナフォーマットは、デバイスに、プラットフォーム、およびベンダー中立であり、エンコーダおよびデコーダの広い範囲にわたって異なるコンピューティングプラットフォーム間で広く実施可能であることが判明しました。広くポータブルリファレンス実装では、[libogg]フリーソフトウェアライセンスで改訂された（3節）BSDライセンスの下で提供されています。
The Xiph.Org Foundation has defined the specification, interoperability, and conformance and conducts regular interoperability testing.
Xiph.Org財団は仕様、相互運用性、および適合性を定義し、定期的な相互運用性テストを実施しました。
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.
オッグスケルトン拡張の使用は既存の実装との相互運用性の問題が発生しないことが確認されました。サードパーティは、しかし、自分自身のテストを実施するために歓迎されています。
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 5334のRFC 4281.参照セクション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".
マジックナンバー（S）：最初の4バイト、0x4f 0x67 0x67 $ 53は、文字列「OggS」に相当します。
File extension(s): .ogx
ファイルの拡張子（S）：.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は、RFC 5334が原因歴史的に、いくつかの実装が.OGGファイルが単独でVorbisのエンコードされたオーディオであることを期待、不安に.ogxの賛成で廃止アプリケーション/ oggの、のためにファイル拡張子.OGGを定義しました。
Macintosh File Type Code(s): OggX
Macintoshのファイルタイプコード（S）：OggX
Person & Email address to contact for further information: See "Authors' Addresses" section.
人とEメールアドレスは、詳細のために連絡する：「著者のアドレス」を参照してください。
Intended usage: COMMON
意図している用法：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.
使用に関する制限事項：タイプapplication / oggのは、ビデオ/ OGGまたはオーディオ/ oggのタイプの下にデータを提供するために適切ではない状況で使用する必要があります。データは.ogxファイル拡張子を使用すべきであるアプリケーション/ oggのタイプの下に提供し、他のすべての論理ビットストリームが含まれて識別するために、オッグスケルトン論理ビットストリームを含まなければなりません。
Author: See "Authors' Addresses" section.
著者：「著者のアドレス」を参照してください。
Change controller: The Xiph.Org Foundation.
変更コントローラ：Xiph.Org財団。
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 5334のRFC 4281.参照セクション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".
マジックナンバー（S）：最初の4バイト、0x4f 0x67 0x67 $ 53は、文字列「OggS」に相当します。
File extension(s): .ogv
ファイルの拡張子（S）：.ogv
Macintosh File Type Code(s): OggV
Macintoshのファイルタイプコード（S）：OggV
Person & Email address to contact for further information: See "Authors' Addresses" section.
人とEメールアドレスは、詳細のために連絡する：「著者のアドレス」を参照してください。
Intended usage: COMMON
意図している用法：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の」下のサービス提供を保証するのに十分な複雑ではないコンテンツを対象としています。例えば、Theoraのビデオ、オーディオVorbisの、スケルトンのメタデータ、およびCMMLキャプションの組み合わせ。オッグスケルトン論理ビットストリームが含まれているはずのデータがタイプ「ビデオ/ oggの」下務めました。タイプ「ビデオ/ oggの」との対話の実装は、多重化されたビットストリームをサポートする必要があります。
Author: See "Authors' Addresses" section.
著者：「著者のアドレス」を参照してください。
Change controller: The Xiph.Org Foundation.
変更コントローラ：Xiph.Org財団。
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 5334のRFC 4281.参照セクション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".
マジックナンバー（S）：最初の4バイト、0x4f 0x67 0x67 $ 53は、文字列「OggS」に相当します。
File extension(s): .oga, .ogg, .spx
ファイルの拡張子（S）：.oga、.OGG、.spx
Macintosh File Type Code(s): OggA
Macintoshのファイルタイプコード（S）：Augie
Person & Email address to contact for further information: See "Authors' Addresses" section.
人とEメールアドレスは、詳細のために連絡する：「著者のアドレス」を参照してください。
Intended usage: COMMON
意図している用法：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のは、」使用されるべきです。デフォルトの.ogaファイル拡張子を使用している場合、コンテンツはオッグスケルトン論理ビットストリームを持つべきである（SHOULD）「オーディオ/ oggの」タイプの下に務めました。 .OGGと.spxファイル拡張子が原因既存の実装との下位互換性の問題に何のスケルトンを必要としない特殊化を示しています。特に、.OGGは.spxのみSpeexのビットストリームが含まれているのOggファイル用に使用されている間、唯一Vorbisのビットストリームが含まれているOGGファイルのために使用されています。
Author: See "Authors' Addresses" section.
著者：「著者のアドレス」を参照してください。
Change controller: The Xiph.Org Foundation.
変更コントローラ：Xiph.Org財団。
The authors gratefully acknowledge the contributions of Magnus Westerlund, Alfred Hoenes, and Peter Saint-Andre.
作者は感謝しマグヌスウェスター、アルフレッドHoenes、そしてピーターサンアンドレの貢献を認めます。
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]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", RFC 3533, May 2003.
[RFC3533]ファイファー、S.、 "オッグカプセル化形式のバージョン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.、歌手、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]解放され、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]ファイファー、S.、パーカー、C.、およびA.パン、 "連続メディアマークアップ言語（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>.
[コーデック]ファイファー、S.およびI.ゴンサルヴェス、 "MIMEタイプの仕様とそれぞれのコーデックパラメータ"、2008年7月、<http://wiki.xiph.org/index.php/MIMETypesCodecs>。
[Dirac] Dirac Group, "Dirac Specification", <http://diracvideo.org/specifications/>.
[ディラック]ディラックグループ、 "ディラック仕様"、<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/ogg/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>.
[オッグ] Xiph.Org財団、 "オッグビットストリームのドキュメント：Oggの論理および物理ビットストリームの概要、オッグ論理ビットストリームフレーミング、オッグマルチストリーム多重化"、<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]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[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のエンコードされたオーディオのための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>.
[スケルトン]ファイファー、S.とC.パーカー、 "オッグスケルトンメタデータのビットストリーム"、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.、 "Speexのコーデック・マニュアル"、2002年2月、<http://speex.org/docs/manual/speex-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のコーデックのためのRTPペイロードフォーマット"、進歩、2008年2月に作業。
[Theora] Xiph.Org Foundation, "Theora Specification", October 2007, <http://theora.org/doc/Theora.pdf>.
[Theoraの] Xiph.Org財団、 "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財団、 "VorbisのI仕様"、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
イヴォ・エマニュエルゴンサルヴェスXiph.Org財団21・カレッジヒルロードサマービル、MA 02144米国
EMail: justivo@gmail.com URI: xmpp:justivo@gmail.com
電子メール：justivo@gmail.com URI：XMPP：justivo@gmail.com
Silvia Pfeiffer Xiph.Org Foundation
シルビア・ファイファーXiph.Org財団
EMail: silvia@annodex.net URI: http://annodex.net/
電子メール：silvia@annodex.net URI：http://annodex.net/
Christopher Montgomery Xiph.Org Foundation
クリストファー・モンゴメリーXiph.Org財団
EMail: monty@xiph.org URI: http://xiph.org
電子メール：monty@xiph.org URI：http://xiph.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。