GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2838

Network Working Group D. Zigmond Request for Comments: 2838 WebTV Networks, Inc. Category: Informational M. Vickers

                                          Liberate Technologies, Inc.
                                                             May 2000
      Uniform Resource Identifiers for Television Broadcasts

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2000).  All Rights Reserved.

1. 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. In
 this context there is a need to reference television broadcasts using
 the URI format described in [RFC 2396]. This document describes a
 widely-implemented URI scheme to refer to such broadcasts.

2. Television URI

 The basic structure of a television URI is:
      tv:<broadcast>
 where broadcast is a description of the data source. The description
 takes the form of a DNS-style identifier for a particular broadcaster
 or television network. For example:
      tv:wqed.org           the WQED station
      tv:nbc.com            the NBC network

Zigmond & Vickers Informational [Page 1] RFC 2838 URIs for TV Broadcasts May 2000

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

3.2 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
 Telecommunications Union, which assigns portions to member countries
 (see [ITU RR]).
 Many modern television networks are not broadcasted 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.  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 ensure uniqueness, the "tv:" scheme uses DNS-style
 identifiers for all broadcast streams.  Because these build on the
 existing registration system for DNS hostname, all name collisions
 can be resolved through the existing DNS dispute resolution
 processes.

Zigmond & Vickers Informational [Page 2] RFC 2838 URIs for TV Broadcasts May 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
 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 IP addresses
 using DNS.  Thus, using the terms as defined in RFC 2396, the "tv:"
 scheme is a Uniform Resource Identifier and not a Uniform Resource
 Locator.
 In order to support these identifiers in a "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 are currently browser-
 and device-specific and are 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 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.
 Previous drafts also allowed network identifiers and call signs to be
 used directly as broadcast identifiers, as in "tv:abc" and "tv:kron".
 These forms should not be used because of the name collision issues
 described in the previous section.

Zigmond & Vickers Informational [Page 3] RFC 2838 URIs for TV Broadcasts May 2000

4. BNF for Television URIs

 The following is a formal specification for the new URIs:
    tvuri          = "tv:" [ broadcast ]
    broadcast      = dns-identifier
    dns-identifier = *( domainlabel "." ) toplabel [ "." ]
    domainlabel    = alphanum | alphanum *( alphanum | "-" ) alphanum
    toplabel       = alpha | alpha *( alphanum | "-" ) alphanum
 The definitions of alpha and alphanum are from [RFC 2396].
 Furthermore, the definition of dns-identifier is identical to the
 definition of hostname in RFC 2396, and 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), 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 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. References

 [RFC 2396]  Berners T., Fielding, R. and L. Masinter,   "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.
 [ATVEF 1.1] Advanced Television Enhancement Forum, "Advanced
             Television Enhancement Forum Specification Version
             1.1r26," February 1999.
             http://www.atvef.com/library/spec1_1a.html

Zigmond & Vickers Informational [Page 4] RFC 2838 URIs for TV Broadcasts May 2000

 [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."

9. Authors' Addresses

 Dan Zigmond
 WebTV Networks, Inc.
 1065 La Avenida
 Mountain View, CA 94043
 USA
 EMail: djz@corp.webtv.net
 Mark Vickers
 Liberate Technologies
 2 Circle Star Way
 San Carlos, CA  94070
 USA
 EMail: mav@liberate.com

Zigmond & Vickers Informational [Page 5] RFC 2838 URIs for TV Broadcasts May 2000

10. Full Copyright Statement

 Copyright (C) The Internet Society (2000).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Zigmond & Vickers Informational [Page 6]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2838.txt · Last modified: 2000/05/24 22:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki