This document does not propose a URI scheme for DTV as such. It proposes a general approach to be used for such a URI scheme, and it analyzes at some length most of the issues which must be addressed in working out the details, with a number of recommendations. The intent of this document is to provide a framework and stimulate discussion among stakeholders in this area, leading to a rapid consensus on the actual details of a DTV URI scheme.

1. General Approach for DTV URL Scheme

The information needed to translate from logical names to direct addresses should be inserted into the broadcast stream. Then different receivers can take the same logical URI which is pointing to a resource coming to them through different local stations and/or cable/satellite operators, and resolve it to the correct direct address for the broadcasts they are receiving.

The translation information should be organized in a hierarchical fashion, to minimize the amount of data which needs to be cached by receivers.

Both forms of URIs should comply with IETF guidelines for URI schemes [6], [7], [8].

Relative URIs can be used in the usual way.

The basic format of a URI in either scheme should be something like "dtv://<host>[/<path>]", where the <host> portion of the URI gets translated between a logical name and a direct address, and the optional <path> portion of the URI is meaningful in the context of the <host>, so that it does not need translation. For example, the <path> portion might correspond to an application name and tap_id in an ATSC Service Description Table, or a carousel name and module name in a data carousel, or the directory path in an object carousel.

With either type of URI it should be possible to reference an entire transport stream, a virtual channel within a transport stream, an event within a channel, an elementary stream within a channel or event, or a data element within an elementary stream.

The remainder of this document addresses three issues:

• Scheme for the direct address URIs
• Scheme for the logical name URIs
• Translation mechanism

2. Direct Address URL Scheme(s)

The DAVIC URL specification is a reasonable direct address specification for DVB broadcast environments in most respects.

However, it does pose one problem in the context of supporting any form of translations from logical names to direct addresses. One element of its syntax complicates the problem of looking at a URI and determining whether it contains a logical name which needs translation, or already contains a direct address. Namely, the individual components of the <host> portion of the URI are all numeric quantities, and DAVIC specifies that they be represented as hexadecimal numbers, with no leading "0x". Thus, they can all start with alphabetic characters, and indeed can consist entirely of alphabetic characters. This means that the simple restrictions on Internet domain names which allow them to be distinguished from IP addresses will not work. There are a number of mechanisms which can be used to eliminate the ambiguity, but none of them are great. It would certainly be much easier if the DAVIC specification required that the numbers be written in decimal form, or in hexadecimal with a leading "0x".

In ATSC broadcast environments the natural hierarchy for a direct addressing scheme is transport stream, virtual channel, event, elementary stream. The point of the event is to identify the time period during which the resource is available (assuming it is not available 24 hours a day, 7 days a week). In some circumstances the event could be omitted (e.g., referencing the video stream for the channel, independently of what event is showing).

The transport stream could be referenced by transport_stream_id or by frequency. At the moment there is no guarantee that the transport_stream_id is globally unique, but I understand that NAB has proposed to the FCC that each broadcast station be assigned a transport_stream_id to go along with their broadcast license, which would make them unique among terrestrial broadcasts. Hopefully the cable and satellite companies could be induced to cooperate to make them globally unique. Assuming that uniqueness can be guaranteed, the transport_stream_id is a good identifier.

The virtual channel could be referenced by program number, major/minor channel number, or source_id. All of these are guaranteed to be unique within a given transport stream at a given time. Of these it appears that the source_id is likely to be the most stable, and therefore would be the preferred identifier.

Referencing an event presents a problem. The event_id is only specified by ATSC to be unique within an EIT, i.e., within a 3-hour period. What is really needed is for it to be unique within the scope of a source_id. So far T3/S8 has flatly refused to consider broadening its scope of uniqueness. If this situation is not changed, almost the only unambiguous way to identify an event will be to give the event_id and identify the associated EIT. About the only reasonable way to identify the EIT will be to give the starting date and time for the EIT. Another approach, of course, is to specify the start time and duration of the event directly, but the syntax for this is bound to be clumsy, and it is not robust in the face of situations where the broadcast schedule slips. It might be an accceptable alternative form of address.

The Service Description Table defined in the draft ATSC Data Broadcast Specification allows an individual data element in an elementary stream to be referenced by specifying an "application name" and a "tap id", without having to specify the elementary stream. Basically the "tap" data structure defines the elementary stream, the protocol used to encode the data element within the elementary stream (data carousel, PES packets, etc.), and how to find the data element within the elementary stream.

Ideally, the application name and tap id can be included within the <path> portion of a URI instead of the <host> portion. A slight problem with this is that the application name is an arbitrary character string, but the tap id is a numeric quantity -- an undesirable feature for a component of the <path>, which ideally should be meaningful to human writers of the URI. Perhaps the ATSC Data Broadcast Specification can be modified to provide a "tap name" as well as a tap id.

Referencing an elementary stream could be done either through the PID or through an association tag (optionally defined by an Association Tag Descriptor associated with the PID in the Program Map Table). Since the association tag is much more stable, it would be the preferred identifier.

