You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
501 lines
26 KiB
501 lines
26 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<title>Requirements TV Broadcast URI Schemes</title>
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-NOTE">
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<div class="head">
|
|
<a href="http://www.w3.org/"><img height="48" width="72"
|
|
src="/Icons/WWW/w3c_home" alt="W3C">
|
|
</a>
|
|
|
|
<h1>TV Broadcast URI Schemes<br>
|
|
Requirements</h1>
|
|
|
|
<h2>W3C Note 21 October 1999</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a class="loc"
|
|
href="http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991021">http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991021</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a class="loc"
|
|
href="http://www.w3.org/TR/TVWeb-URI-Requirements">http://www.w3.org/TR/TVWeb-URI-Requirements</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd><a class="loc"
|
|
href="http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991019">http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991019</a></dd>
|
|
<dt>Editors:</dt>
|
|
<dd><span class="author"><span class="name">Warner ten Kate</span>
|
|
<i>(<span class="email"><a
|
|
href="mailto:warner.ten.kate@philips.com">warner.ten.kate@philips.com</a></span>)</i></span></dd>
|
|
<dd><span class="author"><span class="name">Gomar Thomas</span> <i>(<span
|
|
class="email"><a
|
|
href="mailto:gomer@lgerca.com">gomer@lgerca.com</a></span>)</i></span></dd>
|
|
<dd><span class="author"><span class="name">Craig Finseth</span> <i>(<span
|
|
class="email"><a
|
|
href="mailto:craig@finseth.com">craig@finseth.com</a></span>)</i></span></dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
|
|
© 1999 <a href="http://www.w3.org/">W3C</a> (<a
|
|
href="http://www.lcs.mit.edu/">MIT</a>, <a
|
|
href="http://www.inria.fr/">INRIA</a>, <a
|
|
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
|
|
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software">software
|
|
licensing</a> rules apply.</p>
|
|
</div>
|
|
|
|
<p></p>
|
|
<hr title="Separator from Header">
|
|
|
|
|
|
<h2>Status of this document</h2>
|
|
|
|
<p>This Note was produced by the W3C TV-Web Interest Group. It is the result
|
|
of discussions on URI schemes suited for use in TV Broadcast environments. The
|
|
document reflects preliminary results, and is intended to serve as a base to
|
|
further work to design TV Broadcast URIs. Please send comments to the TV-Web
|
|
mailing list <a href="mailto:www-tv@w3.org">www-tv@w3.org</a>.</p>
|
|
|
|
<p>This version is an update of the version dated 19 October 1999, fixing a wrong link.</p>
|
|
|
|
<p>Publication of a W3C Note does not imply endorsement by the entire W3C
|
|
Membership. A list of current W3C technical reports and publications,
|
|
including Working Drafts and Notes, can be found at <a
|
|
href="http://www.w3.org/TR">http://www.w3.org/TR</a>.</p>
|
|
|
|
<p lang="en" style="font-style: italic">This section represents the status of
|
|
this document at the time this version was published. It will become outdated
|
|
if and when a new version is published.</p>
|
|
|
|
<h2>Table of Contents</h2>
|
|
<dl>
|
|
<dd><a href="#Abstract">Abstract</a></dd>
|
|
<dd><a href="#Definitions">1. TV Broadcast: Definition and scope</a></dd>
|
|
<dd><a href="#Applications">2. Application Scenarios</a></dd>
|
|
<dd><a href="#Requirements">3. Requirements on Global TV Broadcast URI
|
|
schemes</a></dd>
|
|
<dd><a href="#Exceptions">4. Exceptions in TV Broadcast URIs</a></dd>
|
|
<dd><a href="#References">References</a></dd>
|
|
</dl>
|
|
|
|
<h2><a name="Abstract">Abstract</a></h2>
|
|
|
|
<p>This document is an informational document and discusses the requirements
|
|
posed to URI schemes for identifying resources in Television (TV) Broadcast
|
|
environments. The document is the outcome of discussions on this subject by
|
|
the W3C TV-Web Interest Group [TVWebIG, TVWebMail].</p>
|
|
|
|
<p>Typical use cases are summarized where TV Broadcast URIs are involved. A
|
|
distinction is made between Global and Local usage. Also, a hierarchy of
|
|
resource types is identified. Requirements related to the Global usage case
|
|
are listed.</p>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
|
|
|
<h2 class="notoc"><a name="Definitions">1. TV Broadcast: Definition and
|
|
scope</a></h2>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->
|
|
|
|
<h5 class="notoc">Definition of TV Broadcast</h5>
|
|
|
|
<p>In this document <em>TV Broadcast</em> is used as the generic term to refer
|
|
to currently existing TV systems, their transport protocols, and their typical
|
|
operation of content provision and distribution. TV Broadcast concerns both
|
|
digital and analog systems and includes systems like DVB, ATSC, DSS, NTSC, and
|
|
PAL. The TV Broadcast "network layer" is typically non-IP based.</p>
|
|
|
|
<p>The term <em>TV Broadcast URI</em> refers to URIs which identify, and
|
|
possibly locate, TV Broadcast content. In this document "<em>URI</em>" is used
|
|
to indicate TV Broadcast URI.</p>
|
|
|
|
<p>Typically, TV Broadcast systems are push systems. The content streamed
|
|
along a TV Broadcast transport is scheduled by the service provider; the user
|
|
has no influence on that. In this model the user accesses the stream(s) rather
|
|
than the server at the upstream station.</p>
|
|
|
|
<h5 class="notoc">Hierarchy in TV Broadcast content</h5>
|
|
|
|
<p>TV Broadcast content is modeled in a four-layer hierachy, consisting of
|
|
service, event, component, and fragment. Service is at the top, fragment is at
|
|
the bottom of the hierarchy.</p>
|
|
|
|
<p>The term <em>service</em> is used to refer to a concatenation of programs,
|
|
all being broadcast by the same service provider. The programs of a service
|
|
share some tuning characteristics. Service corresponds to the naming "channel"
|
|
as used in today's analog TV.</p>
|
|
|
|
<p>The term <em>event</em> is used to refer to a single TV program. An event
|
|
consumes a time period within a service and therefore can be characterized
|
|
with begin and end times. The service provider determines the granularity in
|
|
which the service is split in events. An event can be a complete program or an
|
|
episode of a program. Events can be grouped in series, e.g., to form a serial.
|
|
Events are the typical entities which EPGs list to present program schedule
|
|
information.</p>
|
|
|
|
<p>The term <em>component</em> is used to refer the constituents of an event.
|
|
The audio and video of a TV program are obvious examples. In case of
|
|
multilingual programs there are multiple audio components. In case of
|
|
interactive programs the components are the application documents and the
|
|
other data these applications are using. Next to continuous data like audio
|
|
and video, component also encompasses discrete data like Web pages and
|
|
applications describing composition and interactivity. The URI identifying an
|
|
application can constitute the base URI for the further components referenced
|
|
by that application.</p>
|
|
|
|
<p>The term <em>fragment</em> is used to refer to a subpart of a component.
|
|
For instance, it can be a slice of a video sequence, or a subregion in an
|
|
image.</p>
|
|
|
|
<p>Due to the push character of TV Broadcast there are <em>two dimensions of
|
|
hierarchy</em>, a schedule related and a content related. The first is the
|
|
hierarchy of transport system, transport stream, service, series, event; The
|
|
second is the hierarchy of series, event, component, fragment.</p>
|
|
|
|
<p>The term <em>resource</em> is to be understood as in RFC 2396, sec.1.1
|
|
[RFC2396]. In the context of TV Broadcast a resource refers to the entities
|
|
service, event, component, and fragment in particular.</p>
|
|
|
|
<h5 class="notoc">Setting and usage of TV Broadcast URIs</h5>
|
|
|
|
<p>TV Broadcast applications need a mechanism to identify and locate the
|
|
components building the application. The URI scheme is a useful tool for that
|
|
as it opens possibilities for seamless transition in referencing resources at
|
|
TV Broadcast transport and Internet sites. URI schemes to locate resources at
|
|
the Internet are well-known, and are not further observed in this document.
|
|
URI schemes to locate resources in a TV Broadcast transport channel have been
|
|
proposed, but most are designed with a particular TV Broadcast transport
|
|
environment in mind.</p>
|
|
|
|
<p>Next to locating components at TV Broadcast transport channels, another
|
|
aspect of TV Broadcast URIs concerns referencing the events. In the first
|
|
place, events are accessible at the TV Broadcast transport channel, possibly
|
|
at several channels and at multiple periods of time. The above mentioned URI
|
|
schemes also address this aspect, but all in their own way. In the second
|
|
place, the content may be stored and made available through another path than
|
|
the TV Broadcast transport channel. Most evident are local storage, like
|
|
VCR-type of devices, and the Internet itself. Local storage devices can be
|
|
connected through an in-home network to the user agent presenting the
|
|
application. Local storage in the sense of the client's local file system or
|
|
in the sense of cache buffering are not observed in this document.</p>
|
|
|
|
<p>TV Broadcast content delivered through a so-called IP-tunnel is considered
|
|
as content made available through the Internet. An IP-tunnel refers to a
|
|
forwarding path which is logically separated from the conventional TV
|
|
Broadcast transport protocol but uses the same physical transmission link.</p>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
|
|
|
<h2 class="notoc"><a name="Applications">2. Application Scenarios</a></h2>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->
|
|
|
|
<h5 class="notoc">Application types, further definition and scope</h5>
|
|
|
|
<p>Applications can be distinguished in usage of URIs for Global and Local
|
|
scope.</p>
|
|
|
|
<p><em>Global</em> refers to URIs contained in documents which can be accessed
|
|
anywhere around the world, and which identify content related to any TV
|
|
Broadcast system in the world, including storage devices associated with that
|
|
TV Broadcast system. Such a global URI may include identification of the TV
|
|
Broadcast system to be used.</p>
|
|
|
|
<p><em>Local</em> refers to URIs contained in documents which are accessed
|
|
within a certain TV Broadcast system, and which identify content to be
|
|
accessed through that TV Broadcast system. URIs that reference content outside
|
|
the local TV Broadcast system, are assumed to be either Global URIs or
|
|
traditional URIs for locating resources at the Internet.</p>
|
|
|
|
<p>This document concentrates on Global URIs, as those have a world-wide
|
|
interest for standardization. It would be nice when Local URIs bear an
|
|
identical format, but that is considered not a necessary requirement. Local
|
|
URIs can be specified within their respective application domains. On the
|
|
other hand, it would be nice when Global URIs can serve as a base URI for
|
|
Local URIs, either as direct copy or by some mapping function. <!--
|
|
This document doesn't list requirements for Local URIs.
|
|
[An example of such a requirement could be:
|
|
The URI MUST be able to refer to the associated audio/video image
|
|
of which the application document forms a part.]
|
|
-->
|
|
</p>
|
|
|
|
<p>Further, URIs can be distinguished in identifying a service or event, and
|
|
in identifying a particular content item (component or fragment) in such a
|
|
service or event. This reflects the two dimensions observed above of schedule
|
|
related and content related hierarchy. The use cases where a content item in a
|
|
certain service is to be identified while the context isn't already that
|
|
service, seem rare. Consequently, a URI is not required to carry both
|
|
informations (service and content item) together.</p>
|
|
|
|
<p>This distinction suggests that identification of a particular content item
|
|
belongs to the Local class of URIs, and that Global URIs typically identify a
|
|
service or an event. However, an exception can be found in the case where the
|
|
same content item is referenced in various transport contexts, e.g. in a
|
|
commercial.</p>
|
|
|
|
<p>An important class of Global URIs identify their resource in a location and
|
|
time independent way, i.e. independent of the particular TV Broadcast
|
|
transport system and particular schedule. For instance, they are also valid
|
|
after local storage. As such, they resemble URN behavior, opposed to URL
|
|
behavior.</p>
|
|
|
|
<p>As the set of resources and their various locations can scale to large
|
|
numbers, it is preferred that the URI scheme imposes a hierarchical structure,
|
|
certainly when the URI's purpose is to locate a resource. A hierarchy allows
|
|
for step-by-step resolution and navigation to the resource identified. By
|
|
that, efficiency and scalability is improved. Further, implying a hierarchical
|
|
structure allows to group resources, and by that to distinguish between, for
|
|
example, in identifying a serial and an event in that serial.</p>
|
|
|
|
<h5 class="notoc">Use cases, both Local and Global URI</h5>
|
|
Below, some representative use cases are listed. An exhaustive list of
|
|
application scenarios is provided in [USECASES].
|
|
<ol>
|
|
<li>Basic EPG type of locating:<br>
|
|
Reference TV Broadcast services and events from a Web page for navigating
|
|
to them. The references are tolerant to modifications in the actual
|
|
transmission schedule, but a coarse indication can be derived. The
|
|
broadcast program can be indicated through tuning data or through naming.
|
|
Next to navigation to the program, the EPG also supports for setting
|
|
reminders or recording of programs. Instead of a single program, the
|
|
serial of which the program is part, is referred to, such that setting a
|
|
reminder or a recording for all episodes can be accomplished.
|
|
<p></p>
|
|
It is the year 2002. Fox is broadcasting a World Cup game from South Korea
|
|
in both analog and digital formats, with the broadcast reaching North
|
|
America, Europe, Africa, Asia, Latin America, Australia, etc., through a
|
|
wide variety of local affiliates and re-broadcast operators. Fox wishes
|
|
to put a hyperlink to the broadcast on its web site, so that users of
|
|
Internet-connected TV receivers all over the world with the right software
|
|
(perhaps native, perhaps downloaded) can click on the hyperlink and have
|
|
their receivers tune to the broadcast (or set a reminder for the
|
|
broadcast, if the game is not currently on).</li>
|
|
<li>A sports fanatic wants to watch all the above broadcasts by Fox.
|
|
Therefore he records all the broadcasts and copies the above Fox World Cup
|
|
page to his local disc. From that page he can access the broadcasts or,
|
|
when they have been recorded, view them from his recording device. At its
|
|
site Fox also provides the transmitted broadcasts, albeit at high
|
|
compression rates. The page will direct users who haven't recorded the
|
|
broadcast to these videos.</li>
|
|
<li>A Web page is composed for presentation on a TV Broadcast receiver. The
|
|
Web page is delivered in association with a TV Broadcast program (the
|
|
transmission paths may be physically separated). The Web page includes an
|
|
object which refers to the associated audio/video image of the TV
|
|
broadcast program.</li>
|
|
<li>In a Web page a TV Broadcast event is referred, but the exact location
|
|
is not known at authoring time. The URI is incomplete in its information.
|
|
Instead a query is added to retrieve the missing information. When the
|
|
available TV Broadcast system supports the query mechanism, the URI can be
|
|
resolved and the identified resource can be retrieved. The query language
|
|
is technology-independent, i.e. it is not relying on specific fields, such
|
|
as SI data, in the TV Broadcast transmission system. <br>
|
|
Examples are:
|
|
<pre> dtv://?program=X-Files
|
|
dtv://ABC/?lang=sp
|
|
</pre>
|
|
</li>
|
|
<li>A TV Broadcast of a soccer match is data-enhanced; in a data carousel
|
|
module or an encapsulated IP datagram a file is contained which gives
|
|
up-to-the-second statistics on goals scored, fouls committed, corner kicks
|
|
taken, shots at goal, shots on goal, etc. The broadcaster wants to put a
|
|
URI on their web site which references this file, allowing applications on
|
|
Internet-connected TV receivers all over the world to get to the file and
|
|
display it in nifty ways.</li>
|
|
<li>A data file is transmitted along with a TV program, the data file is
|
|
containing additional information to that program. It also contains
|
|
hyperlinks to the programs and/or data in other data files being broadcast
|
|
on the same channel and in other channels, so that receivers can set
|
|
reminders for the upcoming game and/or data file.</li>
|
|
<li>A Web page is transmitted with a TV Broadcast commercial. The commercial
|
|
is about an upcoming TV Broadcast program. The viewer can click a hotspot
|
|
area such as to set a reminder for that program. The Web page can also be
|
|
accessed at the broadcaster's Web site.</li>
|
|
<li>A set of three Web page is transmitted with a TV Broadcast commercial.
|
|
The viewer can navigate the three pages. The pages are transmitted
|
|
frequently along various TV Broadcast systems. The pages can also be
|
|
accessed at the advertiser's Web site, where they are maintained at a
|
|
particular sub directory. Therefore, the advertiser uses relative
|
|
referencing between the pages.</li>
|
|
<li>A live quiz show is enhanced such that the viewer can play along. The
|
|
enhancement data are a mixture of Web pages, which compose the quiz's
|
|
question and answer environment, element values, which carry the actual
|
|
questions and (correct) answers to be inserted in the Web pages, and
|
|
procedural cells to control the viewer's score. The Web pages are provided
|
|
at a Web site long before the show is aired, such that viewers can
|
|
prepare. The element values are transported along the TV Broadcast
|
|
transmission channel during the show. They are synchronized with the
|
|
actions in the show such as to complete and update the application.<br>
|
|
There are several levels of play along: some pages provide the viewer with
|
|
hints such as to ease answering, and some pages provide less alternatives
|
|
in the multiple choice questions. The viewer can select his level by
|
|
navigating between these pages.<br>
|
|
Upon the actual broadcast an application is broadcast with the program to
|
|
initiate the enhancement. The application references the Web site, such
|
|
that upon tuning to the TV Broadcast the Web site's home page gets
|
|
retrieved. Triggered by stream events in the TV Broadcast transport
|
|
stream, the application also controls the insertion of element values
|
|
(questions and answers) and the score management (e.g., no score increment
|
|
after answer presentation).</li>
|
|
<li>A Web site provides a EPG covering programs transmitted world-wide. A
|
|
viewer is visiting this site and browses the EPG. Upon encountering his
|
|
favorite movie "Once upon a time in the Cyber" he clicks the item on the
|
|
EPG. Regretfully, the movie isn't scheduled for the 419 TV Broadcast
|
|
satellites his receiver is configured to. Instead of setting a reminder,
|
|
the receiver informs the user the movie will not appear on his reception
|
|
links.</li>
|
|
</ol>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
|
|
|
<h2 class="notoc"><a name="Requirements">3. Requirements on Global TV
|
|
Broadcast URI schemes</a></h2>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->
|
|
|
|
<h5 class="notoc">Conventions used in this document</h5>
|
|
|
|
<p>In this document three levels of priority are used to indicate the
|
|
desirability of a requirement.</p>
|
|
<dl>
|
|
<dt><strong>MUST</strong></dt>
|
|
<dd>The key word "MUST" is to be understood as an essential and critical
|
|
requirement.</dd>
|
|
<dt><strong>SHOULD</strong></dt>
|
|
<dd>The key word "SHOULD" indicates an important requirement.</dd>
|
|
<dt><strong>MAY</strong></dt>
|
|
<dd>The key word "MAY" indicates a useful feature.</dd>
|
|
</dl>
|
|
|
|
<p>[These key words and their meaning are based upon RFC 2119 [RFC2119]. That
|
|
RFC specifies similar wording for implementation compliance with a protocol
|
|
specification. In this document the wording reflects specification compliance
|
|
with protocol goals.] <!-- RFC 2119 wording:
|
|
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 decribed in RFC 2119 [RFC2119].-->
|
|
</p>
|
|
|
|
<h5 class="notoc">Requirements</h5>
|
|
<ol>
|
|
<li>The URI scheme MUST comply with RFC 2396 [RFC2396].</li>
|
|
<li>Where the URI serves as a name identifier (URN), the corresponding URN
|
|
specifications MUST be taken into account, e.g. [RFC2141, RFC2168].</li>
|
|
<li>Where the URI serves as a locator identifier (URL), the definition of
|
|
the URI scheme MUST follow the guidelines as set forth in [URLGUIDE].</li>
|
|
<li>The URI MAY support queries to be posed to the TV Broadcast receiver.
|
|
The query language MUST be independent to the TV Broadcast system.</li>
|
|
<li>The URI scheme SHOULD support relative referencing such that a
|
|
TV-program with all its associated resources can be referenced against a
|
|
common base, which is the TV Broadcast URI of that aggregate.</li>
|
|
<li>Where the URI serves as a locator identifier (URL), the URI scheme
|
|
SHOULD include a hierarchical structure either to identify the resoure as
|
|
a service or an event from a service, or to identify the resource as an
|
|
event, a component from an event, or a fragment from a component. The
|
|
structure SHOULD provide optional levels to group events into series or
|
|
serials and to group components into composites.<br>
|
|
Where the URI serves as a name identifier (URN), the URI scheme MAY
|
|
include such hierarchical structure.</li>
|
|
<li>The URI scheme SHOULD support the spectrum of transport protocols
|
|
applied and standardized in TV Broadcast systems. This includes both
|
|
audio/video and data broadcast protocols.</li>
|
|
<li>A URI MUST be invariant with respect to the normal range of transport
|
|
stream transformations along the path from provider to user, both in
|
|
referencing the time and the location of the resource in that transport
|
|
stream.</li>
|
|
<li>Given a URI, it MUST be possible for a receiver to actually locate the
|
|
resource, or conclude that it is not reachable.</li>
|
|
<li>A URI MUST be meaningful when interpreted, independent of the
|
|
transmission context in which the URI is called. Transmission context
|
|
refers to a coherent set of content streams as they arrive at the
|
|
receiver. An example is a set of TV broadcast services sharing a same
|
|
physical connection; another is an Internet connection. In case the
|
|
context is the same transmission system as in which the content is
|
|
located, the URI MUST be resolvable.</li>
|
|
<li>Where the URI serves as a name identifier (URN), it SHOULD be resolvable
|
|
under any of the following network access conditions:
|
|
<ol>
|
|
<li>TV Broadcast</li>
|
|
<li>Internet</li>
|
|
<li>In Home/local storage</li>
|
|
</ol>
|
|
The actual resource's retrieved content data MAY differ in terms of
|
|
content encoding, content quality, performance, and edit version.</li>
|
|
<li>Where the URI serves as a name identifier (URN), the scheme MUST support
|
|
referencing various instantiations of the same content (encoding,
|
|
quality/compression ratio, versions/edits).</li>
|
|
<li>Any actual scheme SHOULD be coordinated with standardisation bodies such
|
|
as ATSC, DVB, and DAVIC, and SHOULD be reasonably acceptable to those
|
|
bodies.</li>
|
|
<li>The URI scheme MUST interoperate with the Internet access schemes, such
|
|
as to enable seamless transition in referencing resources at TV Broadcast
|
|
or Internet sites.</li>
|
|
</ol>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
|
|
|
<h2 class="notoc"><a name="Exceptions">4. Exceptions in TV Broadcast
|
|
URIs</a></h2>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
|
TV Broadcast differs from the conventional Internet in several ways. The TV
|
|
Broadcast URI scheme is affected by that in the following aspects:
|
|
<ol>
|
|
<li>The host is not necessarily a server identifiable through an IP-address.
|
|
For instance, the "host" is a transport stream.</li>
|
|
<li>The resource access and retrieval scheme is not necessarily IP-stack
|
|
based.</li>
|
|
<li>The resource's availability implicitly depends on, or at least relates
|
|
to, a transmission schedule.</li>
|
|
</ol>
|
|
|
|
<p>Because TV Broadcast is a resource constrained environment, it is
|
|
worthwhile to keep the length of the URI limited. This document does not pose
|
|
a requirement on a maximum length of a TV Broadcast URI. It is left to the
|
|
particular application domain to specify such limitations.</p>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
|
|
|
<h2><a name="References">References</a></h2>
|
|
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->
|
|
<dl>
|
|
<dt>[RFC2119] <a
|
|
href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2119.txt">
|
|
<i>Key words for use in RFCs to Indicate Requirement Levels</i></a>,</dt>
|
|
<dd>RFC 2119, S. Bradner. March 1997.</dd>
|
|
<dt>[TVWebIG] <a href="http://www.w3.org/TV/TVWeb/"> <i>W3C TVWeb Interest
|
|
Group</i></a>,</dt>
|
|
<dd>Group page of the W3C TV-Web IG. Philipp Hoschka.</dd>
|
|
<dt>[TVWebMail] <a href="http://lists.w3.org/Archives/Public/www-tv/">
|
|
<i>TV-Web Mail Archives</i></a>,</dt>
|
|
<dd>Threads starting with messages 0040, 0041, and 0046. Oct/Nov 1998.
|
|
<br>
|
|
<http://lists.w3.org/Archives/Public/www-tv/>.</dd>
|
|
<dt>[RFC2396] <a
|
|
href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2396.txt">
|
|
<i>Uniform Resource Identifiers (URI): Generic Syntax</i></a>,</dt>
|
|
<dd>RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter. Aug. 1998.</dd>
|
|
<dt>[RFC2141] <a
|
|
href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2141.txt">
|
|
<i>URN Syntax</i></a>,</dt>
|
|
<dd>RFC 2141, R. Moats. May 1997.</dd>
|
|
<dt>[RFC2168] <a
|
|
href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2168.txt">
|
|
<i>Resolution of Uniform Resource Identifiers using the Domain Name
|
|
System</i></a>,</dt>
|
|
<dd>RFC 2168, R. Daniel, M. Mealling. June 1997.</dd>
|
|
<dt>[URLGUIDE] <a
|
|
href="http://info.internet.isi.edu/in-drafts/files/draft-ietf-urlreg-guide-05.txt">
|
|
<i>Guidelines for new URL Schemes</i></a>,</dt>
|
|
<dd>Internet-Draft, L. Masinter, H.T. Alvestrand, D. Zigmond, R. Petke.
|
|
March 1999.</dd>
|
|
<dt>[USECASES] <a
|
|
href="http://lists.w3.org/Archives/Public/www-tv/1998OctDec/0224.html">
|
|
<i>Applications list</i></a>,</dt>
|
|
<dd>Posting to the TV-Web IG, C. Finseth. December 1998.</dd>
|
|
</dl>
|
|
</body>
|
|
</html>
|