NOTE-TVWeb-URI-Requirements-19991021 26.4 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
                      "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  <title>Requirements TV Broadcast URI Schemes</title>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/W3C-NOTE">
</head>

<body>

<div class="head">
<a href="http://www.w3.org/"><img height="48" width="72"
src="/Icons/WWW/w3c_home" alt="W3C">
</a>

<h1>TV Broadcast URI Schemes<br>
Requirements</h1>

<h2>W3C Note 21 October 1999</h2>
<dl>
  <dt>This version:</dt>
    <dd><a class="loc"
      href="http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991021">http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991021</a></dd>
  <dt>Latest version:</dt>
    <dd><a class="loc"
      href="http://www.w3.org/TR/TVWeb-URI-Requirements">http://www.w3.org/TR/TVWeb-URI-Requirements</a></dd>
  <dt>Previous version:</dt>
    <dd><a class="loc"
      href="http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991019">http://www.w3.org/TR/1999/NOTE-TVWeb-URI-Requirements-19991019</a></dd>
  <dt>Editors:</dt>
    <dd><span class="author"><span class="name">Warner ten Kate</span>
      <i>(<span class="email"><a
      href="mailto:warner.ten.kate@philips.com">warner.ten.kate@philips.com</a></span>)</i></span></dd>
    <dd><span class="author"><span class="name">Gomar Thomas</span> <i>(<span
      class="email"><a
      href="mailto:gomer@lgerca.com">gomer@lgerca.com</a></span>)</i></span></dd>
    <dd><span class="author"><span class="name">Craig Finseth</span> <i>(<span
      class="email"><a
      href="mailto:craig@finseth.com">craig@finseth.com</a></span>)</i></span></dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
