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