WDIFF

draft-zigmond-tv-url-02.txt --> draft-zigmond-tv-url-03.txt

Network Working Group D. Zigmond
Internet
nternet Draft WebTV Networks, Inc.
Document: draft-zigmond-tv-url-02.txt draft-zigmond-tv-url-03.txt M. Vickers
Liberate Technologies, Inc.
Category: Informational June 1999 December 2000

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 In
this context there is a need to reference television broadcasts
using the URI schemes format 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 [RFC 2396]. 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>

Zigmond 1

Uniform Resource Identifiers for TV Broadcasts January, 2000

where broadcast is a description of the data source. The description
can take
takes the form of an over-the-air broadcast call sign, or a
network identifier. DNS-style identifier for a particular broadcaster
or television network. For example:

tv:wqed

tv:wqed.org the WQED station
tv:nbc
tv:nbc.com 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].
[ATVEF 1.1].

3.2 Call signs DNS-style identifiers

Television broadcasts traditionally have been identified in a variety
of ways. All terrestrial television broadcasters are assigned call
signs (such as "KDKA" or "WQED") 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
Telecommunications 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 [ITU RR]).

Many modern television networks are not broadcast broadcasted over-the-air, but
available only through cable or satellite subscriptions. The
identifiers for these networks (such as the familiar CNN "CNN" and HBO) "HBO")
are not regulated at this time. The current practice is simply to
compare network identifiers against a list of those known In some countries, even over-the-air
broadcasters use these sorts of identifiers, rather than call signs.

Unfortunately, these two namespaces overlap, with most network
identifiers also being valid call signs. Furthermore, network
identifiers are not world unique, and many cases exist of name
collisions. (For example, both the Australian Broadcast Corporation
and the American Broadcasting Company identify themselves as "ABC".)
In order to be
available ensure uniqueness, the "tv:" scheme uses DNS-style
identifiers for all broadcast streams. Because these build on the receiver. Examples of such URIs include:

tv:pbs
tv:cnn
tv:hbo

The same issues apply
existing registration system for DNS hostname, all name collisions
can be resolved through the existing DNS dispute resolution
processes.

Zigmond Informational-Expires July, 2000 2

Uniform Resource Identifiers for TV Broadcasts January, 2000

In the simplest form, domain names themselves are used as broadcast
identifiers. For example:

tv:abc.com the American Broadcast Company
tv:abc.co.au the Australian Broadcast Corporation

In some cases, networks have multiple broadcast streams that need to mapping
be distinguished. This is also handled in DNS style:

tv:east.hbo.com HBO East
tv:west.hbo.com HBO West

It is important to note that these DNS-style identifiers need not
match real hostnames; they should not be resolved to tuning
frequencies IP addresses
using DNS. Thus, using the terms as are discussed defined in 3.2.

The flat namespace for network RFC 2396, the "tv:"
scheme is a Uniform Resource Identifier and not a Uniform Resource
Locator.

In order to support these identifiers poses in a serious problem
going forward. IANA registration could be "tv:" URI, a receiver must
implement a means to map known identifiers to frequencies. The nature
of this map and the way in which it is used avoid collisions,
but at are currently browser-
and device-specific and are beyond the cost scope of restricting bona fide networks with identical
identifiers from using their common abbreviations this document. In
this way, the "tv:" scheme is somewhat analogous to the "news:" and
"file:" schemes in these URIs.
Section 3.5 proposes possible directions [1]: it merely names a television broadcast signal
but assumes that the local browser has some means for resolving this
limitation.

3.4 Channel 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 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 Obsolete forms

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

Previous drafts also allowed network identifiers and call signs to
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 used directly as broadcast identifiers, as "ntsc"
for analog broadcasts in North America, or "atsc" for digital
broadcasts there), "tv:abc" 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.
"tv:kron". These hierarchical forms also will should not be important in allowing
geographically separated networks (such as the Australian Broadcast
Corporation and used because of the American Broadcast Company) to share
identifiers, and for disambiguating call signs and network
identifiers name
collision issues described 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. the previous section.

4. BNF for Television URIs

The following is a formal specification for the new URIs:

Zigmond Informational-Expires July, 2000 3

Uniform Resource Identifiers for TV Broadcasts January, 2000

tvuri = "tv:" [ broadcast ]
broadcast = call-sign | network-id
call-sign dns-identifier
dns-identifier = 1*[ alpha | digit *( domainlabel "." ) toplabel [ "." ]
network-id
domainlabel = 1*[ alpha alphanum | alphanum *( alphanum | digit "-" ) alphanum
toplabel = alpha | safe alpha *( alphanum | extra ] "-" ) alphanum

The definitions of alpha, digit, safe, alpha and extra alphanum are from [RFC 2396].
Furthermore, the definition of dns-identifier is identical the
definition of hostname in RFC 2396
[1]. Both call-sign 2396, and network-id are is 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). co-chaired), and from Craig Finseth, Gomer
Thomas, Harald Alvestrand, and Larry Masinter.

6. Security Considerations

This new URI scheme is subject to the same security implications as
the general URI scheme [1]. described in [RFC 2396]. 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. signal should alert users before performing actions that
may incur costs to the user.

7. IANA Considerations

All broadcast identifiers must be registered with IANA. IANA will use
a hierarchical allocation (see [RFC 2434]) to assign identifiers.
Only the owner of a domain may register identifiers within that
domain. For example, only HBO may register names within "hbo.com",
and only BBC may register names within "bbc.co.uk". Within their
domains, registrants will have complete freedom in their choice of
identifiers, and, as noted above, these identifiers need not match
actual hostnames. The complete list of registered broadcast
identifiers will be publicly available from IANA.

8. References

[1]

[RFC 2396] Berners-Lee, T., Fielding, R., Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 1296, 2396, August 1998.
http://www.ietf.org/rfc/rfc2396.txt

Zigmond Informational-Expires December, 1999 July, 2000 4

Uniform Resource Identifiers for TV Broadcasts June, 1999

[2] January, 2000

[ATVEF 1.1] 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]

[ITU RR] 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]

[RFC 2434] Narton, T., Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October 1998.
http://www.ietf.org/rfc/rfc2434.txt

9. Authors' Address

Dan Zigmond
WebTV Networks, Inc.
One Microsoft Way
Redmond, WA 98052
1065 La Avenida
Mountain View, CA 94043
USA

Email: djz@corp.webtv.net

Mark Vickers
Liberate Technologies
1000 Bridge Parkway
Redwood Shores,
2 Circle Star Way
San Carlos, CA 94065 94070
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 July, 2000 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

----