Uniform Resource Identifier (URI) Scheme for Digital Video Broadcasting (DVB) Programme Resources
draft-mcroberts-uri-dvb-05

Abstract

Uniform Resource Identifier (URI) schemes for broadcasting programme resources transmitted over MPEG-2 Transport Streams [MPEG‑Systems] (Society of Motion Picture and Television Engineers, “Information technology -- Generic coding of moving pictures and associated audio information: Systems,” December 2000.) have been devised in their process of creating standards by the Digital Video Broadcasting Project (DVB), the Association of Radio Industries and Businesses in Japan (ARIB) and the OpenCable Application Platform (OCAP) to acquire current and future scheduled publications of broadcast media content from multimedia applications such as HTTP, MHP [DVB‑MHP] (DVB Project, “Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1,” .), OCAP [OCAP1.0] (CableLabs, “OpenCable Application Platform (OCAP) specification, I16,” .) or other XML based metadata.

These URI locate the actual digital TV, Radio or other multimedia broadcast programme service (i.e. channel or event) and the audio-visual components conforming to that programme for e.g. a HTTP based programme guide in the internet or other XML based programme guides in digital broadcast set-top boxes.

This document defines the "dvb" URI scheme for the benefit of the Internet community, given its definition as part of the Digital Video Broadcasting (DVB) suite of ETSI standards.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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 “work in progress.”

This Internet-Draft will expire on July 9, 2011.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

1.  Introduction

Standards governing televisions, set-top boxes and other consumer electronics devices have for some time been developed with the Internet in mind. The use of Universal Resource Identifiers (URIs) [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) is now commonplace, including for the purpose of identifying resources delivered by way of terrestrial, satellite and cable broadcasts.

For this purpose, a URI scheme was developed as part of the Digital Video Broadcasting (, “DVB Project,” .) [DVB] suite of standards specifically for the purpose of identifying broadcasts delivered by way of DVB-compliant broadcasting systems.

With the advent of digital broadcasting, digital multimedia broadcast services to the home, based on MPEG-2 Transport Streams [MPEG‑Systems] (Society of Motion Picture and Television Engineers, “Information technology -- Generic coding of moving pictures and associated audio information: Systems,” December 2000.) have been widely available in recent years. Each broadcasting programme and composing components (i.e. audio-visual and generic data components) are identifiable in the MPEG-2 Transport Stream. TV/Radio broadcasting programmes within MPEG-2 Transport Stream packets can be delivered over an IP network as well as over a digital broadcast network.

The EPG (Electronic Programme Guide) service for TV/Radio programmes by which people are able to search-select and acquire the favorite programme, must be able to locate selected programme or service in a canonical form. This programme guide is now available on web servers through the internet or im metadata services within the digital broadcasting service to identify the actual broadcast programme material for such advanced broadcasting services.

This document defines the Uniform Resource Identifier (URI) schemes for broadcast programme resources over MPEG-2 Transport Stream [MPEG‑Systems] (Society of Motion Picture and Television Engineers, “Information technology -- Generic coding of moving pictures and associated audio information: Systems,” December 2000.) for DVB services, in conformance with the generic URI syntax [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) to have a high affinity with IP networks.

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of over 270 broadcasters, manufacturers, network operators, software developers, regulatory bodies and others in over 35 countries committed to designing global standards for the global delivery of digital television and data services. Services using DVB standards are available on every continent with a total of more than 500 million DVB receivers already deployed. More information on DVB can be found on their website at http://www.dvb.org

This URI specification is for a permanent assignment.

1.1.  Transmission Scheme

The audio, visual or private data components constituting a TV/radio programme ("service") are defined as elementary stream (ES) components. Several of these TV/radio programmes are bundled in a transport stream (TS) multiplex for delivering over a broadcast transmission network (e.g. satellite, cable or terrestrial). The distinguished unique number for each TS mux packet, elementary stream component, transport stream and transmission network is assigned and transmitted over the satellite, cable or terrestrial broadcasting media, even over the IP network, together with the information table which describes these assigned numbers in the form of MPEG-2 standard [MPEG‑Systems] (Society of Motion Picture and Television Engineers, “Information technology -- Generic coding of moving pictures and associated audio information: Systems,” December 2000.).

