New URI draft overview

From: Craig A. Finseth (fin@finseth.com)
Date: Fri, Nov 12 1999


Date: Fri, 12 Nov 1999 18:02:40 -0600 (CST)
Message-Id: <199911130002.SAA10983@isis.visi.com>
From: "Craig A. Finseth" <fin@finseth.com>
To: www-tv@w3.org
Subject: New URI draft overview

[ And here is an overview document to accompany the tv: and lid:
drafts.  This one has been submitted as an Internet-Draft (as will the
others).  This one will remain informational. ]







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

                                                               G. Thomas
                                                            LGERCA, Inc.
                                                        12 November 1999

                       Guide to TV Broadcast URLs
                       draft-finseth-guide-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document expires 12 May 2000.

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document provides a recommended methods for identifying
   resources within TV broadcast streams.  These methods use the "tv:"
   and "lid:" URL/URI schemes.  These schemes are defined in [1] and



Finseth, Thomas                                                 [Page 1]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   [2].

Environment

   The environment is television.  In this environment, you have a
   receiver that picks up one or more signals and deals with them.
   (We'll use the term "receiver" to denote the box or module that does
   the work.)  There are a few points to keep in mind.

   First, the receiver may have only one source of signal, or it may
   have many.  Typically, inputs can come from:

           - over-the-air antenna (NTSC, ATSC, DVB, potentially other
   formats)
           - cable feed (potentially a variety of formats)
           - satellite feed (again, a variety of formats)

   in any combination.

   Second, the receiver may (and usually will) have some sort of video
   out and/or an imaging device (picture tube/LCD/whatever).  The
   receiver may be able to display images from multiple sources (e.g.,
   picture-in-picture).  In some special cases such as a portable
   stock-ticker type device, the receiver may not be able to decode the
   "normal" audio/video image.

   Third, the receiver may be stand alone, or it may be connected to
   some form of "back channel."  The back channel may be proprietary or
   general-purpose (e.g., a network connection). The channel may be in
   the form of a phone line, DSL, cable modem, general LAN connection,
   etc.


Assumptions

   Please keep these general notes in mind when reading the examples:

   - RFC 2396 documents the terms URI, URN, and URL.  We use that
   document as a base.  This document will use the string "UR*" to refer
   to all three.

   - Consider each example as representing the class of similar cases.
   In particular, if your favorite example isn't on the list, ask
   yourself if it has the same UR* requirements as another that is on
   the list.

   - You can assume that the receiver will know how to deal with already
   standard UR*s such as http:, ftp:, mailto:, file:, etc.  (Note that



Finseth, Thomas                                                 [Page 2]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   this statement is "know how to" and not "be able to:" not all
   receivers will have the capability to use them.)

   - All uses of trademarks in these descriptions are for illustrative
   purposes only. There is no intent to assert that the trademark
   holders actually do or do not intend to carry out any of the
   suggested activities.

   - The term "EPG" means "electronic program guide."

   - This document will use the term "channel" to refer to what some
   protocols refer to as a "virtual channel."  A channel refers to
   content addressible by a number.


Application List

   This section presents a list of ways in which UR*s can be used in a
   television context.  The examples were contributed by a variety of
   people.  The requirements are to...

   1. Be able to refer to the audio/video image.

   2. Be able to include queries into the receiver in a technology-
   independent manner (ie not relying on specific ATSC, DVB, etc SI
   fields).

   3. Provide for technology-specific tuning, such as:

   * Tune to channel 100 on the EchoStar system.

   * Tune to ATSC channel 7.2.

   * Tune to NTSC channel 4.

   4. Provide for network-specific tuning, such as:

   * Tune to the local ABC affiliate.

   * Tune to the HBO East feed.

   5. Be able to uniquely address authored streaming content (video
   and/or audio) in a globally unique, network-independent, and
   transmitter-independent manner.

   6. Be able to name discrete data content (as opposed to streaming
   video and audio) being broadcast by a network, and *not* available
   via the Internet with any known scheme (ie HTTP or FTP), and provide



