cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Network Working Group I. Goncalves cannam@86: Request for Comments: 5334 S. Pfeiffer cannam@86: Obsoletes: 3534 C. Montgomery cannam@86: Category: Standards Track Xiph cannam@86: September 2008 cannam@86: cannam@86: cannam@86: Ogg Media Types cannam@86: cannam@86: Status of This Memo cannam@86: cannam@86: This document specifies an Internet standards track protocol for the cannam@86: Internet community, and requests discussion and suggestions for cannam@86: improvements. Please refer to the current edition of the "Internet cannam@86: Official Protocol Standards" (STD 1) for the standardization state cannam@86: and status of this protocol. Distribution of this memo is unlimited. cannam@86: cannam@86: Abstract cannam@86: cannam@86: This document describes the registration of media types for the Ogg cannam@86: container format and conformance requirements for implementations of cannam@86: these types. This document obsoletes RFC 3534. cannam@86: cannam@86: Table of Contents cannam@86: cannam@86: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 cannam@86: 2. Changes Since RFC 3534 . . . . . . . . . . . . . . . . . . 2 cannam@86: 3. Conformance and Document Conventions . . . . . . . . . . . 3 cannam@86: 4. Deployed Media Types and Compatibility . . . . . . . . . . 3 cannam@86: 5. Relation between the Media Types . . . . . . . . . . . . . 5 cannam@86: 6. Encoding Considerations . . . . . . . . . . . . . . . . . . 5 cannam@86: 7. Security Considerations . . . . . . . . . . . . . . . . . . 6 cannam@86: 8. Interoperability Considerations . . . . . . . . . . . . . . 7 cannam@86: 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 cannam@86: 10. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 7 cannam@86: 10.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 7 cannam@86: 10.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8 cannam@86: 10.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9 cannam@86: 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10 cannam@86: 12. Copying Conditions . . . . . . . . . . . . . . . . . . . . 10 cannam@86: 13. References . . . . . . . . . . . . . . . . . . . . . . . . 11 cannam@86: 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 cannam@86: 13.2. Informative References . . . . . . . . . . . . . . . . . . 11 cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 1] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: 1. Introduction cannam@86: cannam@86: This document describes media types for Ogg, a data encapsulation cannam@86: format defined by the Xiph.Org Foundation for public use. Refer to cannam@86: "Introduction" in [RFC3533] and "Overview" in [Ogg] for background cannam@86: information on this container format. cannam@86: cannam@86: Binary data contained in Ogg, such as Vorbis and Theora, has cannam@86: historically been interchanged using the application/ogg media type cannam@86: as defined by [RFC3534]. This document obsoletes [RFC3534] and cannam@86: defines three media types for different types of content in Ogg to cannam@86: reflect this usage in the IANA media type registry, to foster cannam@86: interoperability by defining underspecified aspects, and to provide cannam@86: general security considerations. cannam@86: cannam@86: The Ogg container format is known to contain [Theora] or [Dirac] cannam@86: video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC] cannam@86: audio, and [CMML] timed text/metadata. As Ogg encapsulates binary cannam@86: data, it is possible to include any other type of video, audio, cannam@86: image, text, or, generally speaking, any time-continuously sampled cannam@86: data. cannam@86: cannam@86: While raw packets from these data sources may be used directly by cannam@86: transport mechanisms that provide their own framing and packet- cannam@86: separation mechanisms (such as UDP datagrams or RTP), Ogg is a cannam@86: solution for stream based storage (such as files) and transport (such cannam@86: as TCP streams or pipes). The media types defined in this document cannam@86: are needed to correctly identify such content when it is served over cannam@86: HTTP, included in multi-part documents, or used in other places where cannam@86: media types [RFC2045] are used. cannam@86: cannam@86: 2. Changes Since RFC 3534 cannam@86: cannam@86: o The type "application/ogg" is redefined. cannam@86: cannam@86: o The types "video/ogg" and "audio/ogg" are defined. cannam@86: cannam@86: o New file extensions are defined. cannam@86: cannam@86: o New Macintosh file type codes are defined. cannam@86: cannam@86: o The codecs parameter is defined for optional use. cannam@86: cannam@86: o The Ogg Skeleton extension becomes a recommended addition for cannam@86: content served under the new types. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 2] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: 3. Conformance and Document Conventions cannam@86: cannam@86: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", cannam@86: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this cannam@86: document are to be interpreted as described in BCP 14, [RFC2119] and cannam@86: indicate requirement levels for compliant implementations. cannam@86: Requirements apply to all implementations unless otherwise stated. cannam@86: cannam@86: An implementation is a software module that supports one of the media cannam@86: types defined in this document. Software modules may support cannam@86: multiple media types, but conformance is considered individually for cannam@86: each type. cannam@86: cannam@86: Implementations that fail to satisfy one or more "MUST" requirements cannam@86: are considered non-compliant. Implementations that satisfy all cannam@86: "MUST" requirements, but fail to satisfy one or more "SHOULD" cannam@86: requirements, are said to be "conditionally compliant". All other cannam@86: implementations are "unconditionally compliant". cannam@86: cannam@86: 4. Deployed Media Types and Compatibility cannam@86: cannam@86: The application/ogg media type has been used in an ad hoc fashion to cannam@86: label and exchange multimedia content in Ogg containers. cannam@86: cannam@86: Use of the "application" top-level type for this kind of content is cannam@86: known to be problematic, in particular since it obfuscates video and cannam@86: audio content. This document thus defines the media types, cannam@86: cannam@86: o video/ogg cannam@86: cannam@86: o audio/ogg cannam@86: cannam@86: which are intended for common use and SHOULD be used when dealing cannam@86: with video or audio content, respectively. This document also cannam@86: obsoletes the [RFC3534] definition of application/ogg and marks it cannam@86: for complex data (e.g., multitrack visual, audio, textual, and other cannam@86: time-continuously sampled data), which is not clearly video or audio cannam@86: data and thus not suited for either the video/ogg or audio/ogg types. cannam@86: Refer to the following section for more details. cannam@86: cannam@86: An Ogg bitstream generally consists of one or more logical bitstreams cannam@86: that each consist of a series of header and data pages packetising cannam@86: time-continuous binary data [RFC3533]. The content types of the cannam@86: logical bitstreams may be identified without decoding the header cannam@86: pages of the logical bitstreams through use of a [Skeleton] cannam@86: bitstream. Using Ogg Skeleton is REQUIRED for content served under cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 3] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: the application/ogg type and RECOMMENDED for video/ogg and audio/ogg, cannam@86: as Skeleton contains identifiers to describe the different cannam@86: encapsulated data. cannam@86: cannam@86: Furthermore, it is RECOMMENDED that implementations that identify a cannam@86: logical bitstream that they cannot decode SHOULD ignore it, while cannam@86: continuing to decode the ones they can. Such precaution ensures cannam@86: backward and forward compatibility with existing and future data. cannam@86: cannam@86: These media types can optionally use the "codecs" parameter described cannam@86: in [RFC4281]. Codecs encapsulated in Ogg require a text identifier cannam@86: at the beginning of the first header page, hence a machine-readable cannam@86: method to identify the encapsulated codecs would be through this cannam@86: header. The following table illustrates how those header values map cannam@86: into strings that are used in the "codecs" parameter when dealing cannam@86: with Ogg media types. cannam@86: cannam@86: Codec Identifier | Codecs Parameter cannam@86: ----------------------------------------------------------- cannam@86: char[5]: 'BBCD\0' | dirac cannam@86: char[5]: '\177FLAC' | flac cannam@86: char[7]: '\x80theora' | theora cannam@86: char[7]: '\x01vorbis' | vorbis cannam@86: char[8]: 'CELT ' | celt cannam@86: char[8]: 'CMML\0\0\0\0' | cmml cannam@86: char[8]: '\213JNG\r\n\032\n' | jng cannam@86: char[8]: '\x80kate\0\0\0' | kate cannam@86: char[8]: 'OggMIDI\0' | midi cannam@86: char[8]: '\212MNG\r\n\032\n' | mng cannam@86: char[8]: 'PCM ' | pcm cannam@86: char[8]: '\211PNG\r\n\032\n' | png cannam@86: char[8]: 'Speex ' | speex cannam@86: char[8]: 'YUV4MPEG' | yuv4mpeg cannam@86: cannam@86: An up-to-date version of this table is kept at Xiph.org (see cannam@86: [Codecs]). cannam@86: cannam@86: Possible examples include: cannam@86: cannam@86: o application/ogg; codecs="theora, cmml, ecmascript" cannam@86: cannam@86: o video/ogg; codecs="theora, vorbis" cannam@86: cannam@86: o audio/ogg; codecs=speex cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 4] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: 5. Relation between the Media Types cannam@86: cannam@86: As stated in the previous section, this document describes three cannam@86: media types that are targeted at different data encapsulated in Ogg. cannam@86: Since Ogg is capable of encapsulating any kind of data, the multiple cannam@86: usage scenarios have revealed interoperability issues between cannam@86: implementations when dealing with content served solely under the cannam@86: application/ogg type. cannam@86: cannam@86: While this document does redefine the earlier definition of cannam@86: application/ogg, this media type will continue to embrace the widest cannam@86: net possible of content with the video/ogg and audio/ogg types being cannam@86: smaller subsets of it. However, the video/ogg and audio/ogg types cannam@86: take precedence in a subset of the usages, specifically when serving cannam@86: multimedia content that is not complex enough to warrant the use of cannam@86: application/ogg. Following this line of thought, the audio/ogg type cannam@86: is an even smaller subset within video/ogg, as it is not intended to cannam@86: refer to visual content. cannam@86: cannam@86: As such, the application/ogg type is the recommended choice to serve cannam@86: content aimed at scientific and other applications that require cannam@86: various multiplexed signals or streams of continuous data, with or cannam@86: without scriptable control of content. For bitstreams containing cannam@86: visual, timed text, and any other type of material that requires a cannam@86: visual interface, but that is not complex enough to warrant serving cannam@86: under application/ogg, the video/ogg type is recommended. In cannam@86: situations where the Ogg bitstream predominantly contains audio data cannam@86: (lyrics, metadata, or cover art notwithstanding), it is recommended cannam@86: to use the audio/ogg type. cannam@86: cannam@86: 6. Encoding Considerations cannam@86: cannam@86: Binary: The content consists of an unrestricted sequence of octets. cannam@86: cannam@86: Note: cannam@86: cannam@86: o Ogg encapsulated content is binary data and should be transmitted cannam@86: in a suitable encoding without CR/LF conversion, 7-bit stripping, cannam@86: etc.; base64 [RFC4648] is generally preferred for binary-to-text cannam@86: encoding. cannam@86: cannam@86: o Media types described in this document are used for stream based cannam@86: storage (such as files) and transport (such as TCP streams or cannam@86: pipes); separate types are used to identify codecs such as in cannam@86: real-time applications for the RTP payload formats of Theora cannam@86: [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well cannam@86: as for identification of encapsulated data within Ogg through cannam@86: Skeleton. cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 5] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: 7. Security Considerations cannam@86: cannam@86: Refer to [RFC3552] for a discussion of terminology used in this cannam@86: section. cannam@86: cannam@86: The Ogg encapsulation format is a container and only a carrier of cannam@86: content (such as audio, video, and displayable text data) with a very cannam@86: rigid definition. This format in itself is not more vulnerable than cannam@86: any other content framing mechanism. cannam@86: cannam@86: Ogg does not provide for any generic encryption or signing of itself cannam@86: or its contained bitstreams. However, it encapsulates any kind of cannam@86: binary content and is thus able to contain encrypted and signed cannam@86: content data. It is also possible to add an external security cannam@86: mechanism that encrypts or signs an Ogg bitstream and thus provides cannam@86: content confidentiality and authenticity. cannam@86: cannam@86: As Ogg encapsulates binary data, it is possible to include executable cannam@86: content in an Ogg bitstream. Implementations SHOULD NOT execute such cannam@86: content without prior validation of its origin by the end-user. cannam@86: cannam@86: Issues may arise on applications that use Ogg for streaming or file cannam@86: transfer in a networking scenario. In such cases, implementations cannam@86: decoding Ogg and its encapsulated bitstreams have to ensure correct cannam@86: handling of manipulated bitstreams, of buffer overflows, and similar cannam@86: issues. cannam@86: cannam@86: It is also possible to author malicious Ogg bitstreams, which attempt cannam@86: to call for an excessively large picture size, high sampling-rate cannam@86: audio, etc. Implementations SHOULD protect themselves against this cannam@86: kind of attack. cannam@86: cannam@86: Ogg has an extensible structure, so that it is theoretically possible cannam@86: that metadata fields or media formats might be defined in the future cannam@86: which might be used to induce particular actions on the part of the cannam@86: recipient, thus presenting additional security risks. However, this cannam@86: type of capability is currently not supported in the referenced cannam@86: specification. cannam@86: cannam@86: Implementations may fail to implement a specific security model or cannam@86: other means to prevent possibly dangerous operations. Such failure cannam@86: might possibly be exploited to gain unauthorized access to a system cannam@86: or sensitive information; such failure constitutes an unknown factor cannam@86: and is thus considered out of the scope of this document. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 6] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: 8. Interoperability Considerations cannam@86: cannam@86: The Ogg container format is device-, platform-, and vendor-neutral cannam@86: and has proved to be widely implementable across different computing cannam@86: platforms through a wide range of encoders and decoders. A broadly cannam@86: portable reference implementation [libogg] is available under the cannam@86: revised (3-clause) BSD license, which is a Free Software license. cannam@86: cannam@86: The Xiph.Org Foundation has defined the specification, cannam@86: interoperability, and conformance and conducts regular cannam@86: interoperability testing. cannam@86: cannam@86: The use of the Ogg Skeleton extension has been confirmed to not cause cannam@86: interoperability issues with existing implementations. Third parties cannam@86: are, however, welcome to conduct their own testing. cannam@86: cannam@86: 9. IANA Considerations cannam@86: cannam@86: In accordance with the procedures set forth in [RFC4288], this cannam@86: document registers two new media types and redefines the existing cannam@86: application/ogg as defined in the following section. cannam@86: cannam@86: 10. Ogg Media Types cannam@86: cannam@86: 10.1. application/ogg cannam@86: cannam@86: Type name: application cannam@86: cannam@86: Subtype name: ogg cannam@86: cannam@86: Required parameters: none cannam@86: cannam@86: Optional parameters: codecs, whose syntax is defined in RFC 4281. cannam@86: See section 4 of RFC 5334 for a list of allowed values. cannam@86: cannam@86: Encoding considerations: See section 6 of RFC 5334. cannam@86: cannam@86: Security considerations: See section 7 of RFC 5334. cannam@86: cannam@86: Interoperability considerations: None, as noted in section 8 of RFC cannam@86: 5334. cannam@86: cannam@86: Published specification: RFC 3533 cannam@86: cannam@86: Applications which use this media type: Scientific and otherwise that cannam@86: require various multiplexed signals or streams of data, with or cannam@86: without scriptable control of content. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 7] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: Additional information: cannam@86: cannam@86: Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, cannam@86: correspond to the string "OggS". cannam@86: cannam@86: File extension(s): .ogx cannam@86: cannam@86: RFC 3534 defined the file extension .ogg for application/ogg, cannam@86: which RFC 5334 obsoletes in favor of .ogx due to concerns where, cannam@86: historically, some implementations expect .ogg files to be solely cannam@86: Vorbis-encoded audio. cannam@86: cannam@86: Macintosh File Type Code(s): OggX cannam@86: cannam@86: Person & Email address to contact for further information: See cannam@86: "Authors' Addresses" section. cannam@86: cannam@86: Intended usage: COMMON cannam@86: cannam@86: Restrictions on usage: The type application/ogg SHOULD only be used cannam@86: in situations where it is not appropriate to serve data under the cannam@86: video/ogg or audio/ogg types. Data served under the application/ogg cannam@86: type SHOULD use the .ogx file extension and MUST contain an Ogg cannam@86: Skeleton logical bitstream to identify all other contained logical cannam@86: bitstreams. cannam@86: cannam@86: Author: See "Authors' Addresses" section. cannam@86: cannam@86: Change controller: The Xiph.Org Foundation. cannam@86: cannam@86: 10.2. video/ogg cannam@86: cannam@86: Type name: video cannam@86: cannam@86: Subtype name: ogg cannam@86: cannam@86: Required parameters: none cannam@86: cannam@86: Optional parameters: codecs, whose syntax is defined in RFC 4281. cannam@86: See section 4 of RFC 5334 for a list of allowed values. cannam@86: cannam@86: Encoding considerations: See section 6 of RFC 5334. cannam@86: cannam@86: Security considerations: See section 7 of RFC 5334. cannam@86: cannam@86: Interoperability considerations: None, as noted in section 8 of RFC cannam@86: 5334. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 8] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: Published specification: RFC 3533 cannam@86: cannam@86: Applications which use this media type: Multimedia applications, cannam@86: including embedded, streaming, and conferencing tools. cannam@86: cannam@86: Additional information: cannam@86: cannam@86: Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, cannam@86: correspond to the string "OggS". cannam@86: cannam@86: File extension(s): .ogv cannam@86: cannam@86: Macintosh File Type Code(s): OggV cannam@86: cannam@86: Person & Email address to contact for further information: See cannam@86: "Authors' Addresses" section. cannam@86: cannam@86: Intended usage: COMMON cannam@86: cannam@86: Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg cannam@86: bitstreams containing visual, audio, timed text, or any other type of cannam@86: material that requires a visual interface. It is intended for cannam@86: content not complex enough to warrant serving under "application/ cannam@86: ogg"; for example, a combination of Theora video, Vorbis audio, cannam@86: Skeleton metadata, and CMML captioning. Data served under the type cannam@86: "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream. cannam@86: Implementations interacting with the type "video/ogg" SHOULD support cannam@86: multiplexed bitstreams. cannam@86: cannam@86: Author: See "Authors' Addresses" section. cannam@86: cannam@86: Change controller: The Xiph.Org Foundation. cannam@86: cannam@86: 10.3. audio/ogg cannam@86: cannam@86: Type name: audio cannam@86: cannam@86: Subtype name: ogg cannam@86: cannam@86: Required parameters: none cannam@86: cannam@86: Optional parameters: codecs, whose syntax is defined in RFC 4281. cannam@86: See section 4 of RFC 5334 for a list of allowed values. cannam@86: cannam@86: Encoding considerations: See section 6 of RFC 5334. cannam@86: cannam@86: Security considerations: See section 7 of RFC 5334. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 9] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: Interoperability considerations: None, as noted in section 8 of RFC cannam@86: 5334. cannam@86: cannam@86: Published specification: RFC 3533 cannam@86: cannam@86: Applications which use this media type: Multimedia applications, cannam@86: including embedded, streaming, and conferencing tools. cannam@86: cannam@86: Additional information: cannam@86: cannam@86: Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, cannam@86: correspond to the string "OggS". cannam@86: cannam@86: File extension(s): .oga, .ogg, .spx cannam@86: cannam@86: Macintosh File Type Code(s): OggA cannam@86: cannam@86: Person & Email address to contact for further information: See cannam@86: "Authors' Addresses" section. cannam@86: cannam@86: Intended usage: COMMON cannam@86: cannam@86: Restrictions on usage: The type "audio/ogg" SHOULD be used when the cannam@86: Ogg bitstream predominantly contains audio data. Content served cannam@86: under the "audio/ogg" type SHOULD have an Ogg Skeleton logical cannam@86: bitstream when using the default .oga file extension. The .ogg and cannam@86: .spx file extensions indicate a specialization that requires no cannam@86: Skeleton due to backward compatibility concerns with existing cannam@86: implementations. In particular, .ogg is used for Ogg files that cannam@86: contain only a Vorbis bitstream, while .spx is used for Ogg files cannam@86: that contain only a Speex bitstream. cannam@86: cannam@86: Author: See "Authors' Addresses" section. cannam@86: cannam@86: Change controller: The Xiph.Org Foundation. cannam@86: cannam@86: 11. Acknowledgements cannam@86: cannam@86: The authors gratefully acknowledge the contributions of Magnus cannam@86: Westerlund, Alfred Hoenes, and Peter Saint-Andre. cannam@86: cannam@86: 12. Copying Conditions cannam@86: cannam@86: The authors agree to grant third parties the irrevocable right to cannam@86: copy, use and distribute the work, with or without modification, in cannam@86: any medium, without royalty, provided that, unless separate cannam@86: permission is granted, redistributed modified works do not contain cannam@86: misleading author, version, name of work, or endorsement information. cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 10] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: 13. References cannam@86: cannam@86: 13.1. Normative References cannam@86: cannam@86: [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail cannam@86: Extensions (MIME) Part One: Format of Internet Message cannam@86: Bodies", RFC 2045, November 1996. cannam@86: cannam@86: [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate cannam@86: Requirement Levels", BCP 14, RFC 2119, March 1997. cannam@86: cannam@86: [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0", cannam@86: RFC 3533, May 2003. cannam@86: cannam@86: [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs cannam@86: Parameter for "Bucket" Media Types", RFC 4281, cannam@86: November 2005. cannam@86: cannam@86: [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and cannam@86: Registration Procedures", BCP 13, RFC 4288, cannam@86: December 2005. cannam@86: cannam@86: 13.2. Informative References cannam@86: cannam@86: [CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous cannam@86: Media Markup Language (CMML)", Work in Progress, cannam@86: March 2006. cannam@86: cannam@86: [Codecs] Pfeiffer, S. and I. Goncalves, "Specification of MIME cannam@86: types and respective codecs parameter", July 2008, cannam@86: . cannam@86: cannam@86: [Dirac] Dirac Group, "Dirac Specification", cannam@86: . cannam@86: cannam@86: [FLAC] Coalson, J., "The FLAC Format", cannam@86: . cannam@86: cannam@86: [libogg] Xiph.Org Foundation, "The libogg API", June 2000, cannam@86: . cannam@86: cannam@86: [Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg cannam@86: logical and physical bitstream overview, Ogg logical cannam@86: bitstream framing, Ogg multi-stream multiplexing", cannam@86: . cannam@86: cannam@86: [RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534, cannam@86: May 2003. cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 11] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC cannam@86: Text on Security Considerations", BCP 72, RFC 3552, cannam@86: July 2003. cannam@86: cannam@86: [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data cannam@86: Encodings", RFC 4648, October 2006. cannam@86: cannam@86: [RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded cannam@86: Audio", RFC 5215, August 2008. cannam@86: cannam@86: [Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata cannam@86: Bitstream", November 2007, cannam@86: . cannam@86: cannam@86: [Speex] Valin, J., "The Speex Codec Manual", February 2002, cannam@86: . cannam@86: cannam@86: [SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard, cannam@86: "RTP Payload Format for the Speex Codec", Work cannam@86: in Progress, February 2008. cannam@86: cannam@86: [Theora] Xiph.Org Foundation, "Theora Specification", cannam@86: October 2007, . cannam@86: cannam@86: [ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded cannam@86: Video", Work in Progress, June 2006. cannam@86: cannam@86: [Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004, cannam@86: . cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 12] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: Authors' Addresses cannam@86: cannam@86: Ivo Emanuel Goncalves cannam@86: Xiph.Org Foundation cannam@86: 21 College Hill Road cannam@86: Somerville, MA 02144 cannam@86: US cannam@86: cannam@86: EMail: justivo@gmail.com cannam@86: URI: xmpp:justivo@gmail.com cannam@86: cannam@86: cannam@86: Silvia Pfeiffer cannam@86: Xiph.Org Foundation cannam@86: cannam@86: EMail: silvia@annodex.net cannam@86: URI: http://annodex.net/ cannam@86: cannam@86: cannam@86: Christopher Montgomery cannam@86: Xiph.Org Foundation cannam@86: cannam@86: EMail: monty@xiph.org cannam@86: URI: http://xiph.org cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 13] cannam@86: cannam@86: RFC 5334 Ogg Media Types September 2008 cannam@86: cannam@86: cannam@86: Full Copyright Statement cannam@86: cannam@86: Copyright (C) The IETF Trust (2008). cannam@86: cannam@86: This document is subject to the rights, licenses and restrictions cannam@86: contained in BCP 78, and except as set forth therein, the authors cannam@86: retain all their rights. cannam@86: cannam@86: This document and the information contained herein are provided on an cannam@86: "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS cannam@86: OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND cannam@86: THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS cannam@86: OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF cannam@86: THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED cannam@86: WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. cannam@86: cannam@86: Intellectual Property cannam@86: cannam@86: The IETF takes no position regarding the validity or scope of any cannam@86: Intellectual Property Rights or other rights that might be claimed to cannam@86: pertain to the implementation or use of the technology described in cannam@86: this document or the extent to which any license under such rights cannam@86: might or might not be available; nor does it represent that it has cannam@86: made any independent effort to identify any such rights. Information cannam@86: on the procedures with respect to rights in RFC documents can be cannam@86: found in BCP 78 and BCP 79. cannam@86: cannam@86: Copies of IPR disclosures made to the IETF Secretariat and any cannam@86: assurances of licenses to be made available, or the result of an cannam@86: attempt made to obtain a general license or permission for the use of cannam@86: such proprietary rights by implementers or users of this cannam@86: specification can be obtained from the IETF on-line IPR repository at cannam@86: http://www.ietf.org/ipr. cannam@86: cannam@86: The IETF invites any interested party to bring to its attention any cannam@86: copyrights, patents or patent applications, or other proprietary cannam@86: rights that may cover technology that may be required to implement cannam@86: this standard. Please address the information to the IETF at cannam@86: ietf-ipr@ietf.org. cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: cannam@86: Goncalves, et al. Standards Track [Page 14] cannam@86: