idnits 2.17.1
draft-mcroberts-uri-dvb-10.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document is more than 15 pages and seems to lack a Table of Contents.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 6 instances of too long lines in the document, the longest one
being 23 characters in excess of 72.
** The abstract seems to contain references ([DVB-MHP], [MPEG-Systems]),
which it shouldn't. Please replace those with straight textual mentions
of the documents in question.
== There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
document.
== There are 2 instances of lines with multicast IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use the 233.252.0.x range defined in RFC 5771
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 658: '...fined. A client MAY attempt resolutio...'
RFC 2119 keyword, line 659: '... multiple suffixes if required, and MAY employ [RFC6762] in order to...'
RFC 2119 keyword, line 669: '...vb.org"). This suffix MAY be used for...'
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 26, 2013) is 4011 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378)
-- Obsolete informational reference (is this intentional?): RFC 4395 (ref.
'BCP115') (Obsoleted by RFC 7595)
Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. McRoberts, Ed.
3 Internet-Draft British Broadcasting Corportation
4 Intended status: Informational A. Adolf
5 Expires: September 27, 2013 Condition-ALPHA
6 March 26, 2013
8 Uniform Resource Identifier (URI) Scheme for Digital Video Broadcasting
9 (DVB) Programme Resources
10 draft-mcroberts-uri-dvb-10
12 Abstract
14 Uniform Resource Identifier (URI) schemes for broadcasting programme
15 resources transmitted over MPEG-2 Transport Streams [MPEG-Systems]
16 have been devised in their process of creating standards by the
17 Digital Video Broadcasting Project (DVB), the Association of Radio
18 Industries and Businesses in Japan (ARIB) and the OpenCable
19 Application Platform (OCAP) to acquire current and future scheduled
20 publications of broadcast media content from multimedia applications
21 such as HTTP, MHP [DVB-MHP], OCAP [OCAP1.0] or other XML based
22 metadata.
24 These URI are used to locate the actual digital TV, Radio or other
25 multimedia broadcast programme services (i.e., channels or events)
26 and also the audio-visual components related to that programme, for
27 example an HTTP-based programme guide on the Web or other XML-based
28 electronic programme guides in digital broadcast receivers.
30 This document defines the "dvb" URI scheme for the benefit of the
31 Internet community, given its definition as part of the Digital Video
32 Broadcasting (DVB) suite of ETSI standards.
34 Status of this Memo
36 This Internet-Draft is submitted in full conformance with the
37 provisions of BCP 78 and BCP 79.
39 Internet-Drafts are working documents of the Internet Engineering
40 Task Force (IETF). Note that other groups may also distribute
41 working documents as Internet-Drafts. The list of current Internet-
42 Drafts is at http://datatracker.ietf.org/drafts/current/.
44 Internet-Drafts are draft documents valid for a maximum of six months
45 and may be updated, replaced, or obsoleted by other documents at any
46 time. It is inappropriate to use Internet-Drafts as reference
47 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on September 27, 2013.
50 Copyright Notice
52 Copyright (c) 2013 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document.
62 1. Introduction
64 Standards governing televisions, set-top boxes and other consumer
65 electronics devices have for some time been developed with the
66 Internet in mind. The use of Universal Resource Identifiers (URIs)
67 [RFC3986] is now commonplace, including for the purpose of
68 identifying resources delivered by way of terrestrial, satellite and
69 cable broadcasts.
71 For this purpose, a URI scheme was developed as part of the Digital
72 Video Broadcasting [DVB] suite of standards specifically for the
73 purpose of identifying broadcasts delivered by way of DVB-compliant
74 broadcasting systems.
76 With the advent of digital broadcasting, digital multimedia broadcast
77 services to the home, based on MPEG-2 Transport Streams
78 [MPEG-Systems], have been widely available in recent years. Each
79 broadcast programme and component (i.e. audio-visual and generic data
80 components) are identifiable within the MPEG-2 Transport Stream.
81 Beyond digital broadcast, television and radio programmes can be
82 delivered to receivers over an IP-based network within MPEG-2
83 Transport Stream packets.
85 The Electronic Programme Guide (EPG) service for television and radio
86 programmes which allows people to find and select programmes must be
87 able to identify a given programme in a canonical form. As programme
88 guides are increasingly being made available on the Web, and on-
89 device programme guides are taking advantage of Internet
90 connectivity, and as receiving devices are increasingly able to
91 present programmes delivered both via digital broadcast and a variety
92 of IP-based protocols, the the use of URIs to identify programmes is
93 an obvious pragmatic choice.
95 This document defines the Uniform Resource Identifier (URI) schemes
96 for broadcast programme resources over MPEG-2 Transport Stream
97 [MPEG-Systems] for DVB services, conforming to the generic URI syntax
98 [RFC3986] to aid in interoperability with existing IP-based services.
100 The Digital Video Broadcasting Project (DVB) is an industry-led
101 consortium of over 270 broadcasters, manufacturers, network
102 operators, software developers, regulatory bodies and others in over
103 35 countries committed to designing global standards for the global
104 delivery of digital television and data services. Services using DVB
105 standards are available on every continent with a total of more than
106 500 million DVB receivers already deployed. More information on DVB
107 can be found on their website at http://www.dvb.org
109 This URI specification is for a permanent assignment.
111 1.1. Transmission Scheme
113 The audio, visual or private data components constituting a TV/radio
114 programme ("service") are defined as elementary stream (ES)
115 components. Several of these TV/radio programmes are bundled in a
116 transport stream (TS) multiplex for delivering over a broadcast
117 transmission network (e.g. satellite, cable or terrestrial). The
118 distinguished unique number for each TS multiplexed packet,
119 elementary stream component, transport stream and transmission
120 network is assigned and transmitted over the satellite, cable or
121 terrestrial broadcasting media, or over an IP network, together with
122 an information table which describesthese assigned numbers, as
123 described by the MPEG-2 standard [MPEG-Systems].
125 +---------------------------------------------------+
126 | BROADCASTING NETWORK |
127 | (e.g. Satellite, Cable, Terrestrial) |
128 | +---------------------------------------+ |
129 | | TRANSPORT STREAM MULTIPLEX |-* |
130 | | (e.g. channel) | | |
131 | | +-----------------------------+ | | |
132 | | | SERVICE |-* | | |
133 | | | +---------------------+ | | | | |
134 | | | | Audio/Visual and |-* | | | | |
135 | | | | Private Data | | | | | | |
136 | | | | Components | | | | | | |
137 | | | +---------------------+ | | | | | |
138 | | | *---------------------* | | | | |
139 | | | | | | | |
140 | | +-----------------------------+ | | | |
141 | | *-----------------------------* | | |
142 | | | | |
143 | +---------------------------------------+ | |
144 | *---------------------------------------* |
145 | |
146 +---------------------------------------------------+
148 Programme Delivery Scheme in MPEG-2 Transport Stream
150 These elements are unambiguously identified in DVB systems through
151 numerical identifiers:
153 o A *network_id* identifies a broadcast transmission network. On
154 satellite and IP broadband, typically one network_id corresponds
155 to an operator. On cable and terrestrial, where different radio
156 frequencies might be used in different regions, operators
157 typically use one network_id per such region.
159 o An *original_network_id* is used where TV/radio programmes are
160 taken from one network and are re-transmitted on another one
161 (noting that a "network" in this context may simply be a different
162 broadcast region for the same operator). The original_network_id
163 is therefore used by receivers as a means of determining
164 equivalence across different networks.
166 o A *transport_stream_id* is used to refer to a time-domain
167 multiplex of several programmes carried in TS packets. One or
168 more multiplexes can be transmitted on any given radio frequency
169 in a DVB network.
171 o A *service_id* identifies a TV, radio or data programme within a
172 TS multiplex. The number of programmes is limited by the capacity
173 of the underlying physical channel.
175 o A *component_tag* identifies an elementary stream (ES) of video,
176 audio, teletext, subtitles, or other data within a service.
178 +---------+
179 | |-------+
180 | | >+++++ Service 1 +++++
181 | > TS 1 |
182 | | >***** Service 2 *****
183 | NET 1 |-------+
184 | |-------+
185 | | >===== Service 3 =====
186 | > TS 2 >xxxxx Service 4 xxxxx
187 | | >##### Service 5 #####
188 | |-------+
189 +---------+
191 Relationship of Network, Transport Stream, and Service
193 The original_network_id is an attribute of a transport stream (TS).
194 In the simplest case, all services originate from the network on
195 which they are transmitted. In this case, the original_network_id of
196 all the TS will be equal to the network_id, and this typically occurs
197 on networks operated by public broadcasters. If one of the public
198 broadcaster's transport streams is, for example, re-transmitted by a
199 cable operator, the information about this stream would containe the
200 cable operator's network_id, and the original_network_id of the
201 public broadcaster.
203 Thus, all assigned network_id values must correlate with actual
204 broadcast infrastructure, whereas this is not required for
205 original_network_id values which have a more logical basis. A
206 globally active content provider may for example choose to register
207 an original_network_id, and distribute pre-multiplexed transport
208 stream to broadcasters, without operating any broadcast network of
209 its own.
211 The assignment of values for both original_network_id and the
212 network_id are coordinated by the DVB Project. The DVB Project in
213 turn has delegated the management of DVB identifiers to DVB Services
214 Sarl [DVB-SVCS]. DVB Services maintains a public register of all
215 assignments, and accepts requests for new assignments on their
216 website.
218 Due to the way broadcast transmission networks are operated (and, to
219 an extent, the design of MPEG-2), some relationships exist between
220 these identifiers:
222 o Each TS is part of exactly one orginial_network_id (see above).
224 o Hence, each TS is unambiguously identified by the tuple
225 {original_network_id, transport_stream_id}.
227 o According to [DVB-SI-SPEC], each service_id is unique within a TS.
228 Hence a service is unambiguously identified by the tuple
229 {original_network_id, transport_stream_id, service_id}.
231 o [DVB-SI-GDL] additionally requires that each service_id be unique
232 within an original_network_id. Hence, in areas where [DVB-SI-GDL]
233 has been made part of the broadcast profile, the tuple
234 {original_network_id, service_id} unambiguously identifies a
235 service.
237 During the process of performing a "service scan", a receiver will
238 capture the identifying information contained within the transport
239 streams and store their transport_stream_id, original_network_id and
240 network_id, as well as the service_id values of all of the services
241 carried within that transport stream. As each radio frequency
242 channel is scanned, the receiver constructs a table correlating each
243 of these tuples with the radio frequency channels and other
244 modulation parameters, such that when it is required to switch to
245 specific service within a transport stream, it can tune the radio
246 receiver appropriately. Within the context of [DVB-IPTV], of course,
247 there are no radio frequencies, however the same model of
248 broadcasters, networks and services is maintained and the same
249 identifiers are used with the same semantics.
251 A DVB service is composed of one or more components. These are
252 identified within the context of a service by their component_tag. A
253 component can be either an elementary stream (ES) carrying video,
254 audio, teletext, subtitles, or other synchronised data or generic
255 data (see also [DVB-DATA], [DVB-TVA] and [DVB-MHP]). Each of these
256 components is sliced into fragments and packetised in TS packets
257 [MPEG-Systems]. All packets for a given component are labeled with
258 the same TS Packet Identifier (PID), effectively providing a virtual
259 channel within the TS for that component. The packets are time-
260 division multiplexed according to each component's data rate
261 requirements for broadcast.
263 ...|v|v|v|a|t|v|v|v|v|v|a|s|v|v|a|v|v|t|a|v|v|...
264 |1|1|1|1|1|2|2|2|2|2|2|2|1|1|1|2|2|1|2|1|2|
265 ---------------------------------------------------->
266 time
267 |x| : a TS packet
268 |x|
270 v1, a1, t1: SD video, audio and teletext of service 1
271 v2, a2, s2: HD video, audio and subtitles of service 2
273 Example TS time domain multiplex
275 In the above figure, all TS packets for "v1" would share the same PID
276 value. Similarly, all TS packets for "a2" would also share a
277 different PID value, and so on. The metadata describing the network,
278 transport streams, services, and their components is transmitted
279 within a TS using well-known PID values according to [MPEG-Systems]
280 and [DVB-SI-SPEC]. These metadata TS packets are not shown in the
281 above figure for clarity.
283 2. Digital Video Broadcasting URI Scheme
285 The DVB URI is defined by [DVB-URI], and that shall be considered the
286 authoritative source of the definition of the scheme-specific-part of
287 the DVB URI.
289 URIs employing the dvb scheme are URLs. DVB URLs may refer to any of
290 the following kinds of resource:
292 o A DVB service
294 o Components within a DVB service (such as an audio or video stream)
296 o An event (for example, a programme)
298 o A transport stream
300 o A file contained within a DSM-CC object carousel
302 o Interactive applications
304 2.1. Syntax
306 This section details the components of the syntax. The syntax also
307 makes use of components defined in [RFC3986] and [RFC5234]. These
308 are not reproduced here for brevity. Future revisions of [DVB-URI]
309 and related specifications may add additional syntax elements or
310 otherwise extend the dvb URI scheme to support emerging DVB-based
311 applications.
313 This URI scheme is in conformance with the generic URI syntax
314 [RFC3986] and uses the registry-based naming authority version of
315 that. It takes the form:
317 DVB-URI = dvb-scheme ":" dvb-path
319 dvb-scheme = "dvb"
321 dvb-path = ( "//" ( dvb-net-entity [ path-absolute ] ))
322 / ( "//" dvb-app-entity )
323 / path-absolute
325 When the dvb-path part only consists of a path-absolute, the URI
326 refers to a file in the default object carousel within the current
327 DVB service. The "current" service is dependent on the usage
328 context.
330 2.1.1. dvb-scheme
332 The dvb-scheme name represents the transmission system using the
333 MPEG-2 standard in the digital broadcasting service in accordance
334 with Section 3.1 of [RFC3986].
336 In this definition "dvb" represents the DVB system which is based on
337 [BT.1306], [BO.1516], [J.83], and [DVB-IPTV].
339 2.1.2. dvb-net-entity
341 A dvb-net-entity uniquely identifies an originator, transport stream,
342 service, event or component within the DVB system, either by way of
343 numeric identifiers or through the use of textual service identifiers
344 (some of which are pre-defined, while others may be advertised within
345 the system). The dvb-net-entity may also refer to a specific DVB
346 carousel, or include a timed event constraint.
348 The general syntax of the dvb-net-entity is:
350 dvb-net-entity = transport-stream / service-entity
352 transport-stream = original-network-id "." transport-stream-id
354 service-entity = dvb-service [ "." component-set [ "$" carousel-id ]]
355 [ event-constraint ]
357 dvb-service = ( original-network-id "." [ transport-stream-id ] "." service-id )
358 / ( "'" textual-service-identifier "'" )
360 original-network-id = hex-string
362 transport-stream-id = hex-string
364 service-id = hex-string
366 textual-service-identifier = reg-name
368 carousel-id = hex-string
370 hex-string = 1*HEXDIG
372 The dvb-net-entity, if present, may identify one the following:
374 o A transport stream (through combination of original_network_id and
375 transport_stream_id)
377 o A service, either through hexadecimal numeric identifiers or
378 through in textual form
380 o An audio, visual, or data component within a service
382 o A carousel contained within a component of a service
384 o An event which occurs within a service
386 2.1.2.1. component-set
388 The component-set referenced in the syntax above is used to identify
389 one or more components of a service and takes the form:
391 component-set = component-tag-set
392 / qualified-component-set
393 / fully-qualified-component-set
395 component-tag-set = component-tag *( "&" component-tag )
397 component-tag = hex-string
399 qualified-component-set = qualified-component *( "&" qualified-component )
401 qualified-component = component-type "=" component-id
403 component-type = "video" / "audio" / "data" / "subtitle"
404 / "teletext" / "dvbst"
406 component-id = component-tag / iso639-language-code
407 / "default" / "current"
408 / "hearing_impaired" / "visually_impaired"
409 / "none"
411 fully-qualified-component-set = fully-qualified-component
412 *( "&" fully-qualified-component )
414 fully-qualified-component = "fqc=" stream-content-and-component-type
415 "," component-tag
416 [ "," iso639-language-code ]
418 stream-content-and-component-type = hex-string
420 iso639-language-code = 3ALPHA
421 2.1.2.2. event-constraint
423 An event-constraint identifies an event occurring within a service:
425 event-constraint = ( event-ref [time-constraint] )
426 / time-constraint
428 event-ref = ";" [ event-id ] [ ";" tva-id ]
430 event-id = hex-string
432 tva-id = hex-string
434 time-constraint = "~" time-duration
436 time-duration = start-time "--" duration
438 start-time = date "T" time "Z"
440 duration = "PT" hours "H" minutes "M" [ seconds "S" ]
442 date = year month day
444 time = hours minutes [ seconds ]
446 year = DIGIT DIGIT DIGIT DIGIT
448 month = DIGIT DIGIT
450 day = DIGIT DIGIT
452 hours = DIGIT DIGIT
454 minutes = DIGIT DIGIT
456 seconds = DIGIT DIGIT
458 An event may be identified by its event-id, a TV-Anytime tva-id, a
459 start-time and duration according to UTC, or a combination of some or
460 all of the three.
462 2.1.3. dvb-app-entity
464 A dvb-app-entity is a specific form of DVB entity identifier which is
465 used in interactive applications, and takes the form:
467 dvb-app-entity = ( "current" [ ( ".audio" / ".video" / ".av" ) ] )
468 / "original"
469 / ( ( "current" / dvb-service ) ".ait/" ait-abs-path )
471 ait-abs-path = "app-root" / ait-application
473 ait-application = org-id-part "." app-id-part [ "?" ait-params ]
475 ait-params = "arg_" 1*DIGIT "=" *uric [ "&" ait-params ]
477 org-id-part = lowposhex-string
479 app-id-part = lowposhex-string
481 lowposhex-string = lowposhex *lowhex
483 lowhex = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
485 posdigit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
487 lowposhex = posdigit / "a" / "b" / "c" / "d" / "e" / "f"
489 DVB interactive applications are Java Xlets that are carried in the
490 broadcast signal. Terminals extract and then execute these Xlets.
491 They are advertised inside the broadcast signal in the Application
492 Information Table (AIT). The dvb-app-entity can thus refer to such
493 application advertisements in its ".ait/" form. In its other forms,
494 the dvb-app-entity refers to a DVB service or components thereof
495 which are used in conjunction with the currently running application.
496 For further information, please see [DVB-MHP].
498 2.2. Encoding
500 Section 5 of [DVB-URI] specifies that:
502 "All characters not within the range of characters allowed in a URI
503 must be encoded into UTF-8 and included in the URI as a sequence of
504 escaped octets. An escaped octet is encoded as a character triplet,
505 consisting of the percent character "%" followed by the two
506 hexadecimal digits representing the octet code."
508 2.3. Community Considerations
510 2.3.1. Context of Use
512 The "dvb" URIs are used as references to resources in digitial
513 multimedia programmes, most often within the context of DVB itself:
514 interactive television applications use them in order to locate
515 resources and to reference services and programmes. These are
516 typically broadcast via satellite, cable and terrestrial systems, but
517 may also be retrieved on-demand from a server via the Internet.
518 Providers of such broadcast services may e.g. reference programmes in
519 the broadcast from an Electronic Programme Guide (EPG) which is
520 published on their web- site. On another example, the metadata which
521 is part of the multimedia broadcasts can also contain such URIs to
522 establish hyperlinks between broadcast services. This might for
523 instance include multi-angle video services (e.g. for sports events).
524 Users of suitably-equipped clients -- i.e. with a suitable tuner card
525 and software installed (Open Source tools including
526 and ) -- are able
527 to exchange such URIs (e.g. via an instant messaging service or
528 email) to provide each other clickable hyperlinks to multimedia
529 content they deem of interest.
531 DVB has published specifications for the distribution of multimedia
532 services via IP unicast and multicast mechanisms. In this context,
533 such URIs are usable in any player client software (no tuner card
534 required) that implements the respective protocols and has the
535 relevant audio and video codecs installed.
537 o For example, a receiver connected to a local area network might
538 allow other devices to query it for information regarding the
539 current programme or service: in this context, a dvb URI would
540 typically be the most authoritative single identifier which could
541 be used to to refer to that programme.
543 o Similarly, a web service can be implemented by a platform operator
544 or a broadcaster (or some party working on their behalf) which
545 allows resolution of dvb URIs - this would allow a device to
546 retrieve web pages or other content which relate to the current
547 programme (or some other entry in the device's Electronic
548 Programme Guide).
550 Implementing such a system naturally requires some mechanism for
551 devices to discover an appropriate resolution service. DVB has
552 developed has developed a service discovery and selection (SD&S)
553 solution as part of [DVB-IPTV].
555 2.3.2. Resolution Considerations
557 The resolution process is determined through the development of DVB
558 standards by the Digital Video Broadcasting Project (DVB).
560 Since the implementations envisaged cover a wide range of devices
561 with quite different access methods and capabilities, no single
562 resolution or delegation mechanism can be referenced in this
563 document.
565 Currently 2 client system classes are covered by DVB specifications:
567 o A broadcast set-top box or other receiver which only has a
568 unidirectional, receive-only connection -- for example by way of a
569 UHF radio receiver. Hence, all DVB URIs need to be resolvable
570 from the service discovery information received within the
571 broadcast stream.
573 o A "home network end device" (HNED) which could be an IPTV set-top
574 box, networked TV or personal digital recorder with an Ethernet or
575 WLAN connection to a home gateway device.
577 Further device classes will be addressed as DVB standardisation
578 progresses. The dvb URIs must however remain valid. DVB will define
579 appropriate resolution mechanisms to ensure that DVB URIs remain
580 valid for those new device classes as well.
582 For the two above example device classes, three mechanisms of
583 conveying such resolution information are currently defined by DVB:
585 o Repeated, cyclic transmission of service discovery information as
586 auxiliary data in digital TV broadcast streams over satellite,
587 cable or terrestrial transmissions according to [DVB-SI-SPEC],
588 [DVB-DATA] and [DVB-TVA]. Typically, this information is collated
589 and stored during a "service scan". It can then be looked up at
590 point of resolution, and the receiver may tune to the associated
591 frequency and if demultiplex the appropriate transport stream.
593 o Repeated, cyclic multicast transmission of SD&S Records via the
594 DVBSTP protocol according to [DVB-IPTV].
596 o Unicast delivery of SD&S Records in response to HTTP "GET /dvb/
597 sdns" requests according to [DVB-IPTV].
599 2.3.2.1. Identifier Management
601 For some of the identifiers used in the DVB URI syntax, DVB provides
602 a public registry which is operated by DVB Services Sarl [DVB-SVCS]
603 and is available on the Web at http://www.dvbservices.com/. [1] On
604 that site, the registry tables can be viewed, downloaded, and
605 applications for new identifiers can be submitted. Most of the
606 identifiers not listed in the registry are under the scope of one of
607 the registered identifiers (for example the service_id is under
608 control of the holder of a network_id or original_network_id). A
609 select few identifiers are not open for registration to the public,
610 and are managed by DVB itself. For details on the nature of each
611 identifier, please refer ot the corresponding DVB standard.
613 2.3.3. Implementation Considerations
615 2.3.3.1. Considerations for resolution server software
617 With on-going development of DVB standards, DVB will establish
618 requirements and seek candidates for operating resolution servers as
619 appropriate.
621 To boot-strap the resolution process, a DVB client needs to discover
622 an entry point (or set of) from which to obtain an initial Service
623 Discovery and Selection XML record:
625 o By default, the service discovery information is provided on the
626 IANA registered well-known port dvbservdsc (port number 3937) via
627 tcp and udp (see http://www.iana.org/assignments/port-numbers) on
628 the IANA registered well-known multicast addresses 224.0.23.14
629 (DvbServDisc on IPv4) and FF0X:0:0:0:0:0:0:12D (DvbServDisc on
630 IPv6).
632 o As set forth in [DVB-IPTV], a list of non-default Service
633 Discovery and Selection (SD&S) entry points addresses may also be
634 provided via DNS based on the service location resource record
635 (SRV RR) [RFC2782]. The service name for DVB services is
636 "_dvbservdsc", the protocol may be tcp or udp, while the rest of
637 the name is the domain name maintained by DVB for service
638 discovery. This domain name is set to "services.dvb.org". The
639 DVB organization will maintain the services.dvb.org domain name
640 for service discovery and new service providers should register
641 with DVB to add them to the DNS SRV list.
643 2.3.3.2. Considerations for resolution client software
645 To obtain the initial Service Discovery and Selection (SD&S) XML
646 record, a client must by default first join the IANA registered well-
647 known multicast addresses 224.0.23.14 (DvbServDisc on IPv4) and/or
648 FF0X:0:0:0:0:0:0:12D (DvbServDisc on IPv6) and try to obtain a boot-
649 strap record from the IANA registered well-known port dvbservdsc
650 (port number 3937) via tcp and udp (see
651 http://www.iana.org/assignments/port-numbers).
653 To discover non-default entry points addresses, [DVB-IPTV] defines
654 that a list of Service Discovery and Selection (SD&S) entry points
655 addresses may be acquired via DNS according to the service location
656 resource record (SRV RR) [RFC2782]. The service name is
657 "_dvbservdsc", the protocol may be tcp or udp, whilst the suffix is
658 implementation-defined. A client MAY attempt resolution using
659 multiple suffixes if required, and MAY employ [RFC6762] in order to
660 perform resolution.
662 HTTP servers are advertised through this mechanism using the "tcp"
663 protocol, while multicast addresses are advertised using the "udp"
664 protocol.
666 SRV RRs will be published for the forseeable future with the suffix
667 "services.dvb.org" (resulting in the fully-qualified domain names
668 "_dvbservdsc._tcp.services.dvb.org" and
669 "_dvbservdsc._udp.services.dvb.org"). This suffix MAY be used for
670 resolution as a fall-back in the event that resolution using any
671 configuration- or implementation-defined suffixes fails.
673 2.4. Rights to Use Trademarks
675 Conforming to section 7.4 of [RFC3978], the DVB Project who is the
676 holder of various trademark and logo rights amongst others but not
677 limited to the term "dvb", hereby grants IETF a perpetual license to
678 use any such trademarks or service marks solely in exercising its
679 rights to reproduce, publish and modify this IETF contribution. This
680 license does not authorize any IETF participant to use any trademark
681 or service mark in connection with any product or service offering,
682 but only in the context of IETF Documents and discussions.
684 2.5. Examples
686 These examples make heavy use of the identifiers defined by DVB to
687 identify entities. Please see Section 1 for an explanation of the
688 concepts.
690 2.5.1. Referring to transport streams and services
692 In the below examples, a receiver uses the identifiers in the URI to
693 search its internal database of radio frequencies and modulation
694 parameters, which it built during a service scan run. It uses the
695 identifiers as keys to look up in the various tables.
697 dvb://233a.1041
698 The DVB transport stream multiplex with id 0x1041 and with
699 original network id 0x233a. This might be used by a broadcaster
700 to provide an entry point to its service offering, without picking
701 out any of his services in particular.
703 dvb://233a.1041.10bf
704 The DVB service with id 0x10bf in the DVB transport stream with id
705 0x1041 and with original network id 0x233a. This could be used as
706 the link behind a "watch this now" button.
708 dvb://233a..10bf
709 The DVB service with id 0x10bf and with original network id
710 0x233a. This could be used as the link behind a "watch this now"
711 button. Note that compared to the previous example the transport
712 stream id is omitted. This is possible in areas where
713 [DVB-SI-GDL] is applicable.
715 dvb://'MetroTV'
716 The DVB service named "MetroTV". Note that as opposed to the
717 previous example, the reference to the service's name is not
718 necessarily unambiguous and requires more contextual information
719 to be resolved. For "speaking" or "promotional" URIs, [DVB-TVA]
720 might be a more general alternative.
722 2.5.2. Referring to service components
724 In addition to referring to a TV/radio programme as a whole, it might
725 be desirable to be able to pick out specific variations of audio and
726 video provided by a programme. One could for instance always be
727 interested in the video with open signing, or in the audio for the
728 visually impaired.
730 dvb://233a.1041.10bf.audio=fra
731 The default video stream and the French language audio stream in
732 the indicated DVB service.
734 dvb://233a.1041.10bf.audio=qaa&subtitles=eng
735 The default video stream, the original language audio stream, and
736 the English language subtitle stream in the indicated DVB service.
738 dvb://233a.1041.10bf.video=default&audio=visually_impaired The
739 default video stream and the audio stream for the visually
740 impaired in the indicated DVB service.
742 dvb://233a.1041.10bf.fqc=50B,3&fqc=640,5,fra The HD video stream
743 (stream_content 0x5 and component_type 0x0B) with component_tag 3,
744 and the French language ("fra") HE.AAC audio for the visually
745 impaired (stream_content 0x6 and component_type 0x40) with
746 component_tag 5.
748 2.5.3. References for triggering
750 Applications might want to trigger on the start and/or end of TV/
751 radio programmes. The user might e.g. have set a flag on the
752 programme, so that the receiver will remind him when it begins, or
753 might even automatically switch to the respective service when the
754 programme begins, and back to the previous service whe it is over.
755 Or a user might have selected a programme for recording. These
756 scenarios require that an application has some notion of the start
757 and end times of TV/radio programmes.
759 Creating accurate recordings of broadcast content is a non-trivial
760 task. For a wider discussion of this, please see [DVB-TVA].
761 Although individual service components can be selected for recording,
762 all components of the service should generally be recorded where
763 appropriate. This would for instance enable to use the original
764 language audio instead of the dubbed version on special playback
765 occasions.
767 dvb://233a.1004.1044;8fff
768 Event with id 0x8fff within the indicated DVB service. A receiver
769 would look up the EPG information for the given service, and for
770 the indicated event within that service. The EPG information will
771 contain the wall-clock start time and duration of the programme as
772 published e.g. also in print. Since the actual times of
773 transmission may be different, triggers should only be fired with
774 appropriate lead-in and lead-out times relative to the published
775 EPG times. Receivers can also use additional information in the
776 EPG, in particular the running_status. Not all broadcasters do
777 however manage the running_status reliably or in real-time.
779 dvb://233a.1004.1044.audio=fra;8fff French audio version of the
780 event with id 0x8fff within the indicated DVB service. The video
781 would also be implied if it is a TV service. See also previous
782 example.
784 dvb://233a.1004.1044;8fff~20100706T000315Z--PT00H31M17S
785 Event with id 0x8fff within the indicated DVB service, starting at
786 00 hours, 03 minutes and 15 seconds UTC on July, 6th, 2010,
787 lasting for 00 hours, 31 minutes and 17 seconds. This form of the
788 URI can be used to convey more accurate transmission times for the
789 content. The programme may be advertised as starting at 00:00 and
790 ending at 00:30 in the EPG. This extended information in the
791 locator can be used to get a much more accurate trigger for the
792 programme. The lead-in and lead-out times can be reduced to the
793 minimum needed to account for the skews of the local and
794 broadcaster clocks.
796 2.5.4. Referring to data objects
798 [DVB-DATA] defines - among other things - an object carousel which
799 can be mounted as a file system. The data for this object carousel
800 is transmitted repeatedly.
802 dvb://233a.1041.10bf/doc/form.pdf
803 File in a subdirectory of an object carousel, for which the root
804 object is carried in the default object carousel of the referenced
805 DVB service.
807 dvb:/image.png
808 File in root directory of an object carousel, for which the root
809 object is carried in the default object carousel of the current
810 service.
812 dvb://233a..10bf.3$10a1240f/doc/form.pdf
813 File in a subdirectory of an object carousel, for which the root
814 object has the transaction id 10a1240f and is carried in the ES
815 with component_tag 3 of the referenced DVB service. Note that
816 compared to the first example the transport stream id is omitted.
817 This is possible in areas where [DVB-SI-GDL] is applicable.
819 2.5.5. References used with interactive applications
821 [DVB-MHP] defines - among other things - how interactive applications
822 can make use of audiovisual or other multimedia services and service
823 components.
825 dvb://233a.1041.10bf.ait/1a2f.23b0?arg_1=Everest&arg_2=Kilimanjaro
826 Reference to the application with id 23b0, published by the
827 organisation with id 1a2f, as advertised in the AIT which is
828 transmitetd as part of the service identified by 233a.1041.10bf.
829 In case the application were to be launched, it should be passed
830 two arguments; the first argument is "Everest", and the second
831 argument is "Kilimanjaro".
833 dvb://current
834 The service currently selected by the Java Xlet via the
835 javax.tv.service.selection package.
837 3. IANA Considerations
839 This specification requests the IANA permanently register the "dvb"
840 URI scheme as specified in this document and summarized in the
841 following template, per [BCP115]:
843 3.1. DVB Registration Template
845 URI scheme name: dvb
847 Status: Permanent
849 URI scheme syntax: See Section 2.
851 URI scheme semantics: See Section 2.
853 Encoding considerations: Conformance with RFC3986, no special
854 considerations.
856 Applications/protocols that use this URI scheme name: dvb URIs are
857 used throughout DVB-compliant broadcasting systems, for example
858 within Freeview and Freesat in the United Kingdom. They are also
859 used in TV-Anytime [TV-Anytime] metadata where it relates to
860 services transmitted by DVB systems.
862 Interoperability considerations: None.
864 Security considerations: See Section 3.2.
866 Contact:
868 Name: Mr. Alexander Adolf
870 Title: Chair - DVB TM-GBS working group
872 Affiliation: Condition-ALPHA Digital Broadcast Technology
874 Address: Gabelsbergerstrasse 60b, 80333 Muenchen, GERMANY
876 Phone: +4915112722124
878 Email: alexander.adolf@me.com
880 Author/Change controller:
882 Name: Mr. Peter Siebert
884 Title: Executive Director
886 Affiliation: DVB Project
888 Address: 17a Ancienne Route, 1218 Grand-Sacconnex, SWITZERLAND
890 Phone: +41227172717
892 Email: siebert@dvb.org
894 3.2. Security Considerations
896 Section 7 of [RFC3986] describes general security considerations for
897 URI schemes. The sections relating to reliability and consistency,
898 malicious construction, back-end transcoding, rare IP address formats
899 and semantic attacks all apply to dvb URIs. The section relating to
900 sensitive information does not apply, given that dvb URIs do not
901 contain authentication information.
903 The security considerations of the Digital Video Broadcasting suite
904 of standards in general are not covered in this document.
906 4. References
908 4.1. Normative References
910 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
911 Resource Identifier (URI): Generic Syntax", RFC 3986,
912 January 2005.
914 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
915 Specifications: ABNF", RFC 5234, January 2008.
917 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978,
918 March 2005.
920 [DVB-URI] DVB Project, "Digital Video Broadcasting (DVB); Uniform
921 Resource Identifiers (URI) for DVB Systems", ETSI TS 102
922 851, .
925 4.2. Informative References
927 [BT.1306] International Telecommunication Union, "Error-correction,
928 data framing, modulation and emission methods for digital
929 terrestrial television broadcasting", ITU-R BT.1306,
930 October 2000.
932 [BO.1516] International Telecommunication Union, "Digital
933 multiprogramme television systems for use by satellites
934 operating in the 11/12 GHz frequency range", ITU-
935 R BO.1516, April 2001.
937 [J.83] International Telecommunication Union, "Digital multi-
938 programme systems for television, sound and data services
939 for cable distribution", ITU-T J.83, April 1997.
941 [MPEG-Systems]
942 Society of Motion Picture and Television Engineers,
943 "Information technology -- Generic coding of moving
944 pictures and associated audio information: Systems", ISO/
945 IEC 13818-1, December 2000.
947 [DVB] "DVB Project", .
949 [DVB-SVCS]
950 "DVB Services Sarl", .
952 [TV-Anytime]
953 "TV-Anytime Forum", .
955 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
956 specifying the location of services (DNS SRV)", RFC 2782,
957 February 2000.
959 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
960 February 2013.
962 [DVB-IPTV]
963 DVB Project, "Digital Video Broadcasting (DVB); Transport
964 of MPEG-2 TS Based DVB Services over IP Based Networks",
965 ETSI TS 102 034, .
968 [DVB-TVA] DVB Project, "Digital Video Broadcasting (DVB); Carriage
969 and signalling of TV-Anytime information in DVB transport
970 streams", ETSI TS 102 323, .
974 [DVB-MHP] DVB Project, "Digital Video Broadcasting (DVB); Multimedia
975 Home Platform (MHP) Specification 1.1.1", ETSI TS 102 812,
976 .
979 [DVB-SI-SPEC]
980 DVB Project, "Digital Video Broadcasting (DVB);
981 Specification for Service Information (SI) in DVB
982 systems", ETSI EN 300 468, .
986 [DVB-SI-GDL]
987 DVB Project, "Digital Video Broadcasting (DVB); Guidelines
988 on implementation and usage of Service Information (SI)",
989 ETSI TS 101 211, .
992 [DVB-DATA]
993 DVB Project, "Digital Video Broadcasting (DVB); DVB
994 specification for data broadcasting", ETSI EN 301 192, .
998 [OCAP1.0] CableLabs, "OpenCable Application Platform (OCAP)
999 specification, I16", OCAP OC-SP-OCAP1.0-I16-050803.
1001 [BCP115] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
1002 Registration Procedures for New URI Schemes", RFC 4395,
1003 BCP 115, February 2006.
1005 URIs
1007 [1]
1009 Authors' Addresses
1011 Mo McRoberts (editor)
1012 British Broadcasting Corportation
1014 Email: mo.mcroberts@bbc.co.uk
1015 URI: http://www.bbc.co.uk/
1017 Alexander Adolf
1018 Condition-ALPHA
1019 Gabelsbergerstrasse 60b
1020 Munich 80333
1021 GERMANY
1023 Email: alexander.adolf@me.com
1024 URI: http://www.condition-alpha.com