TVWeb-URI-Requirements-19990311

TV Broadcast URI Schemes
Requirements

11th March 1999

Editors:

Warner ten Kate <tenkate@natlab.research.philips.com>.

Gomar Thomas <gomer@lgerca.com>.

Craig Finseth <craig@finseth.com>.

Copyright:

Copyright  )  1999 W3C (MIT, INRIA, Keio), All Rights Reserved.

This version:

http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19990311

Latest version:

http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements

Previous version:

http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19981126

This document is an informational document and discusses the requirements posed to URI schemes for identifying resources in TV Broadcast environments. The document is the outcome of discussions on this subject by the W3C TV-Web Interest Group [TVWebIG, TVWebMail].

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.

Table of Contents

Abstract

TV Broadcast: Definition and scope

Application Scenarios

Requirements on Global TV Broadcast URI schemes

Exceptions in TV Broadcast URIs

References

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 possibly locate, TV Broadcast content. In this document "URI" is used to indicate TV Broadcast URI.

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.

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

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

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.

Due to the push character of TV Broadcast there are two dimensions of hierarchy, 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.

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

Setting and usage of TV Broadcast URIs

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.

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.

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.

Application types, further definition and scope

Applications can be distinguished in usage of URIs for Global and Local scope.

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

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

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.

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.

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.

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.

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.

Use cases, both Local and Global URI

1. Basic EPG type of locating:
   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.
   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).
2. 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.
3. 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.
4. 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.
   Examples are:

        dtv://?program=X-Files
        dtv://ABC/?lang=sp
       

5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
   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.
   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).
10. 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.

Conventions used in this document

In this document three levels of priority are used to indicate the desirability of a requirement.

MUST

The key word "MUST" is to be understood as an essential and critical requirement.

SHOULD

The key word "SHOULD" indicates an important requirement.

MAY

The key word "MAY" indicates a useful feature.

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

Requirements

1. The URI scheme MUST comply with RFC 2396 [RFC2396].
2. Where the URI serves as a name identifier (URN), the corresponding URN specifications MUST be taken into account, e.g. [RFC2141, RFC2168].
3. Where the URI serves as a locator identifier (URL), the definition of the URI scheme MUST follow the guidelines as set forth in [URLGUIDE].
4. The URI MAY support queries to be posed to the TV Broadcast receiver. The query language MUST be independent to the TV Broadcast system.
5. 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.
6. 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.
   Where the URI serves as a name identifier (URN), the URI scheme MAY include such hierarchical structure.
7. 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.
8. 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.
9. Given a URI, it MUST be possible for a receiver to actually locate the resource, or conclude that it is not reachable.
10. 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.
11. Where the URI serves as a name identifier (URN), it 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.
12. 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).
13. Any actual scheme SHOULD be coordinated with standardisation bodies such as ATSC, DVB, and DAVIC, and SHOULD be reasonably acceptable to those bodies.
14. 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.

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.

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.

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

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

[RFC2141] URN Syntax,

RFC 2141, R. Moats. May 1997.

[RFC2168] Resolution of Uniform Resource Identifiers using the Domain Name System,

RFC 2168, R. Daniel, M. Mealling. June 1997.

[URLGUIDE] Guidelines for new URL Schemes,

Internet-Draft, L. Masinter, H.T. Alvestrand, D. Zigmond, R. Petke. November 1998.

[USECASES] Applications list,

Posting to the TV-Web IG, C. Finseth. December 1998.