[xiph-commits] r14775 - trunk/standards
ivo at svn.xiph.org
ivo at svn.xiph.org
Fri Apr 18 14:08:41 PDT 2008
Author: ivo
Date: 2008-04-18 14:08:40 -0700 (Fri, 18 Apr 2008)
New Revision: 14775
Modified:
trunk/standards/draft-goncalves-rfc3534bis.txt
trunk/standards/draft-goncalves-rfc3534bis.xml
Log:
Added "Changes since RFC 3534" section. Added codecs under optional parameters with a few examples in section 4. Made some misc corrections.
Modified: trunk/standards/draft-goncalves-rfc3534bis.txt
===================================================================
--- trunk/standards/draft-goncalves-rfc3534bis.txt 2008-04-18 13:15:06 UTC (rev 14774)
+++ trunk/standards/draft-goncalves-rfc3534bis.txt 2008-04-18 21:08:40 UTC (rev 14775)
@@ -5,11 +5,11 @@
Internet-Draft S. Pfeiffer
Obsoletes: 3534 (if approved) C. Montgomery
Intended status: Standards Track Xiph
-Expires: October 10, 2008 April 8, 2008
+Expires: October 21, 2008 April 19, 2008
Ogg Media Types
- draft-goncalves-rfc3534bis-03
+ draft-goncalves-rfc3534bis-04
Status of This Memo
@@ -34,7 +34,7 @@
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on October 10, 2008.
+ This Internet-Draft will expire on October 21, 2008.
Copyright Notice
@@ -52,29 +52,30 @@
-Goncalves, et al. Expires October 10, 2008 [Page 1]
+Goncalves, et al. Expires October 21, 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
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Changes since RFC 3543 . . . . . . . . . . . . . . . . . . 3
+ 3. Conformance and Document Conventions . . . . . . . . . . . 3
+ 4. Deployed Media Types and Compatibility . . . . . . . . . . 4
+ 5. Relation Between the Media Types . . . . . . . . . . . . . 5
+ 6. Encoding Considerations . . . . . . . . . . . . . . . . . . 5
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . 6
+ 8. Interoperability Considerations . . . . . . . . . . . . . . 7
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
+ 10. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 7
+ 10.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 7
+ 10.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 10.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . 10
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 11
@@ -107,18 +108,17 @@
-
-Goncalves, et al. Expires October 10, 2008 [Page 2]
+Goncalves, et al. Expires October 21, 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.
+ 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] 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
@@ -144,14 +144,31 @@
HTTP, included in multi-part documents, or used in other places where
media types [RFC2045] are used.
-2. Conformance and Document Conventions
+2. Changes since RFC 3543
+ o The type "application/ogg" is redefined.
+ o The types "video/ogg" and "audio/ogg" are defined.
+ o New file extensions are defined.
+ o New Macintosh file type codes are defined.
+ o The codecs parameter is defined for optional use.
+ o The Ogg Skeleton extension becomes a recommended addition for
+ content served under the new types.
+
+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] and
indicate requirement levels for compliant implementations.
Requirements apply to all implementations unless otherwise stated.
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 3]
+
+Internet-Draft Ogg Media Types April 2008
+
+
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
@@ -161,17 +178,9 @@
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 10, 2008 [Page 3]
-
-Internet-Draft Ogg Media Types April 2008
-
-
implementations are "unconditionally compliant".
-3. Deployed Media Types and Compatibility
+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.
@@ -179,6 +188,7 @@
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
@@ -205,26 +215,25 @@
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.
+ These media types can optionally use the codecs parameter described
+ in [RFC4281]. Possible examples include:
-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 10, 2008 [Page 4]
+Goncalves, et al. Expires October 21, 2008 [Page 4]
Internet-Draft Ogg Media Types April 2008
+ o application/ogg; codecs="theora, cmml, ecmascript"
+ o video/ogg; codecs="theora, vorbis"
+ o audio/ogg; codecs=speex
+
+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 encapsulate 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.
@@ -248,7 +257,7 @@
is recommended. In situations where the Ogg bitstream predominantly
contains audio data, it is recommended to use the audio/ogg type.
-5. Encoding Considerations
+6. Encoding Considerations
Binary: The content consists of an unrestricted sequence of octets.
@@ -264,8 +273,16 @@
[VoRTP] or Speex [SpRTP] audio, as well as for identification of
the encapsulated data within Ogg.
-6. Security Considerations
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 5]
+
+Internet-Draft Ogg Media Types April 2008
+
+
+7. Security Considerations
+
Refer to [RFC3552] for a discussion of terminology used in this
section.
@@ -274,13 +291,6 @@
rigid definition. This format in itself is not more vulnerable than
any other content framing mechanism.
-
-
-Goncalves, et al. Expires October 10, 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
@@ -290,12 +300,14 @@
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.
+ 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
@@ -314,8 +326,19 @@
or sensitive information; such failure constitutes an unknown factor
and is thus considered out of the scope of this document.
-7. Interoperability Considerations
+
+
+
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 6]
+
+Internet-Draft Ogg Media Types April 2008
+
+
+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
@@ -326,26 +349,19 @@
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.
+9. IANA Considerations
-
-
-
-
-Goncalves, et al. Expires October 10, 2008 [Page 6]
-
-Internet-Draft Ogg Media Types April 2008
-
-
-8. IANA Considerations
-
In accordance with the procedures set forth in [RFC4288], this
document registers two new media types and redefines the existing
application/ogg as defined in the following section.
-9. Ogg Media Types
+10. Ogg Media Types
-9.1. application/ogg
+10.1. application/ogg
Type name: application
@@ -353,30 +369,38 @@
Required parameters: none
- Optional parameters: none
+ Optional parameters: codecs, as defined in RFC 4281.
- Encoding considerations: See section 5.
+ Encoding considerations: See section 6.
- Security considerations: See section 6.
+ Security considerations: See section 7.
- Interoperability considerations: None, as noted in section 7.
+ Interoperability considerations: None, as noted in section 8.
Published specification: RFC 3533
- Applications which use this media type: Scientific and other
- applications which require various multiplexed signals or streams of
- data.
+ 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:
+
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 7]
+
+Internet-Draft Ogg Media Types April 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,
+ RFC 3534 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.
+ where, historically, some implementations expect .ogg files to be
+ solely Vorbis-encoded audio.
Macintosh File Type Code(s): OggX
@@ -385,14 +409,6 @@
Intended usage: COMMON
-
-
-
-Goncalves, et al. Expires October 10, 2008 [Page 7]
-
-Internet-Draft Ogg Media Types April 2008
-
-
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
@@ -404,7 +420,7 @@
Change controller: The Xiph.Org Foundation.
-9.2. video/ogg
+10.2. video/ogg
Type name: video
@@ -412,19 +428,27 @@
Required parameters: none
- Optional parameters: none
+ Optional parameters: codecs, as defined in RFC 4281.
- Encoding considerations: See section 5.
+ Encoding considerations: See section 6.
- Security considerations: See section 6.
+ Security considerations: See section 7.
- Interoperability considerations: None, as noted in section 7.
+ Interoperability considerations: None, as noted in section 8.
Published specification: RFC 3533
Applications which use this media type: Multimedia applications,
- including hardware-based, streaming, and conferencing tools.
+ including embedded, streaming, and conferencing tools.
+
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 8]
+
+Internet-Draft Ogg Media Types April 2008
+
+
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
@@ -441,14 +465,6 @@
Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
bitstreams containing visual, audio, timed text, or any other type of
-
-
-
-Goncalves, et al. Expires October 10, 2008 [Page 8]
-
-Internet-Draft Ogg Media Types April 2008
-
-
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,
@@ -461,7 +477,7 @@
Change controller: The Xiph.Org Foundation.
-9.3. audio/ogg
+10.3. audio/ogg
Type name: audio
@@ -469,19 +485,26 @@
Required parameters: none
- Optional parameters: none
+ Optional parameters: codecs, as defined in RFC 4281.
- Encoding considerations: See section 5.
+ Encoding considerations: See section 6.
- Security considerations: See section 6.
+ Security considerations: See section 7.
- Interoperability considerations: None, as noted in section 7.
+ Interoperability considerations: None, as noted in section 8.
Published specification: RFC 3533
Applications which use this media type: Multimedia applications,
- including hardware-based, streaming, and conferencing tools.
+ including embedded, streaming, and conferencing tools.
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 9]
+
+Internet-Draft Ogg Media Types April 2008
+
+
Additional information:
Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
@@ -497,14 +520,6 @@
Intended usage: COMMON
Restrictions on usage: The type "audio/ogg" SHOULD be used when the
-
-
-
-Goncalves, et al. Expires October 10, 2008 [Page 9]
-
-Internet-Draft Ogg Media Types April 2008
-
-
Ogg bitstream predominantly contains audio data. Content served
under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
bitstream if they use the .oga extension. The .ogg and .spx file
@@ -517,7 +532,7 @@
Change controller: The Xiph.Org Foundation.
-10. Copying Conditions
+11. Copying Conditions
The authors agree to grant third parties the irrevocable right to
copy, use and distribute the work, with or without modification, in
@@ -525,9 +540,9 @@
permission is granted, redistributed modified works do not contain
misleading author, version, name of work, or endorsement information.
-11. References
+12. References
-11.1. Normative References
+12.1. Normative References
[RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533, May 2003.
@@ -539,11 +554,22 @@
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 10]
+
+Internet-Draft Ogg Media Types April 2008
+
+
+ [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.
-11.2. Informative References
+12.2. Informative References
[Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
logical and physical bitstream overview, Ogg logical
@@ -553,14 +579,6 @@
[RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
May 2003.
-
-
-
-Goncalves, et al. Expires October 10, 2008 [Page 10]
-
-Internet-Draft Ogg Media Types April 2008
-
-
[Theora] Xiph.Org Foundation, "Theora Specification",
October 2007, <http://theora.org/doc/Theora_spec.pdf>.
@@ -592,6 +610,13 @@
<http://tools.ietf.org/html/
draft-barbato-avt-rtp-theora>.
+
+
+Goncalves, et al. Expires October 21, 2008 [Page 11]
+
+Internet-Draft Ogg Media Types April 2008
+
+
[VoRTP] Barbato, L., "RTP Payload Format for Vorbis Encoded
Audio", November 2007,
<http://tools.ietf.org/html/draft-ietf-avt-rtp-vorbis>.
@@ -607,16 +632,6 @@
[libogg] Xiph.Org Foundation, "The libogg API", June 2000,
<http://xiph.org/ogg/doc/libogg>.
-
-
-
-
-
-Goncalves, et al. Expires October 10, 2008 [Page 11]
-
-Internet-Draft Ogg Media Types April 2008
-
-
Authors' Addresses
Ivo Emanuel Goncalves
@@ -653,22 +668,7 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Goncalves, et al. Expires October 10, 2008 [Page 12]
+Goncalves, et al. Expires October 21, 2008 [Page 12]
Internet-Draft Ogg Media Types April 2008
@@ -724,5 +724,5 @@
-Goncalves, et al. Expires October 10, 2008 [Page 13]
+Goncalves, et al. Expires October 21, 2008 [Page 13]
Modified: trunk/standards/draft-goncalves-rfc3534bis.xml
===================================================================
--- trunk/standards/draft-goncalves-rfc3534bis.xml 2008-04-18 13:15:06 UTC (rev 14774)
+++ trunk/standards/draft-goncalves-rfc3534bis.xml 2008-04-18 21:08:40 UTC (rev 14775)
@@ -6,7 +6,7 @@
<?rfc symrefs="yes" ?>
<?rfc rfcedstyle="yes" ?>
-<rfc ipr="full3978" docName="draft-goncalves-rfc3534bis-03" obsoletes="3534" category="std">
+<rfc ipr="full3978" docName="draft-goncalves-rfc3534bis-04" obsoletes="3534" category="std">
<front>
<title>Ogg Media Types</title>
<author initials="I.E." surname="Goncalves" fullname="Ivo Emanuel Goncalves">
@@ -37,7 +37,7 @@
<uri>http://xiph.org</uri>
</address>
</author>
- <date day="8" month="April" year="2008"/>
+ <date day="19" month="April" year="2008"/>
<area>Internet</area>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
@@ -45,17 +45,30 @@
<keyword>MIME</keyword>
<keyword>Video</keyword>
<keyword>Audio</keyword>
+ <keyword>Codecs</keyword>
<abstract>
<t>This document describes the registration of media types for the Ogg 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>This document describes media types for Ogg, a data encapsulation format defined by the Xiph.Org Foundation for public use. 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="Changes since RFC 3543">
+ <t>
+ <list style="symbols">
+ <t>The type "application/ogg" is redefined.</t>
+ <t>The types "video/ogg" and "audio/ogg" are defined.</t>
+ <t>New file extensions are defined.</t>
+ <t>New Macintosh file type codes are defined.</t>
+ <t>The codecs parameter is defined for optional use.</t>
+ <t>The Ogg Skeleton extension becomes a recommended addition for content served under the new types.</t>
+ </list>
+ </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>
@@ -64,14 +77,23 @@
<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>
+ <list style="symbols">
+ <t>video/ogg</t>
+ <t>audio/ogg</t>
+ </list>
+ </t>
<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. Refer to the following section for more details.</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 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.</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. Such precaution ensures backward and forward compatibility with existing and future data.</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>
+ <t>These media types can optionally use the codecs parameter described in <xref target="RFC4281"/>. Possible examples include:</t>
+ <t>
+ <list style="symbols">
+ <t>application/ogg; codecs="theora, cmml, ecmascript"</t>
+ <t>video/ogg; codecs="theora, vorbis"</t>
+ <t>audio/ogg; codecs=speex</t>
+ </list>
+ </t>
</section>
<section title="Relation Between the Media Types">
<t>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 usage scenarios have revealed interoperability issues between implementations when dealing with content served solely under the application/ogg type.</t>
@@ -90,14 +112,16 @@
<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 data streams has to ensure correct handling of manipulated bitstreams, of buffer overflows, and similar issues.</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.</t>
+ <t>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.</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 revised (3-clause) BSD license, which is a Free Software license.</t>
+ <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 revised (3-clause) BSD license, which is a Free Software license.</t>
<t>The Xiph.Org Foundation has defined the specification, interoperability, and conformance, and conducts regular interoperability testing.</t>
+ <t>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.</t>
</section>
<section title="IANA Considerations">
<t>In accordance with the procedures set forth in <xref target="RFC4288"/>, this document registers two new media types and redefines the existing application/ogg as defined in the following section.</t>
@@ -107,17 +131,17 @@
<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 5.</t>
- <t>Security considerations: See section 6.</t>
- <t>Interoperability considerations: None, as noted in section 7.</t>
+ <t>Optional parameters: codecs, as defined in RFC 4281.</t>
+ <t>Encoding considerations: See section 6.</t>
+ <t>Security considerations: See section 7.</t>
+ <t>Interoperability considerations: None, as noted in section 8.</t>
<t>Published specification: RFC 3533</t>
- <t>Applications which use this media type: Scientific and other applications which require various multiplexed signals or streams of data.</t>
+ <t>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.</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>
+ <t>RFC 3534 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 files 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>
@@ -130,12 +154,12 @@
<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 5.</t>
- <t>Security considerations: See section 6.</t>
- <t>Interoperability considerations: None, as noted in section 7.</t>
+ <t>Optional parameters: codecs, as defined in RFC 4281.</t>
+ <t>Encoding considerations: See section 6.</t>
+ <t>Security considerations: See section 7.</t>
+ <t>Interoperability considerations: None, as noted in section 8.</t>
<t>Published specification: RFC 3533</t>
- <t>Applications which use this media type: Multimedia applications, including hardware-based, streaming, and conferencing tools.</t>
+ <t>Applications which use this media type: Multimedia applications, including embedded, 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>
@@ -150,12 +174,12 @@
<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 5.</t>
- <t>Security considerations: See section 6.</t>
- <t>Interoperability considerations: None, as noted in section 7.</t>
+ <t>Optional parameters: codecs, as defined in RFC 4281.</t>
+ <t>Encoding considerations: See section 6.</t>
+ <t>Security considerations: See section 7.</t>
+ <t>Interoperability considerations: None, as noted in section 8.</t>
<t>Published specification: RFC 3533</t>
- <t>Applications which use this media type: Multimedia applications, including hardware-based, streaming, and conferencing tools.</t>
+ <t>Applications which use this media type: Multimedia applications, including embedded, 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>
@@ -206,12 +230,28 @@
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
+ <reference anchor="RFC4281">
+ <front>
+ <title>The Codecs Parameter for "Bucket" Media Types</title>
+ <author initials="R." surname="Gellens" fullname="Randall Gellens">
+ <organization abbrev="Qualcomm">QUALCOMM Incorporated</organization>
+ </author>
+ <author initials="D." surname="Singer" fullname="David Singer">
+ <organization abbrev="Apple">Apple Computer, Inc.</organization>
+ </author>
+ <author initials="P." surname="Frojdh" fullname="Per Frojdh">
+ <organization abbrev="Ericsson">Ericsson Research</organization>
+ </author>
+ <date month="November" year="2005"/>
+ </front>
+ <seriesInfo name="RFC" value="4281"/>
+ </reference>
<reference anchor="RFC4288">
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials="N." surname="Freed" fullname="Ned Freed">
<organization>Sun Microsystems</organization>
- </author>John C. Klensin
+ </author>
<author initials="J." surname="Klensin" fullname="John C. Klensin"/>
<date month="December" year="2005"/>
</front>
More information about the commits
mailing list