- From: Craig A. Finseth <fin@finseth.com>
- Date: Mon, 14 Dec 1998 12:21:58 -0600 (CST)
- To: www-tv@w3.org, ph@w3.org
INTERNET-DRAFT C. Finseth
U.S. Satellite Broadcasting
G. Thomas
LGERCA, Inc.
14 December 1998
An Example Instantiation of the TV Broadcast URI Scheme for ATSC
draft-?????-tvweb-uri-instance-00.txt
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to
www-tv@w3.org.
This is work in progress by the W3C TV-Web Interest Group [1]. This
group discusses technological aspects concerning usage of Web
technology in TV Broadcast environments. As such, it aims to specify
a URI scheme for identifying resources in a TV Broadcast environment.
This document is also maintained at that group's web page [2].
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document provides an example instantiation for the ATSC
television system of the URI scheme specified in [1]. This example
is not part of the specification, but serves to aid the the
understanding of that specification.
Finseth, Thomas [Page 1]
INTERNET-DRAFT An Example Instantiation... 14 December 1998
Syntax
URI tags are encoded in the form of descriptors. One tag is stored
per descriptor. Those places where more than one tag is associated
with a resource should list multiple descriptors.
Each descriptor is of the form:
descriptor_tag 8 bits value to be assigned
descriptor_length 8 bits
URI N*8 bits
The URI is limited to 240 characters in length. This length does not
include the query portion of the URL.
This limitation permits future uses of this tag to include
up to 15 bytes of tag-specific data to be included in the
same tag.
Receivers that do not implement these URIs may silently discard these
tags.
To be done: revisit applicable PSIP size limits to ensure
that the various tables can hold a tasteful assortment of
URI tags.
Tag Usage
This section lists each resource and documents how it is tagged.
1. A transmission multiplex.
The tag is placed in the descriptor loop at the end of the VCT
(Virtual Channel Table) for the multiplex.
2. A particular virtual channel.
The tag is placed in the virtual channel's descriptor loop in the VCT
(Virtual Channel Table) for the multiplex.
Option: We can provide an "abreviation" mechanism (e.g., a
zero-length descriptor) which the receiver can expand into
a URI of the form:
btv://<short_name>.com
Note: again, the particular elementary stream usage has
Finseth, Thomas [Page 2]
INTERNET-DRAFT An Example Instantiation... 14 December 1998
been dropped.
If we were to reinstate it, the following notes apply.
The correct thing to do is to extend the service location
descriptor to have an embedded descriptor loop and put the
URI tag there.
As this is not possible, we will define a service location
URI descriptor which combines both URI and and service
location descriptor information. The receiver will use the
"real" service location descriptor for the actual access,
but the service location URI descriptor for matching the
URI to the resource.
Redundant, but it works. We may be able to come up with
something better.
The next block all place their tags in the per-event descriptor loop
in the appropriate EIT (Event Information Table). They differ only
in the placement of the tags and the "meaning" attached to the tags.
3. A collection of event material.
4. A particular episode of a event series.
5. A particular showing of a event.
6. Event material that appears someplace in the time/virtual
channel/provider continuum.
7. A particular once-only event.
Earlier drafts referred to the desire to specify offsets
within events. We were unable to determine any real-world
places where this functionality would be used, so we
dropped it. We can restore it if any real world usages
come to light.
8. A particular application.
The tag is placed with the application in the SDT (Service
Description Table). This placement will require that a descriptor
loop be added to the applications loop in the ServiceDescription. In
the event that an application has more than one URI tag, the _f_i_r_s_t
one is the default Base URI.
If the application URI uses the relative form, it forms its URI from
Finseth, Thomas [Page 3]
INTERNET-DRAFT An Example Instantiation... 14 December 1998
the first URI in the containing event plus the relative form URI.
This new URI is the default Base URI.
If the application has no URI, it forms its URI from the first URI in
the containing event plus the application name. This new URI is the
default Base URI.
9. A particular data item referenced by an application.
Depending upon the data that is being labelled, the tag is place in
one of these places:
- With the resource in the SDT. This placement will require that a
descriptor loop be added _within_ the taps loop in the
ServiceDescription. (Each tap must be able to have a _l_i_s_t of URI
tags.)
- In the moduleInfoBytes structure. This placement will require that
a descriptor loop be added.
Sidenote: there should be a field to carry the other HTTP
headers (in addition to MIME type). MIME type should be
separated, however, for ease of parsing.
ATSC implementations should permit resource URIs to be expressed
relative to their application Base URI where appropriate. For
example, if an appliction has a (Base) URI of:
btv://foo.com/application
and it refers to these modules:
btv://foo.com/application/name1
btv://foo.com/application/name2/name3
btv://foo.com/application/name2/name4
btv://foo.com/name5
btv://bar.com/name6
The first three could be coded in the SDT as:
btv:name1
btv:name2/name3
btv:name2/name4
Thus saving space. Relative forms are not permitted for the last
two.
Further, if there were a data carousel named "name2" with modules
Finseth, Thomas [Page 4]
INTERNET-DRAFT An Example Instantiation... 14 December 1998
named "name3" and "name4", the URI tags for those modules could be
completely omitted.
Referencing Other Data
It is permissible for the broadcaster to tag resources with URI
strings that do not start with "btv:". In such cases, the receiver
should record those tags and use them for matching just like "btv:"
tags. The difference is if the URI tag is not found and does not
start with "btv:", the receiver should use the scheme stated by the
scheme selector to (attempt to) access the data (if the receiver
supports that method).
Essentially, this usage permits the broadcaster to "prime the cache"
of a receiver.
For example, if a receiver were to see data marked with:
http://www.disney.com
and the viewer were to activate a reference such as:
...<a href="http://www.disney.com">...
it could use the received data directly instead of accessing the
Internet and downloading the page. Since the scheme is not "btv:",
if the receiver did not happen to have this page cached, it should
attempt to access the data as it normally would.
Optimizations
This section describes some steps that can be performed to improve
performance.
First, the simplest of receivers can stay simple. Such a receiver
supports only one virtual channel at a time. To operate at all, it
must have the PSIP and data information for the current virtual
channel cached. As the PSIP and data structures contain the URI
information, URIs for all locatable resources are thus in a small set
of in-memory tables. It should be fast and easy to search these
tables.
Second, an advanced receiver can also perform efficiently. Such a
receiver may visit all available multiplexes to determine what
choices are available. These receivers would then cache essential
information from all multiplexes for efficient access.
For each multiplex visited, the receiver could:
Finseth, Thomas [Page 5]
INTERNET-DRAFT An Example Instantiation... 14 December 1998
- identify all URI tags
- build a sorted, uniqued list of the tags
It can then readily identify which multiplex has a given URI.
The receiver could could stop here. Or, it could do a little more
work and save some memory. This extra work takes advantage of the
hierarchical nature of the URLs so that the receiver can eliminate
much of the detail while preserving most of the value.
- for each URI, extract just the authority value
- build a sorted, uniqued list of the authority values
Again, it could stop here (and probably would). It might continue by
looking at only the last two, three, or so components in the
authority value.
The result is a fairly short directory of which URI values are in
which multiplexes. For each URI reference, the receiver can then
quickly determine which multiplexes might have the associated data.
Final determination would require an actual tuning step to verify
that the tags were still valid.
Implications for Local Broacasters
A local broadcaster that is passing through a network feed should
simply pass any network-supplied URI descriptors.
The local broadcaster must add its own URI descriptors for content
that it is adding. The areas are:
1. It may add its own URI to the multiplex as a whole, if
appropriate.
2. It will in general add its own URI to its virtual channels.
3. It would add URIs for the events that the local broadcaster adds
to the schedule AND which are covered by an agreement with the
content provider.
4. It would add URIs for any data applications that it adds to the
transmission.
When adding URIs to existing lists, new URIs must be added at the end
of the list to avoid changing the default Base URIs in the existing
data.
Security Considerations
Finseth, Thomas [Page 6]
INTERNET-DRAFT An Example Instantiation... 14 December 1998
This example does not address security. It assumes that security and
access control are handled by policies and procedures implemented in
the systems themselves.
References
[1] Finseth, C,. Thomas, G., "Specifications for a TV Broadcast URI
Scheme", Internet-Draft ???????????-00.txt
Author's Addresses
Craig A. Finseth
U.S. Satellite Broadcasting
3415 University Ave
St Paul MN 55114
Phone: +1 651-659-7162
Email: craig@finseth.com
Gomer Thomas
LGERCA, Inc.
40 Washington Road
Princeton Junction, NJ 08550
Email: gomer@lgerca.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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 implmentation 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
Finseth, Thomas [Page 7]
INTERNET-DRAFT An Example Instantiation... 14 December 1998
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."
Finseth, Thomas [Page 8]
Received on Monday, 14 December 1998 13:22:20 UTC