+---------------------------------------------------+
| BROADCASTING NETWORK                              |
| (e.g. Satellite, Cable, Terrestrial)              |
|    +---------------------------------------+      |
|    | TRANSPORT STREAM MULTIPLEX            |-*    |
|    | (e.g. channel)                        | |    |
|    |   +-----------------------------+     | |    |
|    |   | SERVICE                     |-*   | |    |
|    |   |  +---------------------+    | |   | |    |
|    |   |  | Audio/Visual and    |-*  | |   | |    |
|    |   |  | Private Data        | |  | |   | |    |
|    |   |  | Components          | |  | |   | |    |
|    |   |  +---------------------+ |  | |   | |    |
|    |   |    *---------------------*  | |   | |    |
|    |   |                             | |   | |    |
|    |   +-----------------------------+ |   | |    |
|    |     *-----------------------------*   | |    |
|    |                                       | |    |
|    +---------------------------------------+ |    |
|      *---------------------------------------*    |
|                                                   |
+---------------------------------------------------+

All these elements are unambiguously identified in DVB systems by numerical ids:

• A network_id identifies a broadcast transmission network. On satellite and IP broadband, typically one network_id corresponds to an operator. On cable and terrestrial, where different radio frequencies might be used in different regions, operators typically use one network_id per such region.
• An original_network_id is used where TV/radio programmes are taken from one network, and are re-transmitted on another one. To enable receivers detecting that a programme is identical to another one, the original_network_id is used to indicate from which network the programme originates.
• A transport_stream_id is used to refer to a time-domain multiplex of several programmes carried in TS packets. One or more multiplexes can be transmitted on any given radio frequency in a DVB network.
• A service_id identifies a TV/radio or data programme within a TS multiplex. The number of programmes is limited by the capacity of the underlying physical channel.
• A component_tag identifies an elementary stream (ES) of video, audio, teletext, subtitles, or other data within a service.

+---------+
|         |-------+
|         |       >+++++ Service 1 +++++
|         >  TS 1 |
|         |       >***** Service 2 *****
|  NET 1  |-------+
|         |-------+
|         |       >===== Service 3 =====
|         >  TS 2 >xxxxx Service 4 xxxxx
|         |       >##### Service 5 #####
|         |-------+
+---------+

The original_network_id is an attribute of a transport stream (TS). In the simplest case, all services originate from the network on which they are transmitted. Then, the original_network_id of all the TS will be equal to the network_id. This typically happens on networks operated by public broadcasters. If one of the public broadcaster's TS is for instance re-transmitted by a cable operator, the information about this TS would indicate the cable operator's network_id, and the original_network_id of the public broadcaster. Hence all assigned network_id values must represent actual broadcast network infrastructures, whereas this is not required for original_network_id values. A globally active content provider may for example choose to register an original_network_id, and distribute pre-multiplexed TS to broadcasters, without operating any broadcast network of its own.

Both, the original_network_id and the network_id are coordinated by the DVB Project. The DVB Project in turn has delegated the management of DVB identifiers to DVB Services Sàrl [DVB‑SVCS] (, “DVB Services Sàrl,” .). DVB Services maintains a public register of all assignments, and accepts requests for new assignments on their website.

Due to the way broadcast transmission networks are operated, some relationships exist between these identifiers:

• Each TS is part of exactly one orginial_network_id (see above).
• Hence, each TS is unambiguously identified by the tuple {original_network_id, transport_stream_id}.
• According to [DVB‑SI‑SPEC] (DVB Project, “Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems,” .), each service_id is unique within a TS. Hence a service is unambiguously identified by the tuple {original_network_id, transport_stream_id, service_id}.
• [DVB‑SI‑GDL] (DVB Project, “Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service Information (SI),” .) additionally requires that each service_id be unique within an original_network_id. Hence, in areas where [DVB‑SI‑GDL] (DVB Project, “Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service Information (SI),” .) has been made part of the broadcast profile, the tuple {original_network_id, service_id} unambiguously identifies a service.

