From: email@example.com To: "'Warner ten Kate'" <firstname.lastname@example.org>, "Simon Gibbs" <email@example.com> Cc: <firstname.lastname@example.org> Date: Fri, 6 Nov 1998 17:12:23 -0800 Message-ID: <15AAE0EBDCC9D1119FFA00805F85642E012CA094@WNI-MSG-02> Subject: 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. email@example.com --------------------------------------------------- -----Original Message----- From: Warner ten Kate [mailto:firstname.lastname@example.org] Sent: Friday, November 06, 1998 12:01 AM To: Simon Gibbs Cc: email@example.com 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.