- From: Chambers, Tim <tchambers@sonypictures.com>
- Date: Wed, 16 Dec 1998 10:45:53 -0800
- To: "'www-tv@w3.org'" <www-tv@w3.org>
Gomer, Correct on all counts. Tim Chambers > -----Original Message----- > From: Gomer Thomas [mailto:gomer@lgerca.com] > Sent: Wednesday, December 16, 1998 10:29 AM > To: Chambers, Tim > Cc: www-tv > Subject: Re: looking for tv-related URI use cases/application > scenarios > > > Tim, > > Your clarification is very helpful. > > As I understand it, you are now sending an "http:" URI, which > refers to a > resource on a Web server in the usual way. Thus, for your > current operations > you do not need a TV URI scheme at all; the already > standardized "http:" > scheme works just fine. However, a key feature of that scheme > which you are > taking advantage of is that the same URI can be included in line 21 > regardless of which local broadcast affiliate or cable > provider is carrying > your program. It does not need to be modified to remain valid. > > As I understand it, in the future you would like to be able > to refer in the > same way to a resource contained in the broadcast stream. I > interpret that > to mean -- and correct me if I am wrong -- that (a) you would > very much like > to preserve this property that the URI does not have to be > modified for each > local affiliate or cable operator who carries your program, > (b) you would > like the syntax of the URI to be as similar to the syntax of > an "http:" URI > as possible, and (c) in fact, it would be useful to be able > to use exactly > the same URI to refer to either an HTML page on a Web server > or an HTML page > included in the broadcast, so receivers with a back channel > could retrieve > it one way and receivers without one could retrieve it the other. > > I am assuming that in your case the actual HTML page would always be > contained in the same channel as the trigger. Please correct > me if that is > an incorrect assumption. > > A lot of these details may seem pretty picayune, but they are > essential to > gain a full understanding of the requirements on syntax and > universality of > binding of any broadcast TV URI scheme. > > Gomer Thomas > > > Chambers, Tim wrote: > > > Thanks, this is an example of a project that we're > currently working on. > > > > To answer these questions below: > > > > Building with todays tv systems in mind, we are not relying on the > > ability to send data on all the lines of the VBI to send > URI triggers > > *and* web data, which would be the ideal. So we are currently NOT > > sending anything but a URI trigger with the TV signal. > > > > This is because the VBI is often stripped out as the signal > moves from > > the television network (or cable provider) to the local distributor. > > There is no clarity over who has the "rights" to the VBI. > As I work for > > a company that is the copyright holder to many great TV > brands, we like > > to think that the same way we provide the "traditional > content" of the > > show, we should be providing the "enhanced content." > > > > Anyway, a solution of sorts to the VBI issue is that line21 has been > > deemed "must carry" by the FCC, with the idea of sending closed > > captioning there. Thus we send the URI trigger down line21 > along with > > the captioning, which would send the set top box user to a > "enhanced tv > > jump page" that is an normal HTML page on our servers. For > all of this, > > we are planning to use the modem-line backchannel that the > set top box > > would support. > > > > The ideal would be that a section of the VBI, or later, of the MPEG > > stream becomes fully standardized for sending additional > data, and that > > there are guarantees that this area could not be removed. > If that were > > the case, we would send everything through the television signal. > > > > Tim Chambers > > Director of Technology and Production > > Columbia Tristar Interactive > > tchambers@sonypictures.com > > > > > -----Original Message----- > > > From: Gomer Thomas [mailto:gomer@lgerca.com] > > > Sent: Wednesday, December 16, 1998 9:33 AM > > > To: Chambers, Tim > > > Cc: 'www-tv@w3.org' > > > Subject: Re: looking for tv-related URI use cases/application > > > scenarios > > > > > > > > > This looks like an excellent use case. Can you provide a > little more > > > detail? Where is the actual "jump page" which is to be loaded > > > up? Is it on > > > an Internet web site? Or is it also encoded in line 21 of the > > > VBI? If it is > > > encoded in line 21, is it in the same channel as the trigger, > > > or can it be > > > in a different channel? > > > > > > Chambers, Tim wrote: > > > > > > > Let's start this off with basics: > > > > > > > > It would be a trigger encoded into the line21 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. > > > > > > > > Tim > > > > > > > > > -----Original Message----- > > > > > From: Philipp Hoschka [mailto:Philipp.Hoschka@sophia.inria.fr] > > > > > Sent: Tuesday, December 15, 1998 12:46 PM > > > > > To: www-tv@w3.org > > > > > Subject: looking for tv-related URI use cases/application > > > scenarios > > > > > > > > > > > > > > > > > > > > To better motivate the requirements, and evaluate their > > > priorities, > > > > > the URI telecon this morning decided that we're lacking > > > application > > > > > scenarios how tv-related URIs would be used > > > > > > > > > > So, if you have a particular idea of how tv URIs will be used, > > > > > please send it to this mailing list > > > > > > > > > > We have an editor (Craig Finseth) who will summarrize these > > > > > scenarios in a coherent document > > > > > > > > > > -Philipp Hoschka, W3C > > > > > > > > > > > > > > > > > -- > > > Gomer Thomas > > > LGERCA, Inc. > > > 40 Washington Road > > > Princeton Junction, NJ 08550 > > > phone: 609-716-3513 > > > fax: 609-716-3503 > > > > > > > > > > -- > Gomer Thomas > LGERCA, Inc. > 40 Washington Road > Princeton Junction, NJ 08550 > phone: 609-716-3513 > fax: 609-716-3503 > >
Received on Wednesday, 16 December 1998 13:50:54 UTC