diff options
Diffstat (limited to 'doc/rfc/rfc5328.txt')
| -rw-r--r-- | doc/rfc/rfc5328.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc5328.txt b/doc/rfc/rfc5328.txt new file mode 100644 index 0000000..3aa0cd6 --- /dev/null +++ b/doc/rfc/rfc5328.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group A. Adolf +Request for Comments: 5328 Micronas GmbH +Category: Informational P. MacAvock + DVB Project + September 2008 + + + A Uniform Resource Name (URN) Namespace for + the Digital Video Broadcasting Project (DVB) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This document describes a Uniform Resource Name (URN) namespace for + the Digital Video Broadcasting Project (DVB) for naming persistent + resources defined within DVB standards. Example resources include + technical documents and specifications, eXtensible Markup Language + (XML) Schemas, classification schemes, XML Document Type Definitions + (DTDs), namespaces, style sheets, media assets, and other types of + resources produced or managed by DVB. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Specification Template ..........................................2 + 3. Examples ........................................................4 + 4. Namespace Considerations ........................................4 + 5. Community Considerations ........................................7 + 6. Security Considerations .........................................9 + 7. IANA Considerations .............................................9 + 8. References .....................................................10 + 8.1. Normative References ......................................10 + 8.2. Informative References ....................................11 + + + + + + + + + + + + + +Adolf & MacAvock Informational [Page 1] + +RFC 5328 DVB URN September 2008 + + +1. Introduction + + The Digital Video Broadcasting Project (DVB) is an industry-led + consortium of over 270 broadcasters, manufacturers, network + operators, software developers, regulatory bodies and others in over + 35 countries committed to designing global standards for the global + delivery of digital television and data services. Services using DVB + standards are available on every continent with a total of more than + 100 million DVB receivers already deployed. + + DVB would like to assign unique, permanent, location-independent + names based on URNs for some resources it produces or manages. These + URNs will be constructed according to the URN syntax defined in + [RFC2141]. + + This namespace specification is for a formal namespace to be + registered according to the procedures set forth in [RFC3406]. + +2. Specification Template + + This section provides the information required to register a formal + namespace according to the registration procedure defined in + [RFC3406]. The URNs conform to the syntax defined in [RFC2141]. + + Namespace ID: + + "dvb" + + Registration Information: + + Version: 1 + Date: 2007-02-28 + + Declared registrant of the namespace: + + Name: Peter MacAvock + Title: Executive Director, DVB Project Office + Affiliation: DVB Digital Video Broadcasting + Address: Ancienne Route 17a + CH-1218 Geneva + SWITZERLAND + Phone: +41 22 717 2719 + Email: macavock@dvb.org + + + + + + + + +Adolf & MacAvock Informational [Page 2] + +RFC 5328 DVB URN September 2008 + + + Declaration of structure: + + URNs assigned by DVB will have the following hierarchical + structure based on the organizational structure of the DVB + standards: + + urn:dvb:<NSS> + + where the syntax of "<NSS>" is specified in Section 2.2 of the URN + Syntax requirements ([RFC2141]). + + The individual URNs will be assigned by DVB through the process of + development of DVB standards. + + Relevant ancillary documentation: + + None + + Identifier uniqueness considerations: + + DVB will establish unique identifiers as appropriate. + + Uniqueness is guaranteed as DVB ensures through its + standardization process that an assigned string is never + reassigned. + + Identifier persistence considerations: + + DVB is committed to maintaining the accessibility and persistence + of all resources that are officially assigned URNs by the + organization. + + Process of identifier assignment: + + Assignment is limited to DVB and those authorities that are + specifically designated by DVB. DVB may designate portions of its + namespace for assignment by other parties under its regime. + + Process of identifier resolution: + + DVB will develop and maintain "URN catalogues" that map all + assigned URNs to Uniform Resource Locators (URLs) specifically to + enable Web-based resolution of named resources. In the future, an + interactive online resolution system may be developed to automate + this process. The latest information about DVB-defined metadata + can always be found on the DVB website at: + + http://www.dvb.org/metadata + + + +Adolf & MacAvock Informational [Page 3] + +RFC 5328 DVB URN September 2008 + + + DVB will authorize additional resolution services as appropriate + and in-line with the DVB standardization process. + + Rules for Lexical Equivalence: + + The "<NSS>" is case insensitive. + + Conformance with URN Syntax: + + No special considerations. + + Validation mechanism: + + None specified. DVB will develop and maintain URN catalogues. + The presence of a URN in a catalogue indicates that it is valid. + + Scope: + + Global + +3. Examples + + The following examples are not guaranteed to be real. They are + presented for pedagogical reasons only. + + urn:dvb:ipdc:esg:2005 + urn:dvb:cs:ZappingTypeCS:2001 + +4. Namespace Considerations + + The urn:dvb namespace is used to identify metadata that is defined by + DVB and describes DVB multimedia and interactive services. The + registration of urn:dvb as a formal namespace enables the use and + referencing of DVB XML fragments in other standards worldwide and + enables those standards to leverage and build upon publicly available + DVB metadata schemas and fragments. + + These URNs are used to refer to, in conjunction with, and as part of + commercial or public multimedia broadcast services. In most markets, + these are under the control of a national regulator. So if a + particular market chooses to use DVB services, in general, the + regulator imposes compliance with the relevant DVB specifications to + ensure interoperability and open competition in the marketplace. + + + + + + + + +Adolf & MacAvock Informational [Page 4] + +RFC 5328 DVB URN September 2008 + + + URN assignment procedures: + + The individual URNs shall be assigned through the process of + development of DVB standards by the Digital Video Broadcasting + Project (DVB). The latest information about DVB defined metadata + can always be found at the owner's website at: + + http://www.dvb.org/metadata + + URN resolution/delegation: + + The resolution and delegation shall be determined through the + process of development of DVB standards by the Digital Video + Broadcasting Project (DVB). + + Since the implementations envisaged cover a wide range of devices + with quite different access methods and capabilities, no single + resolution or delegation mechanism can be referenced in this + document. + + Currently, 2 client system classes are covered by DVB + specifications: + + o A broadcast set-top box that only has a unidirectional, + receive-only connection. Hence, all DVB URNs need to be + resolvable from the service discovery information received in + the broadcast stream. + + o A "home network end device" (HNED) that could be an IPTV set- + top box, networked TV, or personal digital recorder with an + Ethernet or Wireless Local Area Network (WLAN) connection to a + home gateway device. + + Further device classes will be addressed as DVB standardization + progresses. The urn:dvb URNs must however remain valid. DVB will + define appropriate resolution/delegation mechanisms to ensure that + DVB URNs remain valid for those new device classes as well. + + For the two above example device classes, 3 ways of conveying such + resolution information are currently defined by DVB: + + o Repeated, cyclic transmission of Resolution Authority Records + (RAR) and Resolution Records (RR) as auxiliary data in digital + TV broadcast streams over satellite, cable, or terrestrial + transmissions according to [EN300468], [EN301192], and + [TS102323]. + + + + + +Adolf & MacAvock Informational [Page 5] + +RFC 5328 DVB URN September 2008 + + + o Repeated, cyclic multicast transmission of Resolution Records + (RR) via the DVBSTP protocol according to [TS102034]. + + o Unicast delivery of Resolution Records (RR) in response to HTTP + "GET /dvb/sdns" requests according to [TS102034]. + + Type of resources to be identified: + + Types of resources to be identified include XML schema definition + files, classification schemes, and identification systems defined + and openly published by DVB. These resources being identified + constitute a metadata system to describe digital multimedia + broadcast services or content conveyed as part of such services. + The latest DVB defined metadata can always be found at: + + http://www.dvb.org/metadata + + These metadata definitions are not entirely usable without + knowledge of the DVB specifications listed in the Normative + References section. To make them generally useful for client + platforms typically found in computer network environments today, + XSLT transformations to HTML, or other common formats would be + needed to enable rendering in a standard web browser. On the + other hand, it is expected that with the increasing overlap + between the computer and multimedia worlds - e.g., with the + forthcoming DVB file format definition - DVB metadata formats will + get adopted in player implementations on PC platforms as well. + + Type of services to be supported: + + Types of services supported include controlled term lookup in + classification schemes and resolution of ids in identification + systems. + + Concrete examples of these services include digital television + services, (near) video on-demand services, and digital radio sound + services. Another example is interactive multimedia applications + which are tied to audiovisual content. + + This might, e.g., be a quiz show where viewers can compete against + the contestants on the show by picking multiple-choice answers + with their remote control. These end-user services are enabled by + the metadata defined under the urn:dvb namespace. + + Another example is the web-portal site for the video-on-demand + offering of an ISP. The portal pages are likely to describe the + content in terms of title, genre, parental guidance, cast, etc. + The ISP might either publish the DVB format description on their + + + +Adolf & MacAvock Informational [Page 6] + +RFC 5328 DVB URN September 2008 + + + web-portal site directly, or develop an XSLT transformation to + obtain an HTML incarnation of the data. In either case, a client + device (in this example the home gateway or the ISP's web portal) + will need to be able to resolve references to the urn:dvb + namespace. Describing multimedia content in DVB format is a + likely choice since it provides rich information specially + tailored to multimedia applications like television, movies, + music, etc. Furthermore, the DVB content descriptions for + consumer terminals are, of course, compatible with the DVB + Portable Content Format (PCF, defined in ETSI TS 102 523), which + is used in content production environments so that propagation of + content descriptions along the entire production chain is easily + achieved. + +5. Community Considerations + + With the digitization of the audiovisual broadcasting technologies, + television receiver platforms have become quite similar to personal + computer equipment in terms of performance, resources, and + interfaces. Hence, cross-use of content from the respective other + platform (i.e., TV and PC) becomes interesting to consumers and + service providers alike. Web pages can for instance today be viewed + on a general purpose computer, a set-top box, and a mobile phone just + the same. Audio/video broadcasting services are arriving on mobile + phones today ("mobile TV"), and efforts are clearly visible to bring + such services to personal computer platforms as well ("IPTV"). + + Hence, cross-linking between these two domains, the Internet/personal + computer domain and the TV/broadcast domain is called for. Linking + from broadcast domain metadata to Internet-based services is already + enabled through the various URN and URI schemes established in the + relevant DVB standards ([EN300468], [TS102323], and [TS102034]). + Linking from Internet/web resources to DVB multimedia services is not + yet possible in a well-defined way. Thus, a URN scheme is proposed + for DVB defined metadata describing DVB services. As DVB issues its + publications as international standards and has a well-defined + compliance regime, this request is for a formal namespace. + + Open assignment and use of identifiers within the namespace: + + With on-going development of DVB standards, DVB will establish + requirements for assignment and use of identifiers within the DVB + namespace. Current identifier assignments can be inferred from + the relevant DVB standards and from http://www.dvb.org/metadata. + + + + + + + +Adolf & MacAvock Informational [Page 7] + +RFC 5328 DVB URN September 2008 + + + Considerations for resolution server software: + + With on-going development of DVB standards, DVB will establish + requirements and seek candidates for operating resolution servers + as appropriate. + + Sources for resolution information can either be stand-alone + resolution services, which are announced as part of the Service + Discovery and Selection (SD&S), or data conveyed as part of the + SD&S information itself. To boot-strap the resolution process, a + DVB client hence needs to discover an entry point (or set of) from + which to obtain an initial Service Discovery and Selection XML + record. + + By default, the actual service discovery information is provided + on the IANA registered well-known port dvbservdsc (port number + 3937) via tcp and udp (see http://www.iana.org/assignments/port- + numbers) on the IANA registered well-known multicast addresses + 224.0.23.14 (DvbServDisc on IPv4) and FF0X:0:0:0:0:0:0:12D + (DvbServDisc on IPv6). + + As set forth in [TS102034], a list of non-default Service + Discovery and Selection (SD&S) entry points addresses may also be + provided via DNS based on the service location resource record + (SRV RR) [RFC2782]. The service name for DVB services is + "_dvbservdsc", the protocol may be tcp or udp, while the rest of + the name is the domain name maintained by DVB for service + discovery. This domain name is set to "services.dvb.org". The + DVB organization will maintain the services.dvb.org domain name + for service discovery, and new service providers should register + with DVB to add them to the DNS SRV list. + + Considerations for resolution client software: + + With on-going development of DVB standards, DVB members will + develop software implementations of its standards for various + platforms. Today, these platforms typically include Open Source- + based platforms such as Linux. + + To resolve a urn:dvb name, a client needs to retrieve Service + Discovery and Selection (SD&S) data since this either directly + contains resolution data, or lists stand-alone resolution services + from which Resolution Authority Records (RAR) can be retrieved. + + To obtain the initial Service Discovery and Selection (SD&S) XML + record, a client must by default first join the IANA registered + well-known multicast addresses 224.0.23.14 (DvbServDisc on IPv4) + and/or FF0X:0:0:0:0:0:0:12D (DvbServDisc on IPv6) and try to + + + +Adolf & MacAvock Informational [Page 8] + +RFC 5328 DVB URN September 2008 + + + obtain a boot-strap record from the IANA registered well-known + port dvbservdsc (port number 3937) via tcp and udp (see + http://www.iana.org/assignments/port-numbers). + + To discover non-default entry points addresses, [TS102034] defines + that a list of Service Discovery and Selection (SD&S) entry points + addresses may be acquired via DNS according to the service + location resource record (SRV RR) [RFC2782]. The service name is + "_dvbservdsc"; the protocol may be tcp or udp, while the rest of + the name is the domain name maintained by DVB for service + discovery. This domain name is set to "services.dvb.org". So the + lookup shall be either "_dvbservdsc._tcp.services.dvb.org" or + "_dvbservdsc._udp.services.dvb.org". This requires that the + terminal support an SRV cognizant DNS client and in a way + according to the specification in [RFC2782]. The DVB organization + will maintain the services.dvb.org domain name for service + discovery. HTTP servers will be found via the tcp protocol method + whilst the multicast addresses will be found via the udp protocol + method. + +6. Security Considerations + + There are no additional security considerations other than those + normally associated with the use and resolution of URNs in general, + which are described in [RFC1737], [RFC2141], and [RFC3406]. + + This document registers a namespace for URNs. DVB may assign special + meaning to certain of the characters of the Namespace Specific String + in its specifications. Any security consideration resulting from + such assignment is outside the scope of this document. + + When URNs are resolved, i.e., translated from names to locations, the + way the locations are used or accessed may require the resources to + be authenticated. The information about the authentication of either + the name or the resource to which it refers should be carried by + separate information passed along with the URN rather than in the URN + itself. The design of such resolution mechanisms by DVB for DVB URNs + is guided by [RFC2276] and such mechanisms will be published as DVB + specifications. + +7. IANA Considerations + + This document defines a URN NID registration of "dvb". IANA has + registered "dvb" in the URN Namespaces registry. + + + + + + + +Adolf & MacAvock Informational [Page 9] + +RFC 5328 DVB URN September 2008 + + +8. References + + Note: The ETSI specifications listed below - as all ETSI standards - + are available to the general public free of charge. They are + accessible by going to http://www.etsi.org and visiting the + standards download page. Select "Standards" from the + navigation bar at the top, then choose "Download ETSI + Standards" in the contents box on the left. A "Publications + Download Area" link occurs at the top of the body text). The + direct link to the downloads page is + http://pda.etsi.org/pda/queryform.asp. When clicking on the + download link on the search results page, an email address is + requested for the PDF download. As being free-of-charge is + funded by the European Commission, the email addresses are + collected for statistical purposes only to demonstrate benefit + to the general public. + + The ETSI specifications are normative references since the URNs + are used to refer to, in conjunction with, and as part of + commercial or public multimedia broadcast services. In most + markets, these are under the control of a national regulator. + So if a particular market chooses to use DVB services, in + general, the regulator imposes compliance with the relevant DVB + specifications to ensure interoperability and open competition + in the marketplace. Some of the specifications also have "EN" + status, which means that the European Commission has overridden + any national regulations by mandating that if any commercial + service is rolled out in Europe in the respective area, it must + comply with the relevant DVB EN specification(s). Apart from + those legal implications, DVB has become a brand to which + consumers link certain expectations with regard to the level of + service and interoperability. Of course, DVB wants to help + manufacturers meeting those expectations by fostering + interoperability. + +8.1. Normative References + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, + "Uniform Resource Names (URN) Namespace Definition + Mechanisms", BCP 66, RFC 3406, October 2002. + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + + + + +Adolf & MacAvock Informational [Page 10] + +RFC 5328 DVB URN September 2008 + + + [EN300468] European Telecommunications Standards Institute (ETSI), + "Digital Video Broadcasting (DVB); Specification for + Service Information (SI) in DVB systems", October 2007. + + [EN301192] European Telecommunications Standards Institute (ETSI), + "Digital Video Broadcasting (DVB); DVB specification for + data broadcasting", November 2004. + + [TS102323] European Telecommunications Standards Institute (ETSI), + "Digital Video Broadcasting (DVB); Carriage and signalling + of TV-Anytime information in DVB transport streams", + November 2005. + + [TS102034] European Telecommunications Standards Institute (ETSI), + "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS + Based DVB Services over IP Based Networks", October 2007. + +8.2. Informative References + + [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for + Uniform Resource Names", RFC 1737, December 1994. + + [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource + Name Resolution", RFC 2276, January 1998. + +Authors' Addresses + + Alexander Adolf + Micronas GmbH + Frankenthalerstrasse 2 + D-81539 Munich + GERMANY + Tel: +49 89 54845 7203 + Fax: +49 89 54845 7900 + EMail: alexander.adolf@micronas.com + + Peter MacAvock + DVB Digital Video Broadcasting + Ancienne Route 17a + CH-1218 Geneva + SWITZERLAND + Tel: +41 22 717 2717 + EMail: macavock@dvb.org + + + + + + + + +Adolf & MacAvock Informational [Page 11] + +RFC 5328 DVB URN September 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Adolf & MacAvock Informational [Page 12] + |