Network Working Group I. Goncalves
Internet-Draft S. Pfeiffer
Obsoletes: 3534 (if approved) C. Montgomery
Intended status: Standards Track Xiph
Expires: October 6, 2008 April 4, 2008
Ogg Media Types
draft-goncalves-rfc3534bis-02
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 6, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes the registration of media types for the Ogg
[RFC3533] container format and conformance requirements for
implementations of these types.
Goncalves, et al. Expires October 6, 2008 [Page 1]
Internet-Draft Ogg Media Types April 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conformance and Document Conventions . . . . . . . . . . . . 3
3. Deployed Media Types and Compatibility . . . . . . . . . . . 4
4. Relation Between the Media Types . . . . . . . . . . . . . . 4
5. Encoding Considerations . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . 5
7. Interoperability Considerations . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 7
9.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 7
9.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. Copying Conditions . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . . 10
Goncalves, et al. Expires October 6, 2008 [Page 2]
Internet-Draft Ogg Media Types April 2008
1. Introduction
This memo describes media types for Ogg, a data encapsulation format
defined by the Xiph.Org Foundation. 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. 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
Goncalves, et al. Expires October 6, 2008 [Page 3]
Internet-Draft Ogg Media Types April 2008
implementations are "unconditionally compliant".
3. 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
the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
as it is a type of identifier space used to describe the different
encapsulated data.
Furthermore, it is RECOMMENDED that implementations that identify a
logical bitstream which 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.
Ongoing work related to this registration may introduce optional
parameters in future revisions of this document. One example area of
effort may introduce a parameter that would allow for data in use
within the media type to be asserted and determined without
examination of the bitstream. Implementations MUST consider the
impact of such an update.
4. Relation Between the Media Types
As stated in the previous section, this document describes three
media types which are targeted at different data encapsulated in Ogg.
Since Ogg is capable of encapsulate any kind of data, the multiple
Goncalves, et al. Expires October 6, 2008 [Page 4]
Internet-Draft Ogg Media Types April 2008
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. For
bitstreams containing visual, timed text, or any other type of
material that requires a visual interface, but which 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, it is recommended to use the audio/ogg type.
5. 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 for real-time transfer, such as
for the RTP payload formats of Theora [ThRTP] video, and Vorbis
[VoRTP] or Speex [SpRTP] audio, as well as for identification of
the encapsulated data within Ogg.
6. 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.
Goncalves, et al. Expires October 6, 2008 [Page 5]
Internet-Draft Ogg Media Types April 2008
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. This
may be an issue with applications that use Ogg for streaming or file
transfer in a networking scenario. An implementation decoding Ogg
and its encapsulated data streams has 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.
7. 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.
Goncalves, et al. Expires October 6, 2008 [Page 6]
Internet-Draft Ogg Media Types April 2008
8. IANA Considerations
This document registers two new media types and redefines the
existing application/ogg as defined in the following section.
9. Ogg Media Types
9.1. application/ogg
Type name: application
Subtype name: ogg
Required parameters: none
Optional parameters: none
Encoding considerations: See section 5.
Security considerations: See section 6.
Interoperability considerations: None, as noted in section 7.
Published specification: [RFC3533]
Applications which use this media type: Scientific and other
applications which require various multiplexed signals or streams of
data.
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
correspond to the string "OggS".
File extension(s): .ogx
[RFC3534] defined the file extension .ogg for application/ogg,
which this document obsoletes in favor of .ogx due to concerns
where, historically, some implementations expect .ogg 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
Goncalves, et al. Expires October 6, 2008 [Page 7]
Internet-Draft Ogg Media Types April 2008
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.
9.2. video/ogg
Type name: video
Subtype name: ogg
Required parameters: none
Optional parameters: none
Encoding considerations: See section 5.
Security considerations: See section 6.
Interoperability considerations: None, as noted in section 7.
Published specification: [RFC3533]
Applications which use this media type: Multimedia applications,
including hardware-based, 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
Goncalves, et al. Expires October 6, 2008 [Page 8]
Internet-Draft Ogg Media Types April 2008
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.
9.3. audio/ogg
Type name: audio
Subtype name: ogg
Required parameters: none
Optional parameters: none
Encoding considerations: See section 5.
Security considerations: See section 6.
Interoperability considerations: None, as noted in section 7.
Published specification: [RFC3533]
Applications which use this media type: Multimedia applications,
including hardware-based, 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
Goncalves, et al. Expires October 6, 2008 [Page 9]
Internet-Draft Ogg Media Types April 2008
under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
bitstream if they use the .oga extension. The .ogg and .spx file
extensions are a specialization that require no Skeleton due to
concerns of backwards-compatibility with existing implementations.
Use of the .oga file extension is the preferred method of
distributing audio data under the "audio/ogg" type.
Author: See "Authors' Addresses" section.
Change controller: The Xiph.Org Foundation.
10. 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.
11. References
11.1. Normative References
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533, May 2003.
[RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
May 2003.
[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.
11.2. Informative References
[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>.
[Theora] Xiph.Org Foundation, "Theora Specification",
October 2007, <http://theora.org/doc/Theora_spec.pdf>.
[Dirac] Dirac Group, "Dirac Specification",
<http://dirac.sourceforge.net/specification.html>.
Goncalves, et al. Expires October 6, 2008 [Page 10]
Internet-Draft Ogg Media Types April 2008
[Speex] Valin, J., "The Speex Codec Manual", February 2002,
<http://speex.org/docs/manual/speex-manual>.
[Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004,
<http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
[FLAC] Coalson, J., "The FLAC Format",
<http://flac.sourceforge.net/format.html>.
[CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
Media Markup Language (CMML)", March 2006,
<http://annodex.net/TR/cmml.txt>.
[Skeleton] Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
Bitstream", November 2007,
<http://xiph.org/ogg/doc/skeleton.html>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded
Video", July 2006,
<http://tools.ietf.org/html/
draft-barbato-avt-rtp-theora>.
[VoRTP] Barbato, L., "RTP Payload Format for Vorbis Encoded
Audio", November 2007,
<http://tools.ietf.org/html/draft-ietf-avt-rtp-vorbis>.
[SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
"RTP Payload Format for the Speex Codec", July 2007,
<http://tools.ietf.org/html/draft-ietf-avt-rtp-speex>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[libogg] Xiph.Org Foundation, "The libogg API", June 2000,
<http://xiph.org/ogg/doc/libogg>.
Goncalves, et al. Expires October 6, 2008 [Page 11]
Internet-Draft Ogg Media Types April 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
Phone: +61 2 8012 0937
EMail: silvia@annodex.net
Christopher Montgomery
Xiph.Org Foundation
EMail: monty@xiph.org
URI: http://xiph.org
Goncalves, et al. Expires October 6, 2008 [Page 12]
Internet-Draft Ogg Media Types April 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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Goncalves, et al. Expires October 6, 2008 [Page 13]