TV URI Schemes
10th November 1998
Copyright ) 1998 W3C
Keio), All Rights Reserved.
This document lists the requirements posed to URI schemes for use in TV-based
environments. The document summarizes the outcome of discussions on this
subject by the W3C TV-Web Interest Group. It is intended to become an Internet
Draft. See the references for the starters of that discussion.
Definition: In this document TV Broadcast 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 includes
systems like DVB, ATSC, DSS, NTSC, and PAL. The TV Broadcast 'network layer'
is typically non-IP based.
Requirements on TV Broadcast URI schemes
The URI scheme should comply with RFC 2396.
It must be possible for the resource referenced by a URI to be a channel/service
(i.e. a concatenation of programs), an entire program/event, or just a single
component of a program/event. Fragments within a component are outside the
current scope of requirements.
Given a URI, it must be possible for a receiver to actually locate the resource,
or conclude that it is not reachable.
Given a URI, it must be possible for a receiver to determine the time period(s)
within which the resource can be retrieved from the (also resolved) location.
A URI should be invariant with respect to the normal range of transport stream
transformations, both in referencing the time and location of that resource
in that transport stream.
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.
A URI must be meaningful when interpreted from any of the following locations
relative to the resource being referenced:
From the same TV Broadcast network
From another TV Broadcast network
From an arbitrary location in the Internet
[Note: this means that the system can detect it concerns a URI pointing to
a TV Broadcast network.]
A URI should be resolvable under any of the following network access conditions:
TV Broadcast, same or another network
In Home/local storage
Other (future) networks
The actual resource's retrieved content data may differ in terms of content
quality, performance, and edit version.
[Note the difference with the previous requirement, particularly the use
of 'must' and 'should'.]
The URI scheme must be compatible with solutions already adopted in
standardisation bodies such as ATSC, DVB, and DAVIC.
The URI scheme should interoperate with the Internet access schemes, in
[Note: the scheme, not per se the access protocol it calls; it means that
hierarchies in the URI scheme should map as much as possible. This should
assist seamless transitions when the client decides to use another access
protocol (and network).]
Ideally, the URI should support referencing various instantiations of the
same content (quality/compression ratio, versions/edits).
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.
Exceptions in TV Broadcast URIs
TV Broadcast differs from the conventional Internet in several ways. The
TV Broadcast URI scheme is affected by that in the following aspects:
The host is not necessarily a server identifyable through an IP-address.
For instance, the 'host' is a transport stream.
The resource access and retrieval scheme is not necessarily IP-stack based.
The resource's availability implicitly depends on, or at least relates to,
a transmission schedule.
W3C TVWeb Interest Group
Group page of the W3C TV-Web IG. Philipp Hoschka.
Background & Reqs (ASCII)
Message to TV-Web mailing list. Gomer Thomas. Oct 1998.
URL: Background & Reqs (ASCII)
Message to TV-Web mailing list. Craig Finseth. Oct 1998.
URL: Background & Reqs
Message to TV-Web mailing list. Warner ten Kate. Nov 1998.