Network Working Group D. Zigmond Internet Draft WebTV Networks, Inc. Document: draft-zigmond-tv-url-02.txt M. Vickers Liberate Technologies, Inc. Category: Informational June 1999 Internet-Draft Uniform Resource Identifiers for Television Broadcasts 1. Status of this Document This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to djz@corp.webtv.net and mav@liberate.com. 2. Introduction World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. On these devices, some of the URI schemes described in [1] are inappropriate. For example, many of these devices lack local storage, so the "file" scheme is of little use. On the other hand, because these devices do have access to television broadcasts, this document describes a widely-implemented URI scheme to refer to such broadcasts. The goal of this document is to capture the current usage of these URIs, and to suggest some directions for future standardization of them. Zigmond 1 Uniform Resource Identifiers for TV Broadcasts June, 1999 3. Television URI The basic structure of a television URI is: tv:<broadcast> where broadcast is a description of the data source. The description can take the form of an over-the-air broadcast call sign, or a network identifier. For example: tv:wqed the WQED station tv:nbc the NBC network 3.1. Scheme-only form A simplest form of the "tv:" URI scheme is used to refer to the "current" or "default" channel: tv: This URI refers to whichever television broadcast is currently being received by the device. It is often used in combination with HTML content that is actually being broadcast along with the audio and video, where the meaning of "current broadcast" is quite unambiguous (because it is the broadcast along with which the content containing the URI was received). This is in fact the most common usage of the "tv:" scheme today, and is explicitly referenced by the recently published specification of the Advanced Television Enhancement Forum [2]. 3.2 Call signs All terrestrial television broadcasters are assigned call signs to identify their signal. These are generally assigned by national authorities (such as the Federal Communications Commission in the United States) and are world unique. The global namespace is managed by the International Communications Union, which assigns portions to member countries (see [3]). Examples of URIs using call signs are: tv:kdka tv:kron In order to support these call signs in a "tv:" URI, a receiver must implement a means to map known call signs to frequencies. The nature of this map and the way in which it is used will be browser- and device-specific and is beyond the scope of this document. In this way, the "tv:" scheme is somewhat analogous to the "news:" and "file:" schemes in [1]: it merely names a television broadcast signal but assumes that the local browser has some means for actually retrieving that signal on the local device. A variety of software systems currently provide device-specific mappings from such identifiers to specific channel numbers or directly to Zigmond Informational-Expires December, 1999 2 Uniform Resource Identifiers for TV Broadcasts June, 1999 frequencies. These systems can be incorporated into television sets or set-top boxes to facilitate the interpretation of television URIs by the client device. 3.3 Network identifiers Many modern television networks are not broadcast over-the-air, but available only through cable or satellite subscriptions. The identifiers for these networks (such as the familiar CNN and HBO) are not regulated at this time. The current practice is simply to compare network identifiers against a list of those known to be available on the receiver. Examples of such URIs include: tv:pbs tv:cnn tv:hbo The same issues apply to mapping these identifiers to tuning frequencies as are discussed in 3.2. The flat namespace for network identifiers poses a serious problem going forward. IANA registration could be used avoid collisions, but at the cost of restricting bona fide networks with identical identifiers from using their common abbreviations in these URIs. Section 3.5 proposes possible directions for resolving this limitation. 3.4 Channel numbers Previous drafts of this specification allowed broadcasts to be identified by channel numbers, such as "tv:4", and this form is currently supported by several independent platforms. The channel numbers generally correspond to tuning frequencies in the various national broadcast frequency standards; for example, "tv:4" in the United states would be found at 66 MHz. However, because this mapping of channel numbers to frequencies varies from country to country, this form is particularly ill-suited to use on the Internet. It has been removed from this draft, but would likely be re-introduced in a future specification that incorporated the hierarchical forms discussed in section 3.5. 3.5 Hierarchical forms Several people have proposed hierarchical forms of television URIs, following the general form: tv://<tuning-space>/<broadcast> where tuning-space describes a specific namespace (such as "ntsc" for analog broadcasts in North America, or "atsc" for digital broadcasts there), and where broadcast might also be hierarchical Zigmond Informational-Expires December, 1999 3 Uniform Resource Identifiers for TV Broadcasts June, 1999 (such "as nbc/2" for NBC's second stream of programming). Because no consensus yet exists on these forms, all hierarchical forms of "tv:" URIs are reserved for future specifications. These hierarchical forms also will be important in allowing geographically separated networks (such as the Australian Broadcast Corporation and the American Broadcast Company) to share identifiers, and for disambiguating call signs and network identifiers in cases where they collide. It is expected that IANA will be asked to register both tuning spaces and identifiers within some of those spaces. 4. BNF for Television URIs The following is a formal specification for the new URIs: tvuri = "tv:" [ broadcast ] broadcast = call-sign | network-id call-sign = 1*[ alpha | digit ] network-id = 1*[ alpha | digit | safe | extra ] The definitions of alpha, digit, safe, and extra are from RFC 2396 [1]. Both call-sign and network-id are case-insensitive. 5. Acknowledgments Many of the ideas in this document came out of conversations with Andrew Lochart. Other people who supplied valuable input include Matt Trifiro and Eric Del Sesto. The original draft of this URI scheme was developed while the author was at Wink Communications. More recent suggestions have come from Lee Acton, Jonathan Boltax, Dean Blackketter, Michael Dolan, Iain Hackett, Jim Helman, Sean McDowell, David Mott, Scott Watson, and others in the ATVEF Technical Working Group (which the authors co-chaired). 6. Security Considerations This new URI scheme is subject to the same security implications as the general URI scheme [1]. It is possible that the mere act of viewing a television broadcast signal may cause costs to be incurred to the viewer in some instances (e.g., "pay-per-view" movies and events). Any software that uses this URI scheme to allow automatic tuning of a client device to a particular television broadcast signal should alert users before performing actions that may incur costs to the user. 7. References [1] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform Resource Identifiers (URI): Generic Syntax", RFC 1296, August 1998. http://www.ietf.org/rfc/rfc2396.txt Zigmond Informational-Expires December, 1999 4 Uniform Resource Identifiers for TV Broadcasts June, 1999 [2] Advanced Television Enhancement Forum, "Advanced Television Enhancement Forum Specification Version 1.1r26," February 1999. http://www.atvef.com/atvef_spec/TVE-public-1-1r26.htm [3] International Telecommunications Union, "Radio Regulations," 1998. See especially Article S19, "Identification of stations," and Appendix S42, "Table of allocation of international call sign series." [4] Narton, T., Alvestrand, H., "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998. http://www.ietf.org/rfc/rfc2434.txt 8. Authors' Address Dan Zigmond WebTV Networks, Inc. One Microsoft Way Redmond, WA 98052 USA Email: djz@corp.webtv.net Mark Vickers Liberate Technologies 1000 Bridge Parkway Redwood Shores, CA 94065 USA Email: mav@liberate.com 9. Microsoft Intellectual Property Rights Statement Microsoft hereby grants to the IETF, a perpetual, nonexclusive, non- sublicensable, non assignable, royalty-free, world-wide right and license under any Microsoft copyrights in this contribution to copy, publish and distribute the contribution, as well as a right and license of the same scope to any derivative works prepared by the IETF and based on, or incorporating all or part of the contribution. Microsoft further agrees that, upon adoption of this contribution as an Internet Standard, Microsoft will grant to any party a royalty- free license on other reasonable and non-discriminatory terms under applicable Microsoft intellectual property rights to implement and use the technology proposed in this contribution for the purpose of supporting the Internet Standard. Microsoft expressly reserves all other rights it may have in the material and subject matter of this contribution. Microsoft expressly disclaims any and all warranties regarding this contribution including any warranty that (a) this contribution does not violate the rights of others, (b) the owners, if any, of other Zigmond Informational-Expires December, 1999 5 Uniform Resource Identifiers for TV Broadcasts June, 1999 rights in this contribution have been informed of the rights and permissions granted to IETF herein, and (c) any required authorizations from such owners have been obtained. This document and the information contained herein is provided on an "AS IS" basis and MICROSOFT DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT WILL MICROSOFT BE LIABLE TO ANY OTHER PARTY INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. 10. Liberate Technologies Intellectual Property Rights Statement Liberate hereby grants to the IETF a perpetual, nonexclusive, non- sublicensable, non-assignable, royalty-free, worldwide right and license under any Liberate copyrights in this contribution to copy, publish and distribute the contribution, as well as a right and license of the same scope to any derivative works prepared by the IETF and based on, or incorporating all or part of the contribution. Liberate further agrees that, upon adoption of this contribution as an Internet Standard, Liberate is prepared to grant to any party a nonexclusive license on reasonable and non-discriminatory terms under applicable Liberate intellectual property rights to implement and use the technology proposed in this contribution for the purpose of supporting the Internet Standard. Liberate expressly reserves all other rights it may have in the material and subject matter of this contribution. Liberate expressly disclaims any and all warranties regarding this contribution, including any warranty that (a) this contribution does not violate the rights of others, (b) the owners, if any, of other rights in this contribution have been informed of the rights and permissions granted to IETF herein, and (c) any required authorizations from such owners have been obtained. This document and the information contained herein is provided on an "AS IS" basis and LIBERATE DISCLAIMS 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. IN NO EVENT WILL LIBERATE BE LIABLE TO ANY OTHER PARTY INCLUDING THE IETF AND ITS MEMBERS FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR SPECIAL DAMAGES WHETHER Zigmond Informational-Expires December, 1999 6 Uniform Resource Identifiers for TV Broadcasts June, 1999 UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES. Zigmond Informational-Expires December, 1999 7