[xiph-commits] r14132 - experimental/ivo/drafts
ivo at svn.xiph.org
ivo at svn.xiph.org
Mon Nov 12 04:16:51 PST 2007
Author: ivo
Date: 2007-11-12 04:16:51 -0800 (Mon, 12 Nov 2007)
New Revision: 14132
Modified:
experimental/ivo/drafts/draft-xiph-rfc3534bis.txt
Log:
output file from XML with old name so not to break external links
Modified: experimental/ivo/drafts/draft-xiph-rfc3534bis.txt
===================================================================
--- experimental/ivo/drafts/draft-xiph-rfc3534bis.txt 2007-11-12 12:16:17 UTC (rev 14131)
+++ experimental/ivo/drafts/draft-xiph-rfc3534bis.txt 2007-11-12 12:16:51 UTC (rev 14132)
@@ -1,49 +1,118 @@
-Network Working Group I. E. Goncalves
+
+
+
+Network Working Group I. Goncalves
Internet-Draft S. Pfeiffer
-Expires: xxxxx, 2008 C. Montgomery
- Xiph
- October 22, 2007
+Obsoletes: 3534 (if approved) C. Montgomery
+Intended status: Standards Track Xiph
+Expires: May 14, 2008 November 11, 2007
- Ogg Media Types
+ Ogg Media Types
+ draft-goncalves-rfc3534bis-00
+
Status of This Memo
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 14, 2008.
+
Copyright Notice
- Copyright (C) The Internet Society (2007).
+ Copyright (C) The IETF Trust (2007).
Abstract
- This document describes the registration of media types for
- the Ogg container format and conformance requirements for
+ This document describes the registration of media types for the Ogg
+ [RFC3533] container format and conformance requirements for
implementations of these types.
+
+
+
+
+
+
+Goncalves, et al. Expires May 14, 2008 [Page 1]
+
+Internet-Draft Ogg Media Types November 2007
+
+
Table of Contents
- 1. Introduction ....................................................2
- 2. Conformance and Document Conventions ............................2
- 3. Deployed Media Types and Compatibility ..........................3
- 4. Selection of MIME Types for Ogg bitstreams ......................4
- 5. Encoding Considerations .........................................5
- 6. Security Considerations .........................................6
- 7. Interoperability Considerations .................................7
- 8. IANA Considerations .............................................8
- 9. Ogg Media Types .................................................9
- 9.1. application/ogg ............................................9
- 9.2. video/ogg .................................................10
- 9.3. audio/ogg .................................................11
- 10. References ....................................................13
- 10.1. Normative References .....................................13
- 10.2. Informative References ...................................13
- 11. Copying Conditions ............................................14
- Authors' Addresses ............................................14
- Intellectual Property and Copyright Statements ................15
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conformance and Document Conventions . . . . . . . . . . . . 3
+ 3. Deployed Media Types and Compatibility . . . . . . . . . . . 4
+ 4. Encoding Considerations . . . . . . . . . . . . . . . . . . 4
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . 5
+ 6. Interoperability Considerations . . . . . . . . . . . . . . 6
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 8. Ogg Media Types . . . . . . . . . . . . . . . . . . . . . . 6
+ 8.1. application/ogg . . . . . . . . . . . . . . . . . . . . . . 6
+ 8.2. video/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 8.3. audio/ogg . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 9. Copying Conditions . . . . . . . . . . . . . . . . . . . . . 9
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 9
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al. Expires May 14, 2008 [Page 2]
+
+Internet-Draft Ogg Media Types November 2007
+
+
1. Introduction
This memo describes media types for Ogg, a data encapsulation format
@@ -60,21 +129,21 @@
general security considerations.
The Ogg container format is known to contain [Theora] or [Dirac]
- video, and [Speex] (narrow-band and wide-band speech), [Vorbis] or
- [FLAC] audio. 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.
+ 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
+ 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 Ogg bitstreams when they are
- served over HTTP, included in multi-part documents, or used in other
- places where MIME [RFC2045] types are used.
+ are needed to correctly identify such content when it is served over
+ HTTP, included in multi-part documents, or used in other places where
+ media types [RFC2045] are used.
-
2. Conformance and Document Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -92,137 +161,135 @@
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 May 14, 2008 [Page 3]
+
+Internet-Draft Ogg Media Types November 2007
+
+
implementations are "unconditionally compliant".
-
3. Deployed Media Types and Compatibility
The application/ogg media type has been used in an ad-hoc fashion to
label and exchange multimedia content in Ogg containers.
Use of the "application" top-level type for this kind of content is
- known to be problematic, in particular since it obfuscates audio or
- video content. This document thus defines the media types,
+ 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
- * video/ogg
- * 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.
- which are intended for common use and SHOULD be used when dealing with
- video or audio content respectively. The document also replaces the
- 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.
-
- A Ogg bitstream generally consists of one or more logical bitstreams
+ 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 can be identified without decoding the header
- pages of the logical bitstreams through use of a Skeleton [Skeleton]
- bitstream. Skeleton is REQUIRED for application/ogg and RECOMMENDED
- for video/ogg and audio/ogg.
+ time-continuous binary data [RFC3533]. The content types of the
+ logical bitstreams may be identified without decoding the header
+ pages of the logical bitstreams through use of a [Skeleton]
+ bitstream. Using Skeleton is REQUIRED for content served under the
+ application/ogg type and RECOMMENDED for video/ogg and audio/ogg.
- Also, 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.
+ Furthermore, it is RECOMMENDED that implementations that identify a
+ logical bitstream which they cannot decode SHOULD ignore it, while
+ continuing to decode the ones they can.
Ongoing work related to this registration may introduce optional
- MIME media type parameters in future revisions of this document.
- One example area of effort may introduce a parameter that could
- allow for codecs in use within the media type to be asserted and
- determined without examination of the Ogg bitstream. Implementations
- MUST consider the impact of such an update.
+ parameters in future revisions of this document. One example area of
+ effort may introduce a parameter that would allow for data in use
+ within the media type to be asserted and determined without
+ examination of the bitstream. Implementations MUST consider the
+ impact of such an update.
+4. Encoding Considerations
-4. Selection of MIME Types for Ogg bitstreams
+ Binary: The content consists of an unrestricted sequence of octets.
- The MIME types to be assigned to Ogg bitstreams are selected according
- to the contents. Basic guidelines for selecting MIME types are as
- follows:
+ Note:
+ o Ogg encapsulated content is binary data and should be transmitted
+ in a suitable encoding without CR/LF conversion, 7-bit stripping,
+ etc.; base64 [RFC2397] is generally preferred for binary-to-text
+ encoding.
- a) if the bitstream's content cannot clearly be identified as visual or
- audio content, such as e.g. timed text only or time-continuously
- sampled data of scientific experiments, use application/ogg;
- thus, application/ogg is a fallback media type for multiplexed Ogg
- bitstreams.
- b) if the bitstream's content is clearly video, which can be accompanied
- by audio, image, timed text or other data, use video/ogg;
- c) for bitstreams with an audio focus, use audio/ogg.
+Goncalves, et al. Expires May 14, 2008 [Page 4]
+
+Internet-Draft Ogg Media Types November 2007
- In principle, the idea is that Ogg bitstreams of media type audio/ogg
- will be used by audio-specific software applications, while those with
- video/ogg will be used by video-specific software applications.
-
-5. Encoding Considerations
-
- Binary: The content consists of an unrestricted sequence of octets.
-
- NOTE
-
- Ogg encapsulated content is binary data and should be transmitted
- in a suitable encoding without CR/LF conversion, 7-bit stripping
- etc.; base64 [RFC2397] is generally preferred.
-
- Media types described in this document are used for stream based
+ 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 media types are used to specify the actual
- codec formats encapsulated in Ogg, which are also used for RTP
- payload formats, such as Theora video, and Vorbis or Speex audio.
+ pipes); separate types are used for real-time transfer, such as
+ for the RTP payload formats of Theora [ThRTP] video, and Vorbis
+ [VoRTP] or Speex [SpRTP] audio, as well as for identification of
+ the encapsulated content within Ogg.
-6. Security Considerations
+5. Security Considerations
Refer to [RFC3552] for a discussion of terminology used in this
section.
The Ogg encapsulation format is a container and only a carrier of
- content (such as audio, video, and displayable text data) with a
- very rigid definition. This format in itself is not more vulnerable
- than any other content framing mechanism.
+ 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 content bitstreams. However, it
- encapsulates any kind of binary content bitstream 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.
+ Ogg does not provide for any generic encryption or signing of itself
+ or its contained bitstreams. However, it encapsulates any kind of
+ binary content and is thus able to contain encrypted and signed
+ content data. It is also possible to add an external security
+ mechanism that encrypts or signs an Ogg bitstream and thus provides
+ content confidentiality and authenticity.
As Ogg encapsulates binary data, it is possible to include executable
content in an Ogg bitstream. Implementations SHOULD NOT execute such
content without prior validation of its origin by the end-user. This
may be an issue with applications that use Ogg for streaming or file
- transfer in a networking scenario. An implementation decoding Ogg and
- its encapsulated content streams has to ensure correct handling of
- manipulated bitstreams, of buffer overflows, and similar issues.
+ transfer in a networking scenario. An implementation decoding Ogg
+ and its encapsulated content streams has to ensure correct handling
+ of manipulated bitstreams, of buffer overflows, and similar issues.
It is also possible to author malicious Ogg bitstreams, which attempt
- to call for an excessively large picture size, high sampling-rate audio,
- etc. Implementations SHOULD protect themselves against this kind of
- attack.
+ 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.
+ Ogg has an extensible structure, so that it is theoretically possible
+ that metadata fields or media formats might be defined in the future
+ which might be used to induce particular actions on the part of the
+ recipient, thus presenting additional security risks. However, this
+ type of capability is currently not supported in the referenced
+ specification.
Implementations may fail to implement a specific security model or
other means to prevent possibly dangerous operations. Such failure
might possibly be exploited to gain unauthorized access to a system
or sensitive information; such failure constitutes an unknown factor
+
+
+
+Goncalves, et al. Expires May 14, 2008 [Page 5]
+
+Internet-Draft Ogg Media Types November 2007
+
+
and is thus considered out of the scope of this document.
+6. Interoperability Considerations
-7. 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
+ The Ogg container format is device-, platform- and vendor-neutral and
+ has proved to be widely implementable across different computing
+ platforms through a wide range of encoders and decoders. A broadly
portable reference implementation [libogg] is available under the new
- (3-clause) BSD license, which is a Free Software license.
+ (3-clause) BSD license, which is a free software license.
The Ogg container format is not patented and may be implemented by
third parties without intellectual property concerns.
@@ -231,236 +298,328 @@
interoperability, and conformance, and conducts regular
interoperability testing.
+7. IANA Considerations
-8. IANA Considerations
+ This document registers two new media types and redefines the
+ existing application/ogg as defined in the following section.
- This document registers the MIME media types and names to be used
- with various Ogg contents. Section 9 registers two new media types
- and redefines the existing application/ogg for IANA.
+8. Ogg Media Types
+8.1. application/ogg
-9. Ogg Media Types
+ Type name: application
-9.1. application/ogg
+ Subtype name: ogg
- Type name: application
- Subtype name: ogg
- Required parameters: none
- Optional parameters: none
- Encoding considerations: See section 5.
- Security considerations: See section 6.
- Interoperability considerations:
- None, as noted in section 7.
+ Required parameters: none
- Published specification: [Ogg], [Skeleton], [RFC3533]
- Applications which use this media type:
- Scientific, multimedia and other applications which require
- various multiplexed signals or streams of data.
+ Optional parameters: none
+ Encoding considerations: See section 4.
+
+ Security considerations: See section 5.
+
+ Interoperability considerations: None, as noted in section 6.
+
+ Published specification: [RFC3533], [Skeleton]
+
+ Applications which use this media type: Scientific and other
+ applications which require various multiplexed signals or streams of
+ data.
+
Additional information:
- Magic number(s):
- The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the
- string "OggS".
- File extension(s): .ogx
- [RFC3534] defines the file extension .ogg for application/ogg,
- which this document deprecates in favor of .ogx, since .ogg is
- historically used in hardware audio players for Ogg Vorbis
- audio files.
- Macintosh File Type Code(s): OggX
- Person & Email address to contact for further information:
- See "Authors' Addresses" section.
- Intended usage: COMMON
- Restrictions on usage:
- The type application/ogg SHOULD only be used in situations where
- it is not appropriate to serve content under the video/ogg or
- audio/ogg types. Data served under the application/ogg type SHOULD
- use the .ogx file extension and MUST contain an Ogg Skeleton logical
- bitstream to identify all other contained logical bitstreams.
- Author: See "Authors' Addresses" section.
- Change controller: The Xiph.Org Foundation.
+Goncalves, et al. Expires May 14, 2008 [Page 6]
+
+Internet-Draft Ogg Media Types November 2007
-9.2. video/ogg
- Type name: video
- Subtype name: ogg
- Required parameters: none
- Optional parameters: none
- Encoding considerations: See section 5.
- Security considerations: See section 6.
- Interoperability considerations:
- None, as noted in section 7.
+ Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+ correspond to the string "OggS".
- Published specification: [Ogg], [Skeleton], [RFC3533]
- Applications which use this media type:
- Multimedia applications, including device-based, streaming, and
- conferencing tools.
+ File extension(s): .ogx
+ [RFC3534] defined the file extension .ogg for application/ogg,
+ which this document obsoletes in favor of .ogx due to concerns
+ where, historically, some implementations expect .ogg to be solely
+ Vorbis-encoded audio.
+ Macintosh File Type Code(s): OggX
+
+ Person & Email address to contact for further information: See
+ "Authors' Addresses" section.
+
+ Intended usage: COMMON
+
+ Restrictions on usage: The type application/ogg SHOULD only be used
+ in situations where it is not appropriate to serve content under the
+ video/ogg or audio/ogg types. Data served under the application/ogg
+ type SHOULD use the .ogx file extension and MUST contain an Ogg
+ Skeleton logical bitstream to identify all other contained logical
+ bitstreams.
+
+ Author: See "Authors' Addresses" section.
+
+ Change controller: The Xiph.Org Foundation.
+
+8.2. video/ogg
+
+ Type name: video
+
+ Subtype name: ogg
+
+ Required parameters: none
+
+ Optional parameters: none
+
+ Encoding considerations: See section 4.
+
+ Security considerations: See section 5.
+
+ Interoperability considerations: None, as noted in section 6.
+
+ Published specification: [RFC3533], [Skeleton]
+
+ Applications which use this media type: Multimedia applications,
+ including hardware-based, streaming, and conferencing tools.
+
+
+
+
+Goncalves, et al. Expires May 14, 2008 [Page 7]
+
+Internet-Draft Ogg Media Types November 2007
+
+
Additional information:
- Magic number(s):
- The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the
- string "OggS".
- File extension(s): .ogv
- Macintosh File Type Code(s): OggV
+ Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+ correspond to the string "OggS".
- Person & Email address to contact for further information:
- See "Authors' Addresses" section.
+ File extension(s): .ogv
- Intended usage: COMMON
- Restrictions on usage:
- The type "video/ogg" MAY be used for Ogg bitstreams containing
- visual material amongst other content, e.g. for Ogg files containing
- a Theora, a Vorbis [THEORA] and a Skeleton logical bitstream. Data
- served under the type "video/ogg" SHOULD contain an Ogg Skeleton
- logical bitstream. Implementations interacting with the type
- "video/ogg" SHOULD support multiplexed streams.
+ Macintosh File Type Code(s): OggV
- Author: See "Authors' Addresses" section.
- Change controller: The Xiph.Org Foundation.
+ Person & Email address to contact for further information: See
+ "Authors' Addresses" section.
-9.3. audio/ogg
+ Intended usage: COMMON
- Type name: audio
- Subtype name: ogg
- Required parameters: none
- Optional parameters: none
- Encoding considerations: See section 5.
- Security considerations: See section 6.
- Interoperability considerations:
- None, as noted in section 7.
+ Restrictions on usage: The type "video/ogg" MAY be used for Ogg
+ bitstreams containing visual, audio, timed text, or any other type of
+ material that requires a visual interface. It is intended for
+ content not complex enough to warrant serving under "application/
+ ogg"; for example, a combination of Theora video, Vorbis audio,
+ Skeleton metadata, and CMML captioning. Data served under the type
+ "video/ogg" SHOULD contain an Ogg Skeleton logical bitstream.
+ Implementations interacting with the type "video/ogg" SHOULD support
+ multiplexed streams.
- Published specification: [Ogg], [Skeleton], [RFC3533]
- Applications which use this media type:
- Audio and multimedia applications, including device-based, streaming,
- and conferencing tools.
+ Author: See "Authors' Addresses" section.
+ Change controller: The Xiph.Org Foundation.
+
+8.3. audio/ogg
+
+ Type name: audio
+
+ Subtype name: ogg
+
+ Required parameters: none
+
+ Optional parameters: none
+
+ Encoding considerations: See section 4.
+
+ Security considerations: See section 5.
+
+ Interoperability considerations: None, as noted in section 6.
+
+ Published specification: [RFC3533], [Skeleton]
+
+ Applications which use this media type: Multimedia applications,
+ including hardware-based, streaming, and conferencing tools.
+
+
+
+Goncalves, et al. Expires May 14, 2008 [Page 8]
+
+Internet-Draft Ogg Media Types November 2007
+
+
Additional information:
- Magic number(s):
- The first four bytes, 0x4f 0x67 0x67 0x53, correspond to the
- string "OggS".
- File extension(s): .oga, .ogg, .spx
- Historically, .ogg has been used for Ogg files with only one
- logical bitstream being Vorbis [VORBIS], and .spx has been used
- for Ogg files with only one logical bitstream being Speex [SPEEX].
-
- Macintosh File Type Code(s): OggA
+ Magic number(s): The first four bytes, 0x4f 0x67 0x67 0x53,
+ correspond to the string "OggS".
- Person & Email address to contact for further information:
- See "Authors' Addresses" section.
+ File extension(s): .oga, .ogg, .spx
- Intended usage: COMMON
- Restrictions on usage:
- The type "audio/ogg" MAY be used for files containing predominantly
- audio material. Files served under the "audio/ogg" type SHOULD have
- an Ogg Skeleton logical bitstream if they use the .oga extension.
- The .ogg and .spx file extensions are a specialization that require
- no Skeleton due to concerns of backwards-compatibility with existing
- implementations. Use of the .oga file extension is the preferred
- method of distributing audio material under the "audio/ogg" type.
+ Macintosh File Type Code(s): OggA
- Author: See "Authors' Addresses" section.
- Change controller: The Xiph.Org Foundation.
+ Person & Email address to contact for further information: See
+ "Authors' Addresses" section.
+ Intended usage: COMMON
+ Restrictions on usage: The type "audio/ogg" MAY be used for files
+ containing predominantly audio material. Files served under the
+ "audio/ogg" type SHOULD have an Ogg Skeleton logical bitstream if
+ they use the .oga extension. The .ogg and .spx file extensions are a
+ specialization that require no Skeleton due to concerns of backwards-
+ compatibility with existing implementations. Use of the .oga file
+ extension is the preferred method of distributing audio material
+ under the "audio/ogg" type.
+
+ Author: See "Authors' Addresses" section.
+
+ Change controller: The Xiph.Org Foundation.
+
+9. Copying Conditions
+
+ The authors agree to grant third parties the irrevocable right to
+ copy, use and distribute the work, with or without modification, in
+ any medium, without royalty, provided that, unless separate
+ permission is granted, redistributed modified works do not contain
+ misleading author, version, name of work, or endorsement information.
+
10. References
10.1. Normative References
- [Skeleton] Pfeiffer, S., Parker, C., and Pang, A., "The Annodex
- exchange format for time-continuous bitstreams",
- section 4, "The Ogg Skeleton logical bitstream", March
- 2005.
+ [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+ RFC 3533, May 2003.
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
- Mail Extensions (MIME) Part One: Format of Internet
- Message Bodies", RFC 2045, November 1996.
+ [RFC3534] Walleij, L., "The application/ogg Media Type", RFC 3534,
+ May 2003.
- [RFC3533] Pfeiffer, S., "The Ogg Encapsulation Format Version
- 0", RFC 3533, May 2003.
+ [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
- [RFC3534] Walleij, L., "The application/ogg Media Type", RFC
- 3534, May 2003.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing
- RFC Text on Security Considerations", BCP 72, RFC
- 3552, July 2003.
+Goncalves, et al. Expires May 14, 2008 [Page 9]
+
+Internet-Draft Ogg Media Types November 2007
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [Skeleton] Pfeiffer, S. and C. Parker, "The "skeleton" meta
+ information track for Ogg", November 2007, <http://
+ svn.annodex.net/standards/
+ draft-pfeiffer-oggskeleton-current.xml>.
+
+ [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+ Text on Security Considerations", BCP 72, RFC 3552,
+ July 2003.
+
10.2. Informative References
- [Ogg] Xiph.Org Foundation, published specifications in "Ogg
- bitstream documentation": "Ogg logical and physical
- bitstream overview", "Ogg logical bitstream framing",
- "Ogg multi-stream multiplexing",
- <http://xiph.org/ogg/doc>.
+ [Ogg] Xiph.Org Foundation, "Ogg bitstream documentation: Ogg
+ logical and physical bitstream overview, Ogg logical
+ bitstream framing, Ogg multi-stream multiplexing",
+ <http://xiph.org/ogg/doc>.
- [Theora] Xiph.Org Foundation, "Theora Specification", October
- 2007, <http://theora.org/doc/Theora_spec.pdf>.
+ [Theora] Xiph.Org Foundation, "Theora Specification",
+ October 2007, <http://theora.org/doc/Theora_spec.pdf>.
- [Dirac] Dirac Group, "Dirac Specification",
- <http://dirac.sourceforge.net/specification.html>.
+ [Dirac] Dirac Group, "Dirac Specification",
+ <http://dirac.sourceforge.net/specification.html>.
- [Speex] Valin, J., "The Speex Codec Manual", February 2002,
- <http://speex.org/docs/manual/speex-manual>.
+ [Speex] Valin, J., "The Speex Codec Manual", February 2002,
+ <http://speex.org/docs/manual/speex-manual>.
- [Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July
- 2004, <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
+ [Vorbis] Xiph.Org Foundation, "Vorbis I Specification", July 2004,
+ <http://xiph.org/vorbis/doc/Vorbis_I_spec.html>.
- [FLAC] Coalson, J., "The FLAC Format",
- <http://flac.sourceforge.net/format.html>.
+ [FLAC] Coalson, J., "The FLAC Format",
+ <http://flac.sourceforge.net/format.html>.
- [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
- August 1998.
+ [CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
+ Media Markup Language (CMML)", March 2006,
+ <http://annodex.net/TR/cmml.txt>.
- [libogg] Xiph.Org Foundation, "The libogg API", June 2000,
- <http://xiph.org/ogg/doc/libogg>.
+ [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
+ August 1998.
+ [ThRTP] Barbato, L., "RTP Payload Format for Theora Encoded
+ Video", July 2006,
+ <http://tools.ietf.org/html/
+ draft-barbato-avt-rtp-theora>.
-11. Copying Conditions
+ [VoRTP] Barbato, L., "RTP Payload Format for Vorbis Encoded
+ Audio", June 2007, <http://www.ietf.org/internet-drafts/
- 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. Expires May 14, 2008 [Page 10]
+
+Internet-Draft Ogg Media Types November 2007
+
+
+ draft-ietf-avt-rtp-vorbis-07.txt>.
+
+ [SpRTP] Herlein, G., Valin, J., Heggestad, A., and A. Moizard,
+ "RTP Payload Format for the Speex Codec", July 2007,
+ <http://tools.ietf.org/html/draft-ietf-avt-rtp-speex>.
+
+ [libogg] Xiph.Org Foundation, "The libogg API", June 2000,
+ <http://xiph.org/ogg/doc/libogg>.
+
Authors' Addresses
Ivo Emanuel Goncalves
Xiph.Org Foundation
1408 Adams St. NE
- Albuquerque, NM 87110,
- United States
+ Albuquerque, NM 87110
+ US
- Email: justivo at gmail.com
+ EMail: justivo at gmail.com
URI: xmpp:justivo at gmail.com
- Note: Please write "Goncalves" with c-cedilla (U+00E7) wherever
- possible, e.g., as "Ivo Emanuel Gonçalves" in HTML and XML.
-
Silvia Pfeiffer
Xiph.Org Foundation
- Australia
- Email: silvia at silvia-pfeiffer.de
-
+ Phone: +61 2 8012 0937
+ EMail: silvia at annodex.net
+
+
Christopher Montgomery
Xiph.Org Foundation
- USA
- Email: monty at xiph.org
+ EMail: monty at xiph.org
+ URI: http://xiph.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Goncalves, et al. Expires May 14, 2008 [Page 11]
+
+Internet-Draft Ogg Media Types November 2007
+
+
Full Copyright Statement
- Copyright (C) The Internet Society (2007).
+ Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
@@ -468,10 +627,10 @@
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 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
+ 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
@@ -502,3 +661,12 @@
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Goncalves, et al. Expires May 14, 2008 [Page 12]
+
More information about the commits
mailing list