diff options
Diffstat (limited to 'ogg/doc/rfc5334.txt')
| -rw-r--r-- | ogg/doc/rfc5334.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/ogg/doc/rfc5334.txt b/ogg/doc/rfc5334.txt new file mode 100644 index 0000000..fea91fb --- /dev/null +++ b/ogg/doc/rfc5334.txt @@ -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] + |