idnits 2.17.1 draft-adolf-dvb-urn-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 524. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages -- Found 12 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? 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 2 characters in excess of 72. == 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 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2008) is 5779 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Adolf 3 Micronas GmbH 4 Category: Informational P. MacAvock 5 Expires December 2008 DVB Project 6 June 24, 2008 8 A Uniform Resource Name (URN) Namespace for 9 the Digital Video Broadcasting Project (DVB) 10 12 Status of this Memo 14 Distribution of this memo is unlimited. 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes a Uniform Resource Name (URN) namespace for 39 the Digital Video Broadcasting Project (DVB) for naming persistent 40 resources defined within DVB standards. Example resources include 41 technical documents and specifications, eXtensible Markup Language 42 (XML) Schemas, classification schemes, XML Document Type Definitions 43 (DTDs), namespaces, style sheets, media assets, and other types of 44 resources produced or managed by DVB. 46 Table of Contents 48 1. Introduction ....................................................2 49 2. Specification Template ..........................................2 50 3. Examples ........................................................4 51 4. Namespace Considerations ........................................4 52 5. Community Considerations ........................................7 53 6. Security Considerations .........................................9 54 7. IANA Considerations .............................................9 55 8. References ......................................................9 57 1. Introduction 59 The Digital Video Broadcasting Project (DVB) is an industry-led 60 consortium of over 270 broadcasters, manufacturers, network 61 operators, software developers, regulatory bodies and others in over 62 35 countries committed to designing global standards for the global 63 delivery of digital television and data services. Services using DVB 64 standards are available on every continent with a total of more than 65 100 million DVB receivers already deployed. 67 DVB would like to assign unique, permanent, location-independent 68 names based on URNs for some resources it produces or manages. These 69 URNs will be constructed according to the URN syntax defined in 70 [RFC2141]. 72 This namespace specification is for a formal namespace to be 73 registered according to the procedures set forth in [RFC3406]. 75 2. Specification Template 77 This section provides the information required to register a formal 78 namespace according to the registration procedure defined in 79 [RFC3406]. The URNs conform to the syntax defined in [RFC2141]. 81 Namespace ID: 83 "dvb" 85 Registration Information: 87 Version: 1 88 Date: 2007-02-28 90 Declared registrant of the namespace: 92 Name: Peter MacAvock 93 Title: Executive Director, DVB Project Office 94 Affiliation: DVB Digital Video Broadcasting 95 Address: Ancienne Route 17a 96 CH-1218 Geneva 97 SWITZERLAND 98 Phone: +41 22 717 2719 99 Email: macavock@dvb.org 101 Declaration of structure: 103 URNs assigned by DVB will have the following hierarchical 104 structure based on the organizational structure of the DVB 105 standards: 107 urn:dvb: 109 where the syntax of "" is specified in Section 2.2 of the URN 110 Syntax requirements ([RFC2141]). 112 The individual URNs will be assigned by DVB through the process of 113 development of DVB standards. 115 Relevant ancillary documentation: 117 None 119 Identifier uniqueness considerations: 121 DVB will establish unique identifiers as appropriate. 123 Uniqueness is guaranteed as DVB ensures through its 124 standardisation process that an assigned string is never 125 reassigned. 127 Identifier persistence considerations: 129 DVB is committed to maintaining the accessibility and persistence 130 of all resources that are officially assigned URNs by the 131 organization. 133 Process of identifier assignment: 135 Assignment is limited to DVB and those authorities that are 136 specifically designated by DVB. DVB may designate portions of its 137 namespace for assignment by other parties under its regime. 139 Process of identifier resolution: 141 DVB will develop and maintain "URN catalogues" that map all 142 assigned URNs to Uniform Resource Locators (URLs) specifically to 143 enable Web-based resolution of named resources. In the future an 144 interactive on-line resolution system may be developed to automate 145 this process. The latest information about DVB defined metadata 146 can always be found on the DVB website at 147 http://www.dvb.org/metadata 149 DVB will authorize additional resolution services as appropriate 150 and in-line with the DVB standardisation process. 152 Rules for Lexical Equivalence: 154 The "" is case-insensitive. 156 Conformance with URN Syntax: 158 No special considerations. 160 Validation mechanism: 162 None specified. DVB will develop and maintain URN catalogues. The 163 presence of a URN in a catalogue indicates that it is valid. 165 Scope: 167 Global 169 3. Examples 171 The following examples are not guaranteed to be real. They are 172 presented for pedagogical reasons only. 174 urn:dvb:ipdc:esg:2005 175 urn:dvb:cs:ZappingTypeCS:2001 177 4. Namespace Considerations 179 The urn:dvb namespace is used to identify metadata defined by DVB and 180 describing DVB multimedia and interactive services. Registration of 181 urn:dvb as a formal namespace enables use and referencing of DVB XML 182 fragments in other standards worldwide and enables those standards to 183 leverage and build upon publicly available DVB metadata schemas and 184 fragments. 186 These URNs are used to refer to, in conjunction with and as part of 187 commercial or public multimedia broadcast services. In most markets 188 these are under the control of a national regulator. So if a 189 particular market chooses to use DVB services, in general the 190 regulator imposes compliance with the relevant DVB specifications to 191 ensure interoperability and open competition in the marketplace. 193 URN assignment procedures: 195 The individual URNs shall be assigned through the process of 196 development of DVB standards by the Digital Video Broadcasting 197 Project (DVB). The latest information about DVB defined metadata 198 can always be found at the owner's website at 199 http://www.dvb.org/metadata 201 URN resolution/delegation: 203 The resolution and delegation shall be determined through the 204 process of development of DVB standards by the Digital Video 205 Broadcasting Project (DVB). 207 Since the implementations envisaged cover a wide range of devices 208 with quite different access methods and capabilities, no single 209 resolution or delegation mechanism can be referenced in this 210 document. 212 Currently 2 client system classes are covered by DVB 213 specifications: 215 o A broadcast set-top box which only has a unidirectional, 216 receive-only connection. Hence all DVB URNs need to be 217 resolvable from the service discovery information received in 218 the broadcast stream. 220 o A "home network end device" (HNED) which could be an IPTV set- 221 top box, networked TV or personal digital recorder with an 222 Ethernet or WLAN connection to a home gateway device. 224 Further device classes will be addressed as DVB standardisation 225 progresses. The urn:dvb URNs must however remain valid. DVB will 226 define appropriate resolution/delegation mechanisms to ensure that 227 DVB URNs remain valid for those new device classes as well. 229 For the two above example device classes, 3 ways of conveying such 230 resolution information are currently defined by DVB: 232 o Repeated, cyclic transmission of Resolution Authority Records 233 (RAR) and Resolution Records (RR) as auxiliary data in digital 234 TV broadcast streams over satellite, cable or terrestrial 235 transmissions according to [EN300468], [EN301192] and 236 [TS102323]. 238 o Repeated, cyclic multicast transmission of Resolution Records 239 (RR) via the DVBSTP protocol according to [TS102034]. 241 o Unicast delivery of Resolution Records (RR) in response to 242 HTTP "GET /dvb/sdns" requests according to [TS102034]. 244 Type of resources to be identified: 246 Types of resources to be identified include XML schema definition 247 files, classification schemes and identification systems defined 248 and openly published by DVB. These resources being identified 249 constitute a metadata system to describe digital multimedia 250 broadcast services or content conveyed as part of such services. 251 The latest DVB defined metadata can always be found at 252 http://www.dvb.org/metadata 254 These metadata definitions are not entirely usable without 255 knowledge of the DVB specifications listed in the normative 256 references section. To make them generally useful for client 257 platforms typically found in computer network environments today, 258 XSLT transformations to HTML or other common formats would be 259 needed to enable rendering in a standard web browser. On the other 260 hand it is expected that with the increasing overlap between the 261 computer and multimedia worlds - e.g. with the forthcoming DVB 262 file format definition - DVB metadata formats will get adopted in 263 player implementations on PC platforms as well. 265 Type of services to be supported: 267 Types of services supported include controlled term lookup in 268 classification schemes, resolution of ids in identification 269 systems. 271 Concrete examples of these services include digital television 272 services, (near) video on demand services and digital radio sound 273 services. Another example is interactive multimedia applications 274 which are tied to audiovisual content. 276 This might e.g. be a quiz show where viewers can compete against 277 the contestants on the show by picking multiple-choice answers 278 with their remote control. These end-user services are enabled by 279 the metadata defined under the urn:dvb namespace. 281 Another example is the web-portal site for the video-on-demand 282 offering of an ISP. The portal pages are likely to describe the 283 content in terms of title, genre, parental guidance, cast, etc. 284 The ISP might either publish the DVB format description on their 285 web-portal site directly, or develop an XSLT transformation to 286 obtain an HTML incarnation of the data. In either case, a client 287 device (in this example the home gateway or the ISP's web portal) 288 will need to be able to resolve references to the urn:dvb 289 namespace. Describing multimedia content in DVB format is a likely 290 choice since it provides rich information specially tailored to 291 multimedia applications like television, movies, music, etc. 292 Furthermore the DVB content descriptions for consumer terminals 293 are of course compatible with the DVB Portable Content Format 294 (PCF, defined in ETSI TS 102 523) which is used in content 295 production environments so that propagation of content 296 descriptions along the entire production chain is easily achieved. 298 5. Community Considerations 300 With the digitisation of the audiovisual broadcasting technologies, 301 television receiver platforms become quite similar to personal 302 computer equipment in terms of performance, resources and interfaces. 303 Hence cross-use of content from the respective other platform (i.e. 304 TV and PC) becomes interesting to consumers and service providers 305 alike. Web pages can for instance today be viewed on a general 306 purpose computer, a set-top box and a mobile phone just the same. 307 Audio/video broadcasting services are arriving on mobile phones today 308 ("mobile TV"), and efforts are clearly visible to bring such services 309 to personal computer platforms as well ("IPTV"). 311 Hence cross-linking between these two domains, the Internet/personal 312 computer domain and the TV/broadcast domain is called for. Linking 313 from broadcast domain metadata to Internet-based services is already 314 enabled through the various URN and URI schemes established in the 315 relevant DVB standards ([EN300468], [TS102323] and [TS102034]). 316 Linking from Internet/web resources to DVB multimedia services is not 317 yet possible in a well-defined way. Thus a URN scheme is proposed for 318 DVB defined metadata describing DVB services. As DVB issues its 319 publications as international standards and has a well-defined 320 compliance regime, this request is for a formal namespace. 322 Open assignment and use of identifiers within the namespace: 324 With on-going development of DVB standards, DVB will establish 325 requirements for assignment and use of identifiers within the DVB 326 namespace. Current identifier assignments can be inferred from the 327 relevant DVB standards and from http://www.dvb.org/metadata 329 Considerations for resolution server software: 331 With on-going development of DVB standards, DVB will establish 332 requirements and seek candidates for operating resolution servers 333 as appropriate. 335 Sources for resolution information can either be stand-alone 336 resolution services which are announced as part of the Service 337 Discovery and Selection (SD&S), or data conveyed as part of the 338 SD&S information itself. To boot-strap the resolution process, a 339 DVB client hence needs to discover an entry point (or set of) from 340 which to obtain an initial Service Discovery and Selection XML 341 record. 343 By default, the actual service discovery information is provided 344 on the IANA registered well-known port dvbservdsc (port number 345 3937) via tcp and udp (see http://www.iana.org/assignments/port- 346 numbers) on the IANA registered well-known multicast addresses 347 224.0.23.14 (DvbServDisc on IPv4) and FF0X:0:0:0:0:0:0:12D 348 (DvbServDisc on IPv6). 350 As set forth in [TS102034], a list of non-default Service 351 Discovery and Selection (SD&S) entry points addresses may also be 352 provided via DNS based on the service location resource record 353 (SRV RR) [RFC2782]. The service name for DVB services is 354 "_dvbservdsc", the protocol may be tcp or udp, while the rest of 355 the name is the domain name maintained by DVB for service 356 discovery. This domain name is set to "services.dvb.org". The DVB 357 organization will maintain the services.dvb.org domain name for 358 service discovery and new service providers should register with 359 DVB to add them to the DNS SRV list. 361 Considerations for resolution client software: 363 With on-going development of DVB standards, DVB members will 364 develop software implementations of its standards for various 365 platforms. Today, these platforms typically include Open Source 366 based platforms such as Linux. 368 To resolve a urn:dvb name, a client needs to retrieve Service 369 Discovery and Selection (SD&S) data since this either directly 370 contains resolution data, or lists stand-alone resolution services 371 from which Resolution Authority Records (RAR) can be retrieved. 373 To obtain the initial Service Discovery and Selection (SD&S) XML 374 record, a client must by default first join the IANA registered 375 well-known multicast addresses 224.0.23.14 (DvbServDisc on IPv4) 376 and/or FF0X:0:0:0:0:0:0:12D (DvbServDisc on IPv6) and try to 377 obtain a boot-strap record from the IANA registered well-known 378 port dvbservdsc (port number 3937) via tcp and udp (see 379 http://www.iana.org/assignments/port-numbers). 381 To discover non-default entry points addresses, [TS102034] defines 382 that a list of Service Discovery and Selection (SD&S) entry points 383 addresses may be acquired via DNS according to the service 384 location resource record (SRV RR) [RFC2782]. The service name is 385 "_dvbservdsc", the protocol may be tcp or udp, while the rest of 386 the name is the domain name maintained by DVB for service 387 discovery. This domain name is set to "services.dvb.org". So the 388 lookup shall be either "_dvbservdsc._tcp.services.dvb.org" or 389 "_dvbservdsc._udp.services.dvb.org". This requires that the 390 terminal support an SRV cognizant DNS client and according to the 391 specification in [RFC2782]. The DVB organization will maintain the 392 services.dvb.org domain name for service discovery. HTTP servers 393 will be found via the tcp protocol method whilst the multicast 394 addresses will be found via the udp protocol method. 396 6. Security Considerations 398 There are no additional security considerations other than those 399 normally associated with the use and resolution of URNs in general. 401 7. IANA Considerations 403 This document defines a URN NID registration of "dvb". IANA is 404 requested to include it in the URN Namespaces registry. 406 8. References 408 8.1. Normative References 410 The ETSI specifications listed below - as all ETSI standards - are 411 available to the general public free of charge. They are accessible 412 by going to http://www.etsi.org and visiting the standards download 413 page. Select "Standards" from the navigation bat at the top, then 414 choose "Download ETSI Standards" in contents box on the left. A 415 "Publications Download Area" link occurs at the top of the body 416 text). The direct link to the downloads page is 417 http://pda.etsi.org/pda/queryform.asp. When clicking on the download 418 link on the search results page, an email address is requested for 419 the PDF download. As the being free-of-charge is funded by the 420 European Commission, the email addresses are collected for 421 statistical purposes only to demonstrate benefit to the general 422 public. 424 The ETSI specifications are normative references since the URNs are 425 used to refer to, in conjunction with and as part of commercial or 426 public multimedia broadcast services. In most markets these are under 427 the control of a national regulator. So if a particular market 428 chooses to use DVB services, in general the regulator imposes 429 compliance with the relevant DVB specifications to ensure 430 interoperability and open competition in the marketplace. Some of the 431 specifications also have "EN" status which means that the European 432 Commission has overridden any national regulations by mandating that 433 if any commercial service is rolled out in Europe in the respective 434 area, it must comply with the relevant DVB EN specification(s). Apart 435 from those legal implications, DVB bas become a brand to which 436 consumers link certain expectations wrt. the level of service and 437 interoperability. Of course DVB wants to help manufacturers meeting 438 those expectations by fostering interoperability. 440 [RFC2141] Moats, R., "URN Syntax", RFC 2124, May 1997. 442 [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 443 "Uniform Resource Names (URN) Namespace Definition 444 Mechanisms", October 2002. 446 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 447 specifying the location of services (DNS SRV)", February 448 2000 450 [EN300468] European Telecommunications Standards Institute (ETSI), 451 "Digital Video Broadcasting (DVB); Specification for 452 Service Information (SI) in DVB systems", October 2007 454 [EN301192] European Telecommunications Standards Institute (ETSI), 455 "Digital Video Broadcasting (DVB); DVB specification for 456 data broadcasting", November 2004 458 [TS102323] European Telecommunications Standards Institute (ETSI), 459 "Digital Video Broadcasting (DVB); Carriage and signalling 460 of TV-Anytime information in DVB transport streams", 461 November 2005 463 [TS102034] European Telecommunications Standards Institute (ETSI), 464 "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS 465 Based DVB Services over IP Based Networks", October 2007 467 Authors' Addresses 469 Alexander Adolf 470 Micronas GmbH 471 Frankenthalerstrasse 2 472 D-81539 Munich 473 GERMANY 474 Tel: +49 89 54845 7203 475 Fax: +49 89 54845 7900 476 EMail: alexander.adolf@micronas.com 478 Peter MacAvock 479 DVB Digital Video Broadcasting 480 Ancienne Route 17a 481 CH-1218 Geneva 482 SWITZERLAND 483 Tel: +41 22 717 2717 484 EMail: macavock@dvb.org 486 Full Copyright Statement 488 Copyright (C) The IETF Trust (2008). 490 This document is subject to the rights, licenses and restrictions 491 contained in BCP 78, and except as set forth therein, the authors 492 retain all their rights. 494 This document and the information contained herein are provided on an 495 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 496 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND 497 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 498 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 499 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 500 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 502 Intellectual Property 504 The IETF takes no position regarding the validity or scope of any 505 Intellectual Property Rights or other rights that might be claimed 506 to pertain to the implementation or use of the technology 507 described in this document or the extent to which any license 508 under such rights might or might not be available; nor does it 509 represent that it has made any independent effort to identify any 510 such rights. Information on the procedures with respect to 511 rights in RFC documents can be found in BCP 78 and BCP 79. 513 Copies of IPR disclosures made to the IETF Secretariat and any 514 assurances of licenses to be made available, or the result of an 515 attempt made to obtain a general license or permission for the use 516 of such proprietary rights by implementers or users of this 517 specification can be obtained from the IETF on-line IPR repository 518 at http://www.ietf.org/ipr. 520 The IETF invites any interested party to bring to its attention 521 any copyrights, patents or patent applications, or other 522 proprietary rights that may cover technology that may be required 523 to implement this standard. Please address the information to the 524 IETF at ietf-ipr@ietf.org.