TOC 
Network Working GroupI. Goncalves
Internet-DraftS. Pfeiffer
Obsoletes: 3534 (if approved)C. Montgomery
Intended status: Standards TrackXiph
Expires: December 4, 2008June 02, 2008


Ogg Media Types
draft-goncalves-rfc3534bis-07

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 December 4, 2008.

Abstract

This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types.



Table of Contents

1.  Introduction
2.  Changes Since RFC 3534
3.  Conformance and Document Conventions
4.  Deployed Media Types and Compatibility
5.  Relation Between the Media Types
6.  Encoding Considerations
7.  Security Considerations
8.  Interoperability Considerations
9.  IANA Considerations
10.  Ogg Media Types
10.1.  application/ogg
10.2.  video/ogg
10.3.  audio/ogg
11.  Acknowledgements
12.  Copying Conditions
13.  References
13.1.  Normative References
13.2.  Informative References




 TOC 

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] (Pfeiffer, S., “The Ogg Encapsulation Format Version 0,” May 2003.) and "Overview" in [Ogg] (Xiph.Org Foundation, “Ogg bitstream documentation: Ogg logical and physical bitstream overview, Ogg logical bitstream framing, Ogg multi-stream multiplexing,” .) 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] (Walleij, L., “The application/ogg Media Type,” May 2003.). This document obsoletes [RFC3534] (Walleij, L., “The application/ogg Media Type,” May 2003.) 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] (Xiph.Org Foundation, “Theora Specification,” October 2007.) or [Dirac] (Dirac Group, “Dirac Specification,” .) video, [Speex] (Valin, J., “The Speex Codec Manual,” February 2002.) (narrow-band and wide-band) speech, [Vorbis] (Xiph.Org Foundation, “Vorbis I Specification,” July 2004.) or [FLAC] (Coalson, J., “The FLAC Format,” .) audio, and [CMML] (Pfeiffer, S., Parker, C., and A. Pang, “The Continuous Media Markup Language (CMML),” March 2006.) 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 (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2045] are used.



 TOC 

2.  Changes Since RFC 3534



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) 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".



 TOC 

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,

which are intended for common use and SHOULD be used when dealing with video or audio content respectively. This document also obsoletes the [RFC3534] (Walleij, L., “The application/ogg Media Type,” May 2003.) 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] (Pfeiffer, S., “The Ogg Encapsulation Format Version 0,” May 2003.). The content types of the logical bitstreams may be identified without decoding the header pages of the logical bitstreams through use of a [Skeleton] (Pfeiffer, S. and C. Parker, “The Ogg Skeleton Metadata Bitstream,” November 2007.) bitstream. Using Ogg Skeleton is REQUIRED for content served under 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 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.

These media types can optionally use the "codecs" parameter described in [RFC4281] (Gellens, R., Singer, D., and P. Frojdh, “The Codecs Parameter for "Bucket" Media Types,” November 2005.). 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]: 'Speex   '          | speex
     char[8]: 'OggMIDI\0'         | midi
     char[8]: 'CMML\0\0\0\0'      | cmml
     char[8]: '\211PNG\r\n\032\n' | png
     char[8]: '\212MNG\r\n\032\n' | mng
     char[8]: '\213JNG\r\n\032\n' | jng
     char[8]: 'CELT    '          | celt
     char[8]: 'PCM     '          | pcm
     char[9]: '\x80kate\0\0\0\0'  | kate
     char[9]: 'YUV4MPEG2'         | yuv4mpeg

Possible examples include:



 TOC 

5.  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 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 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 (lyrics, metadata, or cover art notwithstanding), it is recommended to use the audio/ogg type.



 TOC 

6.  Encoding Considerations

Binary: The content consists of an unrestricted sequence of octets.

Note:



 TOC 

7.  Security Considerations

Refer to [RFC3552] (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) 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.



 TOC 

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 (Xiph.Org Foundation, “The libogg API,” June 2000.) [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 not to cause interoperability issues with existing implementations. Third parties are, however, welcome to conduct their own testing.



 TOC 

9.  IANA Considerations

In accordance with the procedures set forth in [RFC4288] (Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures,” December 2005.), this document registers two new media types and redefines the existing application/ogg as defined in the following section.



 TOC 

10.  Ogg Media Types



 TOC 

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 XXXX for a list of allowed values.

Encoding considerations: See section 6 of RFC XXXX.

Security considerations: See section 7 of RFC XXXX.

Interoperability considerations: None, as noted in section 8 of RFC XXXX.

Published specification: RFC 3533

Applications which use this media type: Scientific and otherwise which require various multiplexed signals or streams of data, with or without scriptable control of content.

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 XXXX 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.



 TOC 

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 XXXX for a list of allowed values.

Encoding considerations: See section 6 of RFC XXXX.

Security considerations: See section 7 of RFC XXXX.

Interoperability considerations: None, as noted in section 8 of RFC XXXX.

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.



 TOC 

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 XXXX for a list of allowed values.

Encoding considerations: See section 6 of RFC XXXX.

Security considerations: See section 7 of RFC XXXX.

Interoperability considerations: None, as noted in section 8 of RFC XXXX.

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.



 TOC 

11.  Acknowledgements

The authors gratefully acknowledge the contributions of Magnus Westerlund, Alfred Hoenes, and Peter Saint-Andre.



 TOC 

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.



 TOC 

13.  References



 TOC 

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.


 TOC 

13.2. Informative References

[CMML] Pfeiffer, S., Parker, C., and A. Pang, “The Continuous Media Markup Language (CMML),” March 2006.
[Dirac] Dirac Group, “Dirac Specification.”
[FLAC] Coalson, J., “The FLAC Format.”
[libogg] Xiph.Org Foundation, “The libogg API,” June 2000.
[Ogg] Xiph.Org Foundation, “Ogg bitstream documentation: Ogg logical and physical bitstream overview, Ogg logical bitstream framing, Ogg multi-stream multiplexing.”
[RFC3534] Walleij, L., “The application/ogg Media Type,” RFC 3534, May 2003.
[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.
[Skeleton] Pfeiffer, S. and C. Parker, “The Ogg Skeleton Metadata Bitstream,” November 2007.
[Speex] Valin, J., “The Speex Codec Manual,” February 2002.
[SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard, “RTP Payload Format for the Speex Codec,” Work in Progress , July 2007.
[Theora] Xiph.Org Foundation, “Theora Specification,” October 2007.
[ThRTP] Barbato, L., “RTP Payload Format for Theora Encoded Video,” Work in Progress , July 2006.
[Vorbis] Xiph.Org Foundation, “Vorbis I Specification,” July 2004.
[VoRTP] Barbato, L., “RTP Payload Format for Vorbis Encoded Audio,” Work in Progress , November 2007.


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property