During a scan run, a receiver will pick up information about TS. It will learn their transport_stream_id, original_network_id and network_id. Since it scans different radio frequency channels, it is able to link these identifiers to radio frequencies and other modulation parameters. On [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .), of course no radio frquencies are used. The model of broadcasters, networks, and services is however maintained. Hence a [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .) receiver uses the same identifiers with the above semantics to identify services.

Finally, a DVB service is composed of one or more components. These are identified within the service by their component_tag. A component can be either an elementary stream (ES) carrying video, audio, teletext, subtitles, or other synchronised data, or generic data (see also [DVB‑DATA] (DVB Project, “Digital Video Broadcasting (DVB); DVB specification for data broadcasting,” .), [DVB‑TVA] (DVB Project, “Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime information in DVB transport streams,” .) and [DVB‑MHP] (DVB Project, “Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1.1,” .)). Each of these components is then sliced into fragments and packetised in TS packets [MPEG‑Systems] (Society of Motion Picture and Television Engineers, “Information technology -- Generic coding of moving pictures and associated audio information: Systems,” December 2000.). All packets for a given component are labeled with the same TS packet identifier (PID), effectively providing a virtual channel in the TS for the component. All packtes are then multiplexed in the time domain according ot each component's data rate requirements, and the resulting TS is passed to the transmission equipment. For examples how these identifiers are used, please refer to Section 2.5 (Examples).

 ...|v|v|v|a|t|v|v|v|v|v|a|s|v|v|a|v|v|t|a|v|v|...
    |1|1|1|1|1|2|2|2|2|2|2|2|1|1|1|2|2|1|2|1|2|
---------------------------------------------------->
                                                time
 |x| : a TS packet
 |x|

 v1, a1, t1: SD video, audio and teletext of service 1
 v2, a2, s2: HD video, audio and subtitles of service 2

In the above figure, all TS packets for "v1" would share the same PID value. Equally, all TS packets for "a2" would also share another PID value, etc. The metadata describing the network, transport streams, services, and their components is transmitted in a TS on well-known PID values according to [MPEG‑Systems] (Society of Motion Picture and Television Engineers, “Information technology -- Generic coding of moving pictures and associated audio information: Systems,” December 2000.) and [DVB‑SI‑SPEC] (DVB Project, “Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems,” .). These metadata TS packets are not shown in the above figure.

2.  Digital Video Broadcasting URI Scheme

The DVB URI is defined by [DVB‑URI] (DVB Project, “Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for DVB Systems,” .), and that shall be considered the authoritative source of the definition of the scheme-specific-part of the DVB URI.

URIs employing the dvb scheme are URLs. DVB URLs may refer to any of the following kinds of resource:

• A DVB service
• Components within a DVB service (such as an audio or video stream)
• An event (for example, a programme)
• A transport stream
• A file contained within a DSM-CC object carousel
• Interactive applications

2.1.  Syntax

This URI scheme is in conformance with the generic URI syntax [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.). It takes the form:

MPEG-2_TS_URI       = transmission_scheme ":" path

transmission_scheme = "dvb"

path                = [ "//" broadcast_auth_domain ] comp_path

2.1.1.  transmission_scheme

The transmission_scheme name represents the transmission system using the MPEG-2 standard in the digital broadcasting service in accordance with Section 3.1 of [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).

In this definition "dvb" represents the DVB system which is based on [BT.1306] (International Telecommunication Union, “Error-correction, data framing, modulation and emission methods for digital terrestrial television broadcasting,” October 2000.), [BO.1516] (International Telecommunication Union, “Digital multiprogramme television systems for use by satellites operating in the 11/12 GHz frequency range,” April 2001.), [J.83] (International Telecommunication Union, “Digital multi-programme systems for television, sound and data services for cable distribution,” April 1997.), and [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .).

