[xiph-commits] r3277 - standards
silvia at svn.annodex.net
silvia at svn.annodex.net
Sun Nov 18 16:15:46 PST 2007
Author: silvia
Date: 2007-11-18 16:15:46 -0800 (Sun, 18 Nov 2007)
New Revision: 3277
Added:
standards/draft-pfeiffer-cmml-current.txt
standards/draft-pfeiffer-oggskeleton-current.txt
Log:
Added text versions of the I-Ds for readability. DO NOT EDIT THESE, but stick with the XML files!!
Added: standards/draft-pfeiffer-cmml-current.txt
===================================================================
--- standards/draft-pfeiffer-cmml-current.txt (rev 0)
+++ standards/draft-pfeiffer-cmml-current.txt 2007-11-19 00:15:46 UTC (rev 3277)
@@ -0,0 +1,3575 @@
+
+Network Working Group S. Pfeiffer
+Internet-Draft C. Parker
+Intended status: Informational A. Pang
+Expires: September 2, 2005 CSIRO
+ March 2005
+
+
+ The Continuous Media Markup Language (CMML), Version 3.1
+ draft-pfeiffer-cmml-xx
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 September 2, 2005.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2005).
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 1]
+
+Internet-Draft CMML March 2005
+
+
+Abstract
+
+ This specification defines the Continuous Media Markup Language
+ (CMML), version 3.1, an XML-based [XML] markup language for time-
+ continuous data. It is a sister document to the specification of the
+ Annodex [ANX] annotation, indexing and hyperlinking format for time-
+ continuous data. A CMML file is essentially a textual representation
+ of an Annodex file.
+
+ The tags of a CMML file provide for the creation of structured and
+ unstructured annotations as well as hyperlinks and addressable named
+ anchor points for clips of time-continuous data. Through its import
+ tag, the CMML is also an authoring language for Annodex [ANX]
+ streams. The tag names in use in CMML are similar to the ones in
+ XHTML [XHTML].
+
+ 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 [KEYWORDS].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 2]
+
+Internet-Draft CMML March 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. The CMML data types . . . . . . . . . . . . . . . . . . . . . 7
+ 2.1. ContentType . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.2. LinkTypes . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.3. MediaDesc . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 2.4. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 2.5. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 2.6. LanguageCode . . . . . . . . . . . . . . . . . . . . . . . 9
+ 2.7. Internationalisation support . . . . . . . . . . . . . . . 9
+ 2.8. Time specifications . . . . . . . . . . . . . . . . . . . 10
+ 2.9. Core Attributes . . . . . . . . . . . . . . . . . . . . . 10
+ 3. The preamble and the 'cmml' root element . . . . . . . . . . . 11
+ 4. The cmml 'stream' tag . . . . . . . . . . . . . . . . . . . . 12
+ 4.1. The 'import' tag . . . . . . . . . . . . . . . . . . . . . 13
+ 4.2. The 'param' tag . . . . . . . . . . . . . . . . . . . . . 14
+ 5. The cmml 'head' element . . . . . . . . . . . . . . . . . . . 16
+ 5.1. The 'title' element . . . . . . . . . . . . . . . . . . . 16
+ 5.2. The 'base' element . . . . . . . . . . . . . . . . . . . . 17
+ 5.3. The 'meta' element . . . . . . . . . . . . . . . . . . . . 17
+ 5.4. The 'link' element . . . . . . . . . . . . . . . . . . . . 18
+ 5.5. The 'style' element . . . . . . . . . . . . . . . . . . . 18
+ 6. The cmml 'clip' tag . . . . . . . . . . . . . . . . . . . . . 20
+ 6.1. The 'meta' element . . . . . . . . . . . . . . . . . . . . 21
+ 6.2. The 'style' element . . . . . . . . . . . . . . . . . . . 21
+ 6.3. The 'a' element . . . . . . . . . . . . . . . . . . . . . 21
+ 6.4. The 'img' element . . . . . . . . . . . . . . . . . . . . 22
+ 6.5. The 'desc' element . . . . . . . . . . . . . . . . . . . . 22
+ 6.6. The 'caption' element . . . . . . . . . . . . . . . . . . 23
+ 6.7. The 'p' element . . . . . . . . . . . . . . . . . . . . . 23
+ 6.8. The 'span' element . . . . . . . . . . . . . . . . . . . . 23
+ 6.9. The 'br' element . . . . . . . . . . . . . . . . . . . . . 23
+ 7. Serialising CMML . . . . . . . . . . . . . . . . . . . . . . . 25
+ 7.1. The format of the CMML ident header packet . . . . . . . . 25
+ 7.2. The format of the CMML secondary headers . . . . . . . . . 26
+ 7.3. The format of the CMML data packets . . . . . . . . . . . 27
+ 8. Mapping CMML into Ogg and Annodex . . . . . . . . . . . . . . 29
+ 8.1. Media mapping for a CMML logical bitstream inside Ogg . . 29
+ 8.2. Using CMML to author Annodex bitstreams . . . . . . . . . 30
+ 8.2.1. Creating the skeleton ident packet . . . . . . . . . . 31
+ 8.2.2. Creating the skeleton fisbone packets . . . . . . . . 31
+ 8.2.3. The CMML fisbone packet fields . . . . . . . . . . . . 32
+ 8.2.4. Usage of the 'stream' tag . . . . . . . . . . . . . . 33
+ 9. Extracting CMML from Annodex bitstreams . . . . . . . . . . . 35
+ 9.1. Extracting the preamble, 'head' and 'clip' tags . . . . . 35
+ 9.2. Creating a 'stream' tag . . . . . . . . . . . . . . . . . 35
+ 10. MIME media type registration for 'text/cmml' . . . . . . . . . 37
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 3]
+
+Internet-Draft CMML March 2005
+
+
+ 10.1. URI addressing into CMML files . . . . . . . . . . . . . . 37
+ 10.1.1. Query parameters for use with the http protocol
+ server-side . . . . . . . . . . . . . . . . . . . . . 38
+ 10.1.2. Fragment identifiers for use with the http
+ protocol client-side . . . . . . . . . . . . . . . . . 39
+ 11. Security considerations . . . . . . . . . . . . . . . . . . . 40
+ 12. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 41
+ 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
+ Appendix A. CMML DTD . . . . . . . . . . . . . . . . . . . . . . 44
+ Appendix B. An example CMML document . . . . . . . . . . . . . . 45
+ Appendix C. Definitions of terms and abbreviations . . . . . . . 47
+ Appendix D. Glossary of acronyms . . . . . . . . . . . . . . . . 48
+ Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 49
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
+ Intellectual Property and Copyright Statements . . . . . . . . . . 51
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 4]
+
+Internet-Draft CMML March 2005
+
+
+1. Introduction
+
+ The Continuous Media Markup Language (CMML) specifies XML based
+ markup for time-continuous data to allow it to become an integral
+ part of the World Wide Web analogously to how HTML allowed text
+ documents to become part of the Web. Therefore, format of the CMML
+ derives much from XHTML.
+
+ CMML allows the attachment of free-text annotations, metadata,
+ captions and other textual information to clips of time-continuous
+ data. This provides a timed, textual representation of the data that
+ can be indexed by Web search engines.
+
+ CMML also allows the attachment of a hyperlink to each clip of time-
+ continuous data, enabling Web search engines to crawl the content.
+ This also allows users to surf seamlessly between time-continuous
+ data and other Web resources, integrating clips of media into the
+ browsing history of a Web browser.
+
+ CMML also provides a way of referencing a representative image for
+ each clip of time-continuous data, providing a visual representation
+ of the clip in conjunction with the textual representation. The
+ expected usage scenario for this is in the presentation of search
+ results or in a table of clips.
+
+ CMML provides a "head" element to store information that concerns the
+ complete time-continous resource, and a set of "clip" elements that
+ each store information for a temporal subpart of the resource.
+
+ The practical use of a CMML file is in conjunction with the Annodex
+ exchange format [ANX]. CMML markup can be interleaved inside an
+ Annodex file or stream to allow a synchronised delivery of marked-up
+ time-continuous data in a single stream between a Web server and a
+ user agent.
+
+ CMML has also been designed as an authoring language for Annodex
+ bitstreams. It allows the description of time-continuous data
+ bitstream(s) that need to be multiplexed together to create an
+ Annodex bitstream. This information is stored in the "stream"
+ element of a CMML document. Such a document can be used to control
+ the multiplexing process that creates an Annodex file.
+
+ The following picture illustrates the multiplexing activity
+ schematically; in reality, the stream tag is not preserved in its
+ original form and some attribute values are also encoded in the
+ binary data. Details of how CMML markup is encoded in an Annodex
+ bitstream are given later in this document.
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 5]
+
+Internet-Draft CMML March 2005
+
+
+ ----------
+ |stream | CMML
+ ---------- instance
+ | head | document
+ ----------
+ | clip_1 | ----------------------------------------------------
+ ---------- | data bitstream in packets |
+ | ... | ----------------------------------------------------
+ ---------- |
+ | clip_n | |
+ ---------- |
+ | |
+ ------->-<-------
+ | Multiplexing
+ |
+ v
+ ---------------------------------------------------------------------
+ |stream|head|clip_1| data packets |clip_2| data packets ...
+ ---------------------------------------------------------------------
+
+ The CMML is technically fully specified through its DTD as given in
+ the Appendix. The semantic meaning of each of the tags, their
+ content and their attributes is specified in the following sections.
+ The Appendix also contains an example of a CMML (instance) document.
+
+ The file extension of CMML files is ".cmml". This document also
+ applies for registration of the mime-type "text/cmml" for CMML files
+ with IANA. In the meantime, "text/x-cmml" will be used.
+
+ Please note that this document assumes that the reader has a fluent
+ working knowledge of Extensible Markup Language (XML) [XML],
+ Hypertext Markup Language (HTML) [HTML], XHTML [XHTML], Cascading
+ Style Sheets (CSS) [CSS] and the World Wide Web. Basic knowledge
+ about the Annodex [ANX] format is also assumed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 6]
+
+Internet-Draft CMML March 2005
+
+
+2. The CMML data types
+
+ At the beginning of the CMML DTD, several parameter entities are
+ defined that are used throughout the DTD as data types. This section
+ gives a brief overview of them and refers to the relevant standards
+ in which they are defined.
+
+2.1. ContentType
+
+ A "ContentType" specifies the media type and subtype of a document as
+ defined in RFC 2045 [ContentType]. It is used to specify the type of
+ content that one input time-continuous bitstream contains. Examples
+ are "application/annodex", "audio/x-speex", "video/x-theora", or
+ "video/mpeg".
+
+2.2. LinkTypes
+
+ "LinkTypes" specifies a space-separated list of the types of
+ relationships a linked, i.e. related, document has to the current
+ one. As in XHTML, user agents, search engines, etc. may interpret
+ these link types in a variety of ways. For example, user agents may
+ provide access to linked documents through a navigation bar. Authors
+ may use the following recognized link types which are a superset of
+ the ones used for XHTML/HTML:
+
+ o edit: Refers to a document that allows editing the resource. This
+ enables a document author to allow others to edit the CMML which
+ is the basis for an Annodex resource.
+
+ o alternate: Designates substitute versions for the document in
+ which the link occurs. When used together with the media
+ attribute, it implies a version designed for a different medium
+ (or media).
+
+ o stylesheet: Refers to an external style sheet.
+
+ o start: Refers to the first document in a collection of documents.
+ This link type tells search engines which document is considered
+ by the author to be the starting point of the collection.
+
+ o next: Refers to the next document in a linear sequence of
+ documents. User agents may choose to pre-load the "next"
+ document, to reduce the perceived load time.
+
+ o prev: Refers to the previous document in an ordered series of
+ documents.
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 7]
+
+Internet-Draft CMML March 2005
+
+
+ o contents: Refers to a document serving as a table of contents.
+ Although this may seem strange in a CMML file, it makes sense in
+ an Annodex file and may simply refer back to the CMML file or to a
+ HTML page that provides similar information.
+
+ o index: Refers to a document providing an index for the current
+ document.
+
+ o glossary: Refers to a document providing a glossary of terms that
+ pertain to the current document.
+
+ o copyright: Refers to a copyright statement for the current
+ document. While this could also be given in the meta tags, this
+ could refer to a formatted, legal document.
+
+ o chapter: Refers to a document serving as a chapter in a collection
+ of documents.
+
+ o section: Refers to a document serving as a section in a collection
+ of documents.
+
+ o subsection: Refers to a document serving as a subsection in a
+ collection of documents.
+
+ o appendix: Refers to a document serving as an appendix in a
+ collection of documents.
+
+ o help: Refers to a document offering help (more information, links
+ to other sources information, etc.)
+
+ o bookmark: Refers to a bookmark. A bookmark is a link to a key
+ entry point within an extended document. The title attribute may
+ be used, for example, to label the bookmark. Note that several
+ bookmarks may be defined in each document.
+
+2.3. MediaDesc
+
+ A "MediaDesc" describes one or several types of devices for which the
+ given style is appropriate. It is given as a list of comma-separated
+ media descriptors. Which devices are supported will need to be
+ specified in a separate style sheet specification. The following set
+ of device types, adapted from XHTML/HTML in CSS1, are recognized:
+
+ o all: suitable for all devices.
+
+ o aural: suitable for speech synthesizers.
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 8]
+
+Internet-Draft CMML March 2005
+
+
+ o braille: intended for braille tactile feedback devices.
+
+ o embossed: intended for paged braille printers.
+
+ o handheld: intended for handheld devices (characterized by a small,
+ monochrome or colour display and limited bandwidth).
+
+ o print: intended for paged output to a printer or print preview on
+ a screen.
+
+ o projection: intended for projected presentations (projectors or
+ print to transparencies).
+
+ o screen: intended for non-paged, colour computer screens.
+
+ o tty: intended for fixed-pitch character grid displays (such as the
+ teletypes or terminals).
+
+ o tv: for television-type devices with low resolution and limited
+ scrollability.
+
+2.4. Text
+
+ A "Text" describes a short, free form text being used for the "title"
+ attribute.
+
+2.5. URI
+
+ A "URI" is a character string that conforms to the specification of
+ the Uniform Resource Identifier as defined in RFC 3986 [URI]. A URI
+ generally points to a Web resource. The URI time interval
+ specification [timedURI] is supported for CMML and Annodex files.
+ Also, direct addressing of clips as specified in the MIME type
+ application part of this document is supported for CMML and Anndex
+ files.
+
+2.6. LanguageCode
+
+ The "LanguageCode" defines a collection of constant strings that each
+ identify a specific language as defined in RFC 1766 [LANG]. Examples
+ are: en-au, de, x-klingon. Language codes are used to provide
+ internationalisation support.
+
+2.7. Internationalisation support
+
+ To provide international language support, the i18n entity draws
+ together a language given by a "LanguageCode" in "lang" with the
+ directionality of that language in "dir" given either as ltr (left-
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 9]
+
+Internet-Draft CMML March 2005
+
+
+ to-right) or rtl (right-to-left). "ltr" is the default.
+
+2.8. Time specifications
+
+ There are three different time specifications in use in CMML:
+ "Timestamp", "Playbacktime" and "UTCtime".
+
+ A "Timestamp" is generally a name-value pair which defines a time
+ point. The time point value is interpreted according to the time
+ scheme given in the name. If the name is ommitted, it defaults to
+ "npt:". Valid time schemes are the ones defined in the temporal URI
+ specification [timedURI].
+
+ The "Playbacktime" entity is a data type that just specifies a SMPTE
+ or a NPT time. It is therefore equal to the Timestamp entity without
+ the UTC specification.
+
+ The "UTCtime" entity is a data type that just specifies a UTC time
+ without an identifier. UTC time is specified as in the Timestamp
+ entity, but without the "clock:" identifier.
+
+2.9. Core Attributes
+
+ To cluster together the attributes that are common to most
+ displayable elements, the "attrs" entity draws them together. As
+ "i18n" is already a cluster, a "coreattrs" entity is defined, which
+ groups together the other commonly used attributes for displayable
+ elements, namely the unique identifier given in "id", the "class"
+ attribute which provides a space-separated list of style sheet
+ classes that the element belongs to, and the "title" attribute, which
+ provides a short tooltip-like description for an element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 10]
+
+Internet-Draft CMML March 2005
+
+
+3. The preamble and the 'cmml' root element
+
+ A CMML file is an XML instance document of the CMML DTD. An example
+ is given in the Appendix. It starts with the usual xml directive and
+ the DTD specification (see
+ http://www.w3.org/TR/REC-xml#sec-prolog-dtd). The following is an
+ example preamble:
+
+ <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+ <!DOCTYPE cmml SYSTEM "cmml.dtd">
+
+ After the preamble, the CMML tag follows. A CMML file has a "cmml"
+ tag as the root element. It embraces all the other tags.
+
+ <!ELEMENT cmml (stream?, head, clip*)>
+ <!ATTLIST cmml
+ %i18n;
+ id ID #IMPLIED
+ xmlns %URI; #FIXED 'http://www.annodex.net/cmml'
+ granulerate CDATA #IMPLIED
+ >
+
+ The "cmml" tag encloses at most one "stream" element, exactly one
+ "head" element, and as many "clip" elements as the document author
+ requires. A "clip" element describes a section of the related
+ Annodex bitstream.
+
+ Attributes of the "cmml" element are the usual xml root tag
+ attributes: the internationalisation attributes "lang" and "dir", an
+ identifier "id", a fixed namespace "xmlns", and the "granulerate".
+
+ The internationalisation attributes specify the default language
+ (language and directionality) of the complete CMML document. If not
+ given, the language default adheres to the same rules as HTML, where
+ the setting of the HTTP "Content-Language" header may specify the
+ default language of a HTML document received over HTTP, or ultimately
+ the user agent defaults and user preferences set the language. (see
+ http://www.w3.org/TR/REC-html40/struct/dirlang.html)
+
+ Every element has an "id" attribute. The value of the "id" attribute
+ MUST be unique within the document. It allows to uniquely identify
+ an instance of an element and address it.
+
+ The "granulerate" attribute may provide a base temporal resolution
+ for the CMML bitstream. This is in particular used for creation of
+ Annodex files from a given CMML instance document.
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 11]
+
+Internet-Draft CMML March 2005
+
+
+4. The cmml 'stream' tag
+
+ The "stream" element contains information that is used for authoring
+ Annodex [ANX] bitstreams from existing time-continuous data. The
+ Annodex bistream is created by multiplexing the bitstreams given in
+ the "src" attributes of the "import" tags of the "stream" element
+ together with the CMML annotations in a time-synchronous manner.
+
+ The "stream" element describes in the "import" tags the input time-
+ continuous bitstreams that are to be multiplexed together on
+ authoring the Annodex bitstream. Its attributes describe other
+ features of the Annodex bitstream such as the time mappings for the
+ start of the file.
+
+ <!ELEMENT stream (import*)>
+ <!ATTLIST stream
+ id ID #IMPLIED
+ basetime %Playbacktime; "0"
+ utc %UTCtime; #IMPLIED
+ >
+
+ The "stream" element has no text attributes and thus
+ internationalisation attributes are not required. The "id" attribute
+ follows the default language specified in the "cmml" element.
+
+ The "basetime" attribute contains a playback time in seconds
+ associated with the first data packet of the Annodex bitstream. All
+ other times in the CMML file MUST be calculated relative to this
+ basetime. For example, a basetime of 300 seconds npt for a video
+ file implies that the first frame is related to a play time of 300
+ seconds, and a clip with a start time of 350 seconds is to be
+ included 50 seconds into the Annodex bitstream. If no basetime (or
+ no stream tag) is given, the basetime defaults to 0 npt. The
+ basetime can be given as a SMPTE or NPT time, or as a rational number
+ as in 5/1300, but not as a utc time.
+
+ The "utc" attribute associates a calendar date and a wall-clock time
+ with the basetime. It therefore provides a mapping of the basetime
+ to a real-world clock time and is given as a UTC time. If it is
+ omitted, the start attribute in the import tag, and the start and end
+ attributes in clip tags MUST NOT be specified as UTC times.
+
+ The content model of the "stream" tag then proposes an arbitrary
+ number of input bitstreams. These are described one by one in the
+ "import" element.
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 12]
+
+Internet-Draft CMML March 2005
+
+
+4.1. The 'import' tag
+
+ A "import" tag contains information on one of the input bitstreams
+ for the multiplexing process. It may also contain additional
+ parameters to set up the Annodex encoder for each import bitstream.
+
+ <!ELEMENT import (param*)>
+ <!ATTLIST import
+ %i18n;
+ id ID #IMPLIED
+ granulerate CDATA #IMPLIED
+ contenttype %ContentType; #IMPLIED
+ src %URI; #REQUIRED
+ start %Timestamp; "0"
+ end %Timestamp; #IMPLIED
+ title CDATA #IMPLIED
+ >
+
+ The relevant bitstream (fragment) is referenced through the "src"
+ attribute. The src is a URI and may thus also contain a time
+ interval specification in URIs which narrows down the input file to
+ that given subpart. That resource is multiplexed into the Annodex
+ bitstream starting at the time given in the "start" attribute and
+ ending at the latest at the time given in the "end" attribute. The
+ "start" and "end" attributes are interpreted relative to the timeline
+ of the Annodex bitstream.
+
+ The internationalisation attributes provide the language of the
+ import element's and the contained param tags' attribute values, such
+ as the "id" attributes and the "title" attribute.
+
+ The "granulerate" attribute contains the base temporal resolution in
+ Hz of the input bitstream referred in the "src" attribute. It
+ depends on the encoding format of the input bitstream and typically
+ contains the framerate for video (e.g. 25 frames/sec) and the
+ samplerate for audio (e.g. 44100 samples/sec), but may contain any
+ rational number given with an integer denominator larger than 1 sec
+ (e.g. 25 frames on 2 seconds). Each bitstream has its own
+ granulerate dependent on its specific encoding. This attribute is
+ implied as it can be determined automatically during the multiplexing
+ process from the headers of the encoded media bitstream. For
+ bitstreams without header, such as uncompressed audio, the author of
+ the CMML file can provide the granulerate to the multiplexer in this
+ attribute.
+
+ The "contenttype" attribute specifies the media type [ContentType] of
+ the input bitstream referred in the "src" attribute. It is optional
+ as the media type can often be derived from the file name or file
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 13]
+
+Internet-Draft CMML March 2005
+
+
+ header of the media source during multiplexing.
+
+ The "src" attribute specifies a URI to the input bitstream. Commonly
+ used URI schemes are "file" and "http". For specifying temporal
+ subsets of the input bitstream, use the time interval specification
+ for URIs [timedURI].
+
+ The "start" attribute specifies a time in the output Annodex
+ bitstream at which the media bitstream will be inserted. This time
+ is specified with respect to the "basetime" attribute given in the
+ "stream" element.
+
+ The "end" attribute specifies a time in the output Annodex bitstream
+ at which the media bitstream will stop at the latest. This time is
+ also specified with respect to the "basetime" attribute given in the
+ "stream" element. This attribute is not required when the full
+ bitstream is used.
+
+ The optional "title" attribute provides a chance to jot down a human
+ readable comment on the source bitstream. This may e.g. be used in
+ authoring applications for a more human readable display than the
+ "id" tag which is really a key for identifying elements uniquely.
+
+ The content model of the "import" tag then allows an arbitrary number
+ of "param" tags to add as many descriptive parameter values to the
+ mulitplexing activity as necessary.
+
+4.2. The 'param' tag
+
+ A "param" tag is empty, but its attributes contain a name-value pair
+ for describing the input bitstream in the parent "import" element.
+ It inherits its internationalisation from that element, too, to avoid
+ overhead. The "param" element is declared as follows:
+
+ <!ELEMENT param EMPTY>
+ <!ATTLIST param
+ id ID #IMPLIED
+ name CDATA #REQUIRED
+ value CDATA #REQUIRED
+ >
+
+ The "name" attribute identifies a property name. It does not list
+ legal values for this attribute.
+
+ The "value" attribute specifies a property's value. It does not list
+ legal values for this attribute.
+
+ An example parametrisation is the provision of machine-processable
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 14]
+
+Internet-Draft CMML March 2005
+
+
+ low level meta information about the import bitstream such as a
+ video's image height and width and framerate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 15]
+
+Internet-Draft CMML March 2005
+
+
+5. The cmml 'head' element
+
+ The CMML "head" element contains annotation information on the
+ complete Annodex bitstream, for whose creation the CMML file is used.
+ It therefore contains header-type information such as a title, style
+ information, related documents and meta information describing the
+ bitstream.
+
+ The "head" element is declared as the following:
+
+ <!ENTITY % head.misc "(style|meta|link)*">
+
+ <!ELEMENT head (%head.misc;,
+ ((title, %head.misc;, (base, %head.misc;)?) |
+ (base, %head.misc;, (title, %head.misc;))))>
+ <!ATTLIST head
+ %i18n;
+ id ID #IMPLIED
+ profile %URI; #IMPLIED
+ >
+
+ The "head" tag must contain a "title" tag. It may contain one "base"
+ tag before or after the "title" tag and any number of "style",
+ "meta", or "link" tags at any position.
+
+ The "%i18n;" attribute specifies the base language of the "head"
+ tag's attribute values.
+
+ The value of the "profile" attribute is a space-separated list of
+ base URIs specifying locations of "meta" tag schemes such as the
+ Dublin Core (see http://dublincore.org/). These schemes may be used
+ in the "meta" elements of the "head" or the "clip" tags.
+
+5.1. The 'title' element
+
+ The "title" tag gives a descriptive title for the complete Annodex
+ bitstream. It is not considered to be part of the presentation and
+ should be displayed, e.g. as the title of the window that the Annodex
+ bitstream is being displayed in. Exactly one title is required per
+ document. The "title" element is declared as the following:
+
+ <!ELEMENT title (#PCDATA)>
+ <!ATTLIST title
+ %i18n;
+ id ID #IMPLIED
+ >
+
+ The "%i18n;" attribute specifies the base language of the "title"
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 16]
+
+Internet-Draft CMML March 2005
+
+
+ text.
+
+5.2. The 'base' element
+
+ The "base" element defines the base URI of the Annodex bitstream.
+ All relative URIs of the bitstream get interpreted relative to this
+ base. The "base" element is empty, but its attributes contain the
+ base URI. It is declared as follows:
+
+ <!ELEMENT base EMPTY>
+ <!ATTLIST base
+ id ID #IMPLIED
+ href %URI; #REQUIRED
+ >
+
+ The "href" attribute contains the base URI. If the "base" element is
+ omitted, the base URI of the Annodex bitstream is derived from the
+ address through which the Annodex bitstream is accessed.
+
+5.3. The 'meta' element
+
+ The "meta" element in the "head" element defines structured
+ annotations for the complete Annodex bitstream. A "meta" element is
+ empty, but its attributes contain the name-value pairs of a
+ structured annotation. The "meta" element is declared as follows:
+
+ <!ELEMENT meta EMPTY>
+ <!ATTLIST meta
+ %i18n;
+ id ID #IMPLIED
+ name NMTOKEN #IMPLIED
+ content CDATA #REQUIRED
+ scheme CDATA #IMPLIED
+ >
+
+ The "%i18n;" attribute specifies the language of the meta attribute
+ and content texts.
+
+ The "name" attribute identifies a property name. It does not list
+ legal values for this attribute.
+
+ The "content" attribute specifies a property's value. It does not
+ list legal values for this attribute.
+
+ The "scheme" attribute names a scheme to be used to interprete the
+ property's value. The scheme can be located via the "profile"
+ attribute in the "head" element.
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 17]
+
+Internet-Draft CMML March 2005
+
+
+5.4. The 'link' element
+
+ The "link" element in the "head" element defines links to a related
+ external resource. These resources are often used to augment the
+ user agent's ability to process the current document. The "link"
+ element is declared as follows:
+
+ <!ELEMENT link EMPTY>
+ <!ATTLIST link
+ %attrs;
+ href %URI; #IMPLIED
+ type %ContentType; #IMPLIED
+ rel %LinkTypes; #IMPLIED
+ rev %LinkTypes; #IMPLIED
+ media %MediaDesc; #IMPLIED
+ >
+
+ The "attrs;" attribute covers the specification of the language of
+ the title attribute, a unique identifing name, a reference to a style
+ sheet specification, and a title attribute to provide a short
+ description of the relationship between the current document and the
+ one referred to in the "href" attributed.
+
+ The "href" attribute contains a URI reference to a related external
+ resource. These resources are often used to augment the user agent's
+ ability to process the current document.
+
+ The "type" attribute contains a media type specification for the
+ linked document as per RFC 2045 [ContentType], e.g. "text/
+ x-css-cmml".
+
+ The "rel" attribute describes the relationship from the current
+ document to the resource specified by the href attribute. The value
+ of this attribute is a space-separated list of link types.
+
+ The "rev" attribute describes a reverse link from the resource
+ specified by the href attribute to the current document. The value
+ of this attribute is a space-separated list of link types.
+
+ The "media" attribute specifies the intended destination device for
+ style information, if the href points to an external style sheet. It
+ may be a single media descriptor or a comma-separated list. The
+ default value for this attribute is "screen".
+
+5.5. The 'style' element
+
+ The "style" element in the "head" element contains an internally
+ defined style sheet. The "style" element is declared as follows:
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 18]
+
+Internet-Draft CMML March 2005
+
+
+ <!ELEMENT style (#PCDATA)>
+ <!ATTLIST style
+ %i18n;
+ id ID #IMPLIED
+ title %Text; #IMPLIED
+ type %ContentType; #REQUIRED
+ media %MediaDesc; #IMPLIED
+ xml:space (preserve) #FIXED 'preserve'
+ >
+
+ The "i18n;" attribute containt the language of the title attribute.
+
+ The "title" attribute contains a short description of the style in
+ human readable form.
+
+ The "type" attribute contains a media type specification for the
+ linked document as per RFC 2045 [ContentType], e.g. "text/
+ x-css-cmml".
+
+ The "media" attribute specifies the intended destination device for
+ the style information. It may be a single media descriptor or a
+ comma-separated list. The default value for this attribute is
+ "screen".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 19]
+
+Internet-Draft CMML March 2005
+
+
+6. The cmml 'clip' tag
+
+ A CMML file typically contains a number of sections given through
+ "clip" tags. The CMML "clip" tag contains information about a
+ section of the Annodex bitstream. This is expressed in a number of
+ elements and attributes annotating, indexing, and hyperlinking the
+ section. The "start" and "end" attributes are used to give the
+ insertion time for the clip into the Annodex bitstream.
+
+ <!ELEMENT clip ((meta|style)*, a?, img?, desc?, caption?)>
+ <!ATTLIST clip
+ %attrs;
+ track CDATA "default"
+ start %Timestamp; #REQUIRED
+ end %Timestamp; #IMPLIED
+ >
+
+ Any number of "meta" or "style" elements may appear in a clip, and at
+ most one "a" element, one "img" element, and one "desc" element.
+ Though "meta", "style", "a", "img", and "desc" tag are given in a
+ specific order in the DTD, their order is actually random.
+
+ The "%i18n;" attributes part of the "%attrs;" attributes specify the
+ base language for all the clip's attribute values and content
+ elements. Also, a unique identifying name is specified for the clip
+ in the "id" attribute. This name can be used in URIs that point
+ either to the CMML file or the Annodex bitstream created from it, and
+ allows to point straight at the clip. This may either be done as a
+ URI fragment or URI query specification. The "class" attribute
+ provides a space-separated list of style sheet classes, and the
+ "title" attribute a short tooltip-like clip description.
+
+ The "track" attribute specifies the track that this clip belongs to.
+ An annotation track is a set of clips that belong together from a
+ semantic point of view. Clips in the same track must not overlap
+ temporally. A default track must be available always. This track is
+ the one a client (such as a Web browser plugin) will display by
+ default. Other annotation tracks may be created by the document
+ author to describe a more specific content. An example use are
+ different annotation tracks for each speaker in an audio recording of
+ a meeting or tracks of different languages.
+
+ The "start" and "end" attributes specify the time range during which
+ the clip element is defined. This time range is specified with
+ respect to the "basetime" and "utc" attributes given in the "stream"
+ tag. If the "stream" tag does not contain a "utc" specification,
+ "start" and "end" times are not allowed to be given in UTC time.
+ "start" is a required attribute because a clip without a start time
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 20]
+
+Internet-Draft CMML March 2005
+
+
+ is useless. "end" is optional and only required where clips cannot
+ continue on to the following clip.
+
+6.1. The 'meta' element
+
+ The "meta" element is specified above in the "head" section. While a
+ "meta" element in the "head" tag provides meta information for the
+ complete Annodex bitstream, the "meta" elements in a "clip" tag only
+ provide meta information for the clip.
+
+6.2. The 'style' element
+
+ The "style" element is specified above in the "head" section. While
+ a "style" element in the "head" tag provides style sheet information
+ for the complete Annodex bitstream, the "style" elements in a "clip"
+ tag only provide style sheet information for the clip.
+
+6.3. The 'a' element
+
+ The "a" element specifies a link to a related Web resource together
+ with some information on that related resource. The "a" element
+ definition is very closely related to the xhtml "a" element
+ definition with a reduced number of attributes as they make sense for
+ time-continuous data.
+
+ <!ELEMENT a (#PCDATA)>
+ <!ATTLIST a
+ %attrs;
+ href %URI; #REQUIRED
+ >
+
+ The "attrs" attributes specify internationalisation of the anchor's
+ attribute values and of the anchor text, style sheet class, unique
+ id, and a short, textual description of the hyperlink to be given
+ e.g. in tooltips.
+
+ The "href" attribute specifies the location of a Web resource given
+ through a URI. It thus defines a link between the current clip and a
+ resource which the author believes to be connected closely to this
+ clip's content. This might be a html page or another Annodex
+ bitstream clip or an image etc. An "a" element without a "href"
+ attribute is illegal and MUST be flagged or ignored.
+
+ The text contained in an "a" element (i.e. the anchor text) provides
+ a short textual description of the link specified through the "href"
+ attribute. It explains why the connection between the current clip
+ and the destination URI is made. It may e.g. encourage the viewer to
+ follow the link to "Get more information on blah".
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 21]
+
+Internet-Draft CMML March 2005
+
+
+6.4. The 'img' element
+
+ The "img" element specifies the URI of a representative image for the
+ clip. This image should be quite small as it is the representative
+ image (known as "keyframe") for the current clip. This image may be
+ used to visually summarise the content of the clip when a link to it
+ is displayed, e.g. by a search engine or in a table of clips. The
+ "img" element definition is very closely related to the xhtml "img"
+ element definition with a reduced number of attributes as they make
+ sense for time-continuous data.
+
+ <!ELEMENT img EMPTY>
+ <!ATTLIST img
+ %attrs;
+ src %URI; #REQUIRED
+ alt CDATA #IMPLIED
+ >
+
+ The "attrs" attributes specify internationalisation of the image's
+ attribute values, provide an "id" attribute, a short "title" text,
+ and a style sheet "class" for formatting the layout of the image.
+
+ The "src" attribute specifies the location of an image on the Web
+ given through a URI.
+
+ The "alt" attribute specifies alternative text to be displayed
+ instead of the image as required e.g. for accessibility.
+
+6.5. The 'desc' element
+
+ The "desc" tag contains a human readable, textual description of the
+ content of the clip. The "desc" element is declared as the
+ following:
+
+ <!ELEMENT desc (#PCDATA)>
+ <!ATTLIST desc
+ %attrs;
+ >
+
+ The internationalisation attributes specify the language of the text
+ in the description, the "id" attribute a unique identifier for the
+ element, the "class" attribute a style-sheet mapping, and the "title"
+ attribute a brief description to be displayed in e.g. a table of
+ clips.
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 22]
+
+Internet-Draft CMML March 2005
+
+
+6.6. The 'caption' element
+
+ The "caption" element functions as a logical container for one or
+ more textual content units represented as logical paragraphs. It is
+ created as a simplification of the Timed Text standards of W3C
+ [DFXP]. It is bound by the start and end time of the clip tag in
+ which it is contained. The "caption" element is declared as the
+ following:
+
+ <!ELEMENT caption (p*)>
+ <!ATTLIST caption
+ %attrs;
+ >
+
+6.7. The 'p' element
+
+ The "p" element contains a human readable piece of text that may be a
+ transcription, caption, sub-title or similar type of textual
+ description of a temporal subsection of the clip tag in which it is
+ contained. The "p" element is declared as the following:
+
+ <!ELEMENT p (span*, br*, #PCDATA)>
+ <!ATTLIST p
+ %attrs;
+ start %Timestamp; #REQUIRED
+ end %Timestamp; #IMPLIED
+ >
+
+6.8. The 'span' element
+
+ The "span" element functions as a logical container and a temporal
+ structuring element for a subpart of a textual content unit contained
+ in a 'p' element having inline-level formatting semantics. The
+ "span" element is declared as the following:
+
+ <!ELEMENT span (#PCDATA)>
+ <!ATTLIST span
+ %attrs;
+ >
+
+6.9. The 'br' element
+
+ The "br" element denotes an explicit line break. The "br" element is
+ declared as the following:
+
+ <!ELEMENT br EMPTY>
+ <!ATTLIST br
+ %attrs;
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 23]
+
+Internet-Draft CMML March 2005
+
+
+ >
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 24]
+
+Internet-Draft CMML March 2005
+
+
+7. Serialising CMML
+
+ CMML is an annotation language that is meant to mark up any time-
+ continuous data and be interleaved in a time-synchronous fashion with
+ other time-continuous bitstreams. Therefore, CMML must be able to be
+ serialised into a time-continuous bitstream of data packets. This is
+ described in this section.
+
+ CMML is serialised by having some initial header pages that set up
+ the CMML decoding environment, and contain header type information.
+ The content of a CMML bitstream then consists of "clip" tags. The
+ "stream" tag is not copied into the CMML bitstream as it controls the
+ authoring of the Annodex bitstream. Its information can be used in
+ the encapsulation format.
+
+ All of the CMML bitstream information is text. As it gets encoded
+ into a binary bitstream, an encoding format has to be specified. To
+ simplify things, UTF-8 is defined as the mandatory encoding format
+ for all data in a CMML binary bitstream. Also, the encoding process
+ MUST ensure that newline characters are represented as LF (or "\n" in
+ C) only and replace any new line representations that come as CR LF
+ combinations (or "\r\n" in C) with LF only.
+
+7.1. The format of the CMML ident header packet
+
+ The first header packet of a CMML logical bitstream is the CMML ident
+ header. It contains all information required to identify the CMML
+ bitstream and to set up a CMML decoder. It 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'CMML\0\0\0\0' | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version major | Version minor | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ...
+
+
+ The fields in a CMML ident header packet have the following meaning:
+
+ 1. Identifier: a 8 Byte field that identifies this file to be of a
+ CMML logical input bitstream. It contains the magic numbers:
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 25]
+
+Internet-Draft CMML March 2005
+
+
+ 0x43 'C'
+
+ 0x4d 'M'
+
+ 0x4d 'M'
+
+ 0x4c 'L'
+
+ 0x00 '\0'
+
+ 0x00 '\0'
+
+ 0x00 '\0'
+
+ 0x00 '\0'
+
+ 2. Version major: 2 Byte short integer number signifying the major
+ version number of the CMML format bitstream.
+
+ 3. Version minor: 2 Byte short integer number signifying the minor
+ version number of the CMML format bitstream.
+
+ When encapsulating a CMML bitstream, more fields may be added to this
+ header as required by the encapsulation or exchange format.
+
+7.2. The format of the CMML secondary headers
+
+ The CMML secondary headers are a sequence of two packets that contain
+ the CMML and XML "setup" information:
+
+ o one packet with the CMML xml preamble and "cmml" tag.
+
+ o one packet with the CMML "head" tag.
+
+ These packets contain textual, not binary information.
+
+ The CMML preamble tags are all single-line tags, such as the xml
+ processing instruction (<?xml...>) and the document type declaration
+ (<!DOCTYPE...>).
+
+ The only CMML tag that is not already serialized from a CMML file is
+ the "cmml" tag, as it encloses all the other content tags. To
+ serialise it, the "cmml" start tag is transformed into a processing
+ instruction, retaining all its attributes (<?cmml ...>), and the
+ "cmml" end tag is deleted.
+
+ The first CMML secondary header packet has the following format:
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 26]
+
+Internet-Draft CMML March 2005
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <?xml ... | 0-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <!DOCTYPE ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <?cmml ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ The second CMML secondary header packet contains the CMML head
+ element with all its attributes and other containing elements and 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <head ... | 0-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | </head> |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+7.3. The format of the CMML data packets
+
+ The data packets of the CMML bitstream contain the CMML clip
+ elements. Their "start" and "end" attributes however only exist for
+ authoring purposes and are not copied into the bitstream, but are
+ rather represented through the time mapping of the encapsulation
+ format that interleaves CMML data with data from other time-
+ continuous bitstreams. This avoids contradictory doubly represented
+ timing information. Generally the time mapping is done through some
+ timestamp representation and through the position in the stream.
+
+ A "clip" tag is encoded with all tags (except for the "start" and
+ "end" attributes) as a string printed into a clip packet. The "clip"
+ tag's "start" attribute tells the encapsulator at what time to insert
+ the clip packet into the bitstream. If an "end" attribute is
+ present, it leads to the creation of another clip packet, unless
+ another clip packet starts on the same track beforehand. This clip
+ packet contains an empty "clip" tag, i.e. a "clip" tag without
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 27]
+
+Internet-Draft CMML March 2005
+
+
+ "meta", "a", "img" or "desc" elements and no attribute values except
+ for a copy of the "track" attribute from the original "clip" tag.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <clip ... | 0-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | </clip> |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 28]
+
+Internet-Draft CMML March 2005
+
+
+8. Mapping CMML into Ogg and Annodex
+
+8.1. Media mapping for a CMML logical bitstream inside Ogg
+
+ When mapping a CMML logical bitstream into Ogg, the serialisation as
+ described in the previous section is used as a logical bitstream.
+ The ident packet is extended by a few fields that are necessary for
+ handling the time stamping of the content packets (i.e. the clips)
+ for Ogg. Here is its 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'CMML\0\0\0\0' | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version major | Version minor | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate numerator | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate denominator | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granuleshift | 28
+ +-+-+-+-+-+-+-+-+
+
+
+ Fields with more than one byte length are encoded LSB (least
+ significant byte) first.
+
+ The additional fields in an CMML ident header packet for Ogg have the
+ following meaning:
+
+ 1. Granule rate numerator & denominater: 8 Byte integer number each.
+ They represent the temporal resolution of the logical bitstream
+ in Hz given as a rational number in the same way as the fishead
+ basetime field above.
+
+ 2. Granuleshift: a 1 Byte integer number describing whether to
+ partition the granule_position into two for the CMML 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
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 29]
+
+Internet-Draft CMML March 2005
+
+
+ of the granule position of a previous CMML data packet (i.e.
+ "clip" element), which helps to identify how much backwards
+ seeking is necessary to get to the last and still active "clip"
+ element (of the given track). The granuleshift is therefore the
+ log of the maximum possible clip spacing.
+
+ The default granule rate for CMML is: 1/1000. The default granule
+ shift used is 32, which halves the granule position to allow for the
+ backwards pointer.
+
+ The media mapping for CMML into Ogg is as follows:
+
+ o The bos page MUST contain the extended CMML ident packet.
+
+ o The first secondary header packet of CMML contains the xml
+ preamble as described above.
+
+ o The second secondary header packet contains the CMML "head" tag as
+ described above.
+
+ o The content or data packets for CMML contain the CMML "clip" tags
+ each encoded in their own packet and inserted at the accurate
+ time.
+
+ o The eos page contains a packet with an empty clip tag.
+
+ If CMML is encapsulated in Ogg without the skeleton bitstream, it
+ potentially loses time information. The basetime will then be mapped
+ always to 0 and utc time mappings cannot be represented. It also
+ loses all the message header fields which contain machine-readable
+ meta information about the physical bitstream.
+
+8.2. Using CMML to author Annodex bitstreams
+
+ As CMML contains authoring information for Annodex bitstreams, a CMML
+ instance document contains more than just the annotation information
+ necessary for the CMML logical bitstream. It also contains control
+ information to create the control section of an Annodex bitstream,
+ i.e. the skeleton bitstream with its secondary header packets
+ describing each of the contained logical bitstreams. Note that we
+ only describe the creation of Annodex Version 3.0 bitstreams here.
+
+ The authoring information stems in particular from the "stream" tag
+ plus some specific information from the "cmml" tag. Generally, the
+ "stream" tag's attributes contribute to the skeleton fishead packet,
+ the "import" tag's attributes to the skeleton fisbone packets of each
+ logical bitstream, and the "cmml" tag's attributes to the fisbone of
+ the CMML logical bitstream. While the "cmml" tag is represented in
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 30]
+
+Internet-Draft CMML March 2005
+
+
+ full as a processing instruction in the secondary header packets of
+ the CMML logical bitstream (see above), this is not the case for the
+ "stream" tag. Therefore, this section also contains a description of
+ what tags of the "stream" tag are not used inside an Annodex
+ bitstream.
+
+8.2.1. Creating the skeleton ident packet
+
+ The skeleton ident packet receives the "basetime" and the "utc" field
+ information from the "stream" tag.
+
+ "Basetime numerator & denominator": if the "basetime" attribute is
+ given in a CMML instance document, it MUST be represented in the
+ skeleton ident header in the fields "Basetime numerator" and
+ "Basetime denominator". It is converted from a possible NPT or SMPTE
+ representation to a rational number to be stored in these fishead
+ fields.
+
+ "Presentationtime numerator & denominator": to be filled by the muxer
+ appropriately, e.g. reusing the basetime values.
+
+ "UTC": if the "utc" attribute is given in a CMML instance document,
+ it MUST be represented in the skeleton ident header in the "UTC"
+ field.
+
+8.2.2. Creating the skeleton fisbone packets
+
+ A fisbone packet for a logical bitstream is created through the
+ authoring information of an "import" tag in a CMML instance
+ document's "stream" tag. One "import" tag contains information on
+ one particular logical bitstream in the interleaved bitstream and
+ thus creates one particular skeleton fisbone packet.
+
+ "Granulerate numerator & denominator": if the "granulerate" attribute
+ is present in the "import" tag, it MUST be represented in the fisbone
+ header for the respective media bitstream in the fields "Granulerate
+ numerator" and "Granulerate denominator". The encoder MUST however
+ ascertain that the values are sensible, and if it knows the accurate
+ granule rate for a logical bitstream overrun the user input with the
+ one that was used during creation of the interleaved bitstream.
+
+ "Content-type" message header field: this attribute MUST be
+ represented in the respective skeleton fisbone packet as a message
+ header field with name "Content-type", as it signifies the MIME type
+ of the media bitstream, providing for a decoding hint. If the user
+ does not specify the "contenttype" attribute, the encoder MUST
+ provide it during the interleaving process.
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 31]
+
+Internet-Draft CMML March 2005
+
+
+ "ID" message header field: if an "id" attribute is specified for an
+ "import" tag, it SHOULD be represented in the skeleton fisbone header
+ for the respecitve media bitstream as a message header field with
+ name "ID", as it signifies a short identifying machine-readable
+ string for the import media bitstream.
+
+ User specified message header fields: if "name" and "value"
+ attributes are specified in the "param" tags of the "import" tag,
+ these SHOULD be represented in the skeleton fisbone packet of the
+ respective media bitstream as a message header field with the given
+ name-value pair. These fields are highly dependent on the type of
+ media bitstream handled and it therefore depends on the encoding tool
+ to make a selection of the parameters acquired. For example, an
+ audio bitstream that contains speech in a specific language may be
+ identified during CMML authoring through a param element with
+ "Content-Language" name, and acquired into the media bitstream
+ message header field of the same name.
+
+8.2.3. The CMML fisbone packet fields
+
+ A CMML instance document that specifies annotations in "head" and
+ "clip" elements does not get to use the "stream" tag to provide
+ encoding hints for its CMML logical bitstream. Its encoding hints
+ come from the "cmml" tag and the "encoding" attribute of the xml
+ processing directive.
+
+ "Number of header packets": this field has a fixed size of 3 for the
+ CMML specification given in this document. It counts the CMML ident
+ packet, the XML preamble packet and the head tag packet.
+
+ "Granulerate numerator & denominator": if the "granulerate" attribute
+ is present in the "cmml" tag, it MUST be represented in the fisbone
+ header in the fields "Granulerate numerator" and "Granulerate
+ denominator". The encoder MUST however ascertain that the values are
+ sensible. The value defaults to "1/1000" if it is not specified by
+ the user.
+
+ "Content-type" message header field: the content type for the fisbone
+ packet that describes the CMML logical bitstream is fixed at "text/
+ x-cmml" (or "text/cmml" after IANA registration of the MIME type.
+
+ "charset": if the xml processing directive contains an "encoding"
+ attribute, this MUST be represented in the CMML fisbone packet as an
+ addendum to the message header field "Content-type" as a charset.
+ For example: "Content-type: text/x-cmml; charset=UTF-8".
+
+ "ID" message header field: if an "id" attribute is specified for the
+ "cmml" tag, it SHOULD be represented in the skeleton fisbone header
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 32]
+
+Internet-Draft CMML March 2005
+
+
+ for CMML as a message header field with name "ID", as it signifies a
+ short identifying machine-readable string for the import media
+ bitstream.
+
+ "Content-Language" and "Content-Dir" message header fields: if the
+ "lang" and "dir" attributes are given in a "cmml" tag, they MUST be
+ represented in the fishbone packet of the CMML bitstream as message
+ header fields with name "Content-Language" and "Content-Dir".
+
+8.2.4. Usage of the 'stream' tag
+
+ Here is a list of the attribute values of the "stream" tag and how
+ they are being used:
+
+ o id: not used, as this attribute is only used to enable addressing
+ of the stream tag the XML way (e.g. XPath). It is not relevant
+ for the encoded bitstream and will therefore be lost on encoding.
+
+ o basetime: this attribute maps to the skeleton ident header fields
+ "Basetime numerator" and "Basetime denominator".
+
+ o utc: this attribute maps to the skeleton ident header field "UTC".
+
+ Here is a list of the attribute values of the "import" tag and how
+ they are being used:
+
+ o id: this attribute may be represented as a message header field in
+ the respective skeleton fisbone packet.
+
+ o lang, dir: not used, as these attributes signify the language and
+ directionality of the human readable texts in the stream tag which
+ are not acquired into the Annodex bitstream.
+
+ o granulerate: this attribute is used in the skeleton fisbone header
+ fields "Granule rate numerator" and "Granule rate denominator" as
+ well as for the "Presentationtime numerator" and "Presentationtime
+ denominator".
+
+ o contenttype: this attribute is represented in the respective
+ skeleton fisbone packet as a message header field with name
+ "Content-type".
+
+ o src: not used, as this attribute only points to the location of
+ the import media bitstream and is thus pure authoring information.
+
+ o start, end: not used, as this attribute only specifies the segment
+ of the import media bitstream that is to be used during authoring.
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 33]
+
+Internet-Draft CMML March 2005
+
+
+ o title: not used, as this attribute provides a human readable
+ comment on the import bitstream for authoring purposes.
+
+ Here is a list of the attribute values of the "param" tag list and
+ how they are being used:
+
+ o id: not used, as this attribute is only used to enable addressing
+ of the param tag the XML way (e.g. XPath). It is not relevant
+ for the encoded bitstream and will therefore be lost on encoding.
+
+ o name, value: these attributes may be represented in the skeleton
+ fisbone packet of the respective media bitstream as a message
+ header field with the given name-value pair.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 34]
+
+Internet-Draft CMML March 2005
+
+
+9. Extracting CMML from Annodex bitstreams
+
+ The decoding of an Annodex bitstream to CMML is roughly inverse to
+ the encoding of an Annodex bitstream from a CMML file. There are
+ some special cases to take care of, therefore the decoding steps are
+ outlined here.
+
+9.1. Extracting the preamble, 'head' and 'clip' tags
+
+ The data encoded in the CMML logical bitstream conists of the xml
+ preamble, the "cmml" tag, the "head" tag, and the "clip" tags. These
+ are fairly straightforward to extract.
+
+ xml preamble and "cmml" tag: The xml preamble is constructed from the
+ second header packet of the CMML logical bitstream. It contains the
+ full xml preamble. It also contains the "cmml" processing
+ instruction, which MUST be transformed back to a normal element and
+ an end "cmml" tag be added at the end of the created CMML document.
+
+ "head" tag: The "head" tag is constructed from the third header
+ packet of the CMML logical bitstream, which contains the complete
+ content of the "head" element.
+
+ "clip" tags: The "clip" tags are constructed from the content of the
+ CMML logical bitstream. Each packet contains a "clip" tag with all
+ of the information except for the timing information. A decoder MUST
+ take care to add the start time of each "clip" element into the
+ "start" attribute of the respective CMML "clip" tag. The start time
+ will be calculated from the granulerate in the CMML fisbone packet
+ and the granulepos given in the respective "clip" Ogg packet. Empty
+ "clip" tags should also be converted to end time attributes of the
+ previous "clip" tag on the same track.
+
+9.2. Creating a 'stream' tag
+
+ The creation of a "stream" tag is not necessary to extract the
+ content of the CMML logical bitstream and thus a textual
+ representation of the interleaved bitstream. However, if the Annodex
+ bitstream has a non-zero "timebase" or a non-null "utc" time in the
+ skeleton ident header, a "stream" tag will allow accurate time
+ information in the CMML file and SHOULD be created with these
+ attribute values.
+
+ If a "stream" tag is created with the "basetime" and "utc"
+ attributes, it is empty by default. A ripping application MAY
+ however extract all the data bitstreams out of the Annodex bitstream
+ into files, and then reference these files in the "src" attribute of
+ "import" tags.
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 35]
+
+Internet-Draft CMML March 2005
+
+
+ Other attributes of the "import" tags MAY also be filled from the
+ logical bitstreams:
+
+ o the "contenttype" attribute from the "Content-type" Message header
+ field of the respective skeleton secondary header packet,
+
+ o the "granulerate" attribute from the Granulerate fields of the
+ respective skeleton secondary header packet,
+
+ o the "id" attribute from a Message header field called "ID" if
+ available,
+
+ o and "param" elements from all the remaining Message header fields
+ of the respective skeleton secondary header packet, where the
+ field name is stored in the "name" attribute and the value in the
+ "value" attribute.
+
+ A stream tag will thus roughly be created like this:
+
+<stream basetime="[Basetime]" utc="[UTC]">
+ <import id="[ID message header value]"
+ granulerate="[Granulerate numerator]/[Granulerate denominator]"
+ contenttype="[Content-type message header value]"
+ src="[stream1.ogg]"
+ start="[t]">
+ <param name="[message header name]" value="[message header value]"/>
+ </import>
+</stream>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 36]
+
+Internet-Draft CMML March 2005
+
+
+10. MIME media type registration for 'text/cmml'
+
+ This section contains the registration information for the 'text/
+ cmml' media type. While this media type is not approved by the IANA,
+ 'text/x-cmml' may be used to identify CMML instance documents.
+
+ To: ietf-types at iana.org
+
+ Subject: Registration of MIME media type 'text/cmml'
+
+ MIME media type name: text
+
+ MIME subtype name: cmml
+
+ Required parameters: none
+
+ Optional parameters: charset (as in the text/xml media type [text/
+ xml]).
+
+ Encoding Considerations: as appropriate for the charset and the
+ transport mechanism (see text/xml media type [text/xml]).
+
+ Security considerations: see next section.
+
+ Interoperability considerations: CMML is a free specification that is
+ independent of any media encoding format. It is designed to provide
+ interoperability with existing XML tools and systems. Its
+ specification is not patented and can be implemented by third parties
+ without patent considerations.
+
+ Additional information:
+
+ Magic numbers: none. However, CMML files start with the XML
+ preamble as any XML document [text/xml] and will also have the
+ string '<cmml' near the beginning of the file.
+
+ File extension: .cmml
+
+ Macintosh File Type Code: "TEXT"
+
+ Intended usage: COMMON
+
+10.1. URI addressing into CMML files
+
+ There are two ways of hyperlinking via URIs into CMML files: via
+ specification of a temporal interval or via specification of a clip.
+ Both of these ways of addressing are supported for URI queries and
+ URI fragments on CMML files. A server that is capable of supporting
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 37]
+
+Internet-Draft CMML March 2005
+
+
+ these URI queries indicates this by adding the X-Accept-TimeURI
+ header field to its response header fields as defined in the temporal
+ URI query specification [timedURI]. Specifications of a clip in a
+ URI query via the clip's name are regarded as an alias for a time
+ offset. Therefore, a server that supports CMML temporal URI
+ addressing MUST also support the named addressing.
+
+10.1.1. Query parameters for use with the http protocol server-side
+
+ For the purposes of URI queries on CMML files, it is assumed that the
+ query string takes the format of a CGI query string. The Common
+ Gateway Interface, or CGI, is a convention for external gateway
+ programs to interface with information servers such as HTTP servers
+ (see http://hoohoo.ncsa.uiuc.edu/cgi/). This query string is
+ expected to be interpreted by the HTTP server to return a valid CMML
+ file that differs from the original CMML file only by reducing the
+ set of clip tags to the specified interval.
+
+ Temporal query parameter specification:
+
+ Addressing of temporal intervals of CMML files is possible through
+ specification of temporal query intervals in URIs [timedURI]. An
+ example is the following URI:
+ http://example.com/sample.cmml?t="npt:4" , which in the case of CMML
+ relates to the last clip whose start time is just before the given
+ temporal offset and all the clips thereafter.
+
+ Clip specification:
+
+ Addressing of a clip is possible through specification of the clip's
+ id attribute value. The BNF for such an id URI query parameter is:
+
+ id-parameter = "id" "=" id-interval ["," id-interval]
+
+ id-interval = id-name [ "/" [ id-name] ]
+
+ id-name = *( unreserved / pct-encoded / ":" / "?" / "#" /
+ "[" / "]" / "@" / "!" / "$" / "&" / "'" /
+ "(" / ")" / "*" / "+" / ";" / "=" )
+
+
+ All id-name specifications map onto a start and end time. Specifying
+ just an id-name maps to just the start and end times of that clip.
+ Specifying an id-name with a "/" maps to the document starting from
+ the beginning of that clip until the end of the file or stream.
+ Specifying an id range is inclusive and maps to the start time of the
+ first clip and end time of the second clip. Overlapping time
+ intervals MUST be interpreted by merging the intervals into one.
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 38]
+
+Internet-Draft CMML March 2005
+
+
+ It is not valid to give several temporal URI query parameters in one
+ URI query. They all need to be wrapped into a single specification.
+
+ Examples for URIs containing id queries are:
+
+ o http://example.com/sample.cmml?id="dolphin" --- sample.cmml is
+ transferred from the start time of the "dolphin" clip to the end
+ of the file/stream.
+
+ o http://example.com/sample.cmml?id="dolphin/" --- sample.cmml is
+ transferred from the start time of the "dolphin" clip to the end
+ of the file or stream.
+
+ o http://example.com/sample.cmml?id="dolphin/goldfish" ---
+ sample.cmml is transferred from the start time of the "dolphin"
+ clip to the end of the "goldfish" clip.
+
+ Note that id attribute values of all elements have to be unique
+ throughout a XML file (and thus also throughout a CMML file).
+
+10.1.2. Fragment identifiers for use with the http protocol client-side
+
+ For the purposes of URI fragment specifications on CMML files, it is
+ assumed that the fragment gets interpreted by the HTTP client after
+ the retrieval action. The HTTP client is expected to restrict the
+ usage of the resource to the specified interval.
+
+ Temporal fragment specification:
+
+ Addressing of temporal intervals of CMML files is possible through
+ specification of temporal fragments in URIs [timedURI]. An example
+ is the following URI: http://example.com/sample.cmml#t=npt:4 . This
+ then relates to the last clip whose start time is just before the
+ given temporal offset and all the clips thereafter. This may e.g. be
+ useful to do a zoom into a retrieved CMML resource.
+
+ Clip specification:
+
+ The values of the id attribute of the clip tags can be used for
+ addressing media clips directly through fragment identifiers as in
+ http://example.com/sample.cmml#dolphin.
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 39]
+
+Internet-Draft CMML March 2005
+
+
+11. Security considerations
+
+ As CMML is a markup language created by using XML, the same security
+ considerations that apply to XML [text/xml], apply to CMML.
+
+ As the CMML is an authoring language for Annodex bitstreams, there is
+ no executable code attached to this language. The implementation of
+ a multiplexer to actually create an Annodex bitstream must be careful
+ when handling input bitstreams, which are binary data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 40]
+
+Internet-Draft CMML March 2005
+
+
+12. ChangeLog
+
+ draft-pfeiffer-cmml-01:
+
+ o CMML version 2.0: changes to the tags to make CMML more similar to
+ XHTML, in particular from "media" to "import", the introduction of
+ an "img" tag, and the the change from an "a" tag that covers all
+ the other elements to a "clip" tag, reducing the "a" tag back to
+ its HTML meaning.
+
+ draft-pfeiffer-cmml-02:
+
+ o CMML was not changed - only the media mapping into Annodex was
+ adapted because the binary format had changed substantially.
+
+ draft-pfeiffer-cmml-03:
+
+ o added the link tag to the head, which has recognized link types of
+ html plus "edit".
+
+ o added granulerate to the cmml root tag and changed the muxing
+ description for CMML tracks.
+
+ o added title tags for each element.
+
+ o replaced timebase with basetime as a better name.
+
+ o kept the basetime attribute of the stream tag for backwards
+ compatibility.
+
+ draft-pfeiffer-cmml-04:
+
+ o CMML version 3.0: extending the CMML with tags that allow
+ stylesheet specifications for the presentation of the CMML tags,
+ adds the link tag, the title and class attributes, and renames
+ "timebase" to "basetime" as that is the more accurate term used in
+ the industry.
+
+ draft-pfeiffer-cmml-05:
+
+ o CMML version 3.1: extending the CMML with a caption and p tags
+ that allow the creation of tags, captions, subtitles and similar.
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 41]
+
+Internet-Draft CMML March 2005
+
+
+13. References
+
+ [ANX] Pfeiffer, S., Parker, C., and A. Pang, "The Annodex
+ exchange format for time-continuous data files, Version
+ 3.0 (work in progress)",
+ I-D draft-pfeiffer-annodex-02.txt, March 2005,
+ <http://www.annodex.net/TR/annodex.txt>.
+
+ [CSS] Lie, H. and B. Bos, "Cascading Style Sheets, level 1",
+ W3C CSS, January 1999, <http://www.w3.org/TR/REC-CSS1/>.
+
+ [CSS2] Bos, B., Lie, H., Lilley, C., and I. Jacobs, "Cascading
+ Style Sheets, level 2", W3C CSS, May 1998,
+ <http://www.w3.org/TR/REC-CSS2/>.
+
+ [ContentType]
+ Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996,
+ <http://www.ietf.org/rfc/rfc2045.txt>.
+
+ [DFXP] Adams, G., "Timed Text (TT) Authoring Format 1.0 -
+ Distribution Format Exchange Profile (DFXP)", W3C DFXP,
+ November 2006, <http://www.w3.org/TR/ttaf1-dfxp/>.
+
+ [HTML] World Wide Web Consortium, "HTML 4.01 Specification",
+ W3C HTML, December 1999, <http://www.w3.org/TR/html4/>.
+
+ [ISO8601] ISO, TC154., "Data elements and interchange formats --
+ Information interchange -- Representation of dates and
+ times", ISO 8601, 2000.
+
+ [KEYWORDS]
+ Bradner, S., "Key words for use in RFCs to Indicate
+ Requirements Levels", RFC 2119, BCP 14, March 1997.
+
+ [LANG] Alvestrand, H., "Tags for the Identification of
+ Languages", RFC 1766, March 1995,
+ <http://www.ietf.org/rfc/rfc1766.txt>.
+
+ [RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+ Streaming Protocol (RTSP)", RFC 2326, April 1998,
+ <Http://www.ietf.org/rfc/rfc2326.txt>.
+
+ [SMPTE] The Society of Motion Picture and Television Engineers,
+ "SMPTE STANDARD for Television, Audio and Film - Time and
+ Control Code", ANSI 12M-1999, September 1999.
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 42]
+
+Internet-Draft CMML March 2005
+
+
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 3986,
+ January 2005, <http://www.ietf.org/rfc/rfc3986.txt>.
+
+ [XHTML] World Wide Web Consortium, "XHTML(TM) 1.0 The Extensible
+ Hyper Text Markup Language", W3C XHTML, January 2000,
+ <http://www.w3.org/TR/xhtml1/>.
+
+ [XML] World Wide Web Consortium, "Extensible Markup Language
+ (XML) 1.0", W3C XML, October 2000,
+ <http://www.w3.org/TR/2000/REC-xml-20001006>.
+
+ [text/xml]
+ Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
+ July 1998, <http://www.ietf.org/rfc/rfc2376.txt>.
+
+ [timedURI]
+ Pfeiffer, S., Parker, C., and A. Pang, "Specifying time
+ intervals in URI queries and fragments of time-based Web
+ resources (work in progress)",
+ I-D draft-pfeiffer-temporal-fragments-03.txt, March 2005,
+ <http://www.annodex.net/TR/URI_fragments.txt>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 43]
+
+Internet-Draft CMML March 2005
+
+
+Appendix A. CMML DTD
+
+ INCLUDE DTD HERE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 44]
+
+Internet-Draft CMML March 2005
+
+
+Appendix B. An example CMML document
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<!DOCTYPE cmml SYSTEM "cmml.dtd">
+
+<cmml lang="en">
+
+<stream basetime="0">
+ <import contenttype="video/mpeg" src="fish.mpg" start="0"/>
+</stream>
+
+<head>
+ <title>Types of fish</title>
+ <meta name="Producer" content="Joe Ordinary"/>
+ <meta name="DC.Author" content="Joe's friend"/>
+</head>
+
+<clip id="intro" start="0">
+ <a href="http://example.com/fish.html">Read more about fish</a>
+ <desc>This is the introduction to the film Joe made about fish.</desc>
+ <caption>
+ <p id="subtitle1" start="0" end="1" style="text-align: left;">
+ This is a left aligned subtitle.
+ </p>
+ <p id="subtitle2" start="1" end="2" style="text-align: right;">
+ This is a right aligned subtitle.
+ </p>
+ </caption>
+</clip>
+
+<clip id="dolphin" start="npt:3.5" end="npt:0:05:05.9">
+ <img src="dolphin.jpg"/>
+ <desc>Here, Joe caught sight of a dolphin in the ocean.</desc>
+ <meta name="Subject" content="dolphin"/>
+ <caption>
+ <p id="subtitle3">
+ This is a <span style="fontWeight: bold;">lengthy</span><br/>
+ subtitle that is split over two lines.
+ </p>
+ </caption>
+</clip>
+
+<clip id="goldfish" start="npt:0:05:05.9">
+ <a href="http://example.com/morefish.anx?id=goldfish">More video clips on goldfish.</a>
+ <img src="http://example.com/goldfish.jpg"/>
+ <desc>Joe has a fishtank at home with many colourful fish. The common goldfish is one of them and Joe's favourite. Here are some fabulous pictures he has taken of them.</desc>
+ <meta name="Location" content="Joe's fishtank"/>
+ <meta name="Subject" content="goldfish"/>
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 45]
+
+Internet-Draft CMML March 2005
+
+
+</clip>
+
+</cmml>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 46]
+
+Internet-Draft CMML March 2005
+
+
+Appendix C. Definitions of terms and abbreviations
+
+ Mark-up: XML tags and their content used to describe a document.
+
+ Annotating: The task of authoring mark-up for a document thus
+ creating a Web resources.
+
+ Hyperlinking: The task of linking from one Web resource to another.
+ When a link contains a fragment offset into a resource, this is
+ called "deep hyperlinking".
+
+ Clip: A section of a time-continuous document covering some temporal
+ interval.
+
+ Indexing: The task of identifying index points or clips for time-
+ continuous documents.
+
+ Annotation track: A set of clips representing semantically
+ correlated annotations of a time-continuous resource.
+
+ Annodex bitstream: A specific file format for storing annotation,
+ hyperlinking, and indexing information in annotation tracks and
+ multiplexed together with the time-continuous documents they
+ describe.
+
+ Bitstream: A sequence of data containing samples of a time-continous
+ document.
+
+ Time-continuous document: A file containing time-sampled data in a
+ temporally sequential manner.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 47]
+
+Internet-Draft CMML March 2005
+
+
+Appendix D. Glossary of acronyms
+
+ Annodex: Annotated and indexed bitstream format.
+
+ CMML: Continuous Media Markup Language.
+
+ CSS: Cascading Style Sheets.
+
+ DTD: Document Type Declaration.
+
+ XML: eXtensible Markup Language.
+
+ Web: World Wide Web.
+
+ URI: Unified Resource Identifier.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 48]
+
+Internet-Draft CMML March 2005
+
+
+Appendix E. Acknowledgements
+
+ The authors greatly acknowledge the contributions of Zentaro
+ Kavanagh, Andrew Nesbit and Simon Lai in developing this
+ specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 49]
+
+Internet-Draft CMML March 2005
+
+
+Authors' Addresses
+
+ Silvia Pfeiffer
+ Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
+ PO Box 76
+ Epping, NSW 1710
+ Australia
+
+ Phone: +61 2 9372 4180
+ Email: Silvia.Pfeiffer at csiro.au
+ URI: http://www.ict.csiro.au/
+
+
+ Conrad D. Parker
+ Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
+ PO Box 76
+ Epping, NSW 1710
+ Australia
+
+ Phone: +61 2 9372 4222
+ Email: Conrad.Parker at csiro.au
+ URI: http://www.ict.csiro.au/
+
+
+ Andre T. Pang
+ Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
+ PO Box 76
+ Epping, NSW 1710
+ Australia
+
+ Phone: +61 2 9372 4222
+ Email: Andre.Pang at csiro.au
+ URI: http://www.ict.csiro.au/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 50]
+
+Internet-Draft CMML March 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 51]
+
+
+ o http://example.com/sample.cmml?id="dolphin" --- sample.cmml is
+ transferred from the start time of the "dolphin" clip to the end
+ of the file/stream.
+
+ o http://example.com/sample.cmml?id="dolphin/" --- sample.cmml is
+ transferred from the start time of the "dolphin" clip to the end
+ of the file or stream.
+
+ o http://example.com/sample.cmml?id="dolphin/goldfish" ---
+ sample.cmml is transferred from the start time of the "dolphin"
+ clip to the end of the "goldfish" clip.
+
+ Note that id attribute values of all elements have to be unique
+ throughout a XML file (and thus also throughout a CMML file).
+
+10.1.2. Fragment identifiers for use with the http protocol client-side
+
+ For the purposes of URI fragment specifications on CMML files, it is
+ assumed that the fragment gets interpreted by the HTTP client after
+ the retrieval action. The HTTP client is expected to restrict the
+ usage of the resource to the specified interval.
+
+ Temporal fragment specification:
+
+ Addressing of temporal intervals of CMML files is possible through
+ specification of temporal fragments in URIs [timedURI]. An example
+ is the following URI: http://example.com/sample.cmml#t=npt:4 . This
+ then relates to the last clip whose start time is just before the
+ given temporal offset and all the clips thereafter. This may e.g. be
+ useful to do a zoom into a retrieved CMML resource.
+
+ Clip specification:
+
+ The values of the id attribute of the clip tags can be used for
+ addressing media clips directly through fragment identifiers as in
+ http://example.com/sample.cmml#dolphin.
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 39]
+
+Internet-Draft CMML March 2005
+
+
+11. Security considerations
+
+ As CMML is a markup language created by using XML, the same security
+ considerations that apply to XML [text/xml], apply to CMML.
+
+ As the CMML is an authoring language for Annodex bitstreams, there is
+ no executable code attached to this language. The implementation of
+ a multiplexer to actually create an Annodex bitstream must be careful
+ when handling input bitstreams, which are binary data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 40]
+
+Internet-Draft CMML March 2005
+
+
+12. ChangeLog
+
+ draft-pfeiffer-cmml-01:
+
+ o CMML version 2.0: changes to the tags to make CMML more similar to
+ XHTML, in particular from "media" to "import", the introduction of
+ an "img" tag, and the the change from an "a" tag that covers all
+ the other elements to a "clip" tag, reducing the "a" tag back to
+ its HTML meaning.
+
+ draft-pfeiffer-cmml-02:
+
+ o CMML was not changed - only the media mapping into Annodex was
+ adapted because the binary format had changed substantially.
+
+ draft-pfeiffer-cmml-03:
+
+ o added the link tag to the head, which has recognized link types of
+ html plus "edit".
+
+ o added granulerate to the cmml root tag and changed the muxing
+ description for CMML tracks.
+
+ o added title tags for each element.
+
+ o replaced timebase with basetime as a better name.
+
+ o kept the basetime attribute of the stream tag for backwards
+ compatibility.
+
+ draft-pfeiffer-cmml-04:
+
+ o CMML version 3.0: extending the CMML with tags that allow
+ stylesheet specifications for the presentation of the CMML tags,
+ adds the link tag, the title and class attributes, and renames
+ "timebase" to "basetime" as that is the more accurate term used in
+ the industry.
+
+ draft-pfeiffer-cmml-05:
+
+ o CMML version 3.1: extending the CMML with a caption and p tags
+ that allow the creation of tags, captions, subtitles and similar.
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 41]
+
+Internet-Draft CMML March 2005
+
+
+13. References
+
+ [ANX] Pfeiffer, S., Parker, C., and A. Pang, "The Annodex
+ exchange format for time-continuous data files, Version
+ 3.0 (work in progress)",
+ I-D draft-pfeiffer-annodex-02.txt, March 2005,
+ <http://www.annodex.net/TR/annodex.txt>.
+
+ [CSS] Lie, H. and B. Bos, "Cascading Style Sheets, level 1",
+ W3C CSS, January 1999, <http://www.w3.org/TR/REC-CSS1/>.
+
+ [CSS2] Bos, B., Lie, H., Lilley, C., and I. Jacobs, "Cascading
+ Style Sheets, level 2", W3C CSS, May 1998,
+ <http://www.w3.org/TR/REC-CSS2/>.
+
+ [ContentType]
+ Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996,
+ <http://www.ietf.org/rfc/rfc2045.txt>.
+
+ [DFXP] Adams, G., "Timed Text (TT) Authoring Format 1.0 -
+ Distribution Format Exchange Profile (DFXP)", W3C DFXP,
+ November 2006, <http://www.w3.org/TR/ttaf1-dfxp/>.
+
+ [HTML] World Wide Web Consortium, "HTML 4.01 Specification",
+ W3C HTML, December 1999, <http://www.w3.org/TR/html4/>.
+
+ [ISO8601] ISO, TC154., "Data elements and interchange formats --
+ Information interchange -- Representation of dates and
+ times", ISO 8601, 2000.
+
+ [KEYWORDS]
+ Bradner, S., "Key words for use in RFCs to Indicate
+ Requirements Levels", RFC 2119, BCP 14, March 1997.
+
+ [LANG] Alvestrand, H., "Tags for the Identification of
+ Languages", RFC 1766, March 1995,
+ <http://www.ietf.org/rfc/rfc1766.txt>.
+
+ [RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+ Streaming Protocol (RTSP)", RFC 2326, April 1998,
+ <Http://www.ietf.org/rfc/rfc2326.txt>.
+
+ [SMPTE] The Society of Motion Picture and Television Engineers,
+ "SMPTE STANDARD for Television, Audio and Film - Time and
+ Control Code", ANSI 12M-1999, September 1999.
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 42]
+
+Internet-Draft CMML March 2005
+
+
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 3986,
+ January 2005, <http://www.ietf.org/rfc/rfc3986.txt>.
+
+ [XHTML] World Wide Web Consortium, "XHTML(TM) 1.0 The Extensible
+ Hyper Text Markup Language", W3C XHTML, January 2000,
+ <http://www.w3.org/TR/xhtml1/>.
+
+ [XML] World Wide Web Consortium, "Extensible Markup Language
+ (XML) 1.0", W3C XML, October 2000,
+ <http://www.w3.org/TR/2000/REC-xml-20001006>.
+
+ [text/xml]
+ Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
+ July 1998, <http://www.ietf.org/rfc/rfc2376.txt>.
+
+ [timedURI]
+ Pfeiffer, S., Parker, C., and A. Pang, "Specifying time
+ intervals in URI queries and fragments of time-based Web
+ resources (work in progress)",
+ I-D draft-pfeiffer-temporal-fragments-03.txt, March 2005,
+ <http://www.annodex.net/TR/URI_fragments.txt>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 43]
+
+Internet-Draft CMML March 2005
+
+
+Appendix A. CMML DTD
+
+ INCLUDE DTD HERE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 44]
+
+Internet-Draft CMML March 2005
+
+
+Appendix B. An example CMML document
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<!DOCTYPE cmml SYSTEM "cmml.dtd">
+
+<cmml lang="en">
+
+<stream basetime="0">
+ <import contenttype="video/mpeg" src="fish.mpg" start="0"/>
+</stream>
+
+<head>
+ <title>Types of fish</title>
+ <meta name="Producer" content="Joe Ordinary"/>
+ <meta name="DC.Author" content="Joe's friend"/>
+</head>
+
+<clip id="intro" start="0">
+ <a href="http://example.com/fish.html">Read more about fish</a>
+ <desc>This is the introduction to the film Joe made about fish.</desc>
+ <caption>
+ <p id="subtitle1" start="0" end="1" style="text-align: left;">
+ This is a left aligned subtitle.
+ </p>
+ <p id="subtitle2" start="1" end="2" style="text-align: right;">
+ This is a right aligned subtitle.
+ </p>
+ </caption>
+</clip>
+
+<clip id="dolphin" start="npt:3.5" end="npt:0:05:05.9">
+ <img src="dolphin.jpg"/>
+ <desc>Here, Joe caught sight of a dolphin in the ocean.</desc>
+ <meta name="Subject" content="dolphin"/>
+ <caption>
+ <p id="subtitle3">
+ This is a <span style="fontWeight: bold;">lengthy</span><br/>
+ subtitle that is split over two lines.
+ </p>
+ </caption>
+</clip>
+
+<clip id="goldfish" start="npt:0:05:05.9">
+ <a href="http://example.com/morefish.anx?id=goldfish">More video clips on goldfish.</a>
+ <img src="http://example.com/goldfish.jpg"/>
+ <desc>Joe has a fishtank at home with many colourful fish. The common goldfish is one of them and Joe's favourite. Here are some fabulous pictures he has taken of them.</desc>
+ <meta name="Location" content="Joe's fishtank"/>
+ <meta name="Subject" content="goldfish"/>
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 45]
+
+Internet-Draft CMML March 2005
+
+
+</clip>
+
+</cmml>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 46]
+
+Internet-Draft CMML March 2005
+
+
+Appendix C. Definitions of terms and abbreviations
+
+ Mark-up: XML tags and their content used to describe a document.
+
+ Annotating: The task of authoring mark-up for a document thus
+ creating a Web resources.
+
+ Hyperlinking: The task of linking from one Web resource to another.
+ When a link contains a fragment offset into a resource, this is
+ called "deep hyperlinking".
+
+ Clip: A section of a time-continuous document covering some temporal
+ interval.
+
+ Indexing: The task of identifying index points or clips for time-
+ continuous documents.
+
+ Annotation track: A set of clips representing semantically
+ correlated annotations of a time-continuous resource.
+
+ Annodex bitstream: A specific file format for storing annotation,
+ hyperlinking, and indexing information in annotation tracks and
+ multiplexed together with the time-continuous documents they
+ describe.
+
+ Bitstream: A sequence of data containing samples of a time-continous
+ document.
+
+ Time-continuous document: A file containing time-sampled data in a
+ temporally sequential manner.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 47]
+
+Internet-Draft CMML March 2005
+
+
+Appendix D. Glossary of acronyms
+
+ Annodex: Annotated and indexed bitstream format.
+
+ CMML: Continuous Media Markup Language.
+
+ CSS: Cascading Style Sheets.
+
+ DTD: Document Type Declaration.
+
+ XML: eXtensible Markup Language.
+
+ Web: World Wide Web.
+
+ URI: Unified Resource Identifier.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 48]
+
+Internet-Draft CMML March 2005
+
+
+Appendix E. Acknowledgements
+
+ The authors greatly acknowledge the contributions of Zentaro
+ Kavanagh, Andrew Nesbit and Simon Lai in developing this
+ specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 49]
+
+Internet-Draft CMML March 2005
+
+
+Authors' Addresses
+
+ Silvia Pfeiffer
+ Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
+ PO Box 76
+ Epping, NSW 1710
+ Australia
+
+ Phone: +61 2 9372 4180
+ Email: Silvia.Pfeiffer at csiro.au
+ URI: http://www.ict.csiro.au/
+
+
+ Conrad D. Parker
+ Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
+ PO Box 76
+ Epping, NSW 1710
+ Australia
+
+ Phone: +61 2 9372 4222
+ Email: Conrad.Parker at csiro.au
+ URI: http://www.ict.csiro.au/
+
+
+ Andre T. Pang
+ Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
+ PO Box 76
+ Epping, NSW 1710
+ Australia
+
+ Phone: +61 2 9372 4222
+ Email: Andre.Pang at csiro.au
+ URI: http://www.ict.csiro.au/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 50]
+
+Internet-Draft CMML March 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Pfeiffer, et al. Expires September 2, 2005 [Page 51]
+
Added: standards/draft-pfeiffer-oggskeleton-current.txt
===================================================================
--- standards/draft-pfeiffer-oggskeleton-current.txt (rev 0)
+++ standards/draft-pfeiffer-oggskeleton-current.txt 2007-11-19 00:15:46 UTC (rev 3277)
@@ -0,0 +1,1343 @@
+
+Network Working Group S. Pfeiffer
+Internet-Draft C. Parker
+Intended status: Informational Annodex
+Expires: May 22, 2008 November 19, 2007
+
+
+ The "skeleton" meta information track for Ogg
+ draft-pfeiffer-oggskeleton-00
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ 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 22, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 1]
+
+Internet-Draft SKELETON November 2007
+
+
+Abstract
+
+ This specification defines "Skeleton", a logical bitstream for the
+ Ogg encapsulation format version 0 [Ogg]. 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.
+
+ Please note that this document assumes that the reader understands
+ the Ogg encapsulation format version 0 [Ogg]. The specification of
+ Skeleton is not encumbered by patents.
+
+ 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 [rfc2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 2]
+
+Internet-Draft SKELETON November 2007
+
+
+Table of Contents
+
+ 1. Features of Ogg and Skeleton . . . . . . . . . . . . . . . . . 4
+ 2. The Ogg skeleton logical bitstream . . . . . . . . . . . . . . 5
+ 2.1. The format of the skeleton ident header . . . . . . . . . 6
+ 2.2. The format of the skeleton secondary headers . . . . . . . 8
+ 2.3. Media mapping of skeleton into Ogg . . . . . . . . . . . . 11
+ 3. Handling time in an Ogg format bitstream . . . . . . . . . . . 13
+ 3.1. Conceptual overview . . . . . . . . . . . . . . . . . . . 13
+ 3.2. Mapping a granule position to a time position . . . . . . 15
+ 3.3. Seeking into the bitstream . . . . . . . . . . . . . . . . 17
+ 3.4. Remultiplexing an Ogg bitstream using Skeleton . . . . . . 19
+ 4. Security considerations . . . . . . . . . . . . . . . . . . . 20
+ 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+ Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 22
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
+ Intellectual Property and Copyright Statements . . . . . . . . . . 24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 3]
+
+Internet-Draft SKELETON November 2007
+
+
+1. Features of Ogg and Skeleton
+
+ 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.
+
+ 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.
+
+ Codec tracks generally contain the following information:
+
+ o setup information for a codec
+
+ o content data
+
+ 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.
+
+ An Ogg physical bitstream with a Skeleton track has the following
+ mandatory order of Ogg pages:
+
+ 1. skeleton bos page.
+
+ 2. bos pages of the other logical bitstreams.
+
+ 3. secondary header pages of all logical bitstreams, including
+ fisbone.
+
+ 4. skeleton eos page.
+
+ 5. data and eos pages of logical bitstreams, excluding skeleton,
+ multiplexed in a time-synchronous fashion.
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 4]
+
+Internet-Draft SKELETON November 2007
+
+
+2. The Ogg skeleton logical bitstream
+
+ The purpose of Ogg skeleton is to provide codec-specific knowledge
+ that allows parsing, demultiplexing and remultiplexing of Ogg
+ bitstreams without having to decode.
+
+ 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.
+
+ 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 Ogg RFC [Ogg] is presumed.
+ Please also refer to that document for descriptions of the terms used
+ in this document.
+
+ 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.
+
+ The skeleton logical bitstream provides the following functionality
+ on top of Ogg:
+
+ o 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.
+
+ o allows for extraction of a temporal interval of the Ogg physical
+ bitstream while retaining the original start time offset of that
+ interval.
+
+ o 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.
+
+ o allows for temporal offset operations into an Ogg physical
+ bitstream without a need to decode any data.
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 5]
+
+Internet-Draft SKELETON November 2007
+
+
+ o allows generally for handling of content without a need to decode
+ it, such as is necessary in a caching Web proxy.
+
+ o 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.
+
+2.1. The format of the skeleton ident header
+
+ The skeleton logical bitstream starts with an ident header containing
+ information for the complete Ogg physical bitstream. The ident
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 6]
+
+Internet-Draft SKELETON November 2007
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Fields with more than one Byte length are encoded LSB (least
+ significant Byte) first.
+
+ The fields in the skeleton ident header have the following meaning:
+
+ 1. Identifier: a 8 Byte field that identifies this bitstream as a
+ skeleton. It contains the magic numbers:
+
+ 0x66 'f'
+
+ 0x69 'i'
+
+ 0x73 's'
+
+ 0x68 'h'
+
+ 0x65 'e'
+
+ 0x61 'a'
+
+ 0x64 'd'
+
+ 0x00 '\0'
+
+ 2. Version major: 2 Byte unsigned integer signifying the major
+ version number of the skeleton bitstream. This document
+ specifies the major version 3.
+
+ 3. Version minor: 2 Byte unsigned integer signifying the minor
+ version number of the skeleton bitstream. This document
+ specifies the minor version 0.
+
+ 4. 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.
+
+ 5. Basetime numerator & denominator: 8 Byte signed integer each.
+ They represent together the basetime of the Ogg physical
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 7]
+
+Internet-Draft SKELETON November 2007
+
+
+ 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.
+
+ 6. UTC [ISO8601]: 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.
+
+ 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 [SMPTE]. 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.
+
+2.2. The format of the skeleton secondary headers
+
+ 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:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 8]
+
+Internet-Draft SKELETON November 2007
+
+
+ 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-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+ Fields with more than one Byte length are encoded LSB (least
+ significant Byte) first.
+
+ The fields in a skeleton secondary header packet have the following
+ meaning:
+
+ 1. Identifier: a 8 Byte field that identifies this packet as a
+ skeleton secondary header for identifying other logical
+ bitstreams. It contains the magic numbers:
+
+ 0x66 'f'
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 9]
+
+Internet-Draft SKELETON November 2007
+
+
+ 0x69 'i'
+
+ 0x73 's'
+
+ 0x62 'b'
+
+ 0x6f 'o'
+
+ 0x6e 'n'
+
+ 0x65 'e'
+
+ 0x00 '\0'
+
+ 2. 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.
+
+ 3. 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.
+
+ 4. 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.
+
+ 5. 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.
+
+ 6. 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.
+
+ 7. 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.
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 10]
+
+Internet-Draft SKELETON November 2007
+
+
+ 8. 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 signify a time-continuous granule
+ position for an independently decodable and presentable data
+ granule. The lower bits are generally used to specify the
+ relative offset of dependent packets, such as predicted frames
+ of a video. Hence these can be addressed, though not decoded
+ without tracing back to the last fully decodable data granule.
+ This is the case with Ogg Theora; the general procedure is given
+ in section 3.2.
+
+ 9. Padding/future use: 3 Bytes padding data that may be used for
+ future requirements and are mandated to zero in this revision.
+
+ 10. Message header fields: header fields, following the generic
+ Internet Message Format defined in RFC 2822 [Headers]. 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.
+
+ 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 Ogg bitstream, this field contains the MIME type and
+ the character encoding of the data in the logical bitstream. 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.
+
+ As per RFC 2277 [I18N], 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.
+
+ User defined optional message header fields MUST follow the naming
+ standard given in RFC2822.
+
+2.3. Media mapping of skeleton into Ogg
+
+ The media mapping for skeleton into Ogg is as follows:
+
+ o The skeleton ident (fishead) header is mapped into the skeleton
+ bos page.
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 11]
+
+Internet-Draft SKELETON November 2007
+
+
+ o 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.
+
+ o 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.
+
+ o The skeleton eos page MUST contain one packet of length zero.
+
+ 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:
+
+ 1. 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.
+
+ 2. The bos pages of the other logical bitstreams come next as is a
+ requirement of the Ogg bitstream format.
+
+ 3. 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.
+
+ 4. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 12]
+
+Internet-Draft SKELETON November 2007
+
+
+3. Handling time in an Ogg format bitstream
+
+ With time-continuous data inside Ogg, one needs to handle data at
+ four different levels:
+
+ o at the Bytes level, upon seeking.
+
+ o at the packets level, upon encapsulating.
+
+ o at the granules level, upon recomposing.
+
+ o at the time level, upon displaying and addressing.
+
+ This section explains how they all fit together.
+
+3.1. Conceptual overview
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 13]
+
+Internet-Draft SKELETON November 2007
+
+
+ t_url
+ |
+t_0 v t_n
+|------------------------------------------------------------------->|
+----------------------------------------------
+| | | | | | | | | | |//| | | | |
+----------------------------------------------
+audio bitstream 1
+ -------------------------------------------------------------
+ | | | |/////| | | | | | |
+ -------------------------------------------------------------
+ video bitstream 1
+ ----------------------------------------------------
+ | | | | |//| | | | | | | | | | | | |
+ ----------------------------------------------------
+ audio bitstream 2
+ -------------------------------
+ | |/////| | | |
+ -------------------------------
+ video bitstream 2
+
+ 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.
+
+ 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
+ [SMPTE] of 01:00:00:00, not 00:00:00:00 (see also the temporal URI
+ addressing [timedURI] 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.
+
+ Also associated with the basetime is a calendar date [ISO8601] 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.
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 14]
+
+Internet-Draft SKELETON November 2007
+
+
+3.2. Mapping a granule position to a time position
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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 finely-grained description of the
+ temporal position. The following image explains the composition of
+ the granule_position field in an Ogg page:
+
+ granule_position
+ ------------------------------------------------
+ | keyindex | keyoffset |
+ ------------------------------------------------
+
+ The granuleshift field of the skeleton secondary header packets
+ describes how many of the granule_position's 64 bits are being used
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 15]
+
+Internet-Draft SKELETON November 2007
+
+
+ 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.
+
+ The calculation of the temporal position of an Ogg page using
+ Skeleton is thus specified through the following formula:
+
+ t_page = basetime + ((keyindex + keyoffset) / granulerate)
+
+ 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.
+
+ 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:
+
+ t_page = 4 + ((88200 + 0) / 44100) = 6
+
+ 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.
+
+ 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:
+
+ t_page = 0 + ((62 + 5) / 25) = 2.68 sec
+
+ 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:
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 16]
+
+Internet-Draft SKELETON November 2007
+
+
+ o npt: 1000 (milliseconds)
+
+ o smpte-24: 24 (24 fps)
+
+ o smpte-24-drop: 24/1.001 = 23.976 (approx. as per SMPTE)
+
+ o smpte-25: 25
+
+ o smpte-30: 30
+
+ o smpte-30-drop: 30/1.001 = 29.970 (approx. as per SMPTE)
+
+ o smpte-50: 50
+
+ o smpte-60: 60
+
+ o smpte-60-drop: 60/1.001 = 59.940 (approx. as per SMPTE)
+
+ 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.
+
+ 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.
+
+3.3. Seeking into the bitstream
+
+ 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.
+
+ 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
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 17]
+
+Internet-Draft SKELETON November 2007
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 18]
+
+Internet-Draft SKELETON November 2007
+
+
+3.4. Remultiplexing an Ogg bitstream using Skeleton
+
+ 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:
+
+ o no decoding of the logical bitstreams is performed.
+
+ o no changes to the pages, in particular to the granule positions
+ are made.
+
+ o changes occur only to the control section.
+
+ 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:
+
+ o the "presentationtime" MUST be adjusted to the requested start
+ time
+
+ o 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.
+
+ 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 temporal URI addressing [timedURI].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 19]
+
+Internet-Draft SKELETON November 2007
+
+
+4. Security considerations
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 20]
+
+Internet-Draft SKELETON November 2007
+
+
+5. References
+
+ [CMML] Pfeiffer, S., Parker, C., and A. Pang, "The Continuous
+ Media Markup Language (CMML), Version 2.0 (work in
+ progress)", I-D draft-pfeiffer-cmml-02.txt, March 2005,
+ <http://www.annodex.net/TR/cmml.txt>.
+
+ [Headers] Resnick, P., "Internet Message Format", RFC 2822,
+ April 2001, <http://www.ietf.org/rfc/rfc2822.txt>.
+
+ [I18N] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", RFC 2277, January 1998,
+ <http://www.ietf.org/rfc/rfc2277.txt>.
+
+ [ISO8601] ISO, TC154., "Data elements and interchange formats --
+ Information interchange -- Representation of dates and
+ times", ISO 8601, 2000.
+
+ [Ogg] Pfeiffer, S., "The Ogg encapsulation format version 0",
+ RFC 3533, May 2003, <http://www.ietf.org/rfc/rfc3533.txt>.
+
+ [SMPTE] The Society of Motion Picture and Television Engineers,
+ "SMPTE STANDARD for Television, Audio and Film - Time and
+ Control Code", ANSI 12M-1999, September 1999.
+
+ [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirements Levels", RFC 2119, BCP 14, March 1997.
+
+ [timedURI]
+ Pfeiffer, S., Parker, C., and A. Pang, "Specifying time
+ intervals in URI queries and fragments of time-based Web
+ resources (work in progress)",
+ I-D draft-pfeiffer-temporal-fragments-03.txt, March 2005,
+ <http://www.annodex.net/TR/URI_fragments.txt>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 21]
+
+Internet-Draft SKELETON November 2007
+
+
+Appendix A. Acknowledgments
+
+ The authors greatly acknowledge the contributions of Christopher
+ Montgomery and Andre Pang in developing this specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 22]
+
+Internet-Draft SKELETON November 2007
+
+
+Authors' Addresses
+
+ Silvia Pfeiffer
+ Annodex Association, Australia
+
+ Phone: +61 2 8012 0937
+ Email: silvia at annodex.net
+ URI: http://www.annodex.org/
+
+
+ Conrad D. Parker
+ Annodex Association, Australia
+
+ Email: conrad at annodex.net
+ URI: http://www.annodex.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 23]
+
+Internet-Draft SKELETON November 2007
+
+
+Full Copyright Statement
+
+ 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
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Pfeiffer & Parker Expires May 22, 2008 [Page 24]
+
+
More information about the commits
mailing list