idnits 2.17.1 draft-zigmond-tv-url-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 331 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (December 2000) is 8525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 136 ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Zigmond 3 nternet Draft WebTV Networks, Inc. 4 Document: draft-zigmond-tv-url-03.txt M. Vickers 5 Liberate Technologies, Inc. 6 Category: Informational December 2000 8 Internet-Draft 10 Uniform Resource Identifiers for Television Broadcasts 12 1. Status of this Document 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Distribution of this document is unlimited. Please send comments to 34 djz@corp.webtv.net and mav@liberate.com. 36 2. Introduction 38 World-Wide Web browsers are starting to appear on a variety of 39 consumer electronic devices, such as television sets and television 40 set-top boxes, which are capable of receiving television programming 41 from either terrestrial broadcast, satellite broadcast, or cable. In 42 this context there is a need to reference television broadcasts 43 using the URI format described in [RFC 2396]. This document 44 describes a widely-implemented URI scheme to refer to such 45 broadcasts. 47 3. Television URI 49 The basic structure of a television URI is: 51 tv: 53 Zigmond 1 55 Uniform Resource Identifiers for TV Broadcasts January, 2000 57 where broadcast is a description of the data source. The description 58 takes the form of a DNS-style identifier for a particular broadcaster 59 or television network. For example: 61 tv:wqed.org the WQED station 62 tv:nbc.com the NBC network 64 3.1. Scheme-only form 66 A simplest form of the "tv:" URI scheme is used to refer to the 67 "current" or "default" channel: 69 tv: 71 This URI refers to whichever television broadcast is currently being 72 received by the device. It is often used in combination with HTML 73 content that is actually being broadcast along with the audio and 74 video, where the meaning of "current broadcast" is quite unambiguous 75 (because it is the broadcast along with which the content containing 76 the URI was received). This is in fact the most common usage of the 77 "tv:" scheme today, and is explicitly referenced by the recently 78 published specification of the Advanced Television Enhancement Forum 79 [ATVEF 1.1]. 81 3.2 DNS-style identifiers 83 Television broadcasts traditionally have been identified in a variety 84 of ways. All terrestrial television broadcasters are assigned call 85 signs (such as "KDKA" or "WQED") to identify their signal. These are 86 generally assigned by national authorities (such as the Federal 87 Communications Commission in the United States) and are world unique. 88 The global namespace is managed by the International 89 Telecommunications Union, which assigns portions to member countries 90 (see [ITU RR]). 92 Many modern television networks are not broadcasted over-the-air, but 93 available only through cable or satellite subscriptions. The 94 identifiers for these networks (such as the familiar "CNN" and "HBO") 95 are not regulated at this time. In some countries, even over-the-air 96 broadcasters use these sorts of identifiers, rather than call signs. 98 Unfortunately, these two namespaces overlap, with most network 99 identifiers also being valid call signs. Furthermore, network 100 identifiers are not world unique, and many cases exist of name 101 collisions. (For example, both the Australian Broadcast Corporation 102 and the American Broadcasting Company identify themselves as "ABC".) 103 In order to ensure uniqueness, the "tv:" scheme uses DNS-style 104 identifiers for all broadcast streams. Because these build on the 105 existing registration system for DNS hostname, all name collisions 106 can be resolved through the existing DNS dispute resolution 107 processes. 109 Zigmond Informational-Expires July, 2000 2 111 Uniform Resource Identifiers for TV Broadcasts January, 2000 113 In the simplest form, domain names themselves are used as broadcast 114 identifiers. For example: 116 tv:abc.com the American Broadcast Company 117 tv:abc.co.au the Australian Broadcast Corporation 119 In some cases, networks have multiple broadcast streams that need to 120 be distinguished. This is also handled in DNS style: 122 tv:east.hbo.com HBO East 123 tv:west.hbo.com HBO West 125 It is important to note that these DNS-style identifiers need not 126 match real hostnames; they should not be resolved to IP addresses 127 using DNS. Thus, using the terms as defined in RFC 2396, the "tv:" 128 scheme is a Uniform Resource Identifier and not a Uniform Resource 129 Locator. 131 In order to support these identifiers in a "tv:" URI, a receiver must 132 implement a means to map known identifiers to frequencies. The nature 133 of this map and the way in which it is used are currently browser- 134 and device-specific and are beyond the scope of this document. In 135 this way, the "tv:" scheme is somewhat analogous to the "news:" and 136 "file:" schemes in [1]: it merely names a television broadcast signal 137 but assumes that the local browser has some means for actually 138 retrieving that signal on the local device. A variety of software 139 systems currently provide device-specific mappings from such 140 identifiers to specific channel numbers or directly to frequencies. 141 These systems can be incorporated into television sets or set-top 142 boxes to facilitate the interpretation of television URIs by the 143 client device. 145 3.3 Obsolete forms 147 Previous drafts of this specification allowed broadcasts to be 148 identified by channel numbers, such as "tv:4", and this form is 149 currently supported by several independent platforms. The channel 150 numbers generally correspond to tuning frequencies in the various 151 national broadcast frequency standards; for example, "tv:4" in the 152 United states would be found at 66 MHz. However, because this 153 mapping of channel numbers to frequencies varies from country to 154 country, this form is particularly ill-suited to use on the 155 Internet. 157 Previous drafts also allowed network identifiers and call signs to 158 be used directly as broadcast identifiers, as in "tv:abc" and 159 "tv:kron". These forms should not be used because of the name 160 collision issues described in the previous section. 162 4. BNF for Television URIs 164 The following is a formal specification for the new URIs: 166 Zigmond Informational-Expires July, 2000 3 168 Uniform Resource Identifiers for TV Broadcasts January, 2000 170 tvuri = "tv:" [ broadcast ] 171 broadcast = dns-identifier 172 dns-identifier = *( domainlabel "." ) toplabel [ "." ] 173 domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum 174 toplabel = alpha | alpha *( alphanum | "-" ) alphanum 176 The definitions of alpha and alphanum are from [RFC 2396]. 177 Furthermore, the definition of dns-identifier is identical the 178 definition of hostname in RFC 2396, and is case-insensitive. 180 5. Acknowledgments 182 Many of the ideas in this document came out of conversations with 183 Andrew Lochart. Other people who supplied valuable input include Matt 184 Trifiro and Eric Del Sesto. The original draft of this URI scheme 185 was developed while the author was at Wink Communications. More 186 recent suggestions have come from Lee Acton, Jonathan Boltax, Dean 187 Blackketter, Michael Dolan, Iain Hackett, Jim Helman, Sean McDowell, 188 David Mott, Scott Watson, and others in the ATVEF Technical Working 189 Group (which the authors co-chaired), and from Craig Finseth, Gomer 190 Thomas, Harald Alvestrand, and Larry Masinter. 192 6. Security Considerations 194 This new URI scheme is subject to the same security implications as 195 the general URI scheme described in [RFC 2396]. It is possible that 196 the mere act of viewing a television broadcast signal may cause costs 197 to be incurred to the viewer in some instances (e.g., "pay-per-view" 198 movies and events). Any software that uses this URI scheme to allow 199 automatic tuning of a client device to a particular television 200 broadcast signal should alert users before performing actions that 201 may incur costs to the user. 203 7. IANA Considerations 205 All broadcast identifiers must be registered with IANA. IANA will use 206 a hierarchical allocation (see [RFC 2434]) to assign identifiers. 207 Only the owner of a domain may register identifiers within that 208 domain. For example, only HBO may register names within "hbo.com", 209 and only BBC may register names within "bbc.co.uk". Within their 210 domains, registrants will have complete freedom in their choice of 211 identifiers, and, as noted above, these identifiers need not match 212 actual hostnames. The complete list of registered broadcast 213 identifiers will be publicly available from IANA. 215 8. References 217 [RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform 218 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 219 http://www.ietf.org/rfc/rfc2396.txt 221 Zigmond Informational-Expires July, 2000 4 223 Uniform Resource Identifiers for TV Broadcasts January, 2000 225 [ATVEF 1.1] Advanced Television Enhancement Forum, "Advanced 226 Television Enhancement Forum Specification Version 1.1r26," February 227 1999. http://www.atvef.com/atvef_spec/TVE-public-1-1r26.htm 229 [ITU RR] International Telecommunications Union, "Radio Regulations," 230 1998. See especially Article S19, "Identification of stations," and 231 Appendix S42, "Table of allocation of international call sign 232 series." 234 [RFC 2434] Narton, T., Alvestrand, H., "Guidelines for Writing an 235 IANA Considerations Section in RFCs", RFC 2434, October 1998. 236 http://www.ietf.org/rfc/rfc2434.txt 238 9. Authors' Address 240 Dan Zigmond 241 WebTV Networks, Inc. 242 1065 La Avenida 243 Mountain View, CA 94043 244 USA 246 Email: djz@corp.webtv.net 248 Mark Vickers 249 Liberate Technologies 250 2 Circle Star Way 251 San Carlos, CA 94070 252 USA 254 Email: mav@liberate.com 256 Zigmond Informational-Expires July, 2000 5