| Network Working Group | M. McRoberts, Ed. |
| Internet-Draft | British Broadcasting Corportation |
| FYI: 7 | A. Adolf |
| Intended status: Informational | Condition-ALPHA |
| Expires: March 08, 2012 | September 05, 2011 |
Uniform Resource Identifier (URI) Scheme for Digital Video Broadcasting (DVB) Programme Resources
draft-mcroberts-uri-dvb-07
Uniform Resource Identifier (URI) schemes for broadcasting programme resources transmitted over MPEG-2 Transport Streams [MPEG-Systems] 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], OCAP [OCAP1.0] or other XML based metadata.
These URI are used to locate the actual digital TV, Radio or other multimedia broadcast programme services (i.e., channels or events) and also the audio-visual components related to that programme, for example an HTTP-based programme guide on the Web or other XML-based electronic programme guides in digital broadcast receivers.
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.
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 March 08, 2012.
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.
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] 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] 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], have been widely available in recent years. Each broadcast programme and component (i.e. audio-visual and generic data components) are identifiable within the MPEG-2 Transport Stream. Beyond digital broadcast, television and radio programmes can be delivered to receivers over an IP-based network within MPEG-2 Transport Stream packets.
The Electronic Programme Guide (EPG) service for television and radio programmes which allows people to find and select programmes must be able to identify a given programme in a canonical form. As programme guides are increasingly being made available on the Web, and on-device programme guides are taking advantage of Internet connectivity, and as receiving devices are increasingly able to present programmes delivered both via digital broadcast and a variety of IP-based protocols, the the use of URIs to identify programmes is an obvious pragmatic choice.
This document defines the Uniform Resource Identifier (URI) schemes for broadcast programme resources over MPEG-2 Transport Stream [MPEG-Systems] for DVB services, conforming to the generic URI syntax [RFC3986] to aid in interoperability with existing IP-based services.
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.
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 multiplexed packet, elementary stream component, transport stream and transmission network is assigned and transmitted over the satellite, cable or terrestrial broadcasting media, or over an IP network, together with an information table which describesthese assigned numbers, as described by the MPEG-2 standard [MPEG-Systems].
+---------------------------------------------------+
| BROADCASTING NETWORK |
| (e.g. Satellite, Cable, Terrestrial) |
| +---------------------------------------+ |
| | TRANSPORT STREAM MULTIPLEX |-* |
| | (e.g. channel) | | |
| | +-----------------------------+ | | |
| | | SERVICE |-* | | |
| | | +---------------------+ | | | | |
| | | | Audio/Visual and |-* | | | | |
| | | | Private Data | | | | | | |
| | | | Components | | | | | | |
| | | +---------------------+ | | | | | |
| | | *---------------------* | | | | |
| | | | | | | |
| | +-----------------------------+ | | | |
| | *-----------------------------* | | |
| | | | |
| +---------------------------------------+ | |
| *---------------------------------------* |
| |
+---------------------------------------------------+
These elements are unambiguously identified in DVB systems through numerical identifiers:
+---------+
| |-------+
| | >+++++ 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. In this case, the original_network_id of all the TS will be equal to the network_id, and this typically occurs on networks operated by public broadcasters. If one of the public broadcaster's transport streams is, for example, re-transmitted by a cable operator, the information about this stream would containe the cable operator's network_id, and the original_network_id of the public broadcaster.
Thus, all assigned network_id values must correlate with actual broadcast infrastructure, whereas this is not required for original_network_id values which have a more logical basis. A globally active content provider may for example choose to register an original_network_id, and distribute pre-multiplexed transport stream to broadcasters, without operating any broadcast network of its own.
The assignment of values for both 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 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 (and, to an extent, the design of MPEG-2), some relationships exist between these identifiers:
During the process of performing a "service scan", a receiver will capture the identifying information contained within the transport streams and store their transport_stream_id, original_network_id and network_id, as well as the service_id values of all of the services carried within that transport stream. As each radio frequency channel is scanned, the receiver constructs a table correlating each of these tuples with the radio frequency channels and other modulation parameters, such that when it is required to switch to specific service within a transport stream, it can tune the radio receiver appropriately. Within the context of [DVB-IPTV], of course, there are no radio frequencies, however the same model of broadcasters, networks and services is maintained and the same identifiers are used with the same semantics.
A DVB service is composed of one or more components. These are identified within the context of a 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-TVA] and [DVB-MHP]). Each of these components is sliced into fragments and packetised in TS packets [MPEG-Systems]. All packets for a given component are labeled with the same TS Packet Identifier (PID), effectively providing a virtual channel within the TS for that component. The packets are time-division multiplexed according to each component's data rate requirements for broadcast.
...|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. Similarly, all TS packets for "a2" would also share a different PID value, and so on. The metadata describing the network, transport streams, services, and their components is transmitted within a TS using well-known PID values according to [MPEG-Systems] and [DVB-SI-SPEC]. These metadata TS packets are not shown in the above figure for clarity.
The DVB URI is defined by [DVB-URI], 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:
This section details the components of the syntax. The syntax also makes use of components defined in [RFC3986] and [RFC5234]. These are not reproduced here for brevity. Future revisions of [DVB-URI] and related specifications may add additional syntax elements or otherwise extend the dvb URI scheme to support emerging DVB-based applications.
This URI scheme is in conformance with the generic URI syntax [RFC3986] and uses the registry-based naming authority version of that. It takes the form:
DVB-URL = dvb-scheme ":" dvb-path
dvb-scheme = "dvb"
dvb-path = ( "//" ( dvb-net-entity [ path-absolute ] ))
/ ( "//" dvb-app-entity )
/ path-absolute
When the dvb-path part only consists of a path-absolute, the URI refers to a file in the default object carousel within the current DVB service. The "current" service is dependent on the usage context.
The dvb-scheme name represents the transmission system using the MPEG-2 standard in the digital broadcasting service in accordance with Section 3.1 of [RFC3986].
In this definition "dvb" represents the DVB system which is based on [BT.1306], [BO.1516], [J.83], and [DVB-IPTV].
A dvb-net-entity uniquely identifies an originator, transport stream, service, event or component within the DVB system, either by way of numeric identifiers or through the use of textual service identifiers (some of which are pre-defined, while others may be advertised within the system). The dvb-net-entity may also refer to a specific DVB carousel, or include a timed event constraint.
The general syntax of the dvb-net-entity is:
dvb-net-entity = transport-stream / service-entity
transport-stream = original-network-id "." transport-stream-id
service-entity = dvb-service [ "." component-set [ "$" carousel-id ]]
[ event-constraint ]
dvb-service = ( original-network-id "." [ transport-stream-id ] "." service-id )
/ ( "'" textual-service-identifier "'" )
original-network-id = hex-string
transport-stream-id = hex-string
service-id = hex-string
textual-service-identifier = reg-name
carousel-id = hex-string
hex-string = 1*HEXDIG
The dvb-net-entity, if present, may identify one the following:
The component-set referenced in the syntax above is used to identify one or more components of a service and takes the form:
component-set = component-tag-set
/ qualified-component-set
/ fully-qualified-component-set
component-tag-set = component-tag *( "&" component-tag )
component-tag = hex-string
qualified-component-set = qualified-component *( "&" qualified-component )
qualified-component = component-type "=" component-id
component-type = "video" / "audio" / "data" / "subtitle"
/ "teletext" / "dvbst"
component-id = component-tag / iso639-language-code
/ "default" / "current"
/ "hearing_impaired" / "visually_impaired"
/ "none"
fully-qualified-component-set = fully-qualified-component
*( "&" fully-qualified-component )
fully-qualified-component = "fqc=" stream-content-and-component-type
"," component-tag
[ "," iso639-language-code ]
stream-content-and-component-type = hex-string
iso639-language-code = 3ALPHA
An event-constraint identifies an event occurring within a service:
event-constraint = ( event-ref [time-constraint] )
/ time-constraint
event-ref = ";" [ event-id ] [ ";" tva-id ]
event-id = hex-string
tva-id = hex-string
time-constraint = "~" time-duration
time-duration = start-time "--" duration
start-time = date "T" time "Z"
duration = "PT" hours "H" minutes "M" [ seconds "S" ]
date = year month day
time = hours minutes [ seconds ]
year = DIGIT DIGIT DIGIT DIGIT
month = DIGIT DIGIT
day = DIGIT DIGIT
hours = DIGIT DIGIT
minutes = DIGIT DIGIT
seconds = DIGIT DIGIT
An event may be identified by its event-id, a TV-Anytime tva-id, a start-time and duration according to UTC, or a combination of some or all of the three.
A dvb-app-entity is a specific form of DVB entity identifier which is used in interactive applications, and takes the form:
dvb-app-entity = ( "current" [ ( ".audio" / ".video" / ".av" ) ] )
/ "original"
/ ( ( "current" / dvb-service ) ".ait/" ait-abs-path )
ait-abs-path = "app-root" / ait-application
ait-application = org-id-part "." app-id-part [ "?" ait-params ]
ait-params = "arg_" 1*DIGIT "=" *uric [ "&" ait-params ]
org-id-part = lowposhex-string
app-id-part = lowposhex-string
lowposhex-string = lowposhex *lowhex
lowhex = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
posdigit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
lowposhex = posdigit / "a" / "b" / "c" / "d" / "e" / "f"
DVB interactive applications are Java Xlets that are carried in the broadcast signal. Terminals extract and then execute these Xlets. They are advertised inside the broadcast signal in the Application Information Table (AIT). The dvb-app-entity can thus refer to such application advertisements in its ".ait/" form. In its other forms, the dvb-app-entity refers to a DVB service or components thereof which are used in conjunction with the currently running application. For further information, please see [DVB-MHP].
Section 5 of [DVB-URI] 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."
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-equipped clients -- i.e. with a suitable tuner card and software installed (Open Source tools including 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.
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].
The resolution process is determined through the 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:
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, three mechanisms of conveying such resolution information are currently defined by DVB:
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:
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] 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]. 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]. 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.
Conforming to section 7.4 of [RFC3978], 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.
These examples make heavy use of the identifiers defined by DVB to identify entities. Please see Section 1 for an explanation of the concepts.
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.
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.
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]. 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-DATA] 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-MHP] defines - among other things - how interactive applications can make use of audiovisual or other multimedia services and service components.
This specification requests the IANA provisionally register the "dvb" URI scheme as specified in this document and summarized in the following template, per [BCP115]:
Section 7 of [RFC3986] 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.
| [RFC3986] | Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. |
| [RFC3978] | Bradner, S., "IETF Rights in Contributions", RFC 3978, March 2005. |
| [DVB-URI] | DVB Project, "Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for DVB Systems", ETSI TS 102 851, . |