[xiph-commits] r3265 - standards
silvia at svn.annodex.net
silvia at svn.annodex.net
Sat Nov 3 15:33:47 PDT 2007
Author: silvia
Date: 2007-11-03 15:33:46 -0700 (Sat, 03 Nov 2007)
New Revision: 3265
Added:
standards/draft-pfeiffer-oggskeleton-current.xml
Log:
A first draft of the new Ogg Skeleton I-D, required for the new MIME types for Xiph.
Added: standards/draft-pfeiffer-oggskeleton-current.xml
===================================================================
--- standards/draft-pfeiffer-oggskeleton-current.xml (rev 0)
+++ standards/draft-pfeiffer-oggskeleton-current.xml 2007-11-03 22:33:46 UTC (rev 3265)
@@ -0,0 +1,1482 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+
+<?rfc toc="yes"?>
+<?rfc sortrefs="yes"?>
+
+<rfc category="info" ipr="full3667" docName="draft-pfeiffer-oggskeleton-00">
+
+ <front>
+ <title abbrev="SKELETON">The "skeleton" meta information track for Ogg</title>
+
+ <author initials="S.P." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="Annodex">Annodex Association,
+ Australia</organization>
+ <address>
+ <phone>+61 2 8012 0937</phone>
+ <email>silvia at annodex.net</email>
+ <uri>http://www.annodex.org/</uri>
+ </address>
+ </author>
+
+ <author initials="C.D.P." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="Annodex">Annodex Association,
+ Australia</organization>
+ <address>
+ <email>conrad at annodex.net</email>
+ <uri>http://www.annodex.org/</uri>
+ </address>
+ </author>
+
+ <date month="November" year="2007"/>
+
+ <abstract>
+
+ <t>This specification defines "Skeleton", a logical bitstream for
+ the <xref target="Ogg">Ogg encapsulation format version 0</xref>.
+ Skeleton is a header-style bitstream that describes the content
+ of the other logical bitstreams encapsulated inside an Ogg
+ container. Its purpose is to remove codec-specific information
+ requirements from the multiplexing/demultiplexing process.
+ It provides default structure and semantic information to
+ describe multitrack physical Ogg bitstreams. There is also a mechanism
+ through which more information than the default can be provided.
+ </t>
+
+ <t>Please note that this document assumes that the reader understands
+ the <xref target="Ogg">Ogg encapsulation format version 0</xref>.
+ The specification of Skeleton is not encumbered by patents.
+ </t>
+
+ <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>
+
+ </abstract>
+ </front>
+
+ <middle>
+
+ <!--**********-->
+ <!-- FEATURES -->
+ <!--**********-->
+ <section title="Features of Ogg and Skeleton">
+
+ <t>Ogg is a container format for encapsulation of several tracks of
+ temporally interleaved bitstreams of time-continuous data. It
+ enables encapsulation of any type of time-continuous data stream as
+ long as it is streamable. Each track represents codec data for only
+ one type of time-continuous data stream. Ogg is designed to be used
+ both as a persistent file format and as a streaming format to exchange
+ temporally addressable bitstreams.
+ </t>
+
+ <t>Skeleton adds to Ogg a means to describe the codec tracks contained
+ inside Ogg. It assumes reasonably that for each
+ logical bitstream there is a regular data sampling rate (called
+ granulerate). For variable sampling rate bitstreams, it assumes there
+ is a common multiple of the used sampling rates that is used as
+ granulerate.
+ </t>
+
+ <t>Codec tracks generally contain the following information:
+ <list style="symbols">
+ <t>setup information for a codec</t>
+ <t>content data</t>
+ </list>
+ The setup information is inserted at the start of a data
+ bitstream before any content data. Skeleton pulls out the key
+ information about the codecs from their headers and puts them
+ into a defined location in a defined manner, such that no
+ decoding of logical bitstreams is required to find out about the
+ tracks of content encapsulated inside Ogg.
+ </t>
+
+ <t>An Ogg physical bitstream with a Skeleton track has the following
+ mandatory order of Ogg pages:
+ <list style="numbers">
+ <t>skeleton bos page.</t>
+ <t>bos pages of the other logical bitstreams.</t>
+ <t>secondary header pages of all logical bitstreams, including
+ fisbone.</t>
+ <t>skeleton eos page.</t>
+ <t>data and eos pages of logical bitstreams, excluding skeleton,
+ multiplexed in a time-synchronous fashion.</t>
+ </list>
+ </t>
+
+ </section>
+
+ <!--*********************-->
+ <!-- Skeleton definition -->
+ <!--*********************-->
+ <section title="The Ogg skeleton logical bitstream">
+
+ <t>The purpose of Ogg skeleton is to provide codec-specific
+ knowledge that allows parsing, demultiplexing and remultiplexing of
+ Ogg bitstreams without having to decode.
+ </t>
+
+ <t>While the Ogg encapsulation format by itself is capable of
+ interleaving an unlimited number of time-continuous bitstreams,
+ it is not possible to identify the type of bitstreams (e.g. audio
+ or video) and their encoding format (e.g. Vorbis or Speex or Theora)
+ without decoding at least the bos page of the logical bitstreams.
+ Also, further general media type information such as the image
+ dimensions of a frame in a video bitstream or the language of a speech
+ bitstream may be provided in skeleton. Another limitation of Ogg
+ is that each logical bitstream defines its own mapping of
+ granule_position to time, which is therefore also given in the
+ skeleton.
+ </t>
+
+ <t>This section
+ specifies the content of the "skeleton" logical bitstream and how
+ it is mapped into Ogg. Knowledge of the Ogg bitstream format as
+ specified in the <xref target="Ogg">Ogg RFC</xref> is presumed.
+ Please also refer to that document for descriptions of the terms
+ used in this document.
+ </t>
+
+ <t>The skeleton bitstream has the ability to generically describe
+ Ogg bitstreams that consist of one or more time-continuous data
+ bitstream and one or more time-instantaneous data bitstream
+ concurrently interleaved (in Ogg terms: multiplexed). It does
+ not describe sequentially multiplexed Ogg bitstreams, but
+ rather expects that a sequentially multiplexed bitstream has
+ its own skeleton logical bitstream.
+ </t>
+
+ <t>The skeleton logical bitstream provides the following functionality
+ on top of Ogg:
+ <list style="symbols">
+ <t>allows for the identification of the codec format and the
+ content type of encapsulated logical bitstreams without the
+ need to decode that bitstream's headers or data.</t>
+ <t>allows for extraction of a temporal interval of the Ogg
+ physical bitstream while retaining the original start
+ time offset of that interval.</t>
+ <t>allows for attachment of a real-world wall-clock time and a
+ date to the Ogg physical bitstream, thus e.g. retaining
+ creation date/time or first broadcast date/time.</t>
+ <t>allows for temporal offset operations into an Ogg physical
+ bitstream without a need to decode any data.</t>
+ <t>allows generally for handling of content without a need to
+ decode it, such as is necessary in a caching Web proxy.</t>
+ <t>allows for attachment of message header fields given as
+ name-value pairs that contain some sort of protocol messages
+ about the logical bitstream, e.g. the screen size for a video
+ bitstream or the number of channels for an audio bitstream.</t>
+ </list>
+ </t>
+
+
+ <section title="The format of the skeleton ident header">
+
+ <t>The skeleton logical bitstream starts with an ident header
+ containing information for the complete Ogg physical bitstream.
+ The ident header has the following format:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'fishead\0' | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version major | Version minor | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Presentationtime numerator | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Presentationtime denominator | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basetime numerator | 28-31
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 32-35
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Basetime denominator | 36-39
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 40-43
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | UTC | 44-47
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 48-51
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 52-55
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 56-59
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 60-63
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ]]></artwork>
+ </figure>
+
+ <t>Fields with more than one Byte length are encoded LSB (least
+ significant Byte) first.
+ </t>
+
+ <t>The fields in the skeleton ident header have the following
+ meaning:
+ </t>
+ <list style="numbers">
+ <t>Identifier: a 8 Byte field that identifies this bitstream
+ as a skeleton. It contains the magic numbers:
+ <list style="hanging">
+ <t>0x66 'f'</t>
+ <t>0x69 'i'</t>
+ <t>0x73 's'</t>
+ <t>0x68 'h'</t>
+ <t>0x65 'e'</t>
+ <t>0x61 'a'</t>
+ <t>0x64 'd'</t>
+ <t>0x00 '\0'</t>
+ </list>
+ </t>
+ <t>Version major: 2 Byte unsigned integer
+ signifying the major version number of the skeleton
+ bitstream. This document specifies the major version 3.
+ </t>
+ <t>Version minor: 2 Byte unsigned integer
+ signifying the minor version number of the skeleton
+ bitstream. This document specifies the minor version 0.
+ </t>
+ <t>Presentationtime numerator & denominator: 8 Byte signed
+ integer each
+ They represent together the time at which to start
+ presenting the Ogg physical bitstream given as a rational number.
+ The denominator represents the temporal resolution at which the
+ presentationtime is given. E.g. 5 on 1000 results in a
+ presentationtime of 0.005 sec. This enables a very high temporal
+ resolution without having to store floating point numbers. In a
+ newly created physical bitstream presentationtime and basetime are
+ the same. When remultiplexing a subpart of the stream, this number
+ MUST be adapted to the requested start time offset of the newly
+ created stream.
+ </t>
+ <t>Basetime numerator & denominator: 8 Byte signed integer
+ each
+ They represent together the basetime of the
+ Ogg physical bitstream given as a rational number like the
+ presentationtime. This number is fixed once the physical bitstream
+ is created and provides a mapping to time for the beginning of
+ the physical bitstream when it starts with a granule position of 0.
+ </t>
+ <t>UTC: a 20 Byte string containing a UTC time in the form
+ of YYYYMMDDTHHMMSS.sssZ. It associates a calendar date and a
+ wall-clock time with the basetime. It is a sequence of 20 NUL
+ Bytes if not in use, making this ident packet and thus the
+ bos page of the skeleton bitstream constant length.
+ </t>
+ </list>
+
+ <t>Please note: The possible temporal resolution of the presentation-
+ and basetime is on the order of 2^-64. For example, the time formats
+ in use for media that are described in this document range from
+ 1/24 to 1/60 for the different smpte formats. This resolution
+ is enough for any one of these. It is also expected to accommodate
+ any future needs of time resolution for any other time format
+ and time-continuously sampled data.
+ </t>
+
+ </section>
+
+ <section title="The format of the skeleton secondary headers">
+
+ <t>The skeleton secondary headers are a sequence of packets
+ that each contain information about one of the time-continuous
+ or time-instantaneous other logical bitstreams contained
+ within the Ogg physical bitstream.
+ A skeleton secondary header packet has the following format:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'fisbone\0' | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Offset to message header fields | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Serial number | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of header packets | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate numerator | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate denominator | 28-31
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 32-35
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Startgranule | 36-39
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 40-43
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Preroll | 44-47
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granuleshift | Padding/future use | 48-51
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Message header fields ... | 52-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ ]]></artwork>
+ </figure>
+
+ <t>Fields with more than one Byte length are encoded LSB
+ (least significant Byte) first.
+ </t>
+
+ <t>The fields in a skeleton secondary header packet have the
+ following meaning:
+ </t>
+ <list style="numbers">
+ <t>Identifier: a 8 Byte field that identifies this packet
+ as a skeleton secondary header for identifying other
+ logical bitstreams. It contains the magic numbers:
+ <list style="hanging">
+ <t>0x66 'f'</t>
+ <t>0x69 'i'</t>
+ <t>0x73 's'</t>
+ <t>0x62 'b'</t>
+ <t>0x6f 'o'</t>
+ <t>0x6e 'n'</t>
+ <t>0x65 'e'</t>
+ <t>0x00 '\0'</t>
+ </list>
+ </t>
+ <t>Offset to message header fields: 4 Byte unsigned integer
+ that contains the number of Bytes used in this packet before the
+ message header fields. For the version of the skeleton bitstream
+ described in this document this number is fixed to 44. This
+ field accommodates future changes to the skeleton
+ bitstream allowing to parse message header fields even if
+ more fields get inserted before them.</t>
+ <t>Serial number: 4 Byte unsigned integer containing the
+ bitstream_serial_number of the Ogg logical bitstream described
+ by this skeleton secondary header packet and thus connecting
+ it to the logical bitstream.</t>
+ <t>Number of header packets: a 4 Byte unsigned integer
+ that contains the number of header packets of that
+ particular logical bitstream consisting of the bos page and the
+ secondary header pages.</t>
+ <t>Granulerate numerator & denominator: 8 Byte signed integer
+ each
+ They represent the temporal resolution of the
+ logical bitstream in Hz given as a rational number in the
+ same way as the basetime attribute above.</t>
+ <t>Startgranule: 8 Byte signed integer that represents the
+ granule number with which this logical bitstream starts, which
+ is originally 0, but will be a positive offset when only a
+ subpart of the stream is requested.</t>
+ <t>Preroll: 4 Byte unsigned integer that contains the number of
+ packets to pre-roll in order to decode a current packet
+ correctly. This is for example the case with Ogg Vorbis,
+ which requires a pre-roll of 2 packets.</t>
+ <t>Granuleshift: a 1 Byte unsigned integer describing
+ whether to partition the granule_position into two for that
+ logical bitstream, and how many of the lower bits to use for
+ the partitioning. The upper bits then still signify a
+ time-continuous granule position for a directly decodable
+ and presentable data granule. The lower bits allow for
+ specification of a finer resolution such that for example
+ predicted frames of a video can be addressed as well, though
+ not decoded without tracing back to the last fully decodable
+ data granule. This is e.g. the case with Ogg Theora.</t>
+ <t>Padding/future use: 3 Bytes padding data that may be used for
+ future requirements and are mandated to zero in this revision.</t>
+ <t>Message header fields: header fields, following the generic
+ Internet Message Format defined in <xref
+ target="Headers">RFC 2822</xref>. Each header field consists
+ of a name followed by a colon (":") and the field value.
+ Field names are case-insensitive. The field value MAY
+ be preceded by any amount of LWS, though a single SP is
+ preferred. Header fields can be extended over multiple lines
+ by preceding each extra line with at least one SP or HT.</t>
+ </list>
+
+ <t>There is one mandatory Message header field for all of the
+ logical bitstreams: the "Content-type" header field. For an
+ application that is parsing the Annodex bitstream, this field
+ contains the MIME type and the character encoding of the data in
+ the logical bitstream. E.g. for the annotation bitstream, this
+ field will contain the value "Content-type: text/x-cmml; UTF-8"
+ if the character set used in the CMML bitstream is UTF-8.
+ E.g. for a bitstream containing Ogg Vorbis data the value is
+ "Content-type: audio/x-vorbis". The Content-type message header
+ field MUST come first for all of the Message header fields such that
+ it can be found at a fixed location in the skeleton
+ fisbone packet.
+ </t>
+
+ <t>As per <xref target="I18N">RFC 2277</xref>, message header
+ fields are considered protocol data, i.e. it is not expected to
+ have human readable text in there, and they MUST be entirely encoded
+ in UTF-8. In addition, the mandatory header fields MUST be encoded
+ in US-ASCII and it is recommended to also use US-ASCII
+ code points as much as possible for the optional header fields.
+ </t>
+
+ <t>User defined optional message header fields MUST follow the naming
+ standard given in RFC2822.
+ </t>
+
+
+ </section>
+
+ <section title="Media mapping of skeleton into Ogg">
+
+ <t>The media mapping for skeleton into Ogg is as follows:
+ <list style="symbols">
+ <t>The skeleton ident (fishead) header is mapped into the skeleton
+ bos page.</t>
+ <t>The secondary header pages of a skeleton logical bitstream
+ consist of the fisbone header packets that each describe one
+ particular logical data bitstream within the Ogg physical
+ bitstream.</t>
+ <t>There are no content pages or data packets. As the skeleton
+ eos page is included before the first data page of any logical
+ bitstream, there actually cannot be any content data packets.</t>
+ <t>The skeleton eos page contains one packet of length zero.</t>
+ </list>
+ </t>
+
+ <t>When using a skeleton logical bitstream in Ogg, a further
+ restriction on the order in which Ogg pages appear is introduced
+ to allow for easier identification:
+ <list style="numbers">
+ <t>The skeleton bos page is the very first bos page. This allows its
+ differentiation from other Ogg bitstreams that don't contain
+ a skeleton logical bitstream.</t>
+ <t>The bos pages of the other logical bitstreams come next as
+ is a requirement of the Ogg bitstream format.</t>
+ <t>The secondary header pages of all the logical bitstreams
+ in the Ogg physical bitstream come next, as is also a
+ requirement of Ogg. The skeleton secondary header pages
+ are also included here.</t>
+ <t>Before any data pages of any of the logical bitstreams appear
+ in the Ogg physical bitstream, the skeleton eos page MUST end
+ the skeleton logical bitstream. This is necessary to end the
+ control section of the bitstream. If an Ogg stream parser reaches
+ the skeleton eos page, it knows that it has received all the bos
+ and secondary header pages and can start setting up its decoding
+ or parsing environment.</t>
+ </list>
+ </t>
+
+ </section>
+
+ </section>
+
+
+ <!--***************-->
+ <!-- Time handling -->
+ <!--***************-->
+ <section title="Handling time in an Ogg format bitstream">
+
+ <t>With time-continuous data inside Ogg, one needs to handle
+ data at four different levels:
+ <list style="symbols">
+ <t>at the Bytes level, upon seeking.</t>
+ <t>at the packets level, upon encapsulating.</t>
+ <t>at the granules level, upon recomposing.</t>
+ <t>at the time level, upon displaying and addressing.</t>
+ </list>
+ This section explains how they all fit together.
+ </t>
+
+ <section title="Conceptual overview">
+
+ <t>Ogg bitstreams inherently represent one timeline only, where the
+ different logical bitstreams can be thought of as content tracks on that
+ timeline. All of these tracks relate to the same timeline which starts
+ at a certain time point and ends when the last bitstream ends.
+ </t>
+
+ <t>An example bitstream can be seen in the following figure. It consists
+ of an Ogg bitstream that contains 4 media bitstreams. The picture is a
+ conceptual representation of the
+ time intervals covered by the different logical bitstreams and the
+ Ogg pages used to encapsulate the data. In the flat representation these
+ are multiplexed such that the data packets of each of these bitstreams
+ occur at the correct time.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+
+ t_url
+ |
+t_0 v t_n
+|------------------------------------------------------------------->|
+----------------------------------------------
+| | | | | | | | | | |//| | | | |
+----------------------------------------------
+audio bitstream 1
+ -------------------------------------------------------------
+ | | | |/////| | | | | | |
+ -------------------------------------------------------------
+ video bitstream 1
+ ----------------------------------------------------
+ | | | | |//| | | | | | | | | | | | |
+ ----------------------------------------------------
+ audio bitstream 2
+ -------------------------------
+ | |/////| | | |
+ -------------------------------
+ video bitstream 2
+ ]]></artwork>
+ </figure>
+
+
+ <t>The time point at which an Ogg bitstream starts (t_0 in the
+ above diagram) is called the "basetime" and represents the time in
+ seconds associated with the granule position of 0 on all logical
+ bitstreams. Typically, a newly created Ogg file starts all its
+ logical bitstreams at granule position 0, and a typical extract
+ of an Ogg bitstream, such as the one starting at t_url in the
+ image above, starts each of its logical bitstreams at
+ a different granule positions. These granule positions are stored
+ in the "startgranule" field of the skeleton secondary header packets.
+ </t>
+
+ <t>The "basetime" of an Ogg bitstream may be 0, but it can also
+ be any positive time. For example, in professional video production,
+ the first frame of video of a program normally refers to a SMPTE
+ basetime of 01:00:00:00, not 00:00:00:00 (see also the <xref
+ target="timedURI">temporal URI addressing</xref> specification).
+ Associating such a practice to a digital video resource requires
+ a way to store that basetime with the resource and interpreting it
+ correctly when addressing offsets such as t_uri. Skeleton provides
+ such a mapping through the basetime field in the skeleton ident header.
+ </t>
+
+ <t>Also associated with the basetime is a calendar date and
+ wall-clock time (a "UTC base") which represent a real-world time
+ giving some meaningful calendar date association to the content
+ such as the creation time or the first presentation time.
+ The UTC base is specified in the UTC field of the skeleton
+ ident header.
+ </t>
+
+ </section>
+
+ <section title="Mapping a granule position to a time position">
+
+ <t>Each one of the encapsulated data bitstreams have their own
+ temporal resolution at which
+ they provide data to cover the given timeline. This temporal
+ resolution is usually given through the sampling rate of the
+ particular bitstream. For example, a raw audio bitstream at CD
+ quality is sampled with a sampling rate of 44100 Hz. A video
+ bitstream may be sampled with a frame rate of 25 frames per
+ second.
+ </t>
+
+ <t>This temporal resolution is called the "granulerate".
+ A granule is a data element that is based on a regular data rate
+ specific to the content type, such as the frame rate for video or
+ the sampling rate for audio.
+ It even exists for bitstreams that are not sampled at a regular
+ rate - then it is the highest resolution of any of the used
+ sampling rates. The granulerate is specified in the skeleton
+ secondary header packets for each logical bitstream.
+ </t>
+
+ <t>Each one of the bitstreams insert data into the Ogg bitstream
+ through packets which have an associated temporal duration based on
+ the encoder packaging. Packets are packaged into Ogg pages, which
+ have a granule position associated with them. Not taking the special
+ case of a granuleshift into account, the granule position
+ specifies the number of granules that has been encapsulated since
+ the implicit start of the original bitstream until and including the
+ given Ogg page.
+ </t>
+
+ <t>The granule position together with the granulerate and granuleshift
+ information of the skeleton secondary header packets for the particular
+ logical bitstream are used for the calculation of the time position
+ for which a data packet of the logical bitstream completes data.
+ A granule position of -1 indicates a special case and MUST NOT be
+ used for calculation of a mapping to time.
+ </t>
+
+ <t>In principle, the granule position of an Ogg page divided by the
+ granulerate of this page's logical bitstream provides the time
+ position that is reached in that bitstream after decoding all data
+ packets finished on this page. However, the granule_position field
+ in an Ogg page allows for a more fine-grained description of
+ the temporal position. The following image explains the composition
+ of the granule_position field in an Ogg page:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ granule_position
+ ------------------------------------------------
+ | keyindex | keyoffset |
+ ------------------------------------------------
+ ]]></artwork>
+ </figure>
+
+ <t>The granuleshift field of the skeleton secondary header packets
+ describes how many of the granule_position's 64 bits are being used
+ for the keyoffset. The keyoffset part of the granule_position is
+ commonly used when the logical bitstream consists of packets that
+ can only be fully decoded when referring back to a previous packet.
+ For example, video streams often consist of inter and intra coded
+ frames, where the intra frames are fully decodable and the inter
+ frames are intermediate frames that require backtracking to the
+ last inter frame for accurate decoding. Another example is a
+ logical bitstream that is mapped as instantaneous information (i.e.
+ their granuleposition represents the start time and the end time of
+ the packet data), but actually has a duration associated to it, which
+ is provided through a subsequent packet. CMML is such an example.
+ The keyindex part of the granule_position is then used to provide
+ the temporal position of the reference packet
+ and the keyoffset part provides a counter for the data in between.
+ </t>
+
+ <t>The calculation of the temporal position of an Ogg page using
+ Skeleton is thus specified through the following algorithm:
+ <artwork><![CDATA[
+t_page = basetime + ((keyindex + keyoffset) / granulerate)
+ ]]></artwork>
+ </t>
+ <t>The basetime provides the time offset used at the beginning of the
+ logical bitstream for the first data packet and thus MUST be
+ added for a correct calculation of the temporal position.
+ </t>
+
+ <t>As an example regard an audio bitstream that has a granulerate
+ of 44100 (i.e. 44100 samples per 1 sec), a granuleshift of 0,
+ and starts at 4 sec. When reaching a granule_position of 88200, this
+ maps to a time position of 6 seconds:
+ <artwork><![CDATA[
+t_page = 4 + ((88200 + 0) / 44100) = 6
+ ]]></artwork>
+ </t>
+ <t>This signifies that the bitstream has reached the second sec of the
+ audio bitstream after the end of decoding this page's packets, but
+ maps to 6 seconds because of the basetime.
+ </t>
+
+ <t>As another example consider a video bitstream that has a granulerate
+ of 25 (i.e. 25 frames per 1 second), a granuleshift of 3 (because
+ it encodes - say - 7 partial frames between each fully encoded frame),
+ and starts at 0 sec. When reaching a granule_position of 997, i.e.
+ a keyindex of 62 and a keyshift of 5, this maps to a fully decodable
+ time position of 2.68 seconds:
+ <artwork><![CDATA[
+t_page = 0 + ((62 + 5) / 25) = 2.68 sec
+ ]]></artwork>
+ </t>
+
+ <t>The granulerate of a time-instantaneous bitstream such as
+ a CMML bitstream can be chosen arbitrarily by the bitstream
+ multiplexer. Per default, a granulerate of 1000 is used, which
+ is the resolution of npt. The resolution of all the time schemes
+ is given as:
+ <list style="symbols">
+ <t>npt: 1000 (milliseconds)</t>
+ <t>smpte-24: 24 (24 fps)</t>
+ <t>smpte-24-drop: 24/1.001 = 23.976 (approx. as per SMPTE)</t>
+ <t>smpte-25: 25</t>
+ <t>smpte-30: 30</t>
+ <t>smpte-30-drop: 30/1.001 = 29.970 (approx. as per SMPTE)</t>
+ <t>smpte-50: 50</t>
+ <t>smpte-60: 60</t>
+ <t>smpte-60-drop: 60/1.001 = 59.940 (approx. as per SMPTE)</t>
+ </list>
+ </t>
+
+ <t>The granule position of the page finishing data of a
+ time-instantaneous bitstream packet MUST signify the start
+ time of that packet. For example, a CMML bitstream with a granulerate
+ of 1000, a basetime of 0, and a clip that lasts from npt=12.020
+ till npt=15.0 will get a granule_position of 12020. In contrast, the
+ granule_position of the page finishing data of e.g. an audio
+ bitstream with granulerate 44100, basetime 0 and containing
+ data from npt=12.020 to npt=15.0 will be 661500.
+ </t>
+
+ <t>A note about field overflows: an overflow of the granule
+ position field can destroy the temporal integrity of the Ogg
+ physical bitstream. In this case, a multiplexer MUST end the Ogg
+ physical bitstream and restart a new one resetting the counter to 0 and
+ adjusting the basetime appropriately. This is also called
+ sequential multiplexing in Ogg. The same measure MUST be taken
+ in case of an overflow of the page_sequence_number on one of
+ the logical bitstreams.</t>
+
+ </section>
+
+ <section title="Seeking into the bitstream">
+
+ <t>Seeking to a time offset inside an Ogg logical bitstream is
+ a fundamental activity frequently performed on media data. Time
+ inside an Ogg with a Skeleton track is specified as a temporal offset
+ from the "beginning" of the stream, making use of the basetime
+ field. Time offsets can also be specified as calendar dates and
+ times. The UTC base is then used as a basis for offsetting.
+ </t>
+
+ <t>The basetime allows to correctly map a temporal offset point such as
+ a temporal URI to a Byte position in the stream. In the above figure
+ take t_uri=npt:14.0 as the temporal offset addressed on a stream with
+ t_0=npt:5.0 as the basetime - this requires a stream offsetting of only
+ 9 sec to the appropriate granule position in each of the bitstreams,
+ in the figure marked through patterned pages.
+ </t>
+
+ <t>The seeking action is performed on the interleaved bitstream, in
+ which, the data packets occur in a temporally consecutive order based
+ on the time at which their data ends. These times are represented in
+ the granule positions of the Ogg pages, which are only allowed to
+ monotonically increase within one logical bitstream. This
+ implies that when having found an Ogg page with a granule position
+ that maps to a given seek time (i.e. covers the time or ends at it),
+ the seek has found the right location. This applies over all logical
+ bitstreams. In the above example, this means that the Byte position of
+ the first occurring page of the patterned pages has been found.
+ </t>
+
+ <t>There is a complication to the seeking: some logical bitstreams have
+ backwards dependencies in their data packets and these have to be taken
+ into account for seeking. For example, a logical bitstream may require
+ several of its previous packets to allow a correct and complete decoding
+ of the actual packet that occurs at the seektime. This is the case for
+ Theora which requires to go back to the previous keyframe when decoding
+ from a time offset. It is also the case for Vorbis which requires the
+ previous 2 packets for accurate setup of the frequency transform - Speex
+ needs approximately 2 packets for similar reasons. Even instantaneous
+ bitstreams such as CMML may require to go back to a previous packet to
+ recover the last state information - the currently active clip in the
+ case of CMML.
+ </t>
+
+ <t>Therefore, once seeking has located the correct Byte position that
+ refers to the given temporal offset, it MUST seek back. For logical
+ bitstreams that have a non-zero "granuleshift" in the skeleton, it MUST
+ seek back to the Ogg page that has a "keyindex" granule position. For
+ logical bitstreams that have a non-zero "preroll" in the skeleton, it
+ MUST seek back that many packets. The earliest Byte position that
+ satisfies all these requirements is the correct seek position.
+ </t>
+
+ <t>A player that presents from an offset MUST take into account that
+ the bitstream may contain some packets that are only there to allow
+ accurate decoding of the seek time. When the backwards dependencies
+ were resolved for a specific logical bitstream, several non-relevant
+ Ogg pages of may also have ended up in the
+ intermediate. These have to be skipped by a player. The time that a
+ player MUST start presenting from is given in the "presentationtime"
+ in the skeleton ident header.
+ </t>
+
+ </section>
+
+ <section title="Remultiplexing an Ogg bitstream using Skeleton">
+
+ <t>Ogg with a Skeleton track allows for the creation of mashups of
+ a file without actual decoding and re-encoding. A mashup in the sense
+ used here is when a subpart of a Ogg physical bitstream is required,
+ such as a temporal sub-interval from the whole file. Skeleton allows
+ the creation of the mashup bitstream through recomposition and
+ remultiplexing. There are several
+ aims for performing the remultiplexing with as little effort and
+ therefore as little delay as possible:
+ <list style="symbols">
+ <t>no decoding of the logical bitstreams is performed.
+ </t>
+ <t>no changes to the pages, in particular to the granule
+ positions are made.
+ </t>
+ <t>changes occur only to the control section.
+ </t>
+ </list>
+ </t>
+
+ <t>The fields of the skeleton track allow achievement of all these aims.
+ Remultiplexing is essentially achieved by seeking to the position as
+ described above and then including from each logical bitstream only the
+ relevant Ogg pages into the new stream. Changes to fields in the
+ bitstream are restricted to the control section:
+ <list style="symbols">
+ <t>the "presentationtime" MUST be adjusted to the requested start
+ time
+ </t>
+ <t>the "startgranule" for each logical bitstream MUST be adjusted to
+ the granule position at which each logical bitstream starts. This
+ is not the first granule position of the Ogg pages included into
+ the bitstream, but rather the last one that did not get included,
+ as it represents the start time of the bitstream.
+ </t>
+ </list>
+ Everything else, and in particular the Ogg pages, stay the same. This is
+ important also to allow caching of such files as is required for Web
+ proxies and described in <xref target="timedURI">temporal URI
+ addressing</xref>.
+ </t>
+
+ </section>
+
+ </section>
+
+ <!--**********-->
+ <!-- Security -->
+ <!--**********-->
+ <section title="Security considerations">
+
+ <t>Ogg format bitstreams contain several multiplexed
+ binary and non-binary data bitstream. There is no
+ generic encryption or signing mechanism provided for the
+ complete bitstream or anyone of its parts. As the format of the
+ encapsulated media bitstreams is not prescribed and is
+ identified through the "Content-type" Message header field in
+ that bitstream's skeleton secondary header packet,
+ it is possible to encrypt or sign
+ that media bitstream and then mark it accordingly with a MIME
+ type that signifies the encryption. It is up to the applications
+ that use this bitstream to provide an appropriate codec to
+ handle such bitstreams.
+ </t>
+
+ <t>As Ogg format bitstreams generally contain binary media
+ bitstreams, it is possible to include executable content in
+ them. This can be an issue with applications that decode these
+ bitstreams, especially when they are used in a network
+ scenario. Such applications MUST ensure correct handling of
+ manipulated bitstreams, of buffer overflow and the like.
+ </t>
+
+ </section>
+
+
+ <!--***********-->
+ <!-- Changelog -->
+ <!--***********-->
+ <section title="ChangeLog">
+
+ <t>draft-pfeiffer-oggskeleton-00:
+ <list style="symbols">
+
+ <t>Internet-Draft started as an extract from the Annodex I-D.
+ </t>
+
+ </list>
+ </t>
+
+ </section>
+
+ </middle>
+
+ <back>
+
+ <!--************-->
+ <!-- References -->
+ <!--************-->
+ <references>
+
+ <reference anchor="KEYWORDS">
+ <front>
+ <title>Key words for use in RFCs to Indicate Requirements Levels</title>
+
+ <author initials="S." surname="Bradner" fullname="Scott Bradner">
+ <organization>Harvard University</organization>
+ <address>
+ <postal>
+ <street>29 Oxford Street</street>
+ <city>Cambridge</city> <region>MA</region> <code>02138</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 617 495 3864</phone>
+ <email>sob at harvard.edu</email>
+ </address>
+ </author>
+ <date month="March" year="1997" />
+ </front>
+ <seriesInfo name="RFC" value="2119" />
+ <seriesInfo name="BCP" value="14" />
+ </reference>
+
+ <reference anchor="XML" target="http://www.w3.org/TR/2000/REC-xml-20001006">
+ <front>
+ <title>Extensible Markup Language (XML) 1.0</title>
+ <author>
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>timbl at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="October" year="2000" />
+ </front>
+ <seriesInfo name="W3C" value="XML" />
+ </reference>
+
+ <reference anchor="HTML" target="http://www.w3.org/TR/html4/">
+ <front>
+ <title>HTML 4.01 Specification</title>
+ <author>
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>timbl at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="December" year="1999" />
+ </front>
+ <seriesInfo name="W3C" value="HTML" />
+ </reference>
+
+ <reference anchor="XHTML" target="http://www.w3.org/TR/xhtml1/">
+ <front>
+ <title>XHTML(TM) 1.0 The Extensible Hyper Text Markup Language</title>
+ <author>
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>timbl at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="January" year="2000" />
+ </front>
+ <seriesInfo name="W3C" value="XHTML" />
+ </reference>
+
+ <reference anchor="URI" target="http://www.ietf.org/rfc/rfc3986.txt">
+ <front>
+ <title>Uniform Resource Identifiers (URI): Generic
+ Syntax</title>
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>Massachusetts Institute of Technology</street>
+ <street>77 Massachusetts Avenue</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 617 253 5702</phone>
+ <facsimile>+1 617 258 5999</facsimile>
+ <email>timbl at w3.org</email>
+ </address>
+ </author>
+ <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+ <organization abbrev="DAY">Day Software</organization>
+ <address>
+ <postal>
+ <street>5251 California Ave., Suite 110</street>
+ <city>Irvine</city> <region>CA</region> <code>92617</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 949 679 2960</phone>
+ <facsimile>+1 949 679 2927</facsimile>
+ <email>fielding at gbiv.com</email>
+ </address>
+ </author>
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization>Adobe Systems Incorporated</organization>
+ <address>
+ <postal>
+ <street>345 Park Ave</street>
+ <city>San Jose</city> <region>CA</region> <code>95110</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 408 536 3024</phone>
+ <email>LMM at acm.org</email>
+ </address>
+ </author>
+ <date month="January" year="2005" />
+ </front>
+ <seriesInfo name="RFC" value="3986" />
+ </reference>
+
+ <reference anchor="HTTP" target="http://www.ietf.org/rfc/rfc2616.txt">
+ <front>
+ <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
+ <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+ <organization abbrev="UCI">University of California, Irvine</organization>
+ <address>
+ <postal>
+ <street>Department of Information and Computer Science</street>
+ <street>University of California, Irvine</street>
+ <city>Irvine</city> <region>CA</region> <code>92697-3425</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 949 824 7403</phone>
+ <facsimile>+1 949 824 1715</facsimile>
+ <email>fielding at ics.uci.edu</email>
+ </address>
+ </author>
+ <author initials="J." surname="Gettys" fullname="James Gettys">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <facsimile>+1 617 258 8682</facsimile>
+ <email>jg at w3.org</email>
+ </address>
+ </author>
+ <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
+ <organization abbrev="WRL">Western Research Laboratory</organization>
+ <address>
+ <postal>
+ <street>Compaq Computer Corporation</street>
+ <street>250 University Avenue</street>
+ <city>Palo Alto</city> <region>CA</region> <code>94305</code>
+ <country>US</country>
+ </postal>
+ <email>mogul at wrl.dec.com</email>
+ </address>
+ </author>
+ <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <facsimile>+1 617 258 8682</facsimile>
+ <email>frystyk at w3.org</email>
+ </address>
+ </author>
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization>Xerox Corporation</organization>
+ <address>
+ <postal>
+ <street>3333 Coyote Hill Road</street>
+ <city>Palo Alto</city> <region>CA</region> <code>94034</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 650 812 4365</phone>
+ <facsimile>+1 650 812 4333</facsimile>
+ <email>masinter at parc.xerox.com</email>
+ </address>
+ </author>
+ <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
+ <organization>Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city> <region>WA</region> <code>98052</code>
+ <country>US</country>
+ </postal>
+ <email>paulle at microsoft.com</email>
+ </address>
+ </author>
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 617 253 5702</phone>
+ <facsimile>+1 617 258 8682</facsimile>
+ <email>timbl at w3.org</email>
+ </address>
+ </author>
+ <date month="June" year="1999" />
+ </front>
+ <seriesInfo name="RFC" value="2616" />
+ </reference>
+
+ <reference anchor="Headers" target="http://www.ietf.org/rfc/rfc2822.txt">
+ <front>
+ <title>Internet Message Format</title>
+ <author initials="P." surname="Resnick" fullname="Peter W. Resnick">
+ <organization abbrev="QUALCOMM">QUALCOMM Incorporated</organization>
+ <address>
+ <postal>
+ <street>5775 Morehouse Drive</street>
+ <city>San Diego</city> <region>CA</region> <code>92121-1714</code>
+ <country>USA</country>
+ </postal>
+ <phone>+1 858 651 4478</phone>
+ <facsimile>+1 858 651 1102</facsimile>
+ <email>presnick at qualcomm.com</email>
+ </address>
+ </author>
+ <date month="April" year="2001" />
+ </front>
+ <seriesInfo name="RFC" value="2822" />
+ </reference>
+
+ <reference anchor="I18N" target="http://www.ietf.org/rfc/rfc2277.txt">
+ <front>
+ <title>IETF Policy on Character Sets and Languages</title>
+ <author initials="H." surname="Alvestrand"
+ fullname="Harald Tveit Alvestrand">
+ <organization abbrev="UNINETT">UNINETT</organization>
+ <address>
+ <postal>
+ <street>P.O.Box 6883 Elgeseter</street>
+ <city>Trondheim</city> <code>7002</code>
+ <country>Norway</country>
+ </postal>
+ <phone>+47 73 59 70 94</phone>
+ <email>Harald.T.Alvestrand at uninett.no</email>
+ </address>
+ </author>
+ <date month="January" year="1998" />
+ </front>
+ <seriesInfo name="RFC" value="2277" />
+ </reference>
+
+ <reference anchor="RTSP" target="http://www.ietf.org/rfc/rfc2326.txt">
+ <front>
+ <title>Real Time Streaming Protocol (RTSP)</title>
+ <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
+ <organization abbrev="ColU">Columbia University</organization>
+ <address>
+ <postal>
+ <street>Dept. of Computer Science</street>
+ <street>1214 Amsterdam Avenue</street>
+ <city>New York</city> <region>NY</region> <code>10027</code>
+ <country>US</country>
+ </postal>
+ <email>schulzrinne at cs.columbia.edu</email>
+ </address>
+ </author>
+ <author initials="A." surname="Rao" fullname="Anup Rao">
+ <organization abbrev="NS">Netscape Communications Corp.</organization>
+ <address>
+ <postal>
+ <street>501 E. Middlefield Road</street>
+ <city>Mountain View</city> <region>CA</region> <code>94043</code>
+ <country>US</country>
+ </postal>
+ <email>anup at netscape.com</email>
+ </address>
+ </author>
+ <author initials="R." surname="Lanphier" fullname="Robert Lanphier">
+ <organization>RealNetworks</organization>
+ <address>
+ <postal>
+ <street>1111 Third Avenue Suite 2900</street>
+ <city>Seattle</city> <region>WA</region> <code>98101</code>
+ <country>US</country>
+ </postal>
+ <email>robla at real.com</email>
+ </address>
+ </author>
+ <date month="April" year="1998" />
+ </front>
+ <seriesInfo name="RFC" value="2326" />
+ </reference>
+
+ <reference anchor="LANG" target="http://www.ietf.org/rfc/rfc1766.txt">
+ <front>
+ <title>Tags for the Identification of Languages</title>
+ <author initials="H." surname="Alvestrand" fullname="Harald Tveit Alvestrand">
+ <organization abbrev="UNINETT">UNINETT</organization>
+ <address>
+ <postal>
+ <street>Pb. 6883 Elgeseter</street>
+ <city>Trondheim</city> <code>7002</code>
+ <country>Norway</country>
+ </postal>
+ <email>Harald.T.Alvestrand at uninett.no</email>
+ </address>
+ </author>
+ <date month="March" year="1995" />
+ </front>
+ <seriesInfo name="RFC" value="1766" />
+ </reference>
+
+ <reference anchor="MIME" target="http://www.ietf.org/rfc/rfc2046.txt">
+ <front>
+ <title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
+ <author initials="N." surname="Freed" fullname="Ned Freed">
+ <organization abbrev="Innosoft">Innosoft International, Inc.</organization>
+ <address>
+ <postal>
+ <street>1050 East Garvey Avenue South</street>
+ <city>West Covina</city> <region>CA</region> <code>91790</code>
+ <country>USA</country>
+ </postal>
+ <email>ned at innosoft.com</email>
+ </address>
+ </author>
+ <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+ <organization abbrev="First Virtual">First Virtual Holdings</organization>
+ <address>
+ <postal>
+ <street>25 Washington Avenue</street>
+ <city>Morristown</city> <region>NJ</region> <code>07960</code>
+ <country>USA</country>
+ </postal>
+ <email>nsb at nsb.fv.com</email>
+ </address>
+ </author>
+ <date month="November" year="1996" />
+ </front>
+ <seriesInfo name="RFC" value="2046" />
+ </reference>
+
+ <reference anchor="text/xml" target="http://www.ietf.org/rfc/rfc2376.txt">
+ <front>
+ <title>XML Media Types</title>
+ <author initials="E." surname="Whitehead" fullname="E. James Whitehead, Jr.">
+ <organization abbrev="UC Irvine">University of California, Irvine</organization>
+ <address>
+ <postal>
+ <street>Department of Information and Computer Science</street>
+ <city>Irvine</city> <region>CA</region> <code>92697-3425</code>
+ <country>USA</country>
+ </postal>
+ <email>ejw at ics.uci.edu</email>
+ </address>
+ </author>
+ <author initials="M." surname="Murata" fullname="Murata Makoto (Family Given)">
+ <organization abbrev="Fuji Xerox">Fuji Xerox Information Systems</organization>
+ <address>
+ <postal>
+ <street>KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku</street>
+ <city>Kawasaki-shi</city> <region>Kanagawa-ken</region> <code>213</code>
+ <country>Japan</country>
+ </postal>
+ <email>murata at fxis.fujixerox.co.jp</email>
+ </address>
+ </author>
+ <date month="July" year="1998" />
+ </front>
+ <seriesInfo name="RFC" value="2376" />
+ </reference>
+
+ <reference anchor="Ogg" target="http://www.ietf.org/rfc/rfc3533.txt">
+ <front>
+ <title>The Ogg encapsulation format version 0</title>
+ <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ <address>
+ <postal>
+ <street>Locked Bag 17</street>
+ <city>North Ryde</city> <region>NSW</region> <code>2113</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+ 61 2 9325 3100</phone>
+ <facsimile>+ 61 2 9325 3200</facsimile>
+ <email>Silvia.Pfeiffer at csiro.au</email>
+ <uri>http://www.annodex.net/</uri>
+ </address>
+ </author>
+ <date month="May" year="2003" />
+ </front>
+ <seriesInfo name="RFC" value="3533" />
+ </reference>
+
+ <reference anchor="SMPTE">
+ <front>
+ <title>SMPTE STANDARD for Television, Audio and Film - Time and Control Code</title>
+ <author>
+ <organization abbrev="SMPTE"> The Society of Motion Picture and Television Engineers</organization>
+ <address>
+ <postal>
+ <street>595 W. Hartsdale Ave.</street>
+ <city>White Plains</city> <region>NY</region> <code>10607</code>
+ <country>USA</country>
+ </postal>
+ <email>smpte at smpte.org</email>
+ </address>
+ </author>
+ <date month="September" year="1999" />
+ </front>
+ <seriesInfo name="ANSI" value="12M-1999" />
+ </reference>
+
+ <reference anchor="ISO8601">
+ <front>
+ <title>Data elements and interchange formats -- Information interchange -- Representation of dates and times</title>
+ <author initials="TC154" surname="ISO" fullname="ISO - Technical Committee TC 154">
+ <organization abbrev="ISO"> International Organization for Standardization</organization>
+ <address>
+ <postal>
+ <street>1 rue de Varembre</street>
+ <street>Case Postale 56</street>
+ <city>Geneva</city> <region>20</region> <code>1211</code>
+ <country>CH</country>
+ </postal>
+ <email>central at iso.org</email>
+ </address>
+ </author>
+ <date month="" year="2000" />
+ </front>
+ <seriesInfo name="ISO" value="8601" />
+ </reference>
+
+ <reference anchor="timedURI" target="http://www.annodex.net/TR/URI_fragments.txt">
+ <front>
+ <title>Specifying time intervals in URI queries and fragments of time-based Web resources (work in progress)</title>
+ <author initials="S.P." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4180</phone>
+ <email>Silvia.Pfeiffer at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+ <author initials="C." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4222</phone>
+ <email>Conrad.Parker at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+ <author initials="A." surname="Pang" fullname="Andre T. Pang">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4222</phone>
+ <email>Andre.Pang at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+ <date month="March" year="2005" />
+ </front>
+ <seriesInfo name="I-D" value="draft-pfeiffer-temporal-fragments-03.txt" />
+ </reference>
+
+ <reference anchor="CMML" target="http://www.annodex.net/TR/cmml.txt">
+ <front>
+ <title>The Continuous Media Markup Language (CMML), Version 2.0 (work in progress)</title>
+ <author initials="S.P." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4180</phone>
+ <email>Silvia.Pfeiffer at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+ <author initials="C." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4222</phone>
+ <email>Conrad.Parker at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+ <author initials="A." surname="Pang" fullname="Andre T. Pang">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4222</phone>
+ <email>Andre.Pang at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+ <date month="March" year="2005" />
+ </front>
+ <seriesInfo name="I-D" value="draft-pfeiffer-cmml-02.txt" />
+ </reference>
+
+ </references>
+
+ <section title="Acknowledgments">
+ <t>The authors greatly acknowledge the contributions of Christopher
+ Montgomery and Andre Pang in developing this specification.
+ </t>
+ </section>
+
+
+ </back>
+</rfc>
More information about the commits
mailing list