specifications document

INTERNET-DRAFT                                                C. Finseth
                                             U.S. Satellite Broadcasting

                                                               G. Thomas
                                                            LGERCA, Inc.
                                                        14 December 1998


              Specifications for a TV Broadcast URI Scheme
                   draft-?????-tvweb-uri-specs-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 specifies a URI scheme for use in TV broadcast
   environments.  The specification in this document meets the
   requirements set forth in the companion requirements document [3].
   An example informative instantiation for this specification for the



Finseth, Thomas                                                 [Page 1]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   ATSC television system is set forth in [4]: other instantiations are
   not only possible but desirable.

Description

   The requirements that any TV broadcast URI scheme must meet are
   complex.  The URI must connect a use of a resource with the
   definition of the resource.  It must make this connection even though
   the resource may be transmitted in ways not forseen by the original
   author.

   A full summary of the requirements is given in [3].  This document
   will not repeat that discussion.  Rather, this document will specify
   the syntax and semantics of a URI scheme that meets those
   requirements.

   This scheme can be used in a wide variety of TV broadcast
   environments. To help understand how to implement it in practice, a
   companion document is available [4]. This companion document shows
   how TV broadcast URIs can be resolved in a particular environment:
   the ATSC digital television system. The same basic approach can be
   adapted to other TV environments as well.

   The general idea is that a URL is resolved by a TV receiver using
   translation information which is delivered to it in the broadcasts it
   receives. Thus, a URL may represent a resource which is broadcast by
   different terrestrial, cable, and satellite broadcasters in different
   locations, and which is therefore received by different TV receivers
   via different channels and even different broadcast protocols. These
   TV receivers can each correctly resolve the URL to the physical
   broadcast parameters which represent the referenced resource in their
   circumstances by making use of translation information which is
   specific to their circumstances.

One-Paragraph Summary

   Each resource -- such as a virtual channel, event, application, or
   data file -- is identified by a URI.  The URIs are globally unique
   (conceptually) opaque tags and are assigned by the creator of the
   content.  The information necessary to map the URI to the actual
   resource is carried in each transport stream in a transport-stream
   specific manner.  These specifics are invisible to the application:
   it simply uses the URI in an accustomed manner to access the
   resource.


Syntax




Finseth, Thomas                                                 [Page 2]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   The TV broadcast URIs fully comply with the syntax called out in
   [RFC2396].  This document will not review the entire syntax.  Rather,
   it will just highlight the specifics.  Numbers in {}s refer to RFC
   2396 section numbers.

   TV broadcast URIs are simultaneously URIs, URLs, and URNs {1.2}.  The
   term "URI" will continue to be used to refer to the collection.

   TV broadcast URIs are hierachical and the relative forms are fully
   supported {1.4}.

   The standard character set restrictions and operations (e.g. quoting)
   are used {2.}.

   This document does not specify a maximum length of a TV broadcast
   URI.  Content authors should consult the set of instantiation
   documents covering their target systems to determine any limitations
   on length.

   The standard form {3.} is:

           btv://<authority><path>?<query>

   The <authority> part is a registration-based naming authority.  The
   registration is the Domain Name System {3.2}.  Note that the
   <authority> part is not expected to ever be resolved via DNS servers.
   Further, the <authority> part _m_u_s_t be a name: a numeric identifier
   (such as IP address) is not permissible {3.2.2}.

   The server-based portions (including "<userinfo>@" and ":<port>")
   will not be used {3.2.1}.

   Path component interpretation is as specified in {3.3}.

   Query components are permitted; interpretation is as specified in
   {3.4}.

   Fragment identifiers are permitted; interpretation is as specified in
   {4.1}.

   Relative URI references are permitted within an application (see next
   note). However, all URIs will be converted to fully-qualified form
   before being passed to the environment for lookup {5.}.

   Base URIs can be obtained from the Document Context, the Retrieval
   URI, and the default Base URI.  The Encapsulating Entity form is not
   meaningful and not permitted.  Also, for Retrieval URIs, redirection
   is not meaningful and is not permitted. {5.1.}



Finseth, Thomas                                                 [Page 3]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   The default Base URI is the URI explicitly associated with the
   invoking application.  In the case where the invoking application is
   the system or is not clear, the default Base URI is not defined and
   relative forms are not permitted. {5.1.4}

Semantics

   From a TV application's viewpoint, a TV broadcast URI is simply an
   opaque string that is passed to the system for lookup.  The system
   then uses infomration obtained from other sources to associate the
   opaque string with the actual resource.  (This is exactly the same
   model as is used for looking up "traditional" "http:" URLs.)

   This scheme assumes that there will be some "directory-type"
   information available to the system to perform the mapping.  As this
   is presumably the same information used by the system to actually
   perform its other tasks, the mapping can be assumed to be complete
   and correct.

             "Directory-type" information includes what is commonly
             referred to as "PSIP" information: virtual channel tables,
             event information tables, system description tables, etc.
             The specific names and formats of such tables will vary
             from one system to another. In some cases, data may even be
             entered manually.

   TV broadcast URIs have three key properties:

   1. URIs are considered to match when a _c_a_s_e _i_n_d_e_p_e_n_d_a_n_t string
   comparison between the two returns True.  Comparisons are always
   performed on the fully-qualified forms.

             Note: case indepdendant path portions were selected for
             ease of implementation.  RFC 2396 does not specify whether
             the path portion is case indepdendant (the assigning
             authority and scheme portions must be compared case
             independant).  If there are any real objections to our
             making the path portion case indepdendant, this can be
             readily changed.

   2. More than one resource may be identified by the same URI.  Hence,
   a list of matching resources would be returned.

   3. A given resource may be identified by more than one URI.  Hence,
   the same resource may be returned by more than one request.

   Note that while URIs can reference resources that are only available
   at particular times, the URIs themselves do not explicitly encode any



Finseth, Thomas                                                 [Page 4]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   time-related information: any such information is carried by other
   mechanisms.  However, a URI may reference an "event" (e.g., a TV
   program) and that event does carry a time context.

Resources to be Named

   We have identified the following types of resources that could be
   named with TV broadcast URIs.  This list is not part of the
   specification, but is included to help understand how it is used.

   Note that the <authority> portion identifies the entity that made the
   assignment.

   The first two resources identify levels of transmission multiplex
   "bundling."

   1. A transmission multiplex.

   For example, the ABC network feed.  These might be named:

           btv://abc.com/
   or:     btv://abc.com/feed
   or:     btv://feed.abc.com/

   2. A particular virtual channel.

   This resource identifies a particular virtual channel.  Virtual
   channels might be named:

           btv://chan.abc.com/
   or:     btv://abc.com/chan/
           btv://chan.kstp.com/
   or:     btv://kstp.com/chan/

           btv://hbo.com/chan

   The first two indicate the typical case of a network feed with local
   affiliate.  (KSTP is the ABC affiliate in the Minneapolis/St. Paul
   area.)  Both names would be attached to the same virtual channel.

   Note that there is no need for the numeric form (Channel 5).  If the
   local affiliate were to embed a URI in web content, the context would
   just be:

           ...<a href="btv://kstp.com/">tune to Channel 5 now</a>...

   This same form would work on web content found in the Internet
   (assuming that the device had a tuner and was able to receive KSTP's



Finseth, Thomas                                                 [Page 5]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   signal), in content found in the TV broadcast stream, or any other
   content.

   Since virtual channel numbers in a TV are re-used, an application can
   not usefully _e_v_e_r use the virtual channel number alone.  Instead, it
   must refer to the context to determine how to name the desired
   resource.  Given such a lookup, the alphabetic form of the name is no
   more effort to use than the numeric form.

   Note that the national network can use the form:

           ...<a href="btv://abc.com/">tune to ABC now</a>...

   and cause tuning to the local affiliate (assuming there is one) from
   anywhere.

   While there may be some exceptions, TV broadcast URIs are intended
   mainly for internal use by the system and not for presentation to
   viewers.  The following example illustrates why.

   HBO (and many other networks) have multiple feeds: in the U.S., they
   have both an East and West coast feed, with the West coast feed
   ordinarily carrying the same content as the East coast feed, but with
   a three hour delay (live events are carried at the same time on
   both).

   Local providers (e.g., cable systems) on the East coast ordinarily
   carry the East coast feed and call it "HBO".  Local providers on the
   West coast ordinarily carry the West coast feed and also call it
   "HBO".  Nationwide providers (e.g., satellite systems) may carry both
   feeds but must use different names (often "HBO" for the East coast
   feed and "HBOW" or "HBOP" for the West coast feed).  Note that we
   have identical content on the West coast feed, but it is presented
   under two user-visible names, said name depending upon the
   transmission path.

   This URI scheme avoids problem by separating the URI naming from the
   user-visible naming.  The provider can use the same URI whenever the
   content is the same.  Note that the same content is just that: it's
   the same string of bits, even if shifted in time.

   For example, a promotional spot might need a background GIF resource
   named:

           btv://hbo.com/promotions/ad1453/background.gif

   It can (and should) use the same name whenever the resource appears
   in the transmission.  The provider can use its normal scheduling



Finseth, Thomas                                                 [Page 6]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   mechanisms to handle staging of the varoius feeds.

             Note: Earlier drafts had a provision for identifying a
             particular elementary stream, for example, the audio track
             for virtual channel 20-4 in Los Angeles.  We have not
             identified any real-world examples where this would be
             useful that could not be addressed by the creation of a new
             virtual channel.  Given such an example, we could re-open
             this area.

   The next block of resources identify various combinations of event
   material.

   3. A collection of event material.

   For example, the set of Gilligan's Island episodes in the schedule.
   This resource might be defined by attaching a URI like this:

           btv://gilligans-island.com/

   to each episode in the schedule.  A typical use of this form of URI
   might be on the Gillian's Island web page.  It might have a reference
   to:

           ...and click <a href="btv://gilligans-island.com/">here</a>
           to see a when and where it is on in <i>your</i> city...

   4. A particular episode of a event series.

   For example, the "Trouble with Tribbles" episode of the original Star
   Trek.  This resource might be defined by a URI of one of these forms:

           btv://trouble-with-tribbles.startrek.com/
           btv://startrek.com/trouble-with-tribbles
           btv://startrek.com/2nd-season/trouble-with-tribbles

   This specification does not identify which form is preferred: just as
   with "normal" web URLs, the preferred form is selected by the
   <authority>.

   In many cases, material with a the specific episode URI would also
   have a generic series URI:

           btv://trouble-with-tribbles.startrek.com/
           btv://startrek.com/

   5. A particular showing of a event.




Finseth, Thomas                                                 [Page 7]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   For example, the "Trouble with Tribbles" episode of the original Star
   Trek that ran on Nov 16, 1998 at 10:00pm on virtual channel 5 in
   Minneapolis/St. Paul Angeles.  This resource might be identified by a
   URI of the form:

           btv://kstp.com/trouble-with-tribbles/startrek.com

   The URI would be placed _o_n_l_y on the showing for the specified virtual
   channel and at the specified time.

   The naming of this example assumes that the local station is the
   source of the reason for the reference.  For example, there is a
   promotion in conjunction with a local Star Trek convention.  A more
   typical name might be:

           btv://kstp.com/promotion/star-trek/19981116

   The point is, the organization creating the reference can use
   whatever name best suits their purpose.

   6. Event material that appears someplace in the time/virtual
   channel/provider continuum.

   For example, the January 1999 Super Bowl.  This event might carry the
   URI:

           btv://super-bowl-Jan-1999.com/

   or even just,

           btv://super-bowl.com/

   Given that only one is likely to show up in the schedule at a time.
   As with the nationwide network example, the reference can be embedded
   as:

           ...and click <a href="btv://super-bowl.com/">here</a> to
           schedule your TV to tune to the Super Bowl!...

   Again, this reference is only useful if the viewer can actually
   receive the Super Bowl broadcast and it is in the available event
   guide.  It also assumes that references to events in the future can
   integrate to a scheduling system (this situation is common in
   satellite and cable set-top boxes).

   7. A particular once-only event.

   All of the previous examples referred to events that were in some



Finseth, Thomas                                                 [Page 8]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   sense repeating or part of a series.  The same forms and concepts
   apply to once-only events.  The organization responsible assigns the
   URI and it is attached to the appearances.

   The last two points identify "data"-oriented resources.

   8. A particular application.

   URIs can be attached to the applications themselves.  These URIs can
   be used in two ways.

   First, they identify applications to each other for inter-process
   communications.

   Second, the default Base URI for the application is established by
   the act of naming the application itself.

   Example names might be:

           btv://coke.com/commercial45/application
           btv://abc.com/promo5.html

   9. A particular data item referenced by an application.

   Examples are image files (JPEGs, GIFs), sounds, data streams, etc.

   For example,

           btv://coke.com/commercial45/application/background.gif

Referencing Other Data

   This specification covers how a receiver learns about URIs received
   _o_n_l_y over a TV broadcast stream.  Receivers may use other URI schemes
   as they see fit.  For example:

   - The "http:", "ftp:", and similar schemes can be used to access
   content from the Internet (given such a connection).

   - The "file:" scheme may be used to access local information.

   - Other TV broadcast-related schemes may coexist with this scheme
   (e.g., "dvb:" and "davic:").  Applications that use such schemes
   limit their scope of operation to those systems that implement such
   shemes.

Security Considerations




Finseth, Thomas                                                 [Page 9]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   This specification does not address security.  It assumes that
   security and access control are handled by policies and procedures
   implemented in the systems themselves.

   While this specification appears to provide a level of security by
   virtue of the fact that the only resources accessible by an
   application are those named in the broadcast stream, such is not the
   case.  Absent other policies and procedures, an ill-behaved
   application can access resources by using device-specific mechanisms.

References

   [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter,
             "Uniform Resource Identifiers (URI): Generic Syntax", RFC
             2396, August 1998.

   [1] Philipp Hoschka,
         W3C TVWeb Interest Group,
         <http://www.w3.org/TV/TVWeb/>

   [2] Warner ten Kate,
         TV URI Schemes - Requirements
         <http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19981110>

   [3] ten Kate, W., Thomas, G., Finseth, C., "Requirements TV Broadcast
           URI Schemes", Internet-Draft draft-tenkate-tvweb-uri-reqs-00.txt

   [4] Finseth, C,. Thomas, G., "An Example Instantiation of the TV
           Broadcast URI Scheme for ATSC", 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.



Finseth, Thomas                                                [Page 10]

INTERNET-DRAFT         Specifications for a TV...       14 December 1998


   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
   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 11]


Received on Monday, 14 December 1998 13:21:51 UTC