Re: URL: Background and Requirements

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

So far, so good.

   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.

This simple form does not scale well: network IDs are not consistent
across providers, nor is it desirable that they be.

For example, we (USSB) carry both HBO feeds (Eastern and Western time
zones, the latter being 3 hours behind the former).  We need two
different IDs (of course).  We call them HBO and HBOW.

Cable systems on the east coast that carry just one HBO feed usually
carry the east cost feed (of course) and call it HBO.  No problem.

Cable systems on the west coast that carry just one HBO feed usually
carry the _west_ coast feed (no surprize) and call it HBO.

You see the problem.

The user visible name can _not_ be used as the key identifier!

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

And, as the requirements document has identfied, this form of URL is
not generally useful for URLs embedded in broadcast content.  Those
URLs must be able to continue to identify the same content after
substantial transformations of the broadcast stream.

   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

And "tv:" (with no other forms or extras) does this.

   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.

Again, the forms must be transport-independant.  That's the point.

   Do these sound like reasonable goals?  I think the first project is

Yes.

   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.

Gomer and I are working on such a proposal that meets all criteria.

Craig

Received on Monday, 9 November 1998 12:09:26 UTC