RFC 2838

Uniform Resource Identifiers for Television Broadcasts

📅 published May 2000, from ietf

RFC 2838: Uniform Resource Identifiers for Television Broadcasts 📺✨

okay bestie, this is RFC 2838 🎀 It's titled "Uniform Resource Identifiers for Television Broadcasts," and it's from May 2000. The network working group published it as Informational, so it's just sharing info with the internet community and isn't a standard 💅. The authors are D. Zigmond (WebTV Networks, Inc.) and M. Vickers (Liberate Technologies, Inc.). The title block doesn't list anything it obsoletes or updates, so it's a standalone doc 🫶

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 (C) The Internet Society (2000). All Rights Reserved.

1. Introduction 🦋

okay so browsers are showing up on all kinds of consumer electronics now, like TV sets and set-top boxes that can pick up TV shows from over-the-air broadcast, satellite, or cable 📡 That means there's a real need to point at TV broadcasts using the URI format from [RFC 2396]. This doc describes a URI scheme that's already widely implemented for doing exactly that, and it's giving main character energy 👑

2. Television URI 🎀

the basic shape of a television URI is:

tv:<broadcast>

where broadcast describes the data source. The description is a DNS-style identifier for a particular broadcaster or TV network. For example:

tv:wqed.org           the WQED station
tv:nbc.com            the NBC network

3.1. Scheme-only form 🧚

the simplest version of the tv: scheme points at the "current" or "default" channel:

tv:

this means whichever TV broadcast the device is currently receiving. It's used a lot alongside HTML content that's actually being broadcast with the audio and video, where "current broadcast" is super unambiguous, because it's the broadcast the content came in with 🙈 This is honestly the most common use of tv: today, and the recently published ATVEF 1.1 spec explicitly references it [ATVEF 1.1]. iconic 💅

3.2. DNS-style identifiers 🍓

TV broadcasts have traditionally been identified in a bunch of different ways. Every terrestrial broadcaster gets a call sign (like "KDKA" or "WQED") to identify its signal. These are usually handed out by national authorities, like the Federal Communications Commission in the US, and they're world unique. The global namespace is managed by the International Telecommunications Union, which hands out chunks to member countries (see [ITU RR]).

lowkey messy part: a lot of modern TV networks don't go over the air. They're only available through cable or satellite subscriptions. Identifiers for these networks (like the super familiar "CNN" and "HBO") aren't regulated right now. In some countries, even over-the-air broadcasters use these kinds of identifiers instead of call signs 😭

the two namespaces overlap, and most network identifiers are also valid call signs. Network identifiers also aren't world unique, so name collisions happen a lot. (For example, both the Australian Broadcast Corporation and the American Broadcasting Company call themselves "ABC".) To make sure everything is unique, the tv: scheme uses DNS-style identifiers for every broadcast stream. Since these build on the existing DNS hostname registration system, any name collisions can be resolved through the existing DNS dispute resolution processes ⚖️

in the simplest form, domain names themselves are the broadcast identifiers:

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

sometimes a network has multiple streams that need telling apart, and that's handled in DNS style too:

tv:east.hbo.com     HBO East
tv:west.hbo.com     HBO West
⚠️ these DNS-style identifiers don't need to match real hostnames, and they should not be resolved to IP addresses using DNS. So, using the terms from RFC 2396, the tv: scheme is a Uniform Resource Identifier and not a Uniform Resource Locator.

to support these identifiers in a tv: URI, a receiver must have a way to map known identifiers to frequencies. How that map works and how it gets used is browser- and device-specific right now, and it's beyond the scope of this document 🤷‍♀️ So the tv: scheme is kinda like the "news:" and "file:" schemes in [1]. It just names a TV broadcast signal, and it assumes the local browser has some way to actually retrieve that signal on the device. Lots of software systems already provide device-specific mappings from these identifiers to channel numbers or straight to frequencies. Those systems can be built into TV sets or set-top boxes to help client devices interpret tv: URIs ✨

3.3. Obsolete forms 🥀

earlier drafts of this spec let broadcasts be identified by channel numbers, like tv:4, and that form is still supported by several independent platforms. The channel numbers generally line up with tuning frequencies in the various national broadcast frequency standards. For example, tv:4 in the United states would be found at 66 MHz. But since the mapping of channel numbers to frequencies changes from country to country, this form is really ill-suited for use on the Internet 🙃

earlier drafts also let network identifiers and call signs be used directly as broadcast identifiers, like tv:abc and tv:kron. These forms should not be used, because of the name collision issues from the previous section 🚫

4. BNF for Television URIs 💖

here's the formal spec 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 come from [RFC 2396]. Also, dns-identifier is identical to the definition of hostname in RFC 2396, and it's case-insensitive 🧠

5. Acknowledgments 🫶

a lot of the ideas in this doc came out of conversations with Andrew Lochart. Other people who gave 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 came 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. ily all of you 💜

6. Security Considerations 💀

this new URI scheme has the same security implications as the general URI scheme described in [RFC 2396]. It's possible that just watching a TV broadcast signal could cost the viewer money in some cases (like "pay-per-view" movies and events) 💸 Any software that uses this URI scheme to automatically tune a client device to a particular TV broadcast signal should alert users before doing anything that might cost them money.

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`

[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

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.

📦 where this page comes from