&copy; 1999 <a href="http://www.w3.org/">W3C</a> (<a
href="http://www.lcs.mit.edu/">MIT</a>, <a
href="http://www.inria.fr/">INRIA</a>, <a
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> and <a
href="http://www.w3.org/Consortium/Legal/copyright-software">software
licensing</a> rules apply.</p>
</div>

<p></p>
<hr title="Separator from Header">


<h2>Status of this document</h2>

<p>This Note was produced by the W3C TV-Web Interest Group. It is the result
of discussions on URI schemes suited for use in TV Broadcast environments. The
document reflects preliminary results, and is intended to serve as a base to
further work to design TV Broadcast URIs. Please send comments to the TV-Web
mailing list <a href="mailto:www-tv@w3.org">www-tv@w3.org</a>.</p>

<p>This version is an update of the version dated 19 October 1999, fixing a wrong link.</p>

<p>Publication of a W3C Note does not imply endorsement by the entire W3C
Membership.  A list of current W3C technical reports and publications,
including Working Drafts and Notes, can be found at <a
href="http://www.w3.org/TR">http://www.w3.org/TR</a>.</p>

<p lang="en" style="font-style: italic">This section represents the status of
this document at the time this version was published. It will become outdated
if and when a new version is published.</p>

<h2>Table of Contents</h2>
<dl>
    <dd><a href="#Abstract">Abstract</a></dd>
    <dd><a href="#Definitions">1. TV Broadcast: Definition and scope</a></dd>
    <dd><a href="#Applications">2. Application Scenarios</a></dd>
    <dd><a href="#Requirements">3. Requirements on Global TV Broadcast URI
      schemes</a></dd>
    <dd><a href="#Exceptions">4. Exceptions in TV Broadcast URIs</a></dd>
    <dd><a href="#References">References</a></dd>
</dl>

<h2><a name="Abstract">Abstract</a></h2>

<p>This document is an informational document and discusses the requirements
posed to URI schemes for identifying resources in Television (TV) Broadcast
environments. The document is the outcome of discussions on this subject by
the W3C TV-Web Interest Group [TVWebIG, TVWebMail].</p>

<p>Typical use cases are summarized where TV Broadcast URIs are involved. A
distinction is made between Global and Local usage. Also, a hierarchy of
resource types is identified. Requirements related to the Global usage case
are listed.</p>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

<h2 class="notoc"><a name="Definitions">1. TV Broadcast: Definition and
scope</a></h2>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->

<h5 class="notoc">Definition of TV Broadcast</h5>

<p>In this document <em>TV Broadcast</em> is used as the generic term to refer
to currently existing TV systems, their transport protocols, and their typical
operation of content provision and distribution. TV Broadcast concerns both
digital and analog systems and includes systems like DVB, ATSC, DSS, NTSC, and
PAL. The TV Broadcast "network layer" is typically non-IP based.</p>

<p>The term <em>TV Broadcast URI</em> refers to URIs which identify, and
possibly locate, TV Broadcast content. In this document "<em>URI</em>" is used
to indicate TV Broadcast URI.</p>

<p>Typically, TV Broadcast systems are push systems. The content streamed
along a TV Broadcast transport is scheduled by the service provider; the user
has no influence on that. In this model the user accesses the stream(s) rather
than the server at the upstream station.</p>

<h5 class="notoc">Hierarchy in TV Broadcast content</h5>

<p>TV Broadcast content is modeled in a four-layer hierachy, consisting of
service, event, component, and fragment. Service is at the top, fragment is at
the bottom of the hierarchy.</p>

<p>The term <em>service</em> is used to refer to a concatenation of programs,
all being broadcast by the same service provider. The programs of a service
share some tuning characteristics. Service corresponds to the naming "channel"
as used in today's analog TV.</p>

<p>The term <em>event</em> is used to refer to a single TV program. An event
consumes a time period within a service and therefore can be characterized
with begin and end times. The service provider determines the granularity in
which the service is split in events. An event can be a complete program or an
episode of a program. Events can be grouped in series, e.g., to form a serial.
Events are the typical entities which EPGs list to present program schedule
information.</p>

<p>The term <em>component</em> is used to refer the constituents of an event.
The audio and video of a TV program are obvious examples. In case of
multilingual programs there are multiple audio components. In case of
interactive programs the components are the application documents and the
other data these applications are using. Next to continuous data like audio
and video, component also encompasses discrete data like Web pages and
applications describing composition and interactivity. The URI identifying an
application can constitute the base URI for the further components referenced
by that application.</p>

<p>The term <em>fragment</em> is used to refer to a subpart of a component.
For instance, it can be a slice of a video sequence, or a subregion in an
image.</p>

<p>Due to the push character of TV Broadcast there are <em>two dimensions of
hierarchy</em>, a schedule related and a content related. The first is the
hierarchy of transport system, transport stream, service, series, event; The
second is the hierarchy of series, event, component, fragment.</p>

<p>The term <em>resource</em> is to be understood as in RFC 2396, sec.1.1
[RFC2396]. In the context of TV Broadcast a resource refers to the entities
service, event, component, and fragment in particular.</p>

<h5 class="notoc">Setting and usage of TV Broadcast URIs</h5>

<p>TV Broadcast applications need a mechanism to identify and locate the
components building the application. The URI scheme is a useful tool for that
as it opens possibilities for seamless transition in referencing resources at
TV Broadcast transport and Internet sites. URI schemes to locate resources at
the Internet are well-known, and are not further observed in this document.
URI schemes to locate resources in a TV Broadcast transport channel have been
proposed, but most are designed with a particular TV Broadcast transport
environment in mind.</p>

<p>Next to locating components at TV Broadcast transport channels, another
aspect of TV Broadcast URIs concerns referencing the events. In the first
place, events are accessible at the TV Broadcast transport channel, possibly
at several channels and at multiple periods of time. The above mentioned URI
schemes also address this aspect, but all in their own way. In the second
place, the content may be stored and made available through another path than
the TV Broadcast transport channel. Most evident are local storage, like
VCR-type of devices, and the Internet itself. Local storage devices can be
connected through an in-home network to the user agent presenting the
application. Local storage in the sense of the client's local file system or
in the sense of cache buffering are not observed in this document.</p>

<p>TV Broadcast content delivered through a so-called IP-tunnel is considered
as content made available through the Internet. An IP-tunnel refers to a
forwarding path which is logically separated from the conventional TV
Broadcast transport protocol but uses the same physical transmission link.</p>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

<h2 class="notoc"><a name="Applications">2. Application Scenarios</a></h2>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->

<h5 class="notoc">Application types, further definition and scope</h5>

<p>Applications can be distinguished in usage of URIs for Global and Local
scope.</p>

<p><em>Global</em> refers to URIs contained in documents which can be accessed
anywhere around the world, and which identify content related to any TV
Broadcast system in the world, including storage devices associated with that
TV Broadcast system. Such a global URI may include identification of the TV
Broadcast system to be used.</p>

<p><em>Local</em> refers to URIs contained in documents which are accessed
within a certain TV Broadcast system, and which identify content to be
accessed through that TV Broadcast system. URIs that reference content outside
the local TV Broadcast system, are assumed to be either Global URIs or
traditional URIs for locating resources at the Internet.</p>

<p>This document concentrates on Global URIs, as those have a world-wide
interest for standardization. It would be nice when Local URIs bear an
identical format, but that is considered not a necessary requirement. Local
URIs can be specified within their respective application domains. On the
other hand, it would be nice when Global URIs can serve as a base URI for
Local URIs, either as direct copy or by some mapping function. <!--
This document doesn't list requirements for Local URIs.
[An example of such a requirement could be:
The URI MUST be able to refer to the associated audio/video image
of which the application document forms a part.]
-->
</p>

<p>Further, URIs can be distinguished in identifying a service or event, and
in identifying a particular content item (component or fragment) in such a
service or event. This reflects the two dimensions observed above of schedule
related and content related hierarchy. The use cases where a content item in a
certain service is to be identified while the context isn't already that
service, seem rare. Consequently, a URI is not required to carry both
informations (service and content item) together.</p>

<p>This distinction suggests that identification of a particular content item
belongs to the Local class of URIs, and that Global URIs typically identify a
service or an event. However, an exception can be found in the case where the
same content item is referenced in various transport contexts, e.g. in a
commercial.</p>

<p>An important class of Global URIs identify their resource in a location and
time independent way, i.e. independent of the particular TV Broadcast
transport system and particular schedule. For instance, they are also valid
after local storage. As such, they resemble URN behavior, opposed to URL
behavior.</p>

<p>As the set of resources and their various locations can scale to large
numbers, it is preferred that the URI scheme imposes a hierarchical structure,
certainly when the URI's purpose is to locate a resource. A hierarchy allows
for step-by-step resolution and navigation to the resource identified. By
that, efficiency and scalability is improved. Further, implying a hierarchical
structure allows to group resources, and by that to distinguish between, for
example, in identifying a serial and an event in that serial.</p>

<h5 class="notoc">Use cases, both Local and Global URI</h5>
Below, some representative use cases are listed. An exhaustive list of
application scenarios is provided in [USECASES].
<ol>
  <li>Basic EPG type of locating:<br>
    Reference TV Broadcast services and events from a Web page for navigating
    to them. The references are tolerant to modifications in the actual
    transmission schedule, but a coarse indication can be derived. The
    broadcast program can be indicated through tuning data or through naming.
    Next to navigation to the program, the EPG also supports for setting
    reminders or recording of programs. Instead of a single program, the
    serial of which the program is part, is referred to, such that setting a
    reminder or a recording for all episodes can be accomplished.
    <p></p>
    It is the year 2002. Fox is broadcasting a World Cup game from South Korea
    in both analog and digital formats, with the broadcast reaching North
    America, Europe, Africa, Asia, Latin America, Australia, etc., through a
    wide variety of local affiliates and re-broadcast operators.  Fox wishes
    to put a hyperlink to the broadcast on its web site, so that users of
    Internet-connected TV receivers all over the world with the right software
    (perhaps native, perhaps downloaded) can click on the hyperlink and have
    their receivers tune to the broadcast (or set a reminder for the
    broadcast, if the game is not currently on).</li>
  <li>A sports fanatic wants to watch all the above broadcasts by Fox.
    Therefore he records all the broadcasts and copies the above Fox World Cup
    page to his local disc. From that page he can access the broadcasts or,
    when they have been recorded, view them from his recording device. At its
    site Fox also provides the transmitted broadcasts, albeit at high
    compression rates. The page will direct users who haven't recorded the
    broadcast to these videos.</li>
  <li>A Web page is composed for presentation on a TV Broadcast receiver. The
    Web page is delivered in association with a TV Broadcast program (the
    transmission paths may be physically separated). The Web page includes an
    object which refers to the associated audio/video image of the TV
    broadcast program.</li>
  <li>In a Web page a TV Broadcast event is referred, but the exact location
    is not known at authoring time. The URI is incomplete in its information.
    Instead a query is added to retrieve the missing information. When the
    available TV Broadcast system supports the query mechanism, the URI can be
    resolved and the identified resource can be retrieved. The query language
    is technology-independent, i.e. it is not relying on specific fields, such
    as SI data, in the TV Broadcast transmission system. <br>
    Examples are:
    <pre>     dtv://?program=X-Files
                                                 dtv://ABC/?lang=sp
                                                </pre>
  </li>
  <li>A TV Broadcast of a soccer match is data-enhanced; in a data carousel
    module or an encapsulated IP datagram a file is contained which gives
    up-to-the-second statistics on goals scored, fouls committed, corner kicks
    taken, shots at goal, shots on goal, etc. The broadcaster wants to put a
    URI on their web site which references this file, allowing applications on
    Internet-connected TV receivers all over the world to get to the file and
    display it in nifty ways.</li>
  <li>A data file is transmitted along with a TV program, the data file is
    containing additional information to that program. It also contains
    hyperlinks to the programs and/or data in other data files being broadcast
    on the same channel and in other channels, so that receivers can set
    reminders for the upcoming game and/or data file.</li>
  <li>A Web page is transmitted with a TV Broadcast commercial. The commercial
    is about an upcoming TV Broadcast program. The viewer can click a hotspot
    area such as to set a reminder for that program. The Web page can also be
    accessed at the broadcaster's Web site.</li>
  <li>A set of three Web page is transmitted with a TV Broadcast commercial.
    The viewer can navigate the three pages. The pages are transmitted
    frequently along various TV Broadcast systems. The pages can also be
    accessed at the advertiser's Web site, where they are maintained at a
    particular sub directory. Therefore, the advertiser uses relative
    referencing between the pages.</li>
  <li>A live quiz show is enhanced such that the viewer can play along. The
    enhancement data are a mixture of Web pages, which compose the quiz's
    question and answer environment, element values, which carry the actual
    questions and (correct) answers to be inserted in the Web pages, and
    procedural cells to control the viewer's score. The Web pages are provided
    at a Web site long before the show is aired, such that viewers can
    prepare. The element values are transported along the TV Broadcast
    transmission channel during the show. They are synchronized with the
    actions in the show such as to complete and update the application.<br>
    There are several levels of play along: some pages provide the viewer with
    hints such as to ease answering, and some pages provide less alternatives
    in the multiple choice questions. The viewer can select his level by
    navigating between these pages.<br>
    Upon the actual broadcast an application is broadcast with the program to
    initiate the enhancement. The application references the Web site, such
    that upon tuning to the TV Broadcast the Web site's home page gets
    retrieved. Triggered by stream events in the TV Broadcast transport
    stream, the application also controls the insertion of element values
    (questions and answers) and the score management (e.g., no score increment
    after answer presentation).</li>
  <li>A Web site provides a EPG covering programs transmitted world-wide. A
    viewer is visiting this site and browses the EPG. Upon encountering his
    favorite movie "Once upon a time in the Cyber" he clicks the item on the
    EPG. Regretfully, the movie isn't scheduled for the 419 TV Broadcast
    satellites his receiver is configured to. Instead of setting a reminder,
    the receiver informs the user the movie will not appear on his reception
    links.</li>
</ol>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

<h2 class="notoc"><a name="Requirements">3. Requirements on Global TV
Broadcast URI schemes</a></h2>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->

<h5 class="notoc">Conventions used in this document</h5>

<p>In this document three levels of priority are used to indicate the
desirability of a requirement.</p>
<dl>
  <dt><strong>MUST</strong></dt>
    <dd>The key word "MUST" is to be understood as an essential and critical
      requirement.</dd>
  <dt><strong>SHOULD</strong></dt>
    <dd>The key word "SHOULD" indicates an important requirement.</dd>
  <dt><strong>MAY</strong></dt>
    <dd>The key word "MAY" indicates a useful feature.</dd>
</dl>

<p>[These key words and their meaning are based upon RFC 2119 [RFC2119]. That
RFC specifies similar wording for implementation compliance with a protocol
specification. In this document the wording reflects specification compliance
with protocol goals.] <!-- RFC 2119 wording:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as decribed in RFC 2119 [RFC2119].-->
</p>

<h5 class="notoc">Requirements</h5>
<ol>
  <li>The URI scheme MUST comply with RFC 2396 [RFC2396].</li>
  <li>Where the URI serves as a name identifier (URN), the corresponding URN
    specifications MUST be taken into account, e.g. [RFC2141, RFC2168].</li>
  <li>Where the URI serves as a locator identifier (URL), the definition of
    the URI scheme MUST follow the guidelines as set forth in [URLGUIDE].</li>
  <li>The URI MAY support queries to be posed to the TV Broadcast receiver.
    The query language MUST be independent to the TV Broadcast system.</li>
  <li>The URI scheme SHOULD support relative referencing such that a
    TV-program with all its associated resources can be referenced against a
    common base, which is the TV Broadcast URI of that aggregate.</li>
  <li>Where the URI serves as a locator identifier (URL), the URI scheme
    SHOULD include a hierarchical structure either to identify the resoure as
    a service or an event from a service, or to identify the resource as an
    event, a component from an event, or a fragment from a component. The
    structure SHOULD provide optional levels to group events into series or
    serials and to group components into composites.<br>
    Where the URI serves as a name identifier (URN), the URI scheme MAY
    include such hierarchical structure.</li>
  <li>The URI scheme SHOULD support the spectrum of transport protocols
    applied and standardized in TV Broadcast systems. This includes both
    audio/video and data broadcast protocols.</li>
  <li>A URI MUST be invariant with respect to the normal range of transport
    stream transformations along the path from provider to user, both in
    referencing the time and the location of the resource in that transport
    stream.</li>
  <li>Given a URI, it MUST be possible for a receiver to actually locate the
    resource, or conclude that it is not reachable.</li>
  <li>A URI MUST be meaningful when interpreted, independent of the
    transmission context in which the URI is called. Transmission context
    refers to a coherent set of content streams as they arrive at the
    receiver. An example is a set of TV broadcast services sharing a same
    physical connection; another is an Internet connection. In case the
    context is the same transmission system as in which the content is
    located, the URI MUST be resolvable.</li>
  <li>Where the URI serves as a name identifier (URN), it SHOULD be resolvable
    under any of the following network access conditions:
    <ol>
      <li>TV Broadcast</li>
      <li>Internet</li>
      <li>In Home/local storage</li>
    </ol>
    The actual resource's retrieved content data MAY differ in terms of
    content encoding, content quality, performance, and edit version.</li>
  <li>Where the URI serves as a name identifier (URN), the scheme MUST support
    referencing various instantiations of the same content (encoding,
    quality/compression ratio, versions/edits).</li>
  <li>Any actual scheme SHOULD be coordinated with standardisation bodies such
    as ATSC, DVB, and DAVIC, and SHOULD be reasonably acceptable to those
    bodies.</li>
  <li>The URI scheme MUST interoperate with the Internet access schemes, such
    as to enable seamless transition in referencing resources at TV Broadcast
    or Internet sites.</li>
</ol>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

<h2 class="notoc"><a name="Exceptions">4. Exceptions in TV Broadcast
URIs</a></h2>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
TV Broadcast differs from the conventional Internet in several ways. The TV
Broadcast URI scheme is affected by that in the following aspects:
<ol>
  <li>The host is not necessarily a server identifiable through an IP-address.
    For instance, the "host" is a transport stream.</li>
  <li>The resource access and retrieval scheme is not necessarily IP-stack
    based.</li>
  <li>The resource's availability implicitly depends on, or at least relates
    to, a transmission schedule.</li>
</ol>

<p>Because TV Broadcast is a resource constrained environment, it is
worthwhile to keep the length of the URI limited. This document does not pose
a requirement on a maximum length of a TV Broadcast URI. It is left to the
particular application domain to specify such limitations.</p>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->

<h2><a name="References">References</a></h2>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%-->
<dl>
  <dt>[RFC2119] <a
  href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2119.txt">
  <i>Key words for use in RFCs to Indicate Requirement Levels</i></a>,</dt>
    <dd>RFC 2119, S. Bradner. March 1997.</dd>
  <dt>[TVWebIG] <a href="http://www.w3.org/TV/TVWeb/"> <i>W3C TVWeb Interest
  Group</i></a>,</dt>
    <dd>Group page of the W3C TV-Web IG. Philipp Hoschka.</dd>
  <dt>[TVWebMail] <a href="http://lists.w3.org/Archives/Public/www-tv/">
  <i>TV-Web Mail Archives</i></a>,</dt>
    <dd>Threads starting with messages 0040, 0041, and 0046. Oct/Nov 1998.
      <br>
      &lt;http://lists.w3.org/Archives/Public/www-tv/>.</dd>
  <dt>[RFC2396] <a
  href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2396.txt">
  <i>Uniform Resource Identifiers (URI): Generic Syntax</i></a>,</dt>
    <dd>RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter. Aug. 1998.</dd>
  <dt>[RFC2141] <a
  href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2141.txt">
  <i>URN Syntax</i></a>,</dt>
    <dd>RFC 2141, R. Moats. May 1997.</dd>
  <dt>[RFC2168] <a
  href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc2168.txt">
  <i>Resolution of Uniform Resource Identifiers using the Domain Name
  System</i></a>,</dt>
    <dd>RFC 2168, R. Daniel, M. Mealling. June 1997.</dd>
  <dt>[URLGUIDE] <a
  href="http://info.internet.isi.edu/in-drafts/files/draft-ietf-urlreg-guide-05.txt">
  <i>Guidelines for new URL Schemes</i></a>,</dt>
    <dd>Internet-Draft, L. Masinter, H.T. Alvestrand, D. Zigmond, R. Petke.
      March 1999.</dd>
  <dt>[USECASES] <a
  href="http://lists.w3.org/Archives/Public/www-tv/1998OctDec/0224.html">
  <i>Applications list</i></a>,</dt>
    <dd>Posting to the TV-Web IG, C. Finseth. December 1998.</dd>
</dl>
</body>
</html>