I-D TV Broadcast URI Requirements

From: Warner ten Kate (tenkate@natlab.research.philips.com)
Date: Fri, Nov 13 1998

Message-Id: <364C5B13.6EEBEA69@natlab.research.philips.com>
Date: Fri, 13 Nov 1998 17:15:15 +0100
From: Warner ten Kate <tenkate@natlab.research.philips.com>
To: www-tv@w3.org
Cc: gomer@lgerca.co, Philipp Hoschka <ph@w3.org>
Subject: I-D TV Broadcast URI Requirements

I edited the requirements list as we have on our 
TV-Web site [1] into an Internet-Draft, see the attachment.
They are not basically different.

My purpose is to send this to the IETF on Tuesday (17th),
in line with our charter [2].

[1] <http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19981110>
[2] <http://www.w3.org/TV/TVWeb/#Discussion>


Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648    tenkate@natlab.research.philips.com

INTERNET-DRAFT                                            W. ten Kate
draft-tenkate-tvweb-uri-reqs-00.txt            Philips Research Labs.
November 17, 1998
Expires May 17, 1999                                        G. Thomas
                                                         LGERCA, Inc.
               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-based 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 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 
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.
o  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.
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, 
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 

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.


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 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


   1. Philipp Hoschka,
      W3C TVWeb Interest Group, 
   2. Warner ten Kate,
      TV URI Schemes - Requirements