Internet Draft
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:
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:///
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