RE: URL: Background and Requirements

I also agree with this approach.  I think when we really pin down the
requirements for these URLs, we will find that we need more than one
scheme, but not too many more than one.  At the very least, I think we
need to define broadcast content URLs (for describing particular pieces
of broadcast content regardless of location) and broadcast stream URLs
(for accurately describing the location of content within a given
television broadcast architecture).  Let me take these one by one.

1. Broadcast content URLs.  My own work has so far focused on the first
class of URL, and it is for these problems that the "tv:" URL scheme was
designed.  In the simplest case, the "tv:" URL is simply used as a
placeholder for whatever is being broadcast on the "current" channel.
You can imagine that a commercial advertisement, for example, might have
an HTML page that is broadcast along with the video, and this page
includes an OBJECT whose source is simply "tv:".  Because the same
advertisement may be shown on many different networks and many different
types of television broadcasts (cable, satellite, terrestrial, analog,
digital, etc.), it is impractical for the page to actually describe the
location of the television broadcast itself.  Instead, the author simply
wishes to state that the broadcast which is associated with this page
should be embedded in the page.  Since the page itself was delivered
along with the broadcast video, the receiver knows which channel of
video is associated with the page.

A slightly more complicated usage of the "tv:" scheme is to describe a
stream of broadcast content using some sort of identifier.  My original
proposal used station and network identifiers like "tv:bbc" or
"tv:kqed".  We've used this experimentally here at Microsoft with some
success, but it does require some sort of registry to keep identifiers
unique.  IANA could do this, or we could define some other mechanism.

2. Broadcast stream URLs.  Much of the work so far in TV-oriented groups
like DVB seems to have focused on URLs for describing the actual
physical location of a stream of broadcast content.  This is very useful
for some applications, especially applications that are local to a
receiver.  For example, an application might query a local database to
find where a given program is playing and receive back a URL that
defines exactly how to tune that program when it airs.  In the analog
world, something as simple as "ntsc:13", meaning channel 13 of the NTSC
spectrum, might be sufficient.  In digital transports, it's a bit more
complicated.  And you need a different URL scheme for each TV broadcast
transport, since each transport divides the spectrum differently.

To summarize, broadcast content URLs are used to say "show me what's
being broadcast on the current TV channel" or "show me what's being
broadcast on XXX network wherever that network is".  What I've called
broadcast stream URLs are used to say "show me what's on XXX channel",
where "XXX" is sufficiently detailed to uniquely define a specific slice
of the broadcast spectrum.

I would propose that this interest group produce two documents.  The
first would be an Internet-Draft describing a broadcast content URL
scheme, since this scheme could be used for all television applications
and would not be specific to any given TV broadcast transport.  The
second Internet-Draft would give guidelines for defining broadcast
stream URLs, and perhaps give specific schemes for some of the popular
transports like NTSC, PAL, DVB, and ATSC.

Do these sound like reasonable goals?  I think the first project is
pretty straight-forward; I think there's only been one proposal on these
sorts of URLs, and I think the problem is simple enough that the
solution could be fairly non-controversial.  The broadcast stream URLs,
however, require a lot of knowledge of the specific transport.  Perhaps
it would be worth getting together for a face-to-face meeting to talk
through the various proposals here.

	Dan


---------------------------------------------------
Dan Zigmond
Co-Manager, Interactive Television
Senior Manager, Interactive Television Standards
WebTV Networks, Inc.
djz@corp.webtv.net
---------------------------------------------------


-----Original Message-----
From: Warner ten Kate [mailto:tenkate@natlab.research.philips.com]
Sent: Friday, November 06, 1998 12:01 AM
To: Simon Gibbs
Cc: www-tv@w3.org
Subject: Re: URL: Background and Requirements


[I send this yesterday, but the message seems to get lost.
this is a repeat.]

Simon Gibbs wrote:
>
> Perhaps it helps to think of three different "families" of URLs.In
particular:
>
> 1) broadcast URLs
> 2) home network URLs
> 3) "normal" URLs - http:// and others currently in use

This is an interesting approach, which may bring us further.
I would like to see that we specify the relation between these
families, such as to enable transition between the various domains.

Somehow we have to prevent to end up with a series of URLs,
each designed for its particular usage (which disclassifies
them as Uniform, I guess).

Warner.

Received on Friday, 6 November 1998 20:12:56 UTC