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