WDIFF

draft-zigmond-tv-url-00.txt --> draft-zigmond-tv-url-02.txt
Date: Tue, 09 Apr 2002 12:22:28 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 17 Mar 1998 16:30:00 GMT
ETag: "3ddcc6-1708-350ea508"
Accept-Ranges: bytes
Content-Length: 5896
Connection: close
Content-Type: text/plainNetwork Working Group                                       D. Zigmond
Internet-Draft
Internet Draft                                    WebTV Networks
draft-zigmond-tv-url-00.txt Networks, Inc.
Document: draft-zigmond-tv-url-02.txt                       M. Vickers
                                           Liberate Technologies, Inc.
Category: Informational                                      June 1997 1999

Internet-Draft

        Uniform Resource Locators Identifiers for Television Broadcasts

1. Status of this Document

   This document is an Internet-Draft. 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, areas, and its Working Groups. working groups. Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are working draft documents valid for a maximum of six
months. Internet-Drafts
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is not appropriate inappropriate to use
Internet-Drafts Internet- Drafts as
   reference material or to cite them other than as a
"working draft" or "work in progress."

To learn the current status

   The list of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au. can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this document is unlimited. Please send comments to
djz@corp.webtv.net.
   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 URL URI schemes described in [1] are
   inappropriate. For example, many of these devices lack local
   storage, so the "file" scheme is of little use. This draft proposes On the other hand,
   because these devices do have access to television broadcasts, this
   document describes a new URL 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 uniquely identifying streams future
   standardization of television broadcasts on
such devices. them.

Zigmond                                                              1

            Uniform Resource Identifiers for TV Broadcasts  June, 1999

3. Television URL URI

   The basic structure of a television URL URI is:

	tv:<broadacst>

        tv:<broadcast>

   where broadcast is an alpha-numeric a description of the data source.
This The description
   can take the form of an over-the-air broadcast call sign, a channel number, or a
   network indentifier. identifier. For example:

        tv:wqed    the WQED station
	tv:12		channel 12
        tv:nbc     the NBC network

For a browser

3.1. Scheme-only form

   A simplest form of the "tv:" URI scheme is used to understand non-numeric stream identifiers, 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 will
require 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 local channel "tv:" URI, a receiver must
   implement a means to map for the device. 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 draft. document. In this
   way, the "tv" "tv:" scheme is somewhat analagous analogous to the "news" "news:" and "file"
   "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. numbers or directly to

Zigmond          Informational-Expires December, 1999                2

            Uniform Resource Identifiers for TV Broadcasts  June, 1999

   frequencies.  These systems can be incorprated incorporated into television sets
   or set-top boxes to facilitate the interpretation of television URLs URIs
   by the client device.


4. BNF

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 Television URLs these networks (such as the familiar CNN and HBO)
   are not regulated at this time. The following current practice is simply to
   compare network identifiers against a formal 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 URLs:

	tvurl URIs:

      tvuri        = "tv:" [ broadcast ]
      broadcast    = call-sign | network-id | channel-number
      call-sign    = 1*[ alpha | digit ]
      network-id   = 1*[ alpha | digit | safe | extra ]
	channel-number  = 1*digit

   The definitions of alpha alpha, digit, safe, and digit extra are from RFC 1738.

The 2396
   [1]. Both call-sign must follow the conventions for broadcast call-signs
established by the International Telecommunications Union. These are
assigned by national broadcasting authorities and are universally
unique. Examples of television URLs using a call-sign are:

	tv:wqed
	tv:kqed

The network-ids are not currently assigned by an international body.
These generally define streams of video content originating from a
national network (such as NBC or CNN in the United States) which may
be sent over a variety of frequencies in different locations as well
as over a variety of media (often terrestrial broadcast, satellite
broadcast, and cable). These network-ids should be registered with
IANA before use to ensure that mutliple networks are not using the
same identifier. Conflicts between networks over identifiers will be
resolved by IANA. [Author's note: exactly how this registration will
work remains to be worked out.] Examples of television URLs using a network-id are:

	tv:nbc
	tv:cnn
	tv:bbc

Unlike call-signs and network-ids, channel-numbers are not intended to
be universally unique and simply represent a given television channel
on a particular device. When used with a channel-number, a television
URL is similar to a file URL (without a hostname) in that it describes
a purely local resource. An example of a television URL using a
channel-number is:

	tv:3


4. 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 URL URI
   scheme was developed while the author was at Wink Communications.


5.
   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 URL URI scheme is subject to the same security implications as
   the general URL URI scheme [1]. It is possible that the mere act of
   viewing a television broadcast signal may causes cause costs to be incurred
   to the viewer in some instances (eg, (e.g., "pay-per-view" movies and
   events). Any software that uses this URL 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.


6. IANA Considerations

IANA will register network identifiers for use in this URL scheme.
[Author's note: Exactly how the registration process will work and how
disputes between registrants will be resolved has not yet been
decided.]

7. References

   [1] Berners-Lee, T., Fielding, R., Masinter, L., McCahill, M. (editors), "Uniform  Resource Locators (URL)",
   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 1738, December 1994.
ftp://ds.internic.net/rfc/rfc1738.txt 2434, October 1998.
   http://www.ietf.org/rfc/rfc2434.txt

8. Author's Authors' Address

   Dan Zigmond
   WebTV Networks
305 Lytton Avenue
Palo Alto CA 94301 Networks, Inc.
   One Microsoft Way
   Redmond, WA 98052
   USA

   Email: djz@corp.webtv.net
Voice: +1-415-614-6071
Fax: +1-415-463-1670

   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
----