INTERNET-DRAFT W. ten Kate
draft-tenkate-tvweb-uri-reqs-00.txt Philips Research Labs.
November, 1998
Expires May, 1999 G. Thomas
LGERCA, Inc.
C. Finseth
U.S. Satellite Broadcasting
Requirements TV Broadcast URI Schemes
1. Status of this Memo
This document is an Internet-Draft. 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 a "work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
Distribution of this document is unlimited. Please send comments
to www-tv@w3.org.
This is work in progress by the W3C TV-Web Interest Group [1].
This group discusses technological aspects concerning usage of
Web technology in TV Broadcast environments. A.o. it aims to
define a URI scheme for identifying resources in a TV Broadcast
environment. This document is also maintained at that group's
web page [2].
2. Abstract
This document lists the requirements posed to URI schemes for use
in TV Broadcast environments. The document summarizes the outcome
of discussions on this subject by the W3C TV-Web Interest Group [1].
3. TV Broadcast
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.
4. Requirements on TV Broadcast URI schemes
o The URI scheme should comply with RFC 2396.
o It must be possible for the resource identified 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 (e.g., a media stream). Fragments within a
component are outside the current scope of requirements.
o Given a URI, it must be possible for a receiver to actually
locate the resource, or conclude that it is not reachable.
o 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.
[Note: the time period in which the resource is valid/meaningful
is controlled by the lifecycle of the application calling the
resource.]
o A URI should be invariant with respect to the normal range of
transport stream transformations, both in referencing the time
and the location of the resource in that transport stream.
o 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.
o 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.]
o A URI should be resolvable under any of the following network
access conditions:
- TV Broadcast, same or another network
- Internet
- In Home/local storage
- Other (future) networks
The actual resource's retrieved content data may differ in terms
of content encoding, content quality, performance, and edit version.
[Note the difference with the previous requirement, particularly
the use of 'must' and 'should'.]
o The URI scheme must be compatible with solutions already adopted
in standardisation bodies such as ATSC, DVB, and DAVIC.
o The URI scheme should interoperate with the Internet access schemes,
in particular http.
[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).]
o Ideally, the URI should support referencing various instantiations
of the same content (encoding, quality/compression ratio,
versions/edits).
o 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.
5. 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:
o The host is not necessarily a server identifyable through an
IP-address. For instance, the 'host' is a transport stream.
o The resource access and retrieval scheme is not necessarily
IP-stack based.
o The resource's availability implicitly depends on, or at least
relates to, a transmission schedule.
Acknowledgements
Several other members of the TV-Web Interest Group have contributed
to the content of this memo. Their comments, suggestions and other
input are heighly acknowledged.
Authors Address
* Warner R.Th. ten Kate
Philips Research Laboratories
Prof. Holstlaan 4
5656 AA Eindhoven
The Netherlands
Email: tenkate@natlab.research.philips.com
Gomer Thomas
LGERCA, Inc.
40 Washington Road
Princeton Junction, NJ 08550
Email: gomer@lgerca.com
Craig A. Finseth
USSB
3415 University Ave, Suite 201
St Paul MN 55114
Email: craig@finseth.com
References
1. Philipp Hoschka,
W3C TVWeb Interest Group,
2. Warner ten Kate,
TV URI Schemes - Requirements