2.1.2.  broadcast_auth_domain

The broadcast_auth_domain includes the unique number to which a government authority or approved organization govern for the sake of preserving uniqueness. Hence broadcast_auth_domain allows to identify a specific broadcasting company or service in the digital broadcasting network. The unique number in broadcast_auth_domain consists of a sequence of characters separated by ".", which is preceded by a double slash ("//") and optionally terminated by a slash ("/").

broadcast_auth_domain = 0*255 ( unreserved | sub-delims )

unreserved            = ALPHA | DIGIT | "-" | "." | "_" | "~"

sub-delims            = "!" | "$" | "&" | "'" | "(" | ")" |
                        "*" | "+" | "," | ";" | "="

This broadcast_auth_domain consists of a unique name in the digital broadcasting network conforming to the URI.

2.1.3.  comp_path

The comp_path indicates the unique identification of the audio, visual and data component(s) constituting a broadcast programme or event. It can also be structured in hierarchical or non-hierarchical form to identify particular programmes of a service. It is assigned in each broadcasting company or authority for preserving uniqueness in a sequence of TV/radio programmes in one service. The broadcast_auth_domain identifies the broadcast programme (e.g. channel or specific programme event) and comp_path determines the component(s) of the broadcasting programme.

comp_path consists of a sequence of characters, optionally separated by a slash ("/"), to indicate the audio, visual and data component(s) within the scope of the broadcast authority indicated in the broadcast_auth_domain.

comp_path = *( "/" segment )

segment   = *pchar

pchar     = unreserved | pct-encoded | sub-delims | ":" | "@"

2.2.  Encoding

Section 5 of [DVB‑URI] (DVB Project, “Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for DVB Systems,” .) specifies that:

"All characters not within the range of characters allowed in a URI must be encoded into UTF-8 and included in the URI as a sequence of escaped octets. An escaped octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing the octet code."

2.3.  Community Considerations

2.3.1.  Context of Use

