TVWeb-URI-Requirements-19981126

TV Broadcast URI Schemes
Requirements

26th November 1998

Editors:
Warner ten Kate <tenkate@natlab.research.philips.com>.
Gomar Thomas <gomer@lgerca.com>.
Craig Finseth <craig@finseth.com>.
Copyright:
Copyright  )  1998 W3C (MIT, INRIA, Keio), All Rights Reserved.
This version:
http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19981126
Previous versions:
http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19981110

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 [TVWebIG, TVWebMail].

TV Broadcast: Definition and terms

Definition of TV Broadcast

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

The term TV Broadcast URI refers to URIs which identify and/or locate TV Broadcast content. In this document "URI" is used to indicate TV Broadcast URI.

Setting and usage of TV Broadcast URIs

TV Broadcast applications need a mechanism to identify and locate the content 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 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 transmission channel have been proposed, but wide spread consensus has not yet been reached. There is no complete scheme set existing which covers all access types at hand within TV Broadcast transmission protocols.

Next to locating resources at TV Broadcast transmission channels, another aspect of TV Broadcast URIs concerns the referencing of the TV Broadcast content itself. In the first place, this content will be available at the TV Broadcast transmission channel, possibly at several channels and at multiple periods of time. The above mentioned URI schemes address this. In the second place, the content may be stored and made available through another path than the TV Broadcast transmission 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 client 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. 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 transmission protocol but uses the same physical link.

Hierarchy in TV Broadcast content

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.

The term service 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.

The term event is used to refer to a single TV program. An event is 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 are the typical entities which EPGs list to present program schedule information.

The term component is used to refer to 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 the applications are using.

The term fragment 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.

Conventions used in this document

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

Requirements on TV Broadcast URI schemes

  1. The URI scheme SHOULD comply with RFC 2396 [RFC2396].
  2. It MUST be possible for the resource identified by a URI to be a service, an event, or just a single component. Fragments are outside the current scope of requirements.
  3. Given a URI, it MUST be possible for a receiver to actually locate the resource, or conclude that it is not reachable.
  4. The URI scheme MUST support for OPTIONAL information from which 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. The accuracy of the time period SHOULD correspond with the event's granularity as provided by the service signaling system.
    [Note: the time period in which the resource is valid/meaningful is controlled by the lifecycle of the application calling the resource. That application also controls the synchronization of the time period in which the resource is presented. The URI indicates the time period within which the resource is available.]
  5. 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.
  6. 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.
  7. 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.
    [Note: this means that at least the system can detect it concerns a URI pointing to TV Broadcast content.]
  8. A URI SHOULD be resolvable under any of the following network access conditions:
    1. TV Broadcast
    2. Internet
    3. In Home/local storage
    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'.]
  9. Any actual scheme MUST be coordinated with standardisation bodies such as ATSC, DVB, and DAVIC, and MUST be reasonably acceptable to those bodies.
  10. The URI scheme SHOULD interoperate with the Internet access schemes, such as to enable seamless transition in referencing resources at TV Broadcast or Internet sites.
  11. Ideally, the URI SHOULD support referencing various instantiations of the same content (encoding, quality/compression ratio, versions/edits).
  12. 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:
  1. The host is not necessarily a server identifiable through an IP-address. For instance, the 'host' is a transport stream.
  2. The resource access and retrieval scheme is not necessarily IP-stack based.
  3. The resource's availability implicitly depends on, or at least relates to, a transmission schedule.

References

[RFC2119] Key words for use in RFCs to Indicate Requirement Levels.
RFC 2119, S. Bradner. March 1997.
[TVWebIG] W3C TVWeb Interest Group
Group page of the W3C TV-Web IG. Philipp Hoschka.
<http://www.w3.org/TV/TVWeb/>.
[TVWebMail] TV-Web Mail Archives
Threads starting with messages 0040, 0041, and 0046. Oct/Nov 1998.
<http://lists.w3.org/Archives/Public/www-tv/>.
[RFC2396] Uniform Resource Identifiers (URI): Generic Syntax
RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter. Aug. 1998.