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