[xiph-commits] r14533 - trunk/standards
ivo at svn.xiph.org
ivo at svn.xiph.org
Fri Feb 22 06:50:14 PST 2008
Author: ivo
Date: 2008-02-22 06:50:13 -0800 (Fri, 22 Feb 2008)
New Revision: 14533
Added:
trunk/standards/draft-goncalves-rfc3534bis.txt
trunk/standards/draft-goncalves-rfc3534bis.xml
Log:
Commit recent 01 in IETF.
Added: trunk/standards/draft-goncalves-rfc3534bis.txt
===================================================================
--- trunk/standards/draft-goncalves-rfc3534bis.txt (rev 0)
+++ trunk/standards/draft-goncalves-rfc3534bis.txt 2008-02-22 14:50:13 UTC (rev 14533)
@@ -0,0 +1,672 @@
+
+
+
+Network Working Group I. Goncalves
+Internet-Draft S. Pfeiffer
+Obsoletes: 3534 (if approved) C. Montgomery
+Intended status: Standards Track Xiph
+Expires: August 25, 2008 February 22, 2008
+
+
+ Ogg Media Types
+ draft-goncalves-rfc3534bis-01
+
+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 August 25, 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 August 25, 2008 [Page 1]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+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 August 25, 2008 [Page 2]
+
+Internet-Draft Ogg Media Types February 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 August 25, 2008 [Page 3]
+
+Internet-Draft Ogg Media Types February 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.
+
+ 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 [RFC4648] is generally preferred for binary-to-text
+ encoding.
+
+
+
+Goncalves, et al. Expires August 25, 2008 [Page 4]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+ 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 August 25, 2008 [Page 5]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+ 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]
+
+ 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 August 25, 2008 [Page 6]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+ 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]
+
+ Applications which use this media type: Multimedia applications,
+ including hardware-based, streaming, and conferencing tools.
+
+
+
+
+Goncalves, et al. Expires August 25, 2008 [Page 7]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+ 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]
+
+ Applications which use this media type: Multimedia applications,
+ including hardware-based, streaming, and conferencing tools.
+
+
+
+Goncalves, et al. Expires August 25, 2008 [Page 8]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+ 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 August 25, 2008 [Page 9]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+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>.
+
+ [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>.
+
+
+
+Goncalves, et al. Expires August 25, 2008 [Page 10]
+
+Internet-Draft Ogg Media Types February 2008
+
+
+ [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>.
+
+Authors' Addresses
+
+ Ivo Emanuel Goncalves
+ Xiph.Org Foundation
+ 21 College Hill Road
+ Somerville, MA 02144
+ US
+
+ EMail: justivo at gmail.com
+ URI: xmpp:justivo at gmail.com
+
+
+ Silvia Pfeiffer
+ Xiph.Org Foundation
+
+ Phone: +61 2 8012 0937
+ EMail: silvia at annodex.net
+
+
+ Christopher Montgomery
+ Xiph.Org Foundation
+
+ EMail: monty at xiph.org
+ URI: http://xiph.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al. Expires August 25, 2008 [Page 11]
+
+Internet-Draft Ogg Media Types February 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 at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Goncalves, et al. Expires August 25, 2008 [Page 12]
+
Property changes on: trunk/standards/draft-goncalves-rfc3534bis.txt
___________________________________________________________________
Name: svn:executable
+ *
Added: trunk/standards/draft-goncalves-rfc3534bis.xml
===================================================================
--- trunk/standards/draft-goncalves-rfc3534bis.xml (rev 0)
+++ trunk/standards/draft-goncalves-rfc3534bis.xml 2008-02-22 14:50:13 UTC (rev 14533)
@@ -0,0 +1,375 @@
+<?xml version="1.0"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+
+<?rfc toc="yes" ?>
+<?rfc tocindent="no" ?>
+<?rfc symrefs="yes" ?>
+<?rfc rfcedstyle="yes" ?>
+
+<rfc ipr="full3978" docName="draft-goncalves-rfc3534bis-01" obsoletes="3534" category="std">
+
+ <front>
+ <title>Ogg Media Types</title>
+
+ <author initials="I.E." surname="Goncalves" fullname="Ivo Emanuel Goncalves">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ <address>
+ <postal>
+ <street>21 College Hill Road</street>
+ <city>Somerville</city>
+ <region>MA</region>
+ <code>02144</code>
+ <country>US</country>
+ </postal>
+ <email>justivo at gmail.com</email>
+ <uri>xmpp:justivo at gmail.com</uri>
+ </address>
+ </author>
+ <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ <address>
+ <phone>+61 2 8012 0937</phone>
+ <email>silvia at annodex.net</email>
+ </address>
+ </author>
+ <author initials="C." surname="Montgomery" fullname="Christopher Montgomery">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ <address>
+ <email>monty at xiph.org</email>
+ <uri>http://xiph.org</uri>
+ </address>
+ </author>
+
+ <date day="22" month="February" year="2008"/>
+ <area>Internet</area>
+ <keyword>I-D</keyword>
+ <keyword>Internet-Draft</keyword>
+ <keyword>Ogg</keyword>
+ <keyword>MIME</keyword>
+ <keyword>Video</keyword>
+ <keyword>Audio</keyword>
+
+ <abstract>
+ <t>This document describes the registration of media types for the <xref target="RFC3533">Ogg</xref> container format and conformance requirements for implementations of these types.</t>
+ </abstract>
+ </front>
+
+ <middle>
+ <section title="Introduction">
+
+ <t>This memo describes media types for Ogg, a data encapsulation format defined by the Xiph.Org Foundation. Refer to "Introduction" in <xref target="RFC3533"/> and "Overview" in <xref target="Ogg"/> for background information on this container format.</t>
+
+ <t>Binary data contained in Ogg, such as Vorbis and Theora, has historically been interchanged using the application/ogg media type as defined by <xref target="RFC3534"/>. This document obsoletes <xref target="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.</t>
+
+ <t>The Ogg container format is known to contain <xref target="Theora"/> or <xref target="Dirac"/> video, <xref target="Speex"/> (narrow-band and wide-band speech), <xref target="Vorbis"/> or <xref target="FLAC"/> audio, and <xref target="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.</t>
+
+ <t>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 <xref target="RFC2045">media types</xref> are used.</t>
+
+ </section>
+ <section title="Conformance and Document Conventions">
+ <t>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, <xref target="RFC2119"/> and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated.</t>
+ <t>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.</t>
+ <t>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".</t>
+ </section>
+ <section title="Deployed Media Types and Compatibility">
+ <t>The application/ogg media type has been used in an ad-hoc fashion to label and exchange multimedia content in Ogg containers.</t>
+ <t>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,</t>
+ <list style="symbols">
+ <t>video/ogg</t>
+ <t>audio/ogg</t>
+ </list>
+ <t>which are intended for common use and SHOULD be used when dealing with video or audio content respectively. This document also obsoletes the <xref target="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.</t>
+ <t>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 <xref target="RFC3533"/>. The content types of the logical bitstreams may be identified without decoding the header pages of the logical bitstreams through use of a <xref target="Skeleton"/> bitstream. Using Skeleton is REQUIRED for content served under the application/ogg type and RECOMMENDED for video/ogg and audio/ogg.</t>
+ <t>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.</t>
+ <t>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.</t>
+ </section>
+ <section title="Encoding Considerations">
+ <t>Binary: The content consists of an unrestricted sequence of octets.</t>
+ <t>Note:</t>
+ <list style="symbols">
+ <t>Ogg encapsulated content is binary data and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping, etc.; <xref target="RFC4648">base64</xref> is generally preferred for binary-to-text encoding.</t>
+ <t>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 <xref target="ThRTP">Theora</xref> video, and <xref target="VoRTP">Vorbis</xref> or <xref target="SpRTP">Speex</xref> audio, as well as for identification of the encapsulated content within Ogg.</t>
+ </list>
+ </section>
+ <section title="Security Considerations">
+ <t>Refer to <xref target="RFC3552"/> for a discussion of terminology used in this section.</t>
+ <t>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.</t>
+ <t>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.</t>
+ <t>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.</t>
+ <t>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.</t>
+ <t>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.</t>
+ <t>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.</t>
+ </section>
+ <section title="Interoperability Considerations">
+ <t>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 <xref target="libogg">reference implementation</xref> is available under the new (3-clause) BSD license, which is a free software license.</t>
+ <t>The Ogg container format is not patented and may be implemented by third parties without intellectual property concerns.</t>
+ <t>The Xiph.Org Foundation has defined the specification, interoperability, and conformance, and conducts regular interoperability testing.</t>
+ </section>
+ <section title="IANA Considerations">
+ <t>This document registers two new media types and redefines the existing application/ogg as defined in the following section.</t>
+ </section>
+ <section title="Ogg Media Types">
+ <section title="application/ogg">
+ <t>Type name: application</t>
+ <t>Subtype name: ogg</t>
+ <t>Required parameters: none</t>
+ <t>Optional parameters: none</t>
+ <t>Encoding considerations: See section 4.</t>
+ <t>Security considerations: See section 5.</t>
+ <t>Interoperability considerations: None, as noted in section 6.</t>
+ <t>Published specification: <xref target="RFC3533"/></t>
+ <t>Applications which use this media type: Scientific and other applications which require various multiplexed signals or streams of data.</t>
+ <t>Additional information:</t>
+ <t>Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string "OggS".</t>
+ <t>File extension(s): .ogx</t>
+ <list style="hanging">
+ <t><xref target="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.</t>
+ </list>
+ <t>Macintosh File Type Code(s): OggX</t>
+ <t>Person & Email address to contact for further information: See "Authors' Addresses" section.</t>
+ <t>Intended usage: COMMON</t>
+ <t>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.</t>
+ <t>Author: See "Authors' Addresses" section.</t>
+ <t>Change controller: The Xiph.Org Foundation.</t>
+ </section>
+ <section title="video/ogg">
+ <t>Type name: video</t>
+ <t>Subtype name: ogg</t>
+ <t>Required parameters: none</t>
+ <t>Optional parameters: none</t>
+ <t>Encoding considerations: See section 4.</t>
+ <t>Security considerations: See section 5.</t>
+ <t>Interoperability considerations: None, as noted in section 6.</t>
+ <t>Published specification: <xref target="RFC3533"/></t>
+ <t>Applications which use this media type: Multimedia applications, including hardware-based, streaming, and conferencing tools.</t>
+ <t>Additional information:</t>
+ <t>Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string "OggS".</t>
+ <t>File extension(s): .ogv</t>
+ <t>Macintosh File Type Code(s): OggV</t>
+ <t>Person & Email address to contact for further information: See "Authors' Addresses" section.</t>
+ <t>Intended usage: COMMON</t>
+ <t>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.</t>
+ <t>Author: See "Authors' Addresses" section.</t>
+ <t>Change controller: The Xiph.Org Foundation.</t>
+ </section>
+ <section title="audio/ogg">
+ <t>Type name: audio</t>
+ <t>Subtype name: ogg</t>
+ <t>Required parameters: none</t>
+ <t>Optional parameters: none</t>
+ <t>Encoding considerations: See section 4.</t>
+ <t>Security considerations: See section 5.</t>
+ <t>Interoperability considerations: None, as noted in section 6.</t>
+ <t>Published specification: <xref target="RFC3533"/></t>
+ <t>Applications which use this media type: Multimedia applications, including hardware-based, streaming, and conferencing tools.</t>
+ <t>Additional information:</t>
+ <t>Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the string "OggS".</t>
+ <t>File extension(s): .oga, .ogg, .spx</t>
+ <t>Macintosh File Type Code(s): OggA</t>
+ <t>Person & Email address to contact for further information: See "Authors' Addresses" section.</t>
+ <t>Intended usage: COMMON</t>
+ <t>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.</t>
+ <t>Author: See "Authors' Addresses" section.</t>
+ <t>Change controller: The Xiph.Org Foundation.</t>
+ </section>
+ </section>
+ <section title="Copying Conditions">
+ <t>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.</t>
+ </section>
+ </middle>
+
+ <back>
+ <references title="Normative References">
+
+ <reference anchor="RFC3533">
+ <front>
+ <title>The Ogg Encapsulation Format Version 0</title>
+ <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="May" year="2003"/>
+ </front>
+ <seriesInfo name="RFC" value="3533"/>
+ </reference>
+ <reference anchor="RFC3534">
+ <front>
+ <title>The application/ogg Media Type</title>
+ <author initials="L." surname="Walleij" fullname="Linus Walleij">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="May" year="2003"/>
+ </front>
+ <seriesInfo name="RFC" value="3534"/>
+ </reference>
+ <reference anchor="RFC2045">
+ <front>
+ <title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+ <author initials="N." surname="Freed" fullname="Ned Freed">
+ <organization>Innosoft International, Inc.</organization>
+ </author>
+ <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+ </author>
+ <date month="November" year="1996"/>
+ </front>
+ <seriesInfo name="RFC" value="2045"/>
+ </reference>
+ <reference anchor="RFC2119">
+ <front>
+ <title>Key words for use in RFCs to Indicate Requirement Levels</title>
+ <author initials="S." surname="Bradner" fullname="Scott O. Bradner">
+ <organization>Harvard University</organization>
+ </author>
+ <date month="March" year="1997"/>
+ </front>
+ <seriesInfo name="BCP" value="14"/>
+ <seriesInfo name="RFC" value="2119"/>
+ </reference>
+ </references>
+ <references title="Informative References">
+ <reference anchor="Ogg" target="http://xiph.org/ogg/doc">
+ <front>
+ <title>Ogg bitstream documentation: Ogg logical and physical bitstream overview, Ogg logical bitstream framing, Ogg multi-stream multiplexing</title>
+ <author>
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ </front>
+ </reference>
+ <reference anchor="Theora" target="http://theora.org/doc/Theora_spec.pdf">
+ <front>
+ <title>Theora Specification</title>
+ <author>
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="October" year="2007"/>
+ </front>
+ </reference>
+ <reference anchor="Dirac" target="http://dirac.sourceforge.net/specification.html">
+ <front>
+ <title>Dirac Specification</title>
+ <author>
+ <organization>Dirac Group</organization>
+ </author>
+ </front>
+ </reference>
+ <reference anchor="Speex" target="http://speex.org/docs/manual/speex-manual">
+ <front>
+ <title>The Speex Codec Manual</title>
+ <author initials="J." surname="Valin" fullname="Jean-Marc Valin">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="February" year="2002"/>
+ </front>
+ </reference>
+ <reference anchor="Vorbis" target="http://xiph.org/vorbis/doc/Vorbis_I_spec.html">
+ <front>
+ <title>Vorbis I Specification</title>
+ <author>
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="July" year="2004"/>
+ </front>
+ </reference>
+ <reference anchor="FLAC" target="http://flac.sourceforge.net/format.html">
+ <front>
+ <title>The FLAC Format</title>
+ <author initials="J." surname="Coalson" fullname="Josh Coalson">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ </front>
+ </reference>
+ <reference anchor="CMML" target="http://annodex.net/TR/cmml.txt">
+ <front>
+ <title>The Continuous Media Markup Language (CMML)</title>
+ <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ </author>
+ <author initials="C.D." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ </author>
+ <author initials="A.T." surname="Pang" fullname="Andre T. Pang">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ </author>
+ <date month="March" year="2006"/>
+ </front>
+ </reference>
+ <reference anchor="Skeleton" target="http://xiph.org/ogg/doc/skeleton.html">
+ <front>
+ <title>The Ogg Skeleton Metadata Bitstream</title>
+ <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <author initials="C.D." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="November" year="2007"/>
+ </front>
+ </reference>
+ <reference anchor="RFC4648">
+ <front>
+ <title>The Base16, Base32, and Base64 Data Encodings</title>
+ <author initials="S." surname="Josefsson" fullname="Simon Josefsson">
+ <organization>SJD</organization>
+ </author>
+ <date month="October" year="2006"/>
+ </front>
+ <seriesInfo name="RFC" value="4648"/>
+ </reference>
+ <reference anchor="ThRTP" target="http://tools.ietf.org/html/draft-barbato-avt-rtp-theora">
+ <front>
+ <title>RTP Payload Format for Theora Encoded Video</title>
+ <author initials="L." surname="Barbato" fullname="Luca Barbato">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="July" year="2006"/>
+ </front>
+ </reference>
+ <reference anchor="VoRTP" target="http://tools.ietf.org/html/draft-ietf-avt-rtp-vorbis">
+ <front>
+ <title>RTP Payload Format for Vorbis Encoded Audio</title>
+ <author initials="L." surname="Barbato" fullname="Luca Barbato">
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="November" year="2007"/>
+ </front>
+ </reference>
+ <reference anchor="SpRTP" target="http://tools.ietf.org/html/draft-ietf-avt-rtp-speex">
+ <front>
+ <title>RTP Payload Format for the Speex Codec</title>
+ <author initials="G." surname="Herlein" fullname="Greg Herlein">
+ </author>
+ <author initials="J." surname="Valin" fullname="Jean-Marc Valin">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ </author>
+ <author initials="A.E." surname="Heggestad" fullname="Alfred E. Heggestad">
+ </author>
+ <author initials="A." surname="Moizard" fullname="Aymeric Moizard">
+ </author>
+ <date month="July" year="2007"/>
+ </front>
+ </reference>
+ <reference anchor="RFC3552">
+ <front>
+ <title>Guidelines for Writing RFC Text on Security Considerations</title>
+ <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
+ <organization>RTFM, Inc.</organization>
+ </author>
+ <author initials="B." surname="Korver" fullname="Brian Korver">
+ <organization>Xythos Software, Inc.</organization>
+ </author>
+ <date month="July" year="2003"/>
+ </front>
+ <seriesInfo name="BCP" value="72"/>
+ <seriesInfo name="RFC" value="3552"/>
+ </reference>
+ <reference anchor="libogg" target="http://xiph.org/ogg/doc/libogg">
+ <front>
+ <title>The libogg API</title>
+ <author>
+ <organization abbrev="Xiph">Xiph.Org Foundation</organization>
+ </author>
+ <date month="June" year="2000"/>
+ </front>
+ </reference>
+ </references>
+ </back>
+</rfc>
\ No newline at end of file
Property changes on: trunk/standards/draft-goncalves-rfc3534bis.xml
___________________________________________________________________
Name: svn:executable
+ *
More information about the commits
mailing list