RFC5334 日本語訳
5334 Ogg Media Types. I. Goncalves, S. Pfeiffer, C. Montgomery. September 2008. (Format: TXT=27018 bytes) (Obsoletes RFC3534) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group I. Goncalves
Request for Comments: 5334 S. Pfeiffer
Obsoletes: 3534 C. Montgomery
Category: Standards Track Xiph
September 2008
コメントを求めるワーキンググループI.ゴンサルベスの要求をネットワークでつないでください: 5334秒間ファイファーは以下を時代遅れにします。 3534年のC.モンゴメリカテゴリ: 標準化過程Xiph2008年9月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
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.
このドキュメントはオッグコンテナ形式のためのメディアタイプとこれらのタイプの実装のための順応要件の登録について説明します。 このドキュメントはRFC3534を時代遅れにします。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 2。 RFC3534.2 3以来の変化。 順応とドキュメントコンベンション. . . . . . . . . . . 3 4。 メディアタイプと互換性. . . . . . . . . . 3 5であると配布されます。 メディアの関係は.5 6をタイプします。 問題. . . . . . . . . . . . . . . . . . 5 7をコード化します。 セキュリティ問題. . . . . . . . . . . . . . . . . . 6 8。 相互運用性問題. . . . . . . . . . . . . . 7 9。 IANA問題. . . . . . . . . . . . . . . . . . . . 7 10。 オッグメディアTypes.710.1アプリケーション/ogg.710.2ビデオ/ogg. . . . . . . . . . . . . . . . . . . . . . . . . 8 10.3オーディオ/ogg.911。 承認. . . . . . . . . . . . . . . . . . . . . 10 12。 状態. . . . . . . . . . . . . . . . . . . . 10 13をコピーします。 参照. . . . . . . . . . . . . . . . . . . . . . . . 11 13.1。 引用規格. . . . . . . . . . . . . . . . . . . 11 13.2。 有益な参照. . . . . . . . . . . . . . . . . . 11
Goncalves, et al. Standards Track [Page 1] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[1ページ]。
1. Introduction
1. 序論
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財団によって定義されたデータカプセル化書式のためにメディアタイプについて説明します。 このコンテナ形式に関する基礎的な情報について[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.
VorbisやTheoraのように、オッグに含まれたバイナリ・データは、[RFC3534]によって定義されるようにアプリケーション/oggメディアタイプを使用することで歴史的に交換されました。 このドキュメントは、オッグの異なったタイプの内容がIANAメディアのこの用法を反映するようにメディアがunderspecified局面を定義することによって相互運用性を伸ばして、総合証券問題を提供するために登録をタイプするのをタイプする3を、時代遅れにして[RFC3534]、定義します。
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などの)によってこれらのデータ送信端末からの生のパケットは使用されるかもしれませんが、オッグはストリーム基底付き記憶域(ファイルなどの)と輸送(TCPストリームかパイプなどの)のためのソリューションです。 本書では定義されたメディアタイプは、それに複合ドキュメントに含まれていたHTTPの上で役立たれているとき、正しくそのような内容を特定するのが必要である、またはメディアタイプが使用されている[RFC2045]他の場所で使用されます。
2. Changes Since RFC 3534
2. RFC3534以来の変化
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 新しいマッキントッシュファイルの種類コードは定義されます。
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 オッグSkeleton拡張子は新しいタイプの下に役立つ内容のためのお勧めの追加になります。
Goncalves, et al. Standards Track [Page 2] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[2ページ]。
3. Conformance and Document Conventions
3. 順応とドキュメントコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが本書ではこと解釈されるのは中でBCP14について説明しました、[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つ以上の“MUST"要件を満たさない実装は不従順であると考えられます。 すべての“MUST"要件を満たしますが、1つ以上の“SHOULD"要件は満たさない実装が「条件付きに言いなりになる」と言われています。 他のすべての実装が「無条件に言いなりになっています」。
4. Deployed Media Types and Compatibility
4. メディアタイプと互換性であると配布されます。
The application/ogg media type has been used in an ad hoc fashion to label and exchange multimedia content in Ogg containers.
アプリケーション/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.
どれが一般の使用とSHOULDのために意図するか。それぞれビデオかオーディオ内容に対処するときには、使用されてください。 このドキュメントが、また、アプリケーション/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
一般に、オッグbitstreamは時間連続したバイナリ・データ[RFC3533]をpacketisingする一連のヘッダーとデータページからそれぞれ成る1論理的なbitstreamsから成ります。 [骸骨]bitstreamの使用で論理的なbitstreamsのヘッダーページを解読しないで、論理的なbitstreamsのcontent typeは特定されるかもしれません。 オッグSkeletonを使用するのは、下で働かれる内容のためのREQUIREDです。
Goncalves, et al. Standards Track [Page 3] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[3ページ]。
the application/ogg type and RECOMMENDED for video/ogg and audio/ogg, as Skeleton contains identifiers to describe the different encapsulated data.
Skeletonが異なったカプセル化されたデータについて説明する識別子を含むとき、ビデオ/oggとオーディオ/のためのアプリケーション/oggタイプとRECOMMENDEDは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.
その上、論理的にaを特定する実装がbitstreamされるのは、RECOMMENDEDです。それらが解読できるものを解読し続けている間、SHOULDを解読できないのがそれを無視します。 そのような注意は存在と将来のデータとの後ろ向きで前向きな互換性を確実にします。
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%%BODY%%' | dirac
char[5]: '\177FLAC' | flac
char[7]: '\x80theora' | theora
char[7]: '\x01vorbis' | vorbis
char[8]: 'CELT ' | celt
char[8]: 'CMML%%BODY%%%%BODY%%%%BODY%%%%BODY%%' | cmml
char[8]: '\213JNG\r\n%%BODY%%32\n' | jng
char[8]: '\x80kate%%BODY%%%%BODY%%%%BODY%%' | kate
char[8]: 'OggMIDI%%BODY%%' | midi
char[8]: '\212MNG\r\n%%BODY%%32\n' | mng
char[8]: 'PCM ' | pcm
char[8]: '\211PNG\r\n%%BODY%%32\n' | png
char[8]: 'Speex ' | speex
char[8]: 'YUV4MPEG' | yuv4mpeg
コーデック識別子| コーデックパラメタ----------------------------------------------------------- 炭[5]: 'BBCD0円'| dirac炭[5]: '\177FLAC'| flac炭[7]: '\x80theora'| theora炭[7]: '\x01vorbis'| vorbisは[8]を炭にします: '石斧'| 石斧炭[8]: 'CMML0円0円0円0円'| cmml炭[8]: '\213JNG\r\n032円\、n'| jng炭[8]: '\、x80kate0円0円0'円| kate炭[8]: 'OggMIDI0円'| ミディ炭[8]: '\212MNG\r\n032円\、n'| mng炭[8]: 'PCM'| pcm炭[8]: '\211PNG\r\n032円\、n'| png炭[8]: 'Speex'| speex炭[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"
o ビデオ/ogg。 コーデックは「theora、vorbis」と等しいです。
o audio/ogg; codecs=speex
o オーディオ/ogg。 コーデックはspeexと等しいです。
Goncalves, et al. Standards Track [Page 4] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[4ページ]。
5. Relation between the Media Types
5. メディアタイプの関係
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の下で働くのを保証するくらいには複雑でない材料も含むbitstreamsに関しては、ビデオ/oggタイプはお勧めです。 オッグbitstreamがオーディオデータ(歌詞、メタデータ、芸術にもかかわらず、またはカバー)を支配的に含む状況で、オーディオ/oggタイプを使用するのはお勧めです。
6. Encoding Considerations
6. 問題をコード化します。
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 内容がカプセル化されたオッグは、バイナリ・データであり、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ペイロード形式のリアルタイムのアプリケーションなどのコーデックを特定するのに使用されます、よくオッグからSkeletonの中のカプセル化されたデータの識別のように。
Goncalves, et al. Standards Track [Page 5] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[5ページ]。
7. Security Considerations
7. セキュリティ問題
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.
オッグはどんなジェネリック暗号化、それ自体の署名またはその含まれたbitstreamsにも備えません。しかしながら、それは、どんな種類の2進の内容もカプセル化して、その結果、暗号化されて署名している満足しているデータを含むことができます。 それは、また、オッグがbitstreamであると暗号化するか、または署名する対外安全保障メカニズムを加えるのにおいて可能であり、その結果、満足している秘密性と信憑性を提供します。
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.
オッグがバイナリ・データをカプセル化するとき、オッグbitstreamの実行可能な内容を含んでいるのは可能です。 実装SHOULD NOTはエンドユーザによる発生源の先の合法化なしでそのような内容を実行します。
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.
問題はストリーミングかファイル転送にネットワークシナリオでオッグを使用するアプリケーションのときに起こるかもしれません。 そのような場合、オッグを解読する実装とそのカプセル化されたbitstreamsは操られたbitstreams、バッファオーバーフロー、および同様の問題の正しい取り扱いを確実にしなければなりません。
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.
また、作者の悪意があるオッグbitstreamsに、それも可能です。(bitstreamsは過度に大きい画像サイズ、高い標本抽出率オーディオなどを求めるのを試みます)。 実装SHOULDはこの種類の攻撃に対して我が身をかばいます。
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.
実装は特定の機密保護モデルかことによると危険な操作を防ぐ他の手段を実装しないかもしれません。 そのような失敗はシステムか機密情報への不正アクセスを獲得するのにことによると利用されるかもしれません。 そのような失敗は、未知の要素を構成して、このドキュメントの範囲からこのようにして考えられます。
Goncalves, et al. Standards Track [Page 6] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[6ページ]。
8. Interoperability Considerations
8. 相互運用性問題
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ライセンスの下で利用可能です。ライセンスはFree Softwareライセンスです。
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.
オッグSkeleton拡張子の使用は、既存の実装の相互運用性問題を引き起こさないように確認されました。 しかしながら、それら自身のテストを行うのにおいて第三者を歓迎します。
9. IANA Considerations
9. IANA問題
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を再定義します。
10. Ogg Media Types
10. オッグメディアタイプ
10.1. application/ogg
10.1. アプリケーション/ogg
Type name: application
型名: アプリケーション
Subtype name: ogg
Subtypeは以下を命名します。 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.
任意のパラメタ: コーデック。その構文はRFC4281で定義されます。 許容値のリストに関してRFC5334のセクション4を見てください。
Encoding considerations: See section 6 of RFC 5334.
問題をコード化します: RFC5334のセクション6を見てください。
Security considerations: See section 7 of RFC 5334.
セキュリティ問題: RFC5334のセクション7を見てください。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
相互運用性問題: RFC5334のセクション8で注意されるようななし。
Published specification: RFC 3533
広められた仕様: RFC3533
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.
このメディアタイプを使用するアプリケーション: そして、科学的である、さもなければ、それは内容の「スクリプト-可能」コントロールのあるなしにかかわらずデータの様々な多重化信号かストリームを必要とします。
Goncalves, et al. Standards Track [Page 7] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[7ページ]。
Additional information:
追加情報:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string "OggS".
マジックナンバー(s): 最初の4バイト、0x4f、0×67 0×67 0×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.
RFC3534はアプリケーション/oggのためにファイル拡張子.oggを定義しました。(RFC5334は関心を伴う歴史的に、いくつかの実装が.oggファイルが唯一Vorbisによってコード化されたオーディオであると予想する.ogxを支持してoggを時代遅れにします)。
Macintosh File Type Code(s): OggX
マッキントッシュファイルタイプは(s)をコード化します: 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 SHOULDだけをタイプしてください。 アプリケーション/oggタイプSHOULDの下で役立たれるデータは、.ogxファイル拡張子を使用して、他のすべての含まれた論理的なbitstreamsを特定するオッグのSkeletonの論理的なbitstreamを含まなければなりません。
Author: See "Authors' Addresses" section.
以下を書いてください。 「が作者」 セクションに演説するのを確実にしてください。
Change controller: The Xiph.Org Foundation.
コントローラを変えてください: Xiph.Org財団。
10.2. video/ogg
10.2. ビデオ/ogg
Type name: video
型名: ビデオ
Subtype name: ogg
Subtypeは以下を命名します。 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.
任意のパラメタ: コーデック。その構文はRFC4281で定義されます。 許容値のリストに関してRFC5334のセクション4を見てください。
Encoding considerations: See section 6 of RFC 5334.
問題をコード化します: RFC5334のセクション6を見てください。
Security considerations: See section 7 of RFC 5334.
セキュリティ問題: RFC5334のセクション7を見てください。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
相互運用性問題: RFC5334のセクション8で注意されるようななし。
Goncalves, et al. Standards Track [Page 8] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[8ページ]。
Published specification: RFC 3533
広められた仕様: RFC3533
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、0×67 0×67 0×53 ストリング「OggS」に対応してください。
File extension(s): .ogv
ファイル拡張子(s): .ogv
Macintosh File Type Code(s): OggV
マッキントッシュファイルタイプは(s)をコード化します: 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」SHOULDがオッグのbitstreams含有において視覚で使用されて、オーディオ、調節されたテキスト、またはいかなる他のも視覚インタフェースを必要とする材料でタイプされます。 それは内容のために「アプリケーション/ogg」の下で働くのを保証するくらいには複雑でなく意図します。 例えば、Theoraビデオ、Vorbisオーディオ、Skeletonメタデータ、およびCMMLキャプションの組み合わせ。 タイプ「ビデオ/ogg」SHOULDの下で役立たれるデータはオッグのSkeletonの論理的なbitstreamを含んでいます。 タイプ「ビデオ/ogg」SHOULDサポートと対話する実装がbitstreamsを多重送信しました。
Author: See "Authors' Addresses" section.
以下を書いてください。 「が作者」 セクションに演説するのを確実にしてください。
Change controller: The Xiph.Org Foundation.
コントローラを変えてください: Xiph.Org財団。
10.3. audio/ogg
10.3. オーディオ/ogg
Type name: audio
型名: オーディオ
Subtype name: ogg
Subtypeは以下を命名します。 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.
任意のパラメタ: コーデック。その構文はRFC4281で定義されます。 許容値のリストに関してRFC5334のセクション4を見てください。
Encoding considerations: See section 6 of RFC 5334.
問題をコード化します: RFC5334のセクション6を見てください。
Security considerations: See section 7 of RFC 5334.
セキュリティ問題: RFC5334のセクション7を見てください。
Goncalves, et al. Standards Track [Page 9] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[9ページ]。
Interoperability considerations: None, as noted in section 8 of RFC 5334.
相互運用性問題: RFC5334のセクション8で注意されるようななし。
Published specification: RFC 3533
広められた仕様: RFC3533
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、0×67 0×67 0×53 ストリング「OggS」に対応してください。
File extension(s): .oga, .ogg, .spx
ファイル拡張子(s): .oga、.ogg、.spx
Macintosh File Type Code(s): OggA
マッキントッシュファイルタイプは(s)をコード化します: 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」SHOULDをタイプしてください。オッグbitstreamがオーディオデータを支配的に含んでいるときには、使用されてください。 デフォルト.ogaファイル拡張子を使用するとき、「オーディオ/ogg」タイプSHOULDの下で役立たれる内容はオッグのためにSkeletonの論理的なbitstreamを持っています。 .oggと.spxファイル拡張子は、後方の互換性のためSkeletonを全く必要としない専門化は存在するのに実装が関係があるのを示します。 特に、.oggはVorbis bitstreamだけを入れてあるオッグファイルに使用されます、.spxがSpeex bitstreamだけを入れてあるオッグファイルに使用されますが。
Author: See "Authors' Addresses" section.
以下を書いてください。 「が作者」 セクションに演説するのを確実にしてください。
Change controller: The Xiph.Org Foundation.
コントローラを変えてください: Xiph.Org財団。
11. Acknowledgements
11. 承認
The authors gratefully acknowledge the contributions of Magnus Westerlund, Alfred Hoenes, and Peter Saint-Andre.
作者は感謝してマグヌスWesterlund、アルフレッドHoenes、およびピーターサンアンドレの貢献を承諾します。
12. Copying Conditions
12. コピー状態
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.
作者は、仕事をコピーして、使用して、広げる呼び戻せない権利を第三者に与えるのに同意します、変更のあるなしにかかわらず、どんな媒体でも、ロイヤリティなしで、別々の許可が与えられない場合、再配付された変更された作品が紛らわしい作者、バージョン、仕事の名前、または裏書き情報を含んでいなければ。
Goncalves, et al. Standards Track [Page 10] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[10ページ]。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[RFC2045]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533, May 2003.
[RFC3533] ファイファー、S.、「カプセル化がバージョン0インチフォーマットするオッグ、RFC3533、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、「「バケツ」メディアタイプへのコーデックパラメタ」、RFC4281、2005年11月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288,
December 2005.
解放された[RFC4288]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
13.2. Informative References
13.2. 有益な参照
[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/>.
[ディラック]ディラックグループ、「ディラックSpecification」、<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財団、「オッグはドキュメンテーションをbitstreamします」。 「オッグ論理的で物理的なbitstream概要、bitstreamに縁どっているオッグ論理的なオッグマルチストリームは多重送信し」て、<が://xiph.org/ogg/doc>をhttpします。
[RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
May 2003.
L.、「アプリケーション/oggメディアType」、RFC3534 2003年5月の[RFC3534]Walleij。
Goncalves, et al. Standards Track [Page 11] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[11ページ]。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
[RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded
Audio", RFC 5215, August 2008.
[RFC5215] Barbato、L.、「VorbisのためのRTP有効搭載量形式はオーディオをコード化した」RFC5215、2008年8月。
[Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
Bitstream", November 2007,
<http://xiph.org/ogg/doc/skeleton.html>.
[骸骨]ファイファーとS.とC.パーカー、「オッグ骸骨のメタデータ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] ベイリン、J.、「Speexコーデックマニュアル」、2002年2月、<speex http://speex.org/docs/マニュアル/マニュアル>。
[SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
"RTP Payload Format for the Speex Codec", Work
in Progress, February 2008.
G.、ベイリン、J.、Heggestad、A.、およびA.Moizard、「SpeexコーデックのためのRTP有効搭載量形式」という[SpRTP]Herleinは進行中(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.
L.、「TheoraのためのRTP有効搭載量形式はビデオをコード化した」という[ThRTP]Barbatoは進歩、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月、<は://xiph.org/vorbis/doc/Vorbis_I_spec.html>をhttpします。
Goncalves, et al. Standards Track [Page 12] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[12ページ]。
Authors' Addresses
作者のアドレス
Ivo Emanuel Goncalves Xiph.Org Foundation 21 College Hill Road Somerville, MA 02144 US
イヴォエマニュエルゴンサルベスXiph.Org財団21大学ヒル・Road MA02144サマービル(米国)
EMail: justivo@gmail.com URI: xmpp:justivo@gmail.com
メール: justivo@gmail.com ユリ: xmpp: justivo@gmail.com
Silvia Pfeiffer Xiph.Org Foundation
シルビアファイファーXiph.Org財団
EMail: silvia@annodex.net URI: http://annodex.net/
メール: silvia@annodex.net ユリ: http://annodex.net/
Christopher Montgomery Xiph.Org Foundation
クリストファーモンゴメリXiph.Org財団
EMail: monty@xiph.org URI: http://xiph.org
メール: monty@xiph.org ユリ: http://xiph.org
Goncalves, et al. Standards Track [Page 13] RFC 5334 Ogg Media Types September 2008
ゴンサルベス、他 規格は2008年9月にRFC5334オッグメディアタイプを追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Goncalves, et al. Standards Track [Page 14]
ゴンサルベス、他 標準化過程[14ページ]
一覧
スポンサーリンク