The elementary sream could conceivably be referenced through the stream type, as proposed in [4], but I think I would prefer to see that done by use of a "query" at the end of the URI, similar in syntax to the query at the end of an "http:" URI. (One would reference a virtual channel or event in the <host> portion of the URI, and then put something like "?video" or "?audio=<langcode>" or "?stream=<type>"at the end of the URI.

There is a minor syntactical problem to be solved here. Sometimes one wants to specify the event, but not the elementary stream in the <host> portion of the URI. Other times one wants to specify the elementary stream, but not the event. (In a sense, one relates to the time dimension, and the other relates to the a space dimension.) How should these two cases be distinguished syntactically (within the IETF guidelines for URIs)?

It is almost certainly possible to define a scheme for NTSC broadcasts as well, based on just channel number and event.

3. Logical Name URI Scheme

Obviously there would have to be some kind of registration of high level domain names, to avoid conflicts. The existing Internet registration system could be used in most cases, since most DTV content providers will also have Internet sites. A new top level domain "dtv" could be created for DTV content providers who want a totally separate name space for broadcast material. This could be administered by one of the existing domain registration authorities (with no requirement that they create DNS records on their central DNS server for it).

DTV Content providers would determine a logical name hierarchy, similar to the type of name hierarchy which appears in computer file systems or in Internet domain names, and a logical mapping of this hierarchy into transport streams, virtual channels, and events. They would make appropriate names in this name hierarchy known to any other content creator who might want to refer to their content. In the case of networks and local affiliates, typically the networks would have a name hierarchy for the events they produce, and the local affiliates would have a name hierarchy for their locally produced events, and independent content providers would also have their own name hierarchies.

An example of a logical name in a logical name URL scheme might be "four-oclock.news.xyz-2.xyz.com".

In this example "xyz.com" might correspond to a transport stream, "xyz-2" might correspond to a channel within that transport stream, and "four-oclock.news" might refer to an event within that channel.

3. Translation Mechanism

Ideally there would be provisions for translation records to be included in system information at the transport stream level or at the program level. This obviously makes no difference in terms of bandwidth required, but it might simplify management of the translation tables in situations where transport streams are being split apart into individual programs and recombined in different combinations.

Each broadcaster broadcasts translation records for the name space of the providers of the content it is broadcasting (certainly the content it is broadcasting now, and perhaps the content it will be broadcasting for some time into the future, perhaps 12 hours or so). The content providers provide translation tables which have placeholders for the transport stream, channel, event (and elementary stream if needed). These translation records are then adjusted by the broadcasters to provide the correct translations in the context of their particular broadcast before inserting them into the broadcast. A convention could be adopted that the placeholders can be left unchanged, with the interpretation that this means "this one". Such a convention would be very useful in many situations.

To reduce the number of translation records which must be stored in a DTV receiver’s cache, there are two types of translation records. There are “A” records which tell where in the broadcast stream a named resource can be found, and there are “R” records which tell where in the broadcast stream the “A” records can be found for names further down the name hierarchy. Typically the “A” records would appear for names at the bottom of the hierarchy, and “R” records would appear for names in the higher levels of the hierarchy. The table below illustrates this concept.
 

Record Type	Logical Name	Translation	Explanation
A	xyz.com	T1	Transport stream xyz.com is T1.
R	xyz.com	T1	Translation records for names ending in xyz.com are in transport stream T1.
A	movies.xyz.com	T1.S2	Channel movies.xyz.com is T1.S2.
R	movies.xyz.com	T1.S2	Translation records for names ending in movies.xyz.com are in channel T1.S2.
A	Force10.action.movies.xyz.com	T1.S2.E1	Event with given logical name is T1.S2.E1.
A	HighNoon.western.movies.xyz.com	T1.S2.E2	Event with given logical name is T1.S2.E2.
A	Dumbo.other.movies.xyz.com	T1.S2.E3	Event with given logical name is T1.S1.E3.
A	general.xyz.com	T1.S3	Channel general.xyz.com is T1.S3.
R	general.xyz.com	T1.S3	Translation records for names ending in general.xyz.com are in channel T1.S3
A	four-oclock.news.general.xyz.com	T1.S3.E1	Event with given logical name is T1.S3.E1.
A	Mon-NFL.sports.general.xyz.com	T1.S3.E2	Event with given logical name is T1.S3.E2.

  
Thus, DTV receivers only need to scan periodically all the transport streams they can receive and cache the top level “R” records. These enable them to pick up the lower level translation records from the broadcast streams as needed. The need to scan the transport streams periodically for the higher level records is not overly burdensome. For one thing the DTV receivers need to scan the transport streams every few hours for other system and program information in any case. For another thing, the higher level records are likely to be very stable, so they will not need updating frequently.

The provision for "R" records gives flexibility for where the translation records appear in the broadcast. A cable operator might put all of them in a separate, dedicated channel.

Note also from the example that there does not have to be a one-to-one correspondence between components of the logical name and components of the direct address. It can be a many-to-one mapping in either direction, or even a many-to-many mapping.

There are also a lot of syntactical gimmicks which can be used to conserve bandwidth when transmitting these records. It is clear from the example that there will often be "A" records and "R" records with the same values for both logical name and direct address. These can be combined into a single record with some designator showing that it is both an "A" and "R" record. There will often be multiple translation records containing a common portion of both logical name and associated direct address. These could be transmitted with a syntax which only contains the common portions once.

Note that with this translation mechanism the same URI based on a logical name could be correctly translated into a direct address by ATSC receivers in different parts of the world, DVB receivers in different parts of the world, and potentially even by NTSC receivers.

Note that with this translation mechanism it will often be possible for an ordinary "http:" URI to be interpreted as a reference to a resource in a broadcast environment, as long as the broadcaster is broadcasting the resource with the right <path> (e.g., in an object carousel) and is providing the right translation records for the <host> portion. The <protocol> portion of a URI is advisory only. (This is explicitly stated on page 3 of RFC 2396.) There is nothing which prevents a DTV receiver from taking an "http:" URI and attempting to resolve the <host> portion as if it were a "dtv:" URI. How does a receiver decide when to do this? If it has no Internet connection, the choice is easy. Otherwise it might depend on which source the receiver thinks will be faster. 

References: