instantiation document

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

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 (Africa), (Northern
   Europe), (Southern Europe), (Pacific
   Rim), (US East Coast), or (US West Coast).

   Distribution of this document is unlimited. Please send comments to

   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.


   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


   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

             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:


             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

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


   and it refers to these modules:


   The first three could be coded in the SDT as:


   Thus saving space.  Relative forms are not permitted for the last

   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:


   and the viewer were to activate a reference such as:

           ...<a href="">...

   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.


   This section describes some steps that can be performed to improve

   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

   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

   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

   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

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.


   [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

   Gomer Thomas
   LGERCA, Inc.
   40 Washington Road
   Princeton Junction, NJ 08550

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

   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

Finseth, Thomas                                                 [Page 7]
INTERNET-DRAFT        An Example Instantiation...       14 December 1998


Finseth, Thomas                                                 [Page 8]

Received on Monday, 14 December 1998 13:22:20 UTC