|
@@ -0,0 +1,787 @@
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+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.
|
|
|
|
|
+
|
|
|
|
|
+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.
|
|
|
|
|
+
|
|
|
|
|
+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
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 1]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+1. Introduction
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+2. Changes Since RFC 3534
|
|
|
|
|
+
|
|
|
|
|
+ o The type "application/ogg" is redefined.
|
|
|
|
|
+
|
|
|
|
|
+ o The types "video/ogg" and "audio/ogg" are defined.
|
|
|
|
|
+
|
|
|
|
|
+ o New file extensions are defined.
|
|
|
|
|
+
|
|
|
|
|
+ o New Macintosh file type codes are defined.
|
|
|
|
|
+
|
|
|
|
|
+ o The codecs parameter is defined for optional use.
|
|
|
|
|
+
|
|
|
|
|
+ o The Ogg Skeleton extension becomes a recommended addition for
|
|
|
|
|
+ content served under the new types.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 2]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+3. Conformance and Document Conventions
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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".
|
|
|
|
|
+
|
|
|
|
|
+4. Deployed Media Types and Compatibility
|
|
|
|
|
+
|
|
|
|
|
+ The application/ogg media type has been used in an ad hoc fashion to
|
|
|
|
|
+ label and exchange multimedia content in Ogg containers.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 3]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+ the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
|
|
|
|
|
+ as Skeleton contains identifiers to describe the different
|
|
|
|
|
+ encapsulated data.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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]).
|
|
|
|
|
+
|
|
|
|
|
+ Possible examples include:
|
|
|
|
|
+
|
|
|
|
|
+ o application/ogg; codecs="theora, cmml, ecmascript"
|
|
|
|
|
+
|
|
|
|
|
+ o video/ogg; codecs="theora, vorbis"
|
|
|
|
|
+
|
|
|
|
|
+ o audio/ogg; codecs=speex
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 4]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+5. Relation between the Media Types
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+6. Encoding Considerations
|
|
|
|
|
+
|
|
|
|
|
+ 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 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.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 5]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+7. Security Considerations
|
|
|
|
|
+
|
|
|
|
|
+ Refer to [RFC3552] for a discussion of terminology used in this
|
|
|
|
|
+ section.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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 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
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+8. Interoperability Considerations
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ The Xiph.Org Foundation has defined the specification,
|
|
|
|
|
+ interoperability, and conformance and conducts regular
|
|
|
|
|
+ interoperability testing.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+9. IANA Considerations
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+10. Ogg Media Types
|
|
|
|
|
+
|
|
|
|
|
+10.1. application/ogg
|
|
|
|
|
+
|
|
|
|
|
+ Type name: application
|
|
|
|
|
+
|
|
|
|
|
+ Subtype name: 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.
|
|
|
|
|
+
|
|
|
|
|
+ Encoding considerations: See section 6 of RFC 5334.
|
|
|
|
|
+
|
|
|
|
|
+ Security considerations: See section 7 of RFC 5334.
|
|
|
|
|
+
|
|
|
|
|
+ Interoperability considerations: None, as noted in section 8 of RFC
|
|
|
|
|
+ 5334.
|
|
|
|
|
+
|
|
|
|
|
+ Published specification: 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.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 7]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+ Additional information:
|
|
|
|
|
+
|
|
|
|
|
+ Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
|
|
|
|
|
+ correspond to the string "OggS".
|
|
|
|
|
+
|
|
|
|
|
+ File extension(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.
|
|
|
|
|
+
|
|
|
|
|
+ Macintosh File Type Code(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.
|
|
|
|
|
+
|
|
|
|
|
+ Author: See "Authors' Addresses" section.
|
|
|
|
|
+
|
|
|
|
|
+ Change controller: The Xiph.Org Foundation.
|
|
|
|
|
+
|
|
|
|
|
+10.2. video/ogg
|
|
|
|
|
+
|
|
|
|
|
+ Type name: video
|
|
|
|
|
+
|
|
|
|
|
+ Subtype name: 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.
|
|
|
|
|
+
|
|
|
|
|
+ Encoding considerations: See section 6 of RFC 5334.
|
|
|
|
|
+
|
|
|
|
|
+ Security considerations: See section 7 of RFC 5334.
|
|
|
|
|
+
|
|
|
|
|
+ Interoperability considerations: None, as noted in section 8 of RFC
|
|
|
|
|
+ 5334.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 8]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+ Published specification: 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".
|
|
|
|
|
+
|
|
|
|
|
+ File extension(s): .ogv
|
|
|
|
|
+
|
|
|
|
|
+ Macintosh File Type Code(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.
|
|
|
|
|
+
|
|
|
|
|
+ Author: See "Authors' Addresses" section.
|
|
|
|
|
+
|
|
|
|
|
+ Change controller: The Xiph.Org Foundation.
|
|
|
|
|
+
|
|
|
|
|
+10.3. audio/ogg
|
|
|
|
|
+
|
|
|
|
|
+ Type name: audio
|
|
|
|
|
+
|
|
|
|
|
+ Subtype name: 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.
|
|
|
|
|
+
|
|
|
|
|
+ Encoding considerations: See section 6 of RFC 5334.
|
|
|
|
|
+
|
|
|
|
|
+ Security considerations: See section 7 of RFC 5334.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 9]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+ Interoperability considerations: None, as noted in section 8 of RFC
|
|
|
|
|
+ 5334.
|
|
|
|
|
+
|
|
|
|
|
+ Published specification: 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".
|
|
|
|
|
+
|
|
|
|
|
+ File extension(s): .oga, .ogg, .spx
|
|
|
|
|
+
|
|
|
|
|
+ Macintosh File Type Code(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.
|
|
|
|
|
+
|
|
|
|
|
+ Author: See "Authors' Addresses" section.
|
|
|
|
|
+
|
|
|
|
|
+ Change controller: The Xiph.Org Foundation.
|
|
|
|
|
+
|
|
|
|
|
+11. Acknowledgements
|
|
|
|
|
+
|
|
|
|
|
+ The authors gratefully acknowledge the contributions of Magnus
|
|
|
|
|
+ Westerlund, Alfred Hoenes, and Peter Saint-Andre.
|
|
|
|
|
+
|
|
|
|
|
+12. Copying Conditions
|
|
|
|
|
+
|
|
|
|
|
+ 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
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+13. References
|
|
|
|
|
+
|
|
|
|
|
+13.1. Normative References
|
|
|
|
|
+
|
|
|
|
|
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|
|
|
|
+ Extensions (MIME) Part One: Format of Internet Message
|
|
|
|
|
+ Bodies", RFC 2045, November 1996.
|
|
|
|
|
+
|
|
|
|
|
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
|
|
|
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
|
+
|
|
|
|
|
+ [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
|
|
|
|
|
+ RFC 3533, May 2003.
|
|
|
|
|
+
|
|
|
|
|
+ [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
|
|
|
|
|
+ Parameter for "Bucket" Media Types", RFC 4281,
|
|
|
|
|
+ November 2005.
|
|
|
|
|
+
|
|
|
|
|
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
|
|
|
|
|
+ Registration Procedures", BCP 13, RFC 4288,
|
|
|
|
|
+ December 2005.
|
|
|
|
|
+
|
|
|
|
|
+13.2. Informative References
|
|
|
|
|
+
|
|
|
|
|
+ [CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
|
|
|
|
|
+ Media Markup Language (CMML)", Work in Progress,
|
|
|
|
|
+ March 2006.
|
|
|
|
|
+
|
|
|
|
|
+ [Codecs] Pfeiffer, S. and I. Goncalves, "Specification of MIME
|
|
|
|
|
+ types and respective codecs parameter", July 2008,
|
|
|
|
|
+ <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
|
|
|
|
|
+
|
|
|
|
|
+ [Dirac] Dirac Group, "Dirac Specification",
|
|
|
|
|
+ <http://diracvideo.org/specifications/>.
|
|
|
|
|
+
|
|
|
|
|
+ [FLAC] Coalson, J., "The FLAC Format",
|
|
|
|
|
+ <http://flac.sourceforge.net/format.html>.
|
|
|
|
|
+
|
|
|
|
|
+ [libogg] Xiph.Org Foundation, "The libogg API", June 2000,
|
|
|
|
|
+ <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>.
|
|
|
|
|
+
|
|
|
|
|
+ [RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
|
|
|
|
|
+ May 2003.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 11]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+ [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
|
|
|
|
|
+ Text on Security Considerations", BCP 72, RFC 3552,
|
|
|
|
|
+ July 2003.
|
|
|
|
|
+
|
|
|
|
|
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
|
|
|
|
|
+ Encodings", RFC 4648, October 2006.
|
|
|
|
|
+
|
|
|
|
|
+ [RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded
|
|
|
|
|
+ Audio", RFC 5215, August 2008.
|
|
|
|
|
+
|
|
|
|
|
+ [Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
|
|
|
|
|
+ Bitstream", November 2007,
|
|
|
|
|
+ <http://xiph.org/ogg/doc/skeleton.html>.
|
|
|
|
|
+
|
|
|
|
|
+ [Speex] Valin, J., "The Speex Codec Manual", February 2002,
|
|
|
|
|
+ <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.
|
|
|
|
|
+
|
|
|
|
|
+ [Theora] Xiph.Org Foundation, "Theora Specification",
|
|
|
|
|
+ October 2007, <http://theora.org/doc/Theora.pdf>.
|
|
|
|
|
+
|
|
|
|
|
+ [ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded
|
|
|
|
|
+ Video", Work in Progress, June 2006.
|
|
|
|
|
+
|
|
|
|
|
+ [Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004,
|
|
|
|
|
+ <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 12]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Authors' Addresses
|
|
|
|
|
+
|
|
|
|
|
+ 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
|
|
|
|
|
+
|
|
|
|
|
+ EMail: silvia@annodex.net
|
|
|
|
|
+ URI: http://annodex.net/
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+ Christopher Montgomery
|
|
|
|
|
+ Xiph.Org Foundation
|
|
|
|
|
+
|
|
|
|
|
+ EMail: monty@xiph.org
|
|
|
|
|
+ URI: http://xiph.org
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 13]
|
|
|
|
|
+
|
|
|
|
|
+RFC 5334 Ogg Media Types September 2008
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Full Copyright Statement
|
|
|
|
|
+
|
|
|
|
|
+ Copyright (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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+ 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.
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+
|
|
|
|
|
+Goncalves, et al. Standards Track [Page 14]
|
|
|
|
|
+
|