doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc3533.txt b/doc/rfc/rfc3533.txt
new file mode 100644
index 0000000..f2fcd1a
--- /dev/null
+++ b/doc/rfc/rfc3533.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                        S. Pfeiffer
+Request for Comments: 3533                                         CSIRO
+Category: Informational                                         May 2003
+
+
+                 The Ogg Encapsulation Format Version 0
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes the Ogg bitstream format version 0, which is
+   a general, freely-available encapsulation format for media streams.
+   It is able to encapsulate any kind and number of video and audio
+   encoding formats as well as other data streams in a single bitstream.
+
+Terminology
+
+   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, RFC 2119 [2].
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2. Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .   2
+   3. Requirements for a generic encapsulation format  . . . . . . .   3
+   4. The Ogg bitstream format . . . . . . . . . . . . . . . . . . .   3
+   5. The encapsulation process  . . . . . . . . . . . . . . . . . .   6
+   6. The Ogg page format  . . . . . . . . . . . . . . . . . . . . .   9
+   7. Security Considerations  . . . . . . . . . . . . . . . . . . .  11
+   8. References . . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   A. Glossary of terms and abbreviations  . . . . . . . . . . . . .  13
+   B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  14
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  14
+      Full Copyright Statement . . . . . . . . . . . . . . . . . . .  15
+
+
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 1]
+
+RFC 3533                          OGG                           May 2003
+
+
+1. Introduction
+
+   The Ogg bitstream format has been developed as a part of a larger
+   project aimed at creating a set of components for the coding and
+   decoding of multimedia content (codecs) which are to be freely
+   available and freely re-implementable, both in software and in
+   hardware for the computing community at large, including the Internet
+   community.  It is the intention of the Ogg developers represented by
+   Xiph.Org that it be usable without intellectual property concerns.
+
+   This document describes the Ogg bitstream format and how to use it to
+   encapsulate one or several media bitstreams created by one or several
+   encoders.  The Ogg transport bitstream is designed to provide
+   framing, error protection and seeking structure for higher-level
+   codec streams that consist of raw, unencapsulated data packets, such
+   as the Vorbis audio codec or the upcoming Tarkin and Theora video
+   codecs.  It is capable of interleaving different binary media and
+   other time-continuous data streams that are prepared by an encoder as
+   a sequence of data packets.  Ogg provides enough information to
+   properly separate data back into such encoder created data packets at
+   the original packet boundaries without relying on decoding to find
+   packet boundaries.
+
+   Please note that the MIME type application/ogg has been registered
+   with the IANA [1].
+
+2. Definitions
+
+   For describing the Ogg encapsulation process, a set of terms will be
+   used whose meaning needs to be well understood.  Therefore, some of
+   the most fundamental terms are defined now before we start with the
+   description of the requirements for a generic media stream
+   encapsulation format, the process of encapsulation, and the concrete
+   format of the Ogg bitstream.  See the Appendix for a more complete
+   glossary.
+
+   The result of an Ogg encapsulation is called the "Physical (Ogg)
+   Bitstream".  It encapsulates one or several encoder-created
+   bitstreams, which are called "Logical Bitstreams".  A logical
+   bitstream, provided to the Ogg encapsulation process, has a
+   structure, i.e., it is split up into a sequence of so-called
+   "Packets".  The packets are created by the encoder of that logical
+   bitstream and represent meaningful entities for that encoder only
+   (e.g., an uncompressed stream may use video frames as packets).  They
+   do not contain boundary information - strung together they appear to
+   be streams of random bytes with no landmarks.
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 2]
+
+RFC 3533                          OGG                           May 2003
+
+
+   Please note that the term "packet" is not used in this document to
+   signify entities for transport over a network.
+
+3. Requirements for a generic encapsulation format
+
+   The design idea behind Ogg was to provide a generic, linear media
+   transport format to enable both file-based storage and stream-based
+   transmission of one or several interleaved media streams independent
+   of the encoding format of the media data.  Such an encapsulation
+   format needs to provide:
+
+   o  framing for logical bitstreams.
+
+   o  interleaving of different logical bitstreams.
+
+   o  detection of corruption.
+
+   o  recapture after a parsing error.
+
+   o  position landmarks for direct random access of arbitrary positions
+      in the bitstream.
+
+   o  streaming capability (i.e., no seeking is needed to build a 100%
+      complete bitstream).
+
+   o  small overhead (i.e., use no more than approximately 1-2% of
+      bitstream bandwidth for packet boundary marking, high-level
+      framing, sync and seeking).
+
+   o  simplicity to enable fast parsing.
+
+   o  simple concatenation mechanism of several physical bitstreams.
+
+   All of these design considerations have been taken into consideration
+   for Ogg.  Ogg supports framing and interleaving of logical
+   bitstreams, seeking landmarks, detection of corruption, and stream
+   resynchronisation after a parsing error with no more than
+   approximately 1-2% overhead.  It is a generic framework to perform
+   encapsulation of time-continuous bitstreams.  It does not know any
+   specifics about the codec data that it encapsulates and is thus
+   independent of any media codec.
+
+4. The Ogg bitstream format
+
+   A physical Ogg bitstream consists of multiple logical bitstreams
+   interleaved in so-called "Pages".  Whole pages are taken in order
+   from multiple logical bitstreams multiplexed at the page level.  The
+   logical bitstreams are identified by a unique serial number in the
+
+
+
+Pfeiffer                     Informational                      [Page 3]
+
+RFC 3533                          OGG                           May 2003
+
+
+   header of each page of the physical bitstream.  This unique serial
+   number is created randomly and does not have any connection to the
+   content or encoder of the logical bitstream it represents.  Pages of
+   all logical bitstreams are concurrently interleaved, but they need
+   not be in a regular order - they are only required to be consecutive
+   within the logical bitstream.  Ogg demultiplexing reconstructs the
+   original logical bitstreams from the physical bitstream by taking the
+   pages in order from the physical bitstream and redirecting them into
+   the appropriate logical decoding entity.
+
+   Each Ogg page contains only one type of data as it belongs to one
+   logical bitstream only.  Pages are of variable size and have a page
+   header containing encapsulation and error recovery information.  Each
+   logical bitstream in a physical Ogg bitstream starts with a special
+   start page (bos=beginning of stream) and ends with a special page
+   (eos=end of stream).
+
+   The bos page contains information to uniquely identify the codec type
+   and MAY contain information to set up the decoding process.  The bos
+   page SHOULD also contain information about the encoded media - for
+   example, for audio, it should contain the sample rate and number of
+   channels.  By convention, the first bytes of the bos page contain
+   magic data that uniquely identifies the required codec.  It is the
+   responsibility of anyone fielding a new codec to make sure it is
+   possible to reliably distinguish his/her codec from all other codecs
+   in use.  There is no fixed way to detect the end of the codec-
+   identifying marker.  The format of the bos page is dependent on the
+   codec and therefore MUST be given in the encapsulation specification
+   of that logical bitstream type.  Ogg also allows but does not require
+   secondary header packets after the bos page for logical bitstreams
+   and these must also precede any data packets in any logical
+   bitstream.  These subsequent header packets are framed into an
+   integral number of pages, which will not contain any data packets.
+   So, a physical bitstream begins with the bos pages of all logical
+   bitstreams containing one initial header packet per page, followed by
+   the subsidiary header packets of all streams, followed by pages
+   containing data packets.
+
+   The encapsulation specification for one or more logical bitstreams is
+   called a "media mapping".  An example for a media mapping is "Ogg
+   Vorbis", which uses the Ogg framework to encapsulate Vorbis-encoded
+   audio data for stream-based storage (such as files) and transport
+   (such as TCP streams or pipes).  Ogg Vorbis provides the name and
+   revision of the Vorbis codec, the audio rate and the audio quality on
+   the Ogg Vorbis bos page.  It also uses two additional header pages
+   per logical bitstream.  The Ogg Vorbis bos page starts with the byte
+   0x01, followed by "vorbis" (a total of 7 bytes of identifier).
+
+
+
+
+Pfeiffer                     Informational                      [Page 4]
+
+RFC 3533                          OGG                           May 2003
+
+
+   Ogg knows two types of multiplexing: concurrent multiplexing (so-
+   called "Grouping") and sequential multiplexing (so-called
+   "Chaining").  Grouping defines how to interleave several logical
+   bitstreams page-wise in the same physical bitstream.  Grouping is for
+   example needed for interleaving a video stream with several
+   synchronised audio tracks using different codecs in different logical
+   bitstreams.  Chaining on the other hand, is defined to provide a
+   simple mechanism to concatenate physical Ogg bitstreams, as is often
+   needed for streaming applications.
+
+   In grouping, all bos pages of all logical bitstreams MUST appear
+   together at the beginning of the Ogg bitstream.  The media mapping
+   specifies the order of the initial pages.  For example, the grouping
+   of a specific Ogg video and Ogg audio bitstream may specify that the
+   physical bitstream MUST begin with the bos page of the logical video
+   bitstream, followed by the bos page of the audio bitstream.  Unlike
+   bos pages, eos pages for the logical bitstreams need not all occur
+   contiguously.  Eos pages may be 'nil' pages, that is, pages
+   containing no content but simply a page header with position
+   information and the eos flag set in the page header.  Each grouped
+   logical bitstream MUST have a unique serial number within the scope
+   of the physical bitstream.
+
+   In chaining, complete logical bitstreams are concatenated.  The
+   bitstreams do not overlap, i.e., the eos page of a given logical
+   bitstream is immediately followed by the bos page of the next.  Each
+   chained logical bitstream MUST have a unique serial number within the
+   scope of the physical bitstream.
+
+   It is possible to consecutively chain groups of concurrently
+   multiplexed bitstreams.  The groups, when unchained, MUST stand on
+   their own as a valid concurrently multiplexed bitstream.  The
+   following diagram shows a schematic example of such a physical
+   bitstream that obeys all the rules of both grouped and chained
+   multiplexed bitstreams.
+
+               physical bitstream with pages of
+          different logical bitstreams grouped and chained
+      -------------------------------------------------------------
+      |*A*|*B*|*C*|A|A|C|B|A|B|#A#|C|...|B|C|#B#|#C#|*D*|D|...|#D#|
+      -------------------------------------------------------------
+       bos bos bos             eos           eos eos bos       eos
+
+   In this example, there are two chained physical bitstreams, the first
+   of which is a grouped stream of three logical bitstreams A, B, and C.
+   The second physical bitstream is chained after the end of the grouped
+   bitstream, which ends after the last eos page of all its grouped
+   logical bitstreams.  As can be seen, grouped bitstreams begin
+
+
+
+Pfeiffer                     Informational                      [Page 5]
+
+RFC 3533                          OGG                           May 2003
+
+
+   together - all of the bos pages MUST appear before any data pages.
+   It can also be seen that pages of concurrently multiplexed bitstreams
+   need not conform to a regular order.  And it can be seen that a
+   grouped bitstream can end long before the other bitstreams in the
+   group end.
+
+   Ogg does not know any specifics about the codec data except that each
+   logical bitstream belongs to a different codec, the data from the
+   codec comes in order and has position markers (so-called "Granule
+   positions").  Ogg does not have a concept of 'time': it only knows
+   about sequentially increasing, unitless position markers.  An
+   application can only get temporal information through higher layers
+   which have access to the codec APIs to assign and convert granule
+   positions or time.
+
+   A specific definition of a media mapping using Ogg may put further
+   constraints on its specific use of the Ogg bitstream format.  For
+   example, a specific media mapping may require that all the eos pages
+   for all grouped bitstreams need to appear in direct sequence.  An
+   example for a media mapping is the specification of "Ogg Vorbis".
+   Another example is the upcoming "Ogg Theora" specification which
+   encapsulates Theora-encoded video data and usually comes multiplexed
+   with a Vorbis stream for an Ogg containing synchronised audio and
+   video.  As Ogg does not specify temporal relationships between the
+   encapsulated concurrently multiplexed bitstreams, the temporal
+   synchronisation between the audio and video stream will be specified
+   in this media mapping.  To enable streaming, pages from various
+   logical bitstreams will typically be interleaved in chronological
+   order.
+
+5. The encapsulation process
+
+   The process of multiplexing different logical bitstreams happens at
+   the level of pages as described above.  The bitstreams provided by
+   encoders are however handed over to Ogg as so-called "Packets" with
+   packet boundaries dependent on the encoding format.  The process of
+   encapsulating packets into pages will be described now.
+
+   From Ogg's perspective, packets can be of any arbitrary size.  A
+   specific media mapping will define how to group or break up packets
+   from a specific media encoder.  As Ogg pages have a maximum size of
+   about 64 kBytes, sometimes a packet has to be distributed over
+   several pages.  To simplify that process, Ogg divides each packet
+   into 255 byte long chunks plus a final shorter chunk.  These chunks
+   are called "Ogg Segments".  They are only a logical construct and do
+   not have a header for themselves.
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 6]
+
+RFC 3533                          OGG                           May 2003
+
+
+   A group of contiguous segments is wrapped into a variable length page
+   preceded by a header.  A segment table in the page header tells about
+   the "Lacing values" (sizes) of the segments included in the page.  A
+   flag in the page header tells whether a page contains a packet
+   continued from a previous page.  Note that a lacing value of 255
+   implies that a second lacing value follows in the packet, and a value
+   of less than 255 marks the end of the packet after that many
+   additional bytes.  A packet of 255 bytes (or a multiple of 255 bytes)
+   is terminated by a lacing value of 0.  Note also that a 'nil' (zero
+   length) packet is not an error; it consists of nothing more than a
+   lacing value of zero in the header.
+
+   The encoding is optimized for speed and the expected case of the
+   majority of packets being between 50 and 200 bytes large.  This is a
+   design justification rather than a recommendation.  This encoding
+   both avoids imposing a maximum packet size as well as imposing
+   minimum overhead on small packets.  In contrast, e.g., simply using
+   two bytes at the head of every packet and having a max packet size of
+   32 kBytes would always penalize small packets (< 255 bytes, the
+   typical case) with twice the segmentation overhead.  Using the lacing
+   values as suggested, small packets see the minimum possible byte-
+   aligned overhead (1 byte) and large packets (>512 bytes) see a fairly
+   constant ~0.5% overhead on encoding space.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 7]
+
+RFC 3533                          OGG                           May 2003
+
+
+   The following diagram shows a schematic example of a media mapping
+   using Ogg and grouped logical bitstreams:
+
+          logical bitstream with packet boundaries
+ -----------------------------------------------------------------
+ > |       packet_1             | packet_2         | packet_3 |  <
+ -----------------------------------------------------------------
+
+                     |segmentation (logically only)
+                     v
+
+      packet_1 (5 segments)          packet_2 (4 segs)    p_3 (2 segs)
+     ------------------------------ -------------------- ------------
+ ..  |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3|| |seg_1|s_2 | ..
+     ------------------------------ -------------------- ------------
+
+                     | page encapsulation
+                     v
+
+ page_1 (packet_1 data)   page_2 (pket_1 data)   page_3 (packet_2 data)
+------------------------  ----------------  ------------------------
+|H|------------------- |  |H|----------- |  |H|------------------- |
+|D||seg_1|seg_2|seg_3| |  |D|seg_4|s_5 | |  |D||seg_1|seg_2|seg_3| | ...
+|R|------------------- |  |R|----------- |  |R|------------------- |
+------------------------  ----------------  ------------------------
+
+                    |
+pages of            |
+other    --------|  |
+logical         -------
+bitstreams      | MUX |
+                -------
+                   |
+                   v
+
+              page_1  page_2          page_3
+      ------  ------  -------  -----  -------
+ ...  ||   |  ||   |  ||    |  ||  |  ||    |  ...
+      ------  ------  -------  -----  -------
+              physical Ogg bitstream
+
+   In this example we take a snapshot of the encapsulation process of
+   one logical bitstream.  We can see part of that bitstream's
+   subdivision into packets as provided by the codec.  The Ogg
+   encapsulation process chops up the packets into segments.  The
+   packets in this example are rather large such that packet_1 is split
+   into 5 segments - 4 segments with 255 bytes and a final smaller one.
+   Packet_2 is split into 4 segments - 3 segments with 255 bytes and a
+
+
+
+Pfeiffer                     Informational                      [Page 8]
+
+RFC 3533                          OGG                           May 2003
+
+
+   final very small one - and packet_3 is split into two segments.  The
+   encapsulation process then creates pages, which are quite small in
+   this example.  Page_1 consists of the first three segments of
+   packet_1, page_2 contains the remaining 2 segments from packet_1, and
+   page_3 contains the first three pages of packet_2.  Finally, this
+   logical bitstream is multiplexed into a physical Ogg bitstream with
+   pages of other logical bitstreams.
+
+6. The Ogg page format
+
+   A physical Ogg bitstream consists of a sequence of concatenated
+   pages.  Pages are of variable size, usually 4-8 kB, maximum 65307
+   bytes.  A page header contains all the information needed to
+   demultiplex the logical bitstreams out of the physical bitstream and
+   to perform basic error recovery and landmarks for seeking.  Each page
+   is a self-contained entity such that the page decode mechanism can
+   recognize, verify, and handle single pages at a time without
+   requiring the overall bitstream.
+
+   The Ogg page header has the following format:
+
+ 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| capture_pattern: Magic number for page start "OggS"           | 0-3
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| version       | header_type   | granule_position              | 4-7
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                                                               | 8-11
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               | bitstream_serial_number       | 12-15
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               | page_sequence_number          | 16-19
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               | CRC_checksum                  | 20-23
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|                               |page_segments  | segment_table | 24-27
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| ...                                                           | 28-
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The LSb (least significant bit) comes first in the Bytes.  Fields
+   with more than one byte length are encoded LSB (least significant
+   byte) first.
+
+
+
+
+
+
+
+Pfeiffer                     Informational                      [Page 9]
+
+RFC 3533                          OGG                           May 2003
+
+
+   The fields in the page header have the following meaning:
+
+   1. capture_pattern: a 4 Byte field that signifies the beginning of a
+      page.  It contains the magic numbers:
+
+            0x4f 'O'
+
+            0x67 'g'
+
+            0x67 'g'
+
+            0x53 'S'
+
+      It helps a decoder to find the page boundaries and regain
+      synchronisation after parsing a corrupted stream.  Once the
+      capture pattern is found, the decoder verifies page sync and
+      integrity by computing and comparing the checksum.
+
+   2. stream_structure_version: 1 Byte signifying the version number of
+      the Ogg file format used in this stream (this document specifies
+      version 0).
+
+   3. header_type_flag: the bits in this 1 Byte field identify the
+      specific type of this page.
+
+      *  bit 0x01
+
+         set: page contains data of a packet continued from the previous
+            page
+
+         unset: page contains a fresh packet
+
+      *  bit 0x02
+
+         set: this is the first page of a logical bitstream (bos)
+
+         unset: this page is not a first page
+
+      *  bit 0x04
+
+         set: this is the last page of a logical bitstream (eos)
+
+         unset: this page is not a last page
+
+   4. granule_position: an 8 Byte field containing position information.
+      For example, for an audio stream, it MAY contain the total number
+      of PCM samples encoded after including all frames finished on this
+      page.  For a video stream it MAY contain the total number of video
+
+
+
+Pfeiffer                     Informational                     [Page 10]
+
+RFC 3533                          OGG                           May 2003
+
+
+      frames encoded after this page.  This is a hint for the decoder
+      and gives it some timing and position information.  Its meaning is
+      dependent on the codec for that logical bitstream and specified in
+      a specific media mapping.  A special value of -1 (in two's
+      complement) indicates that no packets finish on this page.
+
+   5. bitstream_serial_number: a 4 Byte field containing the unique
+      serial number by which the logical bitstream is identified.
+
+   6. page_sequence_number: a 4 Byte field containing the sequence
+      number of the page so the decoder can identify page loss.  This
+      sequence number is increasing on each logical bitstream
+      separately.
+
+   7. CRC_checksum: a 4 Byte field containing a 32 bit CRC checksum of
+      the page (including header with zero CRC field and page content).
+      The generator polynomial is 0x04c11db7.
+
+   8. number_page_segments: 1 Byte giving the number of segment entries
+      encoded in the segment table.
+
+   9. segment_table: number_page_segments Bytes containing the lacing
+      values of all segments in this page.  Each Byte contains one
+      lacing value.
+
+   The total header size in bytes is given by:
+   header_size = number_page_segments + 27 [Byte]
+
+   The total page size in Bytes is given by:
+   page_size = header_size + sum(lacing_values: 1..number_page_segments)
+   [Byte]
+
+7. Security Considerations
+
+   The Ogg encapsulation format is a container format and only
+   encapsulates content (such as Vorbis-encoded audio).  It does not
+   provide for any generic encryption or signing of itself or its
+   contained content bitstreams.  However, it encapsulates any kind of
+   content bitstream as long as there is a codec for it, 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 physical bitstream and thus provides content confidentiality
+   and authenticity.
+
+   As Ogg encapsulates binary data, it is possible to include executable
+   content in an Ogg bitstream.  This can be an issue with applications
+   that are implemented using the Ogg format, especially when Ogg is
+   used for streaming or file transfer in a networking scenario.  As
+
+
+
+Pfeiffer                     Informational                     [Page 11]
+
+RFC 3533                          OGG                           May 2003
+
+
+   such, Ogg does not pose a threat there.  However, an application
+   decoding Ogg and its encapsulated content bitstreams has to ensure
+   correct handling of manipulated bitstreams, of buffer overflows and
+   the like.
+
+8. References
+
+   [1] Walleij, L., "The application/ogg Media Type", RFC 3534, May
+       2003.
+
+   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 12]
+
+RFC 3533                          OGG                           May 2003
+
+
+Appendix A. Glossary of terms and abbreviations
+
+   bos page: The initial page (beginning of stream) of a logical
+      bitstream which contains information to identify the codec type
+      and other decoding-relevant information.
+
+   chaining (or sequential multiplexing): Concatenation of two or more
+      complete physical Ogg bitstreams.
+
+   eos page: The final page (end of stream) of a logical bitstream.
+
+   granule position: An increasing position number for a specific
+      logical bitstream stored in the page header.  Its meaning is
+      dependent on the codec for that logical bitstream and specified in
+      a specific media mapping.
+
+   grouping (or concurrent multiplexing): Interleaving of pages of
+      several logical bitstreams into one complete physical Ogg
+      bitstream under the restriction that all bos pages of all grouped
+      logical bitstreams MUST appear before any data pages.
+
+   lacing value: An entry in the segment table of a page header
+      representing the size of the related segment.
+
+   logical bitstream: A sequence of bits being the result of an encoded
+      media stream.
+
+   media mapping: A specific use of the Ogg encapsulation format
+      together with a specific (set of) codec(s).
+
+   (Ogg) packet: A subpart of a logical bitstream that is created by the
+      encoder for that bitstream and represents a meaningful entity for
+      the encoder, but only a sequence of bits to the Ogg encapsulation.
+
+   (Ogg) page: A physical bitstream consists of a sequence of Ogg pages
+      containing data of one logical bitstream only.  It usually
+      contains a group of contiguous segments of one packet only, but
+      sometimes packets are too large and need to be split over several
+      pages.
+
+   physical (Ogg) bitstream: The sequence of bits resulting from an Ogg
+      encapsulation of one or several logical bitstreams.  It consists
+      of a sequence of pages from the logical bitstreams with the
+      restriction that the pages of one logical bitstream MUST come in
+      their correct temporal order.
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 13]
+
+RFC 3533                          OGG                           May 2003
+
+
+   (Ogg) segment: The Ogg encapsulation process splits each packet into
+      chunks of 255 bytes plus a last fractional chunk of less than 255
+      bytes.  These chunks are called segments.
+
+Appendix B. Acknowledgements
+
+   The author gratefully acknowledges the work that Christopher
+   Montgomery  and the Xiph.Org foundation have done in defining the Ogg
+   multimedia project and as part of it the open file format described
+   in this document.  The author hopes that providing this document to
+   the Internet community will help in promoting the Ogg multimedia
+   project at http://www.xiph.org/.  Many thanks also for the many
+   technical and typo corrections that C. Montgomery and the Ogg
+   community provided as feedback to this RFC.
+
+Author's Address
+
+   Silvia Pfeiffer
+   CSIRO, Australia
+   Locked Bag 17
+   North Ryde, NSW  2113
+   Australia
+
+   Phone: +61 2 9325 3141
+   EMail: Silvia.Pfeiffer@csiro.au
+   URI:   http://www.cmis.csiro.au/Silvia.Pfeiffer/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 14]
+
+RFC 3533                          OGG                           May 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer                     Informational                     [Page 15]
+