Finseth, Thomas                                                 [Page 3]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   a globally unique reference to it.

   7. Be able to name standard web content that is *also* being made
   available and delivered via some tv data broadcast to local cache.

           http://www.wsj.com/headlines.html

   [ Note: this item is included for completeness.  In fact, we support
   for this is already part of the http: standard and we don't have to
   do anything. ]

   8. Be able to reference an application, both for inter-process
   communcations purposes and to provide a default Base URI for
   contained UR*s.

   9. Be the target of a trigger encoded into the line 21 of the VBI
   (which is must carry for broadcasters) of a TV show that loads up a
   "jump page" of enhanced tv content that supplements the television
   program.  In general, be the target of any trigger.

   10. 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).

   11. In the same situation as (10) above, the broadcast is data-
   enhanced, with a data carousel module or an encapsulated IP datagram
   containing a file which gives up-to-the-second statistics on goals
   scored, fouls committed, corner kicks taken, shots at goal, shots on
   goal, etc. Fox wants to put a UR* 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.

   12. In the same broadcast situation as (10) and (11) above, Fox wants
   to put hyperlinks to the program and/or data in other data files
   being broadcast on the same Fox channel and in other Fox channels, so
   that receivers can set reminders for the upcoming game and/or data
   file.

   13. Paramount Productions wants to put on its web site a generic
   hyperlink to Star Trek episodes and/or movies. A user of an
   Internet-connected TV receiver with the right software can click on



Finseth, Thomas                                                 [Page 4]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   this hyperlink, and the receiver will give the user a mini-EPG
   showing the Star Trek episodes and/or movies which the receiver can
   receive now or in the near future. The user can then select a current
   show for viewing or a future show to set a reminder.  This link will
   identify _a_n_y Star Trek-related information: episodes from the
   Original Series, the Next Generation, Deep Space 9, etc., as well as
   movies, specials, or any other similar material.

   14. In the same situation as in (13) above, the producer wants to put
   on its web site a hyperlink to the Star Trek: Deep Space Nine series,
   and have the mini-EPG show only the current and upcoming episodes of
   this series.

   15. In the same situation as in (14) above, the producer wants to put
   on its web site a hyperlink to each of the episodes which have been
   filmed of the Star Trek: Deep Space Nine series. By clicking on one
   of these hyperlinks, the user can see a mini-EPG showing the current
   and upcoming showings of this specific episode.

   16. A local broadcast station is having a promotion in connection
   with their weekly broadcasts of Star Trek: Deep Space Nine. It wants
   to put a hyperlink on its web site which viewers in its local viewing
   area can click on to tune to, or set a reminder for, its broadcast of
   this week's episode.

   17. A large network, e.g., Fox, wants to put on its website a generic
   invitation to watch a particlular one of its channels, with a
   hyperlink which viewers anywhere in the world where the network
   broadcasts can click on in order to tune to that channel.

   18. A local affiliate of the network mentioned in (17) above wants to
   put a hyperlink on its web site which viewers in its viewing area can
   click on to tune to a particular one of its channels. (It may be
   broadcasting multiple virtual channels in the same physical broadcast
   band, in the case of a digital broadcast).

   19. It is common these days for multiple cable channels to be owned
   by the same parent corporation. In the future this may be
   increasingly true for terrestrial broadcast as well. In such a
   situation, consider the case where the parent corporation wants its
   multiple channels to be able to advertise each other, with hyperlinks
   allowing the user of a receiver with the right software to click on
   such an advertisement appearing in one channel and have the receiver
   automatically switch to the advertised channel, or set a reminder to
   an upcoming show in the advertised channel.

   20. In the same situation as in (19) above, suppose a single
   application can operate with the data of any of multiple different



