Add RFC5334 and link to it.

git-svn-id: http://svn.xiph.org/trunk/ogg@15269 0101bb08-14d6-0310-b084-bc0e0c8e3800

2 files changed, 788 insertions, 1 deletions

diff --git a/doc/index.html b/doc/index.html
index cdef857..a461364 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -91,7 +91,7 @@ li {
 
 <ul>
 <li><a href="rfc3533.txt">rfc3533: The Ogg Encapsulation Format Version 0</a></li>
-<li><a href="rfc3534.txt">rfc3534: The application/ogg Media Type</a></li>
+<li><a href="rfc5334.txt">rfc5334: Ogg Media Types</a></li>
 </ul>
 
 <div id="copyright">
diff --git a/doc/rfc5334.txt b/doc/rfc5334.txt
new file mode 100644
index 0000000..fea91fb
--- /dev/null
+++ b/doc/rfc5334.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                       I. Goncalves
+Request for Comments: 5334                                   S. Pfeiffer
+Obsoletes: 3534                                            C. Montgomery
+Category: Standards Track                                           Xiph
+                                                          September 2008
+
+
+                            Ogg Media Types
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes the registration of media types for the Ogg
+   container format and conformance requirements for implementations of
+   these types.  This document obsoletes RFC 3534.
+
+Table of Contents
+
+   1.     Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.     Changes Since RFC 3534  . . . . . . . . . . . . . . . . . .  2
+   3.     Conformance and Document Conventions  . . . . . . . . . . .  3
+   4.     Deployed Media Types and Compatibility  . . . . . . . . . .  3
+   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.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 10
+   12.    Copying Conditions  . . . . . . . . . . . . . . . . . . . . 10
+   13.    References  . . . . . . . . . . . . . . . . . . . . . . . . 11
+   13.1.  Normative References  . . . . . . . . . . . . . . . . . . . 11
+   13.2.  Informative References  . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 1]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+1.  Introduction
+
+   This document describes media types for Ogg, a data encapsulation
+   format defined by the Xiph.Org Foundation for public use.  Refer to
+   "Introduction" in [RFC3533] 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.  Changes Since RFC 3534
+
+   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.
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 2]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+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.
+
+   An implementation is a software module that supports one of the media
+   types defined in this document.  Software modules may support
+   multiple media types, but conformance is considered individually for
+   each type.
+
+   Implementations that fail to satisfy one or more "MUST" requirements
+   are considered non-compliant.  Implementations that satisfy all
+   "MUST" requirements, but fail to satisfy one or more "SHOULD"
+   requirements, are said to be "conditionally compliant".  All other
+   implementations are "unconditionally compliant".
+
+4.  Deployed Media Types and Compatibility
+
+   The application/ogg media type has been used in an ad hoc fashion to
+   label and exchange multimedia content in Ogg containers.
+
+   Use of the "application" top-level type for this kind of content is
+   known to be problematic, in particular since it obfuscates video and
+   audio content.  This document thus defines the media types,
+
+   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.
+   Refer to the following section for more details.
+
+   An Ogg bitstream generally consists of one or more logical bitstreams
+   that each consist of a series of header and data pages packetising
+   time-continuous binary data [RFC3533].  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 Ogg Skeleton is REQUIRED for content served under
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 3]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   the application/ogg type and RECOMMENDED for video/ogg and audio/ogg,
+   as Skeleton contains identifiers to describe the different
+   encapsulated data.
+
+   Furthermore, it is RECOMMENDED that implementations that identify a
+   logical bitstream 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.
+
+   These media types can optionally use the "codecs" parameter described
+   in [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.
+
+        Codec Identifier             | Codecs Parameter
+       -----------------------------------------------------------
+        char[5]: 'BBCD\0'            | dirac
+        char[5]: '\177FLAC'          | flac
+        char[7]: '\x80theora'        | theora
+        char[7]: '\x01vorbis'        | vorbis
+        char[8]: 'CELT    '          | celt
+        char[8]: 'CMML\0\0\0\0'      | cmml
+        char[8]: '\213JNG\r\n\032\n' | jng
+        char[8]: '\x80kate\0\0\0'    | kate
+        char[8]: 'OggMIDI\0'         | midi
+        char[8]: '\212MNG\r\n\032\n' | mng
+        char[8]: 'PCM     '          | pcm
+        char[8]: '\211PNG\r\n\032\n' | png
+        char[8]: 'Speex   '          | speex
+        char[8]: 'YUV4MPEG'          | yuv4mpeg
+
+   An up-to-date version of this table is kept at Xiph.org (see
+   [Codecs]).
+
+   Possible examples include:
+
+   o  application/ogg; codecs="theora, cmml, ecmascript"
+
+   o  video/ogg; codecs="theora, vorbis"
+
+   o  audio/ogg; codecs=speex
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 4]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+5.  Relation between the Media Types
+
+   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.
+
+   While this document does redefine the earlier definition of
+   application/ogg, this media type will continue to embrace the widest
+   net possible of content with the video/ogg and audio/ogg types being
+   smaller subsets of it.  However, the video/ogg and audio/ogg types
+   take precedence in a subset of the usages, specifically when serving
+   multimedia content that is not complex enough to warrant the use of
+   application/ogg.  Following this line of thought, the audio/ogg type
+   is an even smaller subset within video/ogg, as it is not intended to
+   refer to visual content.
+
+   As such, the application/ogg type is the recommended choice to serve
+   content aimed at scientific and other applications that require
+   various multiplexed signals or streams of continuous data, with or
+   without scriptable control of content.  For bitstreams containing
+   visual, timed text, and any other type of material that requires a
+   visual interface, but 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.
+
+6.  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.
+
+   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 to identify codecs such as in
+      real-time applications for the RTP payload formats of Theora
+      [ThRTP] video, Vorbis [RFC5215], or Speex [SpRTP] audio, as well
+      as for identification of encapsulated data within Ogg through
+      Skeleton.
+
+
+
+Goncalves, et al.           Standards Track                     [Page 5]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+7.  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.
+
+   Issues may arise on applications that use Ogg for streaming or file
+   transfer in a networking scenario.  In such cases, implementations
+   decoding Ogg and its encapsulated bitstreams have to ensure correct
+   handling of manipulated bitstreams, of buffer overflows, and similar
+   issues.
+
+   It is also possible to author malicious Ogg bitstreams, which attempt
+   to call for an excessively large picture size, high sampling-rate
+   audio, etc.  Implementations SHOULD protect themselves against this
+   kind of attack.
+
+   Ogg has an extensible structure, so that it is theoretically possible
+   that metadata fields or media formats might be defined in the future
+   which might be used to induce particular actions on the part of the
+   recipient, thus presenting additional security risks.  However, this
+   type of capability is currently not supported in the referenced
+   specification.
+
+   Implementations may fail to implement a specific security model or
+   other means to prevent possibly dangerous operations.  Such failure
+   might possibly be exploited to gain unauthorized access to a system
+   or sensitive information; such failure constitutes an unknown factor
+   and is thus considered out of the scope of this document.
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 6]
+
+RFC 5334                    Ogg Media Types               September 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
+   portable reference implementation [libogg] is available under the
+   revised (3-clause) BSD license, which is a Free Software license.
+
+   The Xiph.Org Foundation has defined the specification,
+   interoperability, and conformance and conducts regular
+   interoperability testing.
+
+   The use of the Ogg Skeleton extension has been confirmed to not cause
+   interoperability issues with existing implementations.  Third parties
+   are, however, welcome to conduct their own testing.
+
+9.  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.
+
+10.  Ogg Media Types
+
+10.1.  application/ogg
+
+   Type name: application
+
+   Subtype name: ogg
+
+   Required parameters: none
+
+   Optional parameters: codecs, whose syntax is defined in RFC 4281.
+   See section 4 of RFC 5334 for a list of allowed values.
+
+   Encoding considerations: See section 6 of RFC 5334.
+
+   Security considerations: See section 7 of RFC 5334.
+
+   Interoperability considerations: None, as noted in section 8 of RFC
+   5334.
+
+   Published specification: RFC 3533
+
+   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.
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 7]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   Additional information:
+
+   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+   correspond to the string "OggS".
+
+   File extension(s): .ogx
+
+      RFC 3534 defined the file extension .ogg for application/ogg,
+      which RFC 5334 obsoletes in favor of .ogx due to concerns where,
+      historically, some implementations expect .ogg files to be solely
+      Vorbis-encoded audio.
+
+   Macintosh File Type Code(s): OggX
+
+   Person & Email address to contact for further information: See
+   "Authors' Addresses" section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: The type application/ogg SHOULD only be used
+   in situations where it is not appropriate to serve data under the
+   video/ogg or audio/ogg types.  Data served under the application/ogg
+   type SHOULD use the .ogx file extension and MUST contain an Ogg
+   Skeleton logical bitstream to identify all other contained logical
+   bitstreams.
+
+   Author: See "Authors' Addresses" section.
+
+   Change controller: The Xiph.Org Foundation.
+
+10.2.  video/ogg
+
+   Type name: video
+
+   Subtype name: ogg
+
+   Required parameters: none
+
+   Optional parameters: codecs, whose syntax is defined in RFC 4281.
+   See section 4 of RFC 5334 for a list of allowed values.
+
+   Encoding considerations: See section 6 of RFC 5334.
+
+   Security considerations: See section 7 of RFC 5334.
+
+   Interoperability considerations: None, as noted in section 8 of RFC
+   5334.
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 8]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   Published specification: RFC 3533
+
+   Applications which use this media type: Multimedia applications,
+   including embedded, streaming, and conferencing tools.
+
+   Additional information:
+
+   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+   correspond to the string "OggS".
+
+   File extension(s): .ogv
+
+   Macintosh File Type Code(s): OggV
+
+   Person & Email address to contact for further information: See
+   "Authors' Addresses" section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: The type "video/ogg" SHOULD be used for Ogg
+   bitstreams containing visual, audio, timed text, or any other type of
+   material that requires a visual interface.  It is intended for
+   content not complex enough to warrant serving under "application/
+   ogg"; for example, a combination of Theora video, Vorbis audio,
+   Skeleton metadata, and CMML captioning.  Data served under the type
+   "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
+   Implementations interacting with the type "video/ogg" SHOULD support
+   multiplexed bitstreams.
+
+   Author: See "Authors' Addresses" section.
+
+   Change controller: The Xiph.Org Foundation.
+
+10.3.  audio/ogg
+
+   Type name: audio
+
+   Subtype name: ogg
+
+   Required parameters: none
+
+   Optional parameters: codecs, whose syntax is defined in RFC 4281.
+   See section 4 of RFC 5334 for a list of allowed values.
+
+   Encoding considerations: See section 6 of RFC 5334.
+
+   Security considerations: See section 7 of RFC 5334.
+
+
+
+
+Goncalves, et al.           Standards Track                     [Page 9]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   Interoperability considerations: None, as noted in section 8 of RFC
+   5334.
+
+   Published specification: RFC 3533
+
+   Applications which use this media type: Multimedia applications,
+   including embedded, streaming, and conferencing tools.
+
+   Additional information:
+
+   Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+   correspond to the string "OggS".
+
+   File extension(s): .oga, .ogg, .spx
+
+   Macintosh File Type Code(s): OggA
+
+   Person & Email address to contact for further information: See
+   "Authors' Addresses" section.
+
+   Intended usage: COMMON
+
+   Restrictions on usage: The type "audio/ogg" SHOULD be used when the
+   Ogg bitstream predominantly contains audio data.  Content served
+   under the "audio/ogg" type SHOULD have an Ogg Skeleton logical
+   bitstream when using the default .oga file extension.  The .ogg and
+   .spx file extensions indicate a specialization that requires no
+   Skeleton due to backward compatibility concerns with existing
+   implementations.  In particular, .ogg is used for Ogg files that
+   contain only a Vorbis bitstream, while .spx is used for Ogg files
+   that contain only a Speex bitstream.
+
+   Author: See "Authors' Addresses" section.
+
+   Change controller: The Xiph.Org Foundation.
+
+11.  Acknowledgements
+
+   The authors gratefully acknowledge the contributions of Magnus
+   Westerlund, Alfred Hoenes, and Peter Saint-Andre.
+
+12.  Copying Conditions
+
+   The authors agree to grant third parties the irrevocable right to
+   copy, use and distribute the work, with or without modification, in
+   any medium, without royalty, provided that, unless separate
+   permission is granted, redistributed modified works do not contain
+   misleading author, version, name of work, or endorsement information.
+
+
+
+Goncalves, et al.           Standards Track                    [Page 10]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3533]   Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+               RFC 3533, May 2003.
+
+   [RFC4281]   Gellens, R., Singer, D., and P. Frojdh, "The Codecs
+               Parameter for "Bucket" Media Types", RFC 4281,
+               November 2005.
+
+   [RFC4288]   Freed, N. and J. Klensin, "Media Type Specifications and
+               Registration Procedures", BCP 13, RFC 4288,
+               December 2005.
+
+13.2.  Informative References
+
+   [CMML]      Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
+               Media Markup Language (CMML)", Work in Progress,
+               March 2006.
+
+   [Codecs]    Pfeiffer, S. and I. Goncalves, "Specification of MIME
+               types and respective codecs parameter", July 2008,
+               <http://wiki.xiph.org/index.php/MIMETypesCodecs>.
+
+   [Dirac]     Dirac Group, "Dirac Specification",
+               <http://diracvideo.org/specifications/>.
+
+   [FLAC]      Coalson, J., "The FLAC Format",
+               <http://flac.sourceforge.net/format.html>.
+
+   [libogg]    Xiph.Org Foundation, "The libogg API", June 2000,
+               <http://xiph.org/ogg/doc/libogg>.
+
+   [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>.
+
+   [RFC3534]   Walleij, L., "The application/ogg Media Type", RFC 3534,
+               May 2003.
+
+
+
+Goncalves, et al.           Standards Track                    [Page 11]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+   [RFC3552]   Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+               Text on Security Considerations", BCP 72, RFC 3552,
+               July 2003.
+
+   [RFC4648]   Josefsson, S., "The Base16, Base32, and Base64 Data
+               Encodings", RFC 4648, October 2006.
+
+   [RFC5215]   Barbato, L., "RTP Payload Format for Vorbis Encoded
+               Audio", RFC 5215, August 2008.
+
+   [Skeleton]  Pfeiffer, S. and C. Parker, "The Ogg Skeleton Metadata
+               Bitstream", November 2007,
+               <http://xiph.org/ogg/doc/skeleton.html>.
+
+   [Speex]     Valin, J., "The Speex Codec Manual", February 2002,
+               <http://speex.org/docs/manual/speex-manual>.
+
+   [SpRTP]     Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
+               "RTP Payload Format for the Speex Codec", Work
+               in Progress, February 2008.
+
+   [Theora]    Xiph.Org Foundation, "Theora Specification",
+               October 2007, <http://theora.org/doc/Theora.pdf>.
+
+   [ThRTP]     Barbato, L., "RTP Payload Format for Theora Encoded
+               Video", Work in Progress, June 2006.
+
+   [Vorbis]    Xiph.Org Foundation, "Vorbis I Specification", July 2004,
+               <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                    [Page 12]
+
+RFC 5334                    Ogg Media Types               September 2008
+
+
+Authors' Addresses
+
+   Ivo Emanuel Goncalves
+   Xiph.Org Foundation
+   21 College Hill Road
+   Somerville, MA  02144
+   US
+
+   EMail: justivo@gmail.com
+   URI:   xmpp:justivo@gmail.com
+
+
+   Silvia Pfeiffer
+   Xiph.Org Foundation
+
+   EMail: silvia@annodex.net
+   URI:   http://annodex.net/
+
+
+   Christopher Montgomery
+   Xiph.Org Foundation
+
+   EMail: monty@xiph.org
+   URI:   http://xiph.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                    [Page 13]
+
+RFC 5334                    Ogg Media Types               September 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@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al.           Standards Track                    [Page 14]
+