AW: work on url for television started

Sorry
This problem is already solved with UR*.
There is no difference between a local device and broadcast device.
It is no problem to give every device an IP.
If there is a diffrence in addressing, the U is missused.
It only makes sence to diffrenciate behind UR*.
Henning Timcke
Ideen Werft22 GmbH

-----Ursprüngliche Nachricht-----
Von:	Simon Gibbs [SMTP:simon@arch.sel.sony.com]
Gesendet am:	Freitag, 16. Oktober 1998 21:38
An:	Larry Masinter
Cc:	www-tv@w3.org; Philipp Hoschka; Rodger Lea
Betreff:	Re: work on url for television started

Ok - maybe I should have been more explicit.
It's quite possible that DTV receivers will display
signals from several sources, both broadcast and
and those originating local devices in the home.
Examples of local sources could include DVD players,
AV disk arrays, PCs, DVCR etc. Furthermore,
the various home networking technologies now
underdevelopment will allow the receiver to select
and control local sources. So it's certainly reasonable
to imagine an HTML page rendered on the receiver
but containing URLs that refer to in-home content.
For example, imagine an "integrated" EPG. It would
be nice if this allowed me to access both what is
coming in over broadcast channels and what is
sitting around on local storage. So the problem then
is to define a URL scheme for local content that
allows the receiver to locate and play that content.

Simon



Larry Masinter wrote:

> > As input to this process consider the following...
> >
> > DTV receivers, in addition to tuning and displaying broadcast
> > signals, are likely to receive content from other devices in the
> > home. For example a digital cable set-top box may have a
> > "pass-through" IEEE 1394 connection to an ATSC receiver for
> > high-def decoding. The same network connection can also be used
> > to receive digital video streams from other devices in the
> > home. Just as existing URLs can refer to local and remote
> > objects, so perhaps we should allow tv URLs to refer to local
> > and remote sources.
>
> As written, this isn't very compelling. Perhaps we should, perhaps
> we shouldn't. You've set the context, but not really described
> the problem you're trying to solve.  Yes, here's a device with
> a lot of capabilities. So what's the problem?
>
> Larry

Received on Friday, 16 October 1998 16:21:47 UTC