Finseth, Thomas                                                 [Page 5]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   data services broadcast on different channels, for example a ticker
   application which can display many different categories of ticker
   information. The provider of these multiple different data services
   provides along with each service an index which the viewer can use to
   select the data service(s) of interest. The application uses the UR*
   associated with each service in the index to tune to the service(s)
   selected by the viewer.

   21. The NFL wishes to help people watch the superbowl.  It
   distributes e-mail (to people who have signed up for such a service)
   containing a UR* which they can click on to have their receiver look
   up when the SuperBowl is on.  Some of the e-mail is sent via the
   Internet and some is sent via an "e-mail" channel and received on a
   TV receiver.

   22. Some global brand (Coca Cola for the sake of argument, with the
   normal trademark note), wishes to place a UR* (maybe as a datagram)
   in to be broadcast with the program and displayed as a pop-up,
   linking to one or more of:

   a) A web-cast infomercial on their site.

   b) Infomercial broadcast separately, for example the previous night,
   and locally stored on the receiver's memory.

   c) Infomercial broadcast on a separate advertising channel.

   d) Infomercial available on a VOD (or NVOD) channel.

   23. A sponsor wishes to identify data describing their logo (perhaps
   animated) for inclusion in the program guide.

   24. A content creator (such as an advertising agency or production
   studio) needs to be able to assemble and test a commercial, program
   or other material including all UR* references, then be able to
   distribute a final tape (whatever) for airing over a variety of
   transports (ATSC, DVB, etc.).  The point here is that when the UR*s
   are locked down, the distribution format(s) is(are) not known.

   25. With the advent of powerful computers and software such as Adobe
   AfterEffects, just about anyone can become a content creator.  Thus,
   the naming mechanism must scale to the tens of millions of authors:
   it must be globally unique.

   26. In the case where a receiver can obtain the same material from
   two different sources (e.g., over-the-air and cable), the UR* scheme
   must provide mechanisms to:




Finseth, Thomas                                                 [Page 6]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   a) allow the receiver to determine that, in fact, the same material
   is being received from both sources (and it can thus use either), or

   b) even though the material may appear to be the same, it really is
   not and so substitution is not permissible.

   In other words, the UR* must not force solutions in this area.
   Rather, it must provide the content creators and/or broadcasters the
   tools to make the correct distinctions.

   27. Some broadcasters may elect to transmit some material in advance
   of usage (as opposed to in "real time").  The UR* mechanism should
   allow receivers that have such "pre-cached" material to make use of
   it while other receivers use the "real time" version from the _same_
   reference in the running application .  (The pre-cached version may
   be pre-rendered for speed or may be transmitted at a higher
   resolution.)

   28. The UR* mechanism should facilitate the recording of a program
   with all video, audio, and data streams and subsequent playback.

   29. Given (28) the source space of UR*s should be large enough that
   UR*s need not be reused.  (Since you can't tell when a live data
   stream is going to be mixed with the playback of a previously
   recorded one.)

   In summary, UR*s reference things transmitted down the broadcast
   stream(s).  The things that they can reference are one or more
   instances of:

   a) the tuner output

   b) a transmission multiplex

   c) a (virtual) channel

   d) an event

   e) an application

   f) data used by an application



General Notes

   A full summary of the requirements that such a scheme must meet is
   given in [3].  This document will not repeat that discussion.



Finseth, Thomas                                                 [Page 7]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   UR*s used in TV broadcasts have these key properties:

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

   2. A given resource may be identified by more than one UR*.  Hence,
   the same resource may be returned by more than one request.

   3. While UR*s can reference resources that are only available at
   particular times, the UR*s themselves do not explicitly encode any
   time-related information: any such information is carried by other
   mechanisms.  However, a UR* may reference an "event" (e.g., a TV
   program) and that event does carry a time context.


Guide to Resources Naming

   This section identifies each type of resource available within a TV
   broadcast stream and identifies the preferred

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

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

   1. The "current TV image."  The preferred form is the "tv:" scheme.
   Example using HTML are:

           <body src="tv:">
                   ...
           </body

   which places the "live" image as a background and:

           <table>
           <tr><td>Upper left</td><td><img src="tv:"></td></tr>
           <tr><td>Lower left</td><td>Lower right</td></tr>
           </table>

   which does a "picture-in-picture" type display with the image in the
   upper-right corner.


   2. A transmission multiplex.  The preferred method is to use the
   "lid:" scheme.

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



