[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 3534) 00 01 02 03 04 05 06 07 RFC 5334

Network Working Group                                       I. Goncalves
Internet-Draft                                               S. Pfeiffer
Obsoletes: 3534 (if approved)                              C. Montgomery
Intended status: Standards Track                                    Xiph
Expires: June 5, 2008                                   December 3, 2007


                            Ogg Media Types
                     draft-goncalves-rfc3534bis-00

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 June 5, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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 June 5, 2008                  [Page 1]


Internet-Draft               Ogg Media Types               December 2007


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Conformance and Document Conventions . . . . . . . . . . . .  3
   3.    Deployed Media Types and Compatibility . . . . . . . . . . .  4
   4.    Encoding Considerations  . . . . . . . . . . . . . . . . . .  4
   5.    Security Considerations  . . . . . . . . . . . . . . . . . .  5
   6.    Interoperability Considerations  . . . . . . . . . . . . . .  6
   7.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  6
   8.    Ogg Media Types  . . . . . . . . . . . . . . . . . . . . . .  6
   8.1.  application/ogg  . . . . . . . . . . . . . . . . . . . . . .  6
   8.2.  video/ogg  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   8.3.  audio/ogg  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   9.    Copying Conditions . . . . . . . . . . . . . . . . . . . . .  9
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . .  9
   10.1. Normative References . . . . . . . . . . . . . . . . . . . .  9
   10.2. Informative References . . . . . . . . . . . . . . . . . . . 10


































Goncalves, et al.         Expires June 5, 2008                  [Page 2]


Internet-Draft               Ogg Media Types               December 2007


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 June 5, 2008                  [Page 3]


Internet-Draft               Ogg Media Types               December 2007


   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.

   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 Skeleton is REQUIRED for content served under the
   application/ogg type and RECOMMENDED for video/ogg and audio/ogg.

   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.

   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.  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 [RFC2397] is generally preferred for binary-to-text
      encoding.



Goncalves, et al.         Expires June 5, 2008                  [Page 4]


Internet-Draft               Ogg Media Types               December 2007


   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 content within Ogg.

5.  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.  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 content 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



Goncalves, et al.         Expires June 5, 2008                  [Page 5]


Internet-Draft               Ogg Media Types               December 2007


   and is thus considered out of the scope of this document.

6.  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 new
   (3-clause) BSD license, which is a free software license.

   The Ogg container format is not patented and may be implemented by
   third parties without intellectual property concerns.

   The Xiph.Org Foundation has defined the specification,
   interoperability, and conformance, and conducts regular
   interoperability testing.

7.  IANA Considerations

   This document registers two new media types and redefines the
   existing application/ogg as defined in the following section.

8.  Ogg Media Types

8.1.  application/ogg

   Type name: application

   Subtype name: ogg

   Required parameters: none

   Optional parameters: none

   Encoding considerations: See section 4.

   Security considerations: See section 5.

   Interoperability considerations: None, as noted in section 6.

   Published specification: [RFC3533], [Skeleton]

   Applications which use this media type: Scientific and other
   applications which require various multiplexed signals or streams of
   data.

   Additional information:




Goncalves, et al.         Expires June 5, 2008                  [Page 6]


Internet-Draft               Ogg Media Types               December 2007


   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
   in situations where it is not appropriate to serve content 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.

8.2.  video/ogg

   Type name: video

   Subtype name: ogg

   Required parameters: none

   Optional parameters: none

   Encoding considerations: See section 4.

   Security considerations: See section 5.

   Interoperability considerations: None, as noted in section 6.

   Published specification: [RFC3533], [Skeleton]

   Applications which use this media type: Multimedia applications,
   including hardware-based, streaming, and conferencing tools.




Goncalves, et al.         Expires June 5, 2008                  [Page 7]


Internet-Draft               Ogg Media Types               December 2007


   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" MAY 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 streams.

   Author: See "Authors' Addresses" section.

   Change controller: The Xiph.Org Foundation.

8.3.  audio/ogg

   Type name: audio

   Subtype name: ogg

   Required parameters: none

   Optional parameters: none

   Encoding considerations: See section 4.

   Security considerations: See section 5.

   Interoperability considerations: None, as noted in section 6.

   Published specification: [RFC3533], [Skeleton]

   Applications which use this media type: Multimedia applications,
   including hardware-based, streaming, and conferencing tools.



Goncalves, et al.         Expires June 5, 2008                  [Page 8]


Internet-Draft               Ogg Media Types               December 2007


   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" MAY be used for files
   containing predominantly audio material.  Files served 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 material
   under the "audio/ogg" type.

   Author: See "Authors' Addresses" section.

   Change controller: The Xiph.Org Foundation.

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

10.  References

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



Goncalves, et al.         Expires June 5, 2008                  [Page 9]


Internet-Draft               Ogg Media Types               December 2007


   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [Skeleton]  Pfeiffer, S. and C. Parker, "The "skeleton" meta
               information track for Ogg", November 2007, <http://
               svn.annodex.net/standards/
               draft-pfeiffer-oggskeleton-current.xml>.

   [RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
               Text on Security Considerations", BCP 72, RFC 3552,
               July 2003.

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

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

   [RFC2397]   Masinter, L., "The "data" URL scheme", RFC 2397,
               August 1998.

   [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://www.ietf.org/



Goncalves, et al.         Expires June 5, 2008                 [Page 10]


Internet-Draft               Ogg Media Types               December 2007


               internet-drafts/draft-ietf-avt-rtp-vorbis-08.txt>.

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

   [libogg]    Xiph.Org Foundation, "The libogg API", June 2000,
               <http://xiph.org/ogg/doc/libogg>.

Authors' Addresses

   Ivo Emanuel Goncalves
   Xiph.Org Foundation
   1408 Adams St. NE
   Albuquerque, NM  87110
   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 June 5, 2008                 [Page 11]


Internet-Draft               Ogg Media Types               December 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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 June 5, 2008                 [Page 12]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/