The "dvb" URIs are used as references to resources in digitial multimedia programmes, most often within the context of DVB itself: interactive television applications use them in order to locate resources and to reference services and programmes. These are typically broadcast via satellite, cable and terrestrial systems, but may also be retrieved on-demand from a server via the Internet. Providers of such broadcast services may e.g. reference programmes in the broadcast from an Electronic Programme Guide (EPG) which is published on their web- site. On another example, the metadata which is part of the multimedia broadcasts can also contain such URIs to establish hyperlinks between broadcast services. This might for instance include multi-angle video services (e.g. for sports events). Users of suitably equipepd clients - i.e. with a suitable tuner card and software installed (Open Source tools include e.g. http://www.linuxtv.org/ and http://www.mythtv.org/) - are able to exchange such URIs (e.g. via an instant messaging service or email) to provide each other clickable hyperlinks to multimedia content they deem of interest.

DVB has published specifications for the distribution of multimedia services via IP unicast and multicast mechanisms. In this context, such URIs are usable in any player client software (no tuner card required) that implements the respective protocols and has the relevant audio and video codecs installed.

• For example, a receiver connected to a local area network might allow other devices to query it for information regarding the current programme or service: in this context, a dvb URI would typically be the most authoritative single identifier which could be used to to refer to that programme.
• Similarly, a web service can be implemented by a platform operator or a broadcaster (or some party working on their behalf) which allows resolution of dvb URIs - this would allow a device to retrieve web pages or other content which relate to the current programme (or some other entry in the device's Electronic Programme Guide).

Implementing such a system naturally requires some mechanism for devices to discover an appropriate resolution service. DVB has developed has developed a service discovery and selection (SD&S) solution as part of [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .).

2.3.2.  Resolution Considerations

The resolution is determined through the process of development of DVB standards by the Digital Video Broadcasting Project (DVB).

Since the implementations envisaged cover a wide range of devices with quite different access methods and capabilities, no single resolution or delegation mechanism can be referenced in this document.

Currently 2 client system classes are covered by DVB specifications:

• A broadcast set-top box which only has a unidirectional, receive-only connection. Hence all DVB URIs need to be resolvable from the service discovery information received in the broadcast stream.
• A "home network end device" (HNED) which could be an IPTV set-top box, networked TV or personal digital recorder with an Ethernet or WLAN connection to a home gateway device.

Further device classes will be addressed as DVB standardisation progresses. The dvb URIs must however remain valid. DVB will define appropriate resolution mechanisms to ensure that DVB URIs remain valid for those new device classes as well.

For the two above example device classes, 3 ways of conveying such resolution information are currently defined by DVB:

• Repeated, cyclic transmission of service discovery information as auxiliary data in digital TV broadcast streams over satellite, cable or terrestrial transmissions according to [DVB‑SI‑SPEC] (DVB Project, “Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems,” .), [DVB‑DATA] (DVB Project, “Digital Video Broadcasting (DVB); DVB specification for data broadcasting,” .) and [DVB‑TVA] (DVB Project, “Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime information in DVB transport streams,” .).
• Repeated, cyclic multicast transmission of SD&S Records via the DVBSTP protocol according to [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .).
• Unicast delivery of SD&S Records in response to HTTP "GET /dvb/sdns" requests according to [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .).

2.3.3.  Implementation Considerations

2.3.3.1.  Considerations for resolution server software

With on-going development of DVB standards, DVB will establish requirements and seek candidates for operating resolution servers as appropriate.

To boot-strap the resolution process, a DVB client needs to discover an entry point (or set of) from which to obtain an initial Service Discovery and Selection XML record:

• By default, the service discovery information is provided on the IANA registered well-known port dvbservdsc (port number 3937) via tcp and udp (see http://www.iana.org/assignments/port-numbers) on the IANA registered well-known multicast addresses 224.0.23.14 (DvbServDisc on IPv4) and FF0X:0:0:0:0:0:0:12D (DvbServDisc on IPv6).
• As set forth in [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .), a list of non-default Service Discovery and Selection (SD&S) entry points addresses may also be provided via DNS based on the service location resource record (SRV RR) [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.). The service name for DVB services is "_dvbservdsc", the protocol may be tcp or udp, while the rest of the name is the domain name maintained by DVB for service discovery. This domain name is set to "services.dvb.org". The DVB organization will maintain the services.dvb.org domain name for service discovery and new service providers should register with DVB to add them to the DNS SRV list.

2.3.3.2.  Considerations for resolution client software

To obtain the initial Service Discovery and Selection (SD&S) XML record, a client must by default first join the IANA registered well-known multicast addresses 224.0.23.14 (DvbServDisc on IPv4) and/or FF0X:0:0:0:0:0:0:12D (DvbServDisc on IPv6) and try to obtain a boot-strap record from the IANA registered well-known port dvbservdsc (port number 3937) via tcp and udp (see http://www.iana.org/assignments/port-numbers).

To discover non-default entry points addresses, [DVB‑IPTV] (DVB Project, “Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks,” .) defines that a list of Service Discovery and Selection (SD&S) entry points addresses may be acquired via DNS according to the service location resource record (SRV RR) [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.). The service name is "_dvbservdsc", the protocol may be tcp or udp, while the rest of the name is the domain name maintained by DVB for service discovery. This domain name is set to "services.dvb.org". So the lookup shall be either "_dvbservdsc._tcp.services.dvb.org" or "_dvbservdsc._udp.services.dvb.org". This requires that the terminal support an SRV cognizant DNS client and according to the specification in [RFC2782] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.). The DVB organization will maintain the services.dvb.org domain name for service discovery. HTTP servers will be found via the tcp protocol method whilst the multicast addresses will be found via the udp protocol method.

2.4.  Rights to Use Trademarks

Conforming to section 7.4 of [RFC3978] (Bradner, S., “IETF Rights in Contributions,” March 2005.), the DVB Project who is the holder of various trademark and logo rights amongst others but not limited to the term "dvb", hereby grants IETF a perpetual license to use any such trademarks or service marks solely in exercising its rights to reproduce, publish and modify this IETF contribution. This license does not authorize any IETF participant to use any trademark or service mark in connection with any product or service offering, but only in the context of IETF Documents and discussions.

2.5.  Examples

These examples make heavy use of the identifiers defined by DVB to identify entities. Please see Section 1 (Introduction) for an explanation of the concepts.

2.5.1.  Referring to transport streams and services

In the below examples, a receiver uses the identifiers in the URI to search its internal database of radio frequencies and modulation parameters, which it built during a service scan run. It uses the identifiers as keys to look up in the various tables.

dvb://233a.1041

The DVB transport stream multiplex with id 0x1041 and with original network id 0x233a. This might be used by a broadcaster to provide an entry point to its service offering, without picking out any of his services in particular.

dvb://233a.1041.10bf

The DVB service with id 0x10bf in the DVB transport stream with id 0x1041 and with original network id 0x233a. This could be used as the link behind a "watch this now" button.

dvb://233a..10bf

The DVB service with id 0x10bf and with original network id 0x233a. This could be used as the link behind a "watch this now" button. Note that compared to the previous example the transport stream id is omitted. This is possible in areas where [DVB‑SI‑GDL] (DVB Project, “Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service Information (SI),” .) is applicable.

dvb://'MetroTV'

The DVB service named "MetroTV". Note that as opposed to the previous example, the reference to the service's name is not necessarily unambiguous and requires more contextual information to be resolved. For "speaking" or "promotional" URIs, [DVB‑TVA] (DVB Project, “Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime information in DVB transport streams,” .) might be a more general alternative.

2.5.2.  Referring to service components

In addition to referring to a TV/radio programme as a whole, it might be desirable to be able to pick out specific variations of audio and video provided by a programme. One could for instance always be interested in the video with open signing, or in the audio for the visually impaired.

dvb://233a.1041.10bf.audio=fra

The default video stream and the French language audio stream in the indicated DVB service.

dvb://233a.1041.10bf.audio=qaa&subtitles=eng

The default video stream, the original language audio stream, and the English language subtitle stream in the indicated DVB service.

dvb://233a.1041.10bf.video=default&audio=visually_impaired

The default video stream and the audio stream for the visually impaired in the indicated DVB service.

dvb://233a.1041.10bf.fqc=50B,3&fqc=640,5,fra

The HD video stream (stream_content 0x5 and component_type 0x0B) with component_tag 3, and the French language ("fra") HE.AAC audio for the visually impaired (stream_content 0x6 and component_type 0x40) with component_tag 5.

2.5.3.  References for triggering

Applications might want to trigger on the start and/or end of TV/radio programmes. The user might e.g. have set a flag on the programme, so that the receiver will remind him when it begins, or might even automatically switch to the respective service when the programme begins, and back to the previous service whe it is over. Or a user might have selected a programme for recording. These scenarios require that an application has some notion of the start and end times of TV/radio programmes.

Creating accurate recordings of broadcast content is a non-trivial task. For a wider discussion of this, please see [DVB‑TVA] (DVB Project, “Digital Video Broadcasting (DVB); Carriage and signalling of TV-Anytime information in DVB transport streams,” .). Although individual service components can be selected for recording, all components of the service should generally be recorded where appropriate. This would for instance enable to use the original language audio instead of the dubbed version on special playback occasions.

dvb://233a.1004.1044;8fff

Event with id 0x8fff within the indicated DVB service. A receiver would look up the EPG information for the given service, and for the indicated event within that service. The EPG information will contain the wall-clock start time and duration of the programme as published e.g. also in print. Since the actual times of transmission may be different, triggers should only be fired with appropriate lead-in and lead-out times relative to the published EPG times. Receivers can also use additional information in the EPG, in particular the running_status. Not all broadcasters do however manage the running_status reliably or in real-time.

dvb://233a.1004.1044.audio=fra;8fff

French audio version of the event with id 0x8fff within the indicated DVB service. The video would also be implied if it is a TV service. See also previous example.

dvb://233a.1004.1044;8fff~20100706T000315Z--PT00H31M17S

Event with id 0x8fff within the indicated DVB service, starting at 00 hours, 03 minutes and 15 seconds UTC on July, 6th, 2010, lasting for 00 hours, 31 minutes and 17 seconds. This form of the URI can be used to convey more accurate transmission times for the content. The programme may be advertised as starting at 00:00 and ending at 00:30 in the EPG. This extended information in the locator can be used to get a much more accurate trigger for the programme. The lead-in and lead-out times can be reduced to the minimum needed to account for the skews of the local and broadcaster clocks.

2.5.4.  Referring to data objects

[DVB‑DATA] (DVB Project, “Digital Video Broadcasting (DVB); DVB specification for data broadcasting,” .) defines - among other things - an object carousel which can be mounted as a file system. The data for this object carousel is transmitted repeatedly.

dvb://233a.1041.10bf/doc/form.pdf

File in a subdirectory of an object carousel, for which the root object is carried in the default object carousel of the referenced DVB service.

dvb:/image.png

File in root directory of an object carousel, for which the root object is carried in the default object carousel of the current service.

dvb://233a..10bf.3$10a1240f/doc/form.pdf

File in a subdirectory of an object carousel, for which the root object has the transaction id 10a1240f and is carried in the ES with component_tag 3 of the referenced DVB service. Note that compared to the first example the transport stream id is omitted. This is possible in areas where [DVB‑SI‑GDL] (DVB Project, “Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service Information (SI),” .) is applicable.

3.  IANA Considerations

This specification requests the IANA provisionally register the "dvb" URI scheme as specified in this document and summarized in the following template, per [BCP115] (Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes,” February 2006.):

3.1.  DVB Registration Template

URI scheme name:

dvb

Status:

Permanent

URI scheme syntax:

See Section 2 (Digital Video Broadcasting URI Scheme).

URI scheme semantics:

See Section 2 (Digital Video Broadcasting URI Scheme).

Encoding considerations:

Conformance with RFC3986, no special considerations.

Applications/protocols that use this URI scheme name:

dvb URIs are used throughout DVB-compliant broadcasting systems, for example within Freeview and Freesat in the United Kingdom. They are also used in TV-Anytime [TV‑Anytime] (, “TV-Anytime Forum,” .) metadata where it relates to services transmitted by DVB systems.

Interoperability considerations:

None.

Security considerations:

See Section 3.2 (Security Considerations).

Contact:

Name:

Mr. Alexander Adolf

Title:

Chair - DVB TM-GBS working group

Affiliation:

Condition-ALPHA Digital Broadcast Technology

Address:

Gabelsbergerstrasse 60b, 80333 München, GERMANY

Phone:

+4915112722124

Email:

alexander.adolf@me.com

Author/Change controller:

Name:

Mr. Peter Siebert

Title:

Executive Director

Affiliation:

DVB Project

Address:

17a Ancienne Route, 1218 Grand-Sacconnex, SWITZERLAND

Phone:

+41227172717

Email:

siebert@dvb.org

3.2.  Security Considerations

Section 7 of [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) describes general security considerations for URI schemes. The sections relating to reliability and consistency, malicious construction, back-end transcoding, rare IP address formats and semantic attacks all apply to dvb URIs. The section relating to sensitive information does not apply, given that dvb URIs do not contain authentication information.

The security considerations of the Digital Video Broadcasting suite of standards in general are not covered in this document.

4.  References

4.1. Normative References

4.2. Informative References

Authors' Addresses