Finseth, Thomas                                                 [Page 8]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


           lid://abc.com/
   or:     lid://abc.com/feed
   or:     lid://feed.abc.com/

   3. A particular virtual channel.  The preferred method is the
   "tv:<name>" scheme.

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

           tv:abc.com
   or:     tv:chan.abc.com
   or:     tv:hbo.com
   or:     tv:west.hbo.com
           tv:chan.kstp.com

   The first two indicate typical cases of a network feed.

   The next two indicate naming generic and specified feeds.

   The last one could be attached to the same channel as either of the
   first two (as KSTP is the ABC affiliate in the Minneapolis/St. Paul
   area.)

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

           ...<a href="tv: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
   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="tv:abc.com">tune to ABC now</a>...

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




Finseth, Thomas                                                 [Page 9]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   While there may be some exceptions, TV broadcast UR*s 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 cable
   and satellite systems offer identical content on the West coast feed,
   but present that content under two user-visible names, said name
   depending upon the transmission path.

   The reccomended scheme avoids problem by separating the UR* naming
   from the user-visible naming.  The provider can use the same UR*
   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:

           lid://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
   mechanisms to handle staging of the varoius feeds.

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

   4. A collection of event material.  The preferred method is to use
   the "lid:" scheme.

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

           lid://gilligans-island.com/

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



Finseth, Thomas                                                [Page 10]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


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

   5. A particular episode of a event series.  The preferred method is
   to use the "lid:" scheme.

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

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

   This specification does not identify which form is preferred: just as
   with "normal" web UR*s, the preferred form is selected by the
   organization named in the <authority> portion.

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

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

   6. A particular showing of a event.  The preferred method is to use
   the "lid:" scheme.

   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.  This resource might be identified by a UR* of
   the form:

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

   The UR* 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:

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

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

   Note that it is common for local broadcasters to change the time of a
   broadcast, both "in advance" (e.g., always starting "E.R." 5 minutes



Finseth, Thomas                                                [Page 11]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   late) or "on the fly" as local conditions change (e.g., to accomodate
   a live event running long).  As such, UR*s should never contain
   specific show times.  Rather, they should identify the material and
   the receiver would process the reference through its EPG to determine
   actual show times.

   7. Event material that appears someplace in the time/virtual
   channel/provider continuum.  The preferred method is to use the
   "lid:"  scheme.

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

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

   or even just,

           lid://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="lid://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.  The preferred method is to use the
   "lid:" scheme.

   All of the previous examples referred to events that were in some
   sense repeating or part of a series.  The same forms and concepts
   apply to once-only events.  The organization responsible assigns the
   UR* and it is attached to the appearances.

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

   8. A particular application.  The preferred method is to use the
   "lid:" scheme.

   UR*s can be attached to the applications themselves.  These UR*s can
   be used in two ways.




Finseth, Thomas                                                [Page 12]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   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:

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

   9. A particular data item referenced by an application.  The
   preferred method is to use the "lid:" scheme.

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

   For example,

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

Referencing Other Data

   This document covers how a receiver learns about UR*s received _o_n_l_y
   over a TV broadcast stream.  Receivers may use other UR* 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:").  However, their use should be avoided by
   well-formed applications.

Security Considerations

   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



Finseth, Thomas                                                [Page 13]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   [1] "tv:"

   [2] "lid:"

   [3] ten Kate, Warner; Thomas, Gomer; Finseth, Craig, "TV Broadcast URI
   Schemes Requirements", 11 March 1999.
           http://www.w3.org/TV/TVWeb/TVWeb-URI-Requirements-19990311

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

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 (1999).  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.




Finseth, Thomas                                                [Page 14]

INTERNET-DRAFT         Guide to TV Broadcast URLs       12 November 1999


   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."

   This document expires 31 October 1999.











































Finseth, Thomas                                                [Page 15]