7 Network Working Group I. Goncalves
8 Request for Comments: 5334 S. Pfeiffer
9 Obsoletes: 3534 C. Montgomery
10 Category: Standards Track Xiph
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 This document describes the registration of media types for the Ogg
27 container format and conformance requirements for implementations of
28 these types. This document obsoletes RFC 3534.
32 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
33 2. Changes Since RFC 3534 . . . . . . . . . . . . . . . . . . 2
34 3. Conformance and Document Conventions . . . . . . . . . . . 3
35 4. Deployed Media Types and Compatibility . . . . . . . . . . 3
36 5. Relation between the Media Types . . . . . . . . . . . . . 5
37 6. Encoding Considerations . . . . . . . . . . . . . . . . . . 5
38 7. Security Considerations . . . . . . . . . . . . . . . . . . 6
39 8. Interoperability Considerations . . . . . . . . . . . . . . 7
40 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
41 10. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 7
42 10.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 7
43 10.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8
44 10.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9
45 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
46 12. Copying Conditions . . . . . . . . . . . . . . . . . . . . 10
47 13. References . . . . . . . . . . . . . . . . . . . . . . . . 11
48 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11
49 13.2. Informative References . . . . . . . . . . . . . . . . . . 11
58 Goncalves, et al. Standards Track [Page 1]
60 RFC 5334 Ogg Media Types September 2008
65 This document describes media types for Ogg, a data encapsulation
66 format defined by the Xiph.Org Foundation for public use. Refer to
67 "Introduction" in [RFC3533] and "Overview" in [Ogg] for background
68 information on this container format.
70 Binary data contained in Ogg, such as Vorbis and Theora, has
71 historically been interchanged using the application/ogg media type
72 as defined by [RFC3534]. This document obsoletes [RFC3534] and
73 defines three media types for different types of content in Ogg to
74 reflect this usage in the IANA media type registry, to foster
75 interoperability by defining underspecified aspects, and to provide
76 general security considerations.
78 The Ogg container format is known to contain [Theora] or [Dirac]
79 video, [Speex] (narrow-band and wide-band) speech, [Vorbis] or [FLAC]
80 audio, and [CMML] timed text/metadata. As Ogg encapsulates binary
81 data, it is possible to include any other type of video, audio,
82 image, text, or, generally speaking, any time-continuously sampled
85 While raw packets from these data sources may be used directly by
86 transport mechanisms that provide their own framing and packet-
87 separation mechanisms (such as UDP datagrams or RTP), Ogg is a
88 solution for stream based storage (such as files) and transport (such
89 as TCP streams or pipes). The media types defined in this document
90 are needed to correctly identify such content when it is served over
91 HTTP, included in multi-part documents, or used in other places where
92 media types [RFC2045] are used.
94 2. Changes Since RFC 3534
96 o The type "application/ogg" is redefined.
98 o The types "video/ogg" and "audio/ogg" are defined.
100 o New file extensions are defined.
102 o New Macintosh file type codes are defined.
104 o The codecs parameter is defined for optional use.
106 o The Ogg Skeleton extension becomes a recommended addition for
107 content served under the new types.
114 Goncalves, et al. Standards Track [Page 2]
116 RFC 5334 Ogg Media Types September 2008
119 3. Conformance and Document Conventions
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123 document are to be interpreted as described in BCP 14, [RFC2119] and
124 indicate requirement levels for compliant implementations.
125 Requirements apply to all implementations unless otherwise stated.
127 An implementation is a software module that supports one of the media
128 types defined in this document. Software modules may support
129 multiple media types, but conformance is considered individually for
132 Implementations that fail to satisfy one or more "MUST" requirements
133 are considered non-compliant. Implementations that satisfy all
134 "MUST" requirements, but fail to satisfy one or more "SHOULD"
135 requirements, are said to be "conditionally compliant". All other
136 implementations are "unconditionally compliant".
138 4. Deployed Media Types and Compatibility
140 The application/ogg media type has been used in an ad hoc fashion to
141 label and exchange multimedia content in Ogg containers.
143 Use of the "application" top-level type for this kind of content is
144 known to be problematic, in particular since it obfuscates video and
145 audio content. This document thus defines the media types,
151 which are intended for common use and SHOULD be used when dealing
152 with video or audio content, respectively. This document also
153 obsoletes the [RFC3534] definition of application/ogg and marks it
154 for complex data (e.g., multitrack visual, audio, textual, and other
155 time-continuously sampled data), which is not clearly video or audio
156 data and thus not suited for either the video/ogg or audio/ogg types.
157 Refer to the following section for more details.
159 An Ogg bitstream generally consists of one or more logical bitstreams
160 that each consist of a series of header and data pages packetising
161 time-continuous binary data [RFC3533]. The content types of the
162 logical bitstreams may be identified without decoding the header
163 pages of the logical bitstreams through use of a [Skeleton]
164 bitstream. Using Ogg Skeleton is REQUIRED for content served under
170 Goncalves, et al. Standards Track [Page 3]
172 RFC 5334 Ogg Media Types September 2008
175 the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
176 as Skeleton contains identifiers to describe the different
179 Furthermore, it is RECOMMENDED that implementations that identify a
180 logical bitstream that they cannot decode SHOULD ignore it, while
181 continuing to decode the ones they can. Such precaution ensures
182 backward and forward compatibility with existing and future data.
184 These media types can optionally use the "codecs" parameter described
185 in [RFC4281]. Codecs encapsulated in Ogg require a text identifier
186 at the beginning of the first header page, hence a machine-readable
187 method to identify the encapsulated codecs would be through this
188 header. The following table illustrates how those header values map
189 into strings that are used in the "codecs" parameter when dealing
190 with Ogg media types.
192 Codec Identifier | Codecs Parameter
193 -----------------------------------------------------------
194 char[5]: 'BBCD\0' | dirac
195 char[5]: '\177FLAC' | flac
196 char[7]: '\x80theora' | theora
197 char[7]: '\x01vorbis' | vorbis
198 char[8]: 'CELT ' | celt
199 char[8]: 'CMML\0\0\0\0' | cmml
200 char[8]: '\213JNG\r\n\032\n' | jng
201 char[8]: '\x80kate\0\0\0' | kate
202 char[8]: 'OggMIDI\0' | midi
203 char[8]: '\212MNG\r\n\032\n' | mng
204 char[8]: 'PCM ' | pcm
205 char[8]: '\211PNG\r\n\032\n' | png
206 char[8]: 'Speex ' | speex
207 char[8]: 'YUV4MPEG' | yuv4mpeg
209 An up-to-date version of this table is kept at Xiph.org (see
212 Possible examples include:
214 o application/ogg; codecs="theora, cmml, ecmascript"
216 o video/ogg; codecs="theora, vorbis"
218 o audio/ogg; codecs=speex
226 Goncalves, et al. Standards Track [Page 4]
228 RFC 5334 Ogg Media Types September 2008
231 5. Relation between the Media Types
233 As stated in the previous section, this document describes three
234 media types that are targeted at different data encapsulated in Ogg.
235 Since Ogg is capable of encapsulating any kind of data, the multiple
236 usage scenarios have revealed interoperability issues between
237 implementations when dealing with content served solely under the
238 application/ogg type.
240 While this document does redefine the earlier definition of
241 application/ogg, this media type will continue to embrace the widest
242 net possible of content with the video/ogg and audio/ogg types being
243 smaller subsets of it. However, the video/ogg and audio/ogg types
244 take precedence in a subset of the usages, specifically when serving
245 multimedia content that is not complex enough to warrant the use of
246 application/ogg. Following this line of thought, the audio/ogg type
247 is an even smaller subset within video/ogg, as it is not intended to
248 refer to visual content.
250 As such, the application/ogg type is the recommended choice to serve
251 content aimed at scientific and other applications that require
252 various multiplexed signals or streams of continuous data, with or
253 without scriptable control of content. For bitstreams containing
254 visual, timed text, and any other type of material that requires a
255 visual interface, but that is not complex enough to warrant serving
256 under application/ogg, the video/ogg type is recommended. In
257 situations where the Ogg bitstream predominantly contains audio data
258 (lyrics, metadata, or cover art notwithstanding), it is recommended
259 to use the audio/ogg type.
261 6. Encoding Considerations
263 Binary: The content consists of an unrestricted sequence of octets.
267 o Ogg encapsulated content is binary data and should be transmitted
268 in a suitable encoding without CR/LF conversion, 7-bit stripping,
269 etc.; base64 [RFC4648] is generally preferred for binary-to-text
272 o Media types described in this document are used for stream based
273 storage (such as files) and transport (such as TCP streams or
274 pipes); separate types are used to identify codecs such as in
275 real-time applications for the RTP payload formats of Theora
276 [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
277 as for identification of encapsulated data within Ogg through
282 Goncalves, et al. Standards Track [Page 5]
284 RFC 5334 Ogg Media Types September 2008
287 7. Security Considerations
289 Refer to [RFC3552] for a discussion of terminology used in this
292 The Ogg encapsulation format is a container and only a carrier of
293 content (such as audio, video, and displayable text data) with a very
294 rigid definition. This format in itself is not more vulnerable than
295 any other content framing mechanism.
297 Ogg does not provide for any generic encryption or signing of itself
298 or its contained bitstreams. However, it encapsulates any kind of
299 binary content and is thus able to contain encrypted and signed
300 content data. It is also possible to add an external security
301 mechanism that encrypts or signs an Ogg bitstream and thus provides
302 content confidentiality and authenticity.
304 As Ogg encapsulates binary data, it is possible to include executable
305 content in an Ogg bitstream. Implementations SHOULD NOT execute such
306 content without prior validation of its origin by the end-user.
308 Issues may arise on applications that use Ogg for streaming or file
309 transfer in a networking scenario. In such cases, implementations
310 decoding Ogg and its encapsulated bitstreams have to ensure correct
311 handling of manipulated bitstreams, of buffer overflows, and similar
314 It is also possible to author malicious Ogg bitstreams, which attempt
315 to call for an excessively large picture size, high sampling-rate
316 audio, etc. Implementations SHOULD protect themselves against this
319 Ogg has an extensible structure, so that it is theoretically possible
320 that metadata fields or media formats might be defined in the future
321 which might be used to induce particular actions on the part of the
322 recipient, thus presenting additional security risks. However, this
323 type of capability is currently not supported in the referenced
326 Implementations may fail to implement a specific security model or
327 other means to prevent possibly dangerous operations. Such failure
328 might possibly be exploited to gain unauthorized access to a system
329 or sensitive information; such failure constitutes an unknown factor
330 and is thus considered out of the scope of this document.
338 Goncalves, et al. Standards Track [Page 6]
340 RFC 5334 Ogg Media Types September 2008
343 8. Interoperability Considerations
345 The Ogg container format is device-, platform-, and vendor-neutral
346 and has proved to be widely implementable across different computing
347 platforms through a wide range of encoders and decoders. A broadly
348 portable reference implementation [libogg] is available under the
349 revised (3-clause) BSD license, which is a Free Software license.
351 The Xiph.Org Foundation has defined the specification,
352 interoperability, and conformance and conducts regular
353 interoperability testing.
355 The use of the Ogg Skeleton extension has been confirmed to not cause
356 interoperability issues with existing implementations. Third parties
357 are, however, welcome to conduct their own testing.
359 9. IANA Considerations
361 In accordance with the procedures set forth in [RFC4288], this
362 document registers two new media types and redefines the existing
363 application/ogg as defined in the following section.
367 10.1. application/ogg
369 Type name: application
373 Required parameters: none
375 Optional parameters: codecs, whose syntax is defined in RFC 4281.
376 See section 4 of RFC 5334 for a list of allowed values.
378 Encoding considerations: See section 6 of RFC 5334.
380 Security considerations: See section 7 of RFC 5334.
382 Interoperability considerations: None, as noted in section 8 of RFC
385 Published specification: RFC 3533
387 Applications which use this media type: Scientific and otherwise that
388 require various multiplexed signals or streams of data, with or
389 without scriptable control of content.
394 Goncalves, et al. Standards Track [Page 7]
396 RFC 5334 Ogg Media Types September 2008
399 Additional information:
401 Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
402 correspond to the string "OggS".
404 File extension(s): .ogx
406 RFC 3534 defined the file extension .ogg for application/ogg,
407 which RFC 5334 obsoletes in favor of .ogx due to concerns where,
408 historically, some implementations expect .ogg files to be solely
409 Vorbis-encoded audio.
411 Macintosh File Type Code(s): OggX
413 Person & Email address to contact for further information: See
414 "Authors' Addresses" section.
416 Intended usage: COMMON
418 Restrictions on usage: The type application/ogg SHOULD only be used
419 in situations where it is not appropriate to serve data under the
420 video/ogg or audio/ogg types. Data served under the application/ogg
421 type SHOULD use the .ogx file extension and MUST contain an Ogg
422 Skeleton logical bitstream to identify all other contained logical
425 Author: See "Authors' Addresses" section.
427 Change controller: The Xiph.Org Foundation.
435 Required parameters: none
437 Optional parameters: codecs, whose syntax is defined in RFC 4281.
438 See section 4 of RFC 5334 for a list of allowed values.
440 Encoding considerations: See section 6 of RFC 5334.
442 Security considerations: See section 7 of RFC 5334.
444 Interoperability considerations: None, as noted in section 8 of RFC
450 Goncalves, et al. Standards Track [Page 8]
452 RFC 5334 Ogg Media Types September 2008
455 Published specification: RFC 3533
457 Applications which use this media type: Multimedia applications,
458 including embedded, streaming, and conferencing tools.
460 Additional information:
462 Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
463 correspond to the string "OggS".
465 File extension(s): .ogv
467 Macintosh File Type Code(s): OggV
469 Person & Email address to contact for further information: See
470 "Authors' Addresses" section.
472 Intended usage: COMMON
474 Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
475 bitstreams containing visual, audio, timed text, or any other type of
476 material that requires a visual interface. It is intended for
477 content not complex enough to warrant serving under "application/
478 ogg"; for example, a combination of Theora video, Vorbis audio,
479 Skeleton metadata, and CMML captioning. Data served under the type
480 "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
481 Implementations interacting with the type "video/ogg" SHOULD support
482 multiplexed bitstreams.
484 Author: See "Authors' Addresses" section.
486 Change controller: The Xiph.Org Foundation.
494 Required parameters: none
496 Optional parameters: codecs, whose syntax is defined in RFC 4281.
497 See section 4 of RFC 5334 for a list of allowed values.
499 Encoding considerations: See section 6 of RFC 5334.
501 Security considerations: See section 7 of RFC 5334.
506 Goncalves, et al. Standards Track [Page 9]
508 RFC 5334 Ogg Media Types September 2008
511 Interoperability considerations: None, as noted in section 8 of RFC
514 Published specification: RFC 3533
516 Applications which use this media type: Multimedia applications,
517 including embedded, streaming, and conferencing tools.
519 Additional information:
521 Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
522 correspond to the string "OggS".
524 File extension(s): .oga, .ogg, .spx
526 Macintosh File Type Code(s): OggA
528 Person & Email address to contact for further information: See
529 "Authors' Addresses" section.
531 Intended usage: COMMON
533 Restrictions on usage: The type "audio/ogg" SHOULD be used when the
534 Ogg bitstream predominantly contains audio data. Content served
535 under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
536 bitstream when using the default .oga file extension. The .ogg and
537 .spx file extensions indicate a specialization that requires no
538 Skeleton due to backward compatibility concerns with existing
539 implementations. In particular, .ogg is used for Ogg files that
540 contain only a Vorbis bitstream, while .spx is used for Ogg files
541 that contain only a Speex bitstream.
543 Author: See "Authors' Addresses" section.
545 Change controller: The Xiph.Org Foundation.
549 The authors gratefully acknowledge the contributions of Magnus
550 Westerlund, Alfred Hoenes, and Peter Saint-Andre.
552 12. Copying Conditions
554 The authors agree to grant third parties the irrevocable right to
555 copy, use and distribute the work, with or without modification, in
556 any medium, without royalty, provided that, unless separate
557 permission is granted, redistributed modified works do not contain
558 misleading author, version, name of work, or endorsement information.
562 Goncalves, et al. Standards Track [Page 10]
564 RFC 5334 Ogg Media Types September 2008
569 13.1. Normative References
571 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
572 Extensions (MIME) Part One: Format of Internet Message
573 Bodies", RFC 2045, November 1996.
575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
576 Requirement Levels", BCP 14, RFC 2119, March 1997.
578 [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
581 [RFC4281] Gellens, R., Singer, D., and P. Frojdh, "The Codecs
582 Parameter for "Bucket" Media Types", RFC 4281,
585 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
586 Registration Procedures", BCP 13, RFC 4288,
589 13.2. Informative References
591 [CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
592 Media Markup Language (CMML)", Work in Progress,
595 [Codecs] Pfeiffer, S. and I. Goncalves, "Specification of MIME
596 types and respective codecs parameter", July 2008,
597 <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
599 [Dirac] Dirac Group, "Dirac Specification",
600 <http://diracvideo.org/specifications/>.
602 [FLAC] Coalson, J., "The FLAC Format",
603 <http://flac.sourceforge.net/format.html>.
605 [libogg] Xiph.Org Foundation, "The libogg API", June 2000,
606 <http://xiph.org/ogg/doc/libogg>.
608 [Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
609 logical and physical bitstream overview, Ogg logical
610 bitstream framing, Ogg multi-stream multiplexing",
611 <http://xiph.org/ogg/doc>.
613 [RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
618 Goncalves, et al. Standards Track [Page 11]
620 RFC 5334 Ogg Media Types September 2008
623 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
624 Text on Security Considerations", BCP 72, RFC 3552,
627 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
628 Encodings", RFC 4648, October 2006.
630 [RFC5215] Barbato, L., "RTP Payload Format for Vorbis Encoded
631 Audio", RFC 5215, August 2008.
633 [Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
634 Bitstream", November 2007,
635 <http://xiph.org/ogg/doc/skeleton.html>.
637 [Speex] Valin, J., "The Speex Codec Manual", February 2002,
638 <http://speex.org/docs/manual/speex-manual>.
640 [SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
641 "RTP Payload Format for the Speex Codec", Work
642 in Progress, February 2008.
644 [Theora] Xiph.Org Foundation, "Theora Specification",
645 October 2007, <http://theora.org/doc/Theora.pdf>.
647 [ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded
648 Video", Work in Progress, June 2006.
650 [Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004,
651 <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
674 Goncalves, et al. Standards Track [Page 12]
676 RFC 5334 Ogg Media Types September 2008
681 Ivo Emanuel Goncalves
687 EMail: justivo@gmail.com
688 URI: xmpp:justivo@gmail.com
694 EMail: silvia@annodex.net
695 URI: http://annodex.net/
698 Christopher Montgomery
701 EMail: monty@xiph.org
730 Goncalves, et al. Standards Track [Page 13]
732 RFC 5334 Ogg Media Types September 2008
735 Full Copyright Statement
737 Copyright (C) The IETF Trust (2008).
739 This document is subject to the rights, licenses and restrictions
740 contained in BCP 78, and except as set forth therein, the authors
741 retain all their rights.
743 This document and the information contained herein are provided on an
744 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
745 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
746 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
747 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
748 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
749 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
751 Intellectual Property
753 The IETF takes no position regarding the validity or scope of any
754 Intellectual Property Rights or other rights that might be claimed to
755 pertain to the implementation or use of the technology described in
756 this document or the extent to which any license under such rights
757 might or might not be available; nor does it represent that it has
758 made any independent effort to identify any such rights. Information
759 on the procedures with respect to rights in RFC documents can be
760 found in BCP 78 and BCP 79.
762 Copies of IPR disclosures made to the IETF Secretariat and any
763 assurances of licenses to be made available, or the result of an
764 attempt made to obtain a general license or permission for the use of
765 such proprietary rights by implementers or users of this
766 specification can be obtained from the IETF on-line IPR repository at
767 http://www.ietf.org/ipr.
769 The IETF invites any interested party to bring to its attention any
770 copyrights, patents or patent applications, or other proprietary
771 rights that may cover technology that may be required to implement
772 this standard. Please address the information to the IETF at
786 Goncalves, et al. Standards Track [Page 14]