[xiph-commits] r15184 - trunk/standards
silvia at svn.xiph.org
silvia at svn.xiph.org
Thu Aug 14 21:10:25 PDT 2008
Author: silvia
Date: 2008-08-14 21:10:25 -0700 (Thu, 14 Aug 2008)
New Revision: 15184
Added:
trunk/standards/rfc5334.xml
Log:
added xml file from RFC editor
Added: trunk/standards/rfc5334.xml
===================================================================
--- trunk/standards/rfc5334.xml (rev 0)
+++ trunk/standards/rfc5334.xml 2008-08-15 04:10:25 UTC (rev 15184)
@@ -0,0 +1,646 @@
+<?xml version="1.0"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+
+<?rfc toc="yes" ?>
+<?rfc tocindent="no" ?>
+<?rfc symrefs="yes" ?>
+<?rfc rfcedstyle="yes" ?>
+
+<rfc number="5334" 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>
+ <email>silvia at annodex.net</email>
+ <uri>http://annodex.net/</uri>
+ </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 month="August" 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>
+ <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. This document obsoletes <xref target="RFC3534"/>.</t>
+ </abstract>
+ </front>
+ <middle>
+ <section title="Introduction">
+ <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 3534">
+ <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>
+ <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>
+ <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 Skeleton contains identifiers to describe the different encapsulated data.</t>
+ <t>Furthermore, it is RECOMMENDED that implementations that identify a logical bitstream that 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>These media types can optionally use the "codecs" parameter described in <xref target="RFC4281"/>. Codecs encapsulated in Ogg require a text identifier at the beginning of the first header page, hence a machine-readable method to identify the encapsulated codecs would be through this header. The following table illustrates how those header values map into strings that are used in the "codecs" parameter when dealing with Ogg media types.</t>
+ <figure>
+ <artwork><![CDATA[
+ Codec Identifier | Codecs Parameter
+ -----------------------------------------------------------
+ char[5]: 'BBCD\0' | dirac
+ char[5]: '\177FLAC' | flac
+ char[7]: '\x80theora' | theora
+ char[7]: '\x01vorbis' | vorbis
+ char[8]: 'Speex ' | speex
+ char[8]: 'OggMIDI\0' | midi
+ char[8]: 'CMML\0\0\0\0' | cmml
+ char[8]: '\211PNG\r\n\032\n' | png
+ char[8]: '\212MNG\r\n\032\n' | mng
+ char[8]: '\213JNG\r\n\032\n' | jng
+ char[8]: 'CELT ' | celt
+ char[8]: 'PCM ' | pcm
+ char[9]: '\x80kate\0\0\0\0' | kate
+ char[9]: 'YUV4MPEG2' | yuv4mpeg
+ ]]></artwork>
+ </figure>
+ <t>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 that are targeted at different data encapsulated in Ogg. Since Ogg is capable of encapsulating any kind of data, the multiple usage scenarios have revealed interoperability issues between implementations when dealing with content served solely under the application/ogg type.</t>
+ <t>While this document does redefine the earlier definition of application/ogg, this media type will continue to embrace the widest net possible of content with the video/ogg and audio/ogg types being smaller subsets of it. However, the video/ogg and audio/ogg types take precedence in a subset of the usages, specifically when serving multimedia content that is not complex enough to warrant the use of application/ogg. Following this line of thought, the audio/ogg type is an even smaller subset within video/ogg, as it is not intended to refer to visual content.</t>
+ <t>As such, the application/ogg type is the recommended choice to serve content aimed at scientific and other applications that require various multiplexed signals or streams of continuous data, with or without scriptable control of content. For bitstreams containing visual, timed text, and any other type of material that requires a visual interface, but that is not complex enough to warrant serving under application/ogg, the video/ogg type is recommended. In situations where the Ogg bitstream predominantly contains audio data (lyrics, metadata, or cover art notwithstanding), it is recommended to use the audio/ogg type.</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 to identify codecs such as in real-time applications for the RTP payload formats of <xref target="ThRTP">Theora</xref> video, <xref target="RFC5215">Vorbis</xref>, or <xref target="SpRTP">Speex</xref> audio, as well as for identification of encapsulated data within Ogg through Skeleton.</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.</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 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 to not 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>
+ </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: codecs, whose syntax is defined in RFC 4281. See section 4 of RFC &rfc.number; for a list of allowed values.</t>
+ <t>Encoding considerations: See section 6 of RFC &rfc.number;.</t>
+ <t>Security considerations: See section 7 of RFC &rfc.number;.</t>
+ <t>Interoperability considerations: None, as noted in section 8 of RFC &rfc.number;.</t>
+ <t>Published specification: RFC 3533</t>
+ <t>Applications which use this media type: Scientific and otherwise that 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>RFC 3534 defined the file extension .ogg for application/ogg, which RFC &rfc.number; 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>
+ <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 data under the video/ogg or audio/ogg types. Data served under the application/ogg type SHOULD use the .ogx file extension and MUST contain an Ogg Skeleton logical bitstream to identify all other contained logical bitstreams.</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: codecs, whose syntax is defined in RFC 4281. See section 4 of RFC &rfc.number; for a list of allowed values.</t>
+ <t>Encoding considerations: See section 6 of RFC &rfc.number;.</t>
+ <t>Security considerations: See section 7 of RFC &rfc.number;.</t>
+ <t>Interoperability considerations: None, as noted in section 8 of RFC &rfc.number;.</t>
+ <t>Published specification: RFC 3533</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>
+ <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" SHOULD be used for Ogg bitstreams containing visual, audio, timed text, or any other type of material that requires a visual interface. It is intended for content not complex enough to warrant serving under "application/ogg"; for example, a combination of Theora video, Vorbis audio, Skeleton metadata, and CMML captioning. Data served under the type "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream. Implementations interacting with the type "video/ogg" SHOULD support multiplexed bitstreams.</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: codecs, whose syntax is defined in RFC 4281. See section 4 of RFC &rfc.number; for a list of allowed values.</t>
+ <t>Encoding considerations: See section 6 of RFC &rfc.number;.</t>
+ <t>Security considerations: See section 7 of RFC &rfc.number;.</t>
+ <t>Interoperability considerations: None, as noted in section 8 of RFC &rfc.number;.</t>
+ <t>Published specification: RFC 3533</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>
+ <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" SHOULD be used when the Ogg bitstream predominantly contains audio data. Content served under the "audio/ogg" type SHOULD have an Ogg Skeleton logical bitstream when using the default .oga file extension. The .ogg and .spx file extensions indicate a specialization that requires no Skeleton due to backward compatibility concerns with existing implementations. In particular, .ogg is used for Ogg files that contain only a Vorbis bitstream, while .spx is used for Ogg files that contain only a Speex bitstream.</t>
+ <t>Author: See "Authors' Addresses" section.</t>
+ <t>Change controller: The Xiph.Org Foundation.</t>
+ </section>
+ </section>
+ <section title="Acknowledgements">
+ <t>The authors gratefully acknowledge the contributions of Magnus Westerlund, Alfred Hoenes, and Peter Saint-Andre.</t>
+ </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="RFC2045">
+−
+<front>
+−
+<title abbrev="Internet Message Bodies">
+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>
+−
+<address>
+−
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<city>West Covina</city>
+<region>CA</region>
+<code>91790</code>
+<country>US</country>
+</postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned at innosoft.com</email>
+</address>
+</author>
+−
+<author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+<organization>First Virtual Holdings</organization>
+−
+<address>
+−
+<postal>
+<street>25 Washington Avenue</street>
+<city>Morristown</city>
+<region>NJ</region>
+<code>07960</code>
+<country>US</country>
+</postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb at nsb.fv.com</email>
+</address>
+</author>
+<date year="1996" month="November"/>
+−
+<abstract>
+−
+<t>
+STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for
+</t>
+−
+<t>
+(1) textual message bodies in character sets other than US-ASCII,
+</t>
+−
+<t>
+(2) an extensible set of different formats for non-textual message bodies,
+</t>
+<t>(3) multi-part message bodies, and</t>
+−
+<t>
+(4) textual header information in character sets other than US-ASCII.
+</t>
+−
+<t>
+These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
+</t>
+−
+<t>
+This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance
+ criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
+</t>
+−
+<t>
+These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="2045"/>
+<format type="TXT" octets="72932" target="ftp://ftp.isi.edu/in-notes/rfc2045.txt"/>
+</reference>
+ <reference anchor="RFC2119">
+−
+<front>
+−
+<title abbrev="RFC Key Words">
+Key words for use in RFCs to Indicate Requirement Levels
+</title>
+−
+<author initials="S." surname="Bradner" fullname="Scott Bradner">
+<organization>Harvard University</organization>
+−
+<address>
+−
+<postal>
+<street>1350 Mass. Ave.</street>
+<street>Cambridge</street>
+<street>MA 02138</street>
+</postal>
+<phone>- +1 617 495 3864</phone>
+<email>sob at harvard.edu</email>
+</address>
+</author>
+<date year="1997" month="March"/>
+<area>General</area>
+<keyword>keyword</keyword>
+−
+<abstract>
+−
+<t>
+
+ In many standards track documents several words are used to signify
+ the requirements in the specification. These words are often
+ capitalized. This document defines these words as they should be
+ interpreted in IETF documents. Authors who follow these guidelines
+ should incorporate this phrase near the beginning of their document:
+
+−
+<list>
+−
+<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
+ RFC 2119.
+</t>
+</list>
+</t>
+−
+<t>
+
+ Note that the force of these words is modified by the requirement
+ level of the document in which they are used.
+</t>
+</abstract>
+</front>
+<seriesInfo name="BCP" value="14"/>
+<seriesInfo name="RFC" value="2119"/>
+<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
+<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
+<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
+</reference>
+−
+<reference anchor="RFC3533">
+−
+<front>
+<title>The Ogg Encapsulation Format Version 0</title>
+−
+<author initials="S." surname="Pfeiffer" fullname="S. Pfeiffer">
+<organization/>
+</author>
+<date year="2003" month="May"/>
+−
+<abstract>
+−
+<t>
+This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams. It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. This memo provides information for the Internet community. This memo provides information for the Internet community.
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="3533"/>
+<format type="TXT" octets="32045" target="ftp://ftp.isi.edu/in-notes/rfc3533.txt"/>
+</reference>
+−
+<reference anchor="RFC4281">
+−
+<front>
+<title>The Codecs Parameter for "Bucket" Media Types</title>
+−
+<author initials="R." surname="Gellens" fullname="R. Gellens">
+<organization/>
+</author>
+−
+<author initials="D." surname="Singer" fullname="D. Singer">
+<organization/>
+</author>
+−
+<author initials="P." surname="Frojdh" fullname="P. Frojdh">
+<organization/>
+</author>
+<date year="2005" month="November"/>
+−
+<abstract>
+−
+<t>
+Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from the Content-Type alone if the content can be rendered.</t><t> This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within.</t><t> By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and instal
ling the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.) [STANDARDS TRACK]
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="4281"/>
+<format type="TXT" octets="25529" target="ftp://ftp.isi.edu/in-notes/rfc4281.txt"/>
+</reference>
+<reference anchor="RFC4288">
+−
+<front>
+−
+<title>
+Media Type Specifications and Registration Procedures
+</title>
+−
+<author initials="N." surname="Freed" fullname="N. Freed">
+<organization/>
+</author>
+−
+<author initials="J." surname="Klensin" fullname="J. Klensin">
+<organization/>
+</author>
+<date year="2005" month="December"/>
+−
+<abstract>
+−
+<t>
+This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+</t>
+</abstract>
+</front>
+<seriesInfo name="BCP" value="13"/>
+<seriesInfo name="RFC" value="4288"/>
+<format type="TXT" octets="52667" target="ftp://ftp.isi.edu/in-notes/rfc4288.txt"/>
+</reference>
+ </references>
+ <references title="Informative References">
+ <reference anchor="CMML">
+ <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>
+ <seriesInfo name='Work in' value='Progress' />
+ </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="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="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>
+ <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="RFC3534">
+−
+<front>
+<title>The application/ogg Media Type</title>
+−
+<author initials="L." surname="Walleij" fullname="L. Walleij">
+<organization/>
+</author>
+<date year="2003" month="May"/>
+−
+<abstract>
+−
+<t>
+The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the Ogg Bitstream Format developers that it be usable without intellectual property concerns. [STANDARDS TRACK]
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="3534"/>
+<format type="TXT" octets="10013" target="ftp://ftp.isi.edu/in-notes/rfc3534.txt"/>
+</reference>
+
+<reference anchor="RFC3552">
+−
+<front>
+−
+<title>
+Guidelines for Writing RFC Text on Security Considerations
+</title>
+−
+<author initials="E." surname="Rescorla" fullname="E. Rescorla">
+<organization/>
+</author>
+−
+<author initials="B." surname="Korver" fullname="B. Korver">
+<organization/>
+</author>
+<date year="2003" month="July"/>
+−
+<abstract>
+−
+<t>
+All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
+</t>
+</abstract>
+</front>
+<seriesInfo name="BCP" value="72"/>
+<seriesInfo name="RFC" value="3552"/>
+<format type="TXT" octets="110393" target="ftp://ftp.isi.edu/in-notes/rfc3552.txt"/>
+</reference>
+
+<reference anchor="RFC4648">
+−
+<front>
+<title>The Base16, Base32, and Base64 Data Encodings</title>
+−
+<author initials="S." surname="Josefsson" fullname="S. Josefsson">
+<organization/>
+</author>
+<date year="2006" month="October"/>
+−
+<abstract>
+−
+<t>
+This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS TRACK]
+</t>
+</abstract>
+</front>
+<seriesInfo name="RFC" value="4648"/>
+<format type="TXT" octets="35491" target="ftp://ftp.isi.edu/in-notes/rfc4648.txt"/>
+</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="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="SpRTP" >
+ <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="February" year="2008"/>
+ </front>
+ <seriesInfo name="Work in" value="Progress"/>
+ </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="ThRTP" >
+ <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="June" year="2006"/>
+ </front>
+ <seriesInfo name="Work in" value="Progress"/>
+ </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="RFC5215" >
+ <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="August" year="2008"/>
+ </front>
+ <seriesInfo name="RFC" value="5215"/>
+ </reference>
+ </references>
+ </back>
+</rfc>
More information about the commits
mailing list