Re: Update of RFC 2838, tv: URI

> [Re. venue for follow-up discussions, I suggest that the URI mailing 
> list (uri <at> w3.org), in particular for syntax aspects.]
> 
> At 21:23 06/08/20, Keith Moore wrote:
>> My impression was similar - if you're just going to have the tv:
>> URI point to a web page, why not just use the http (or whatever)
>> URI that points to the web page?
> 
> In my understanding, the intent is not to use HTTP for retrieval, but
> just to use DNS and Web pages as a lightweight way of assigning IDs
> to TV channels. The web page is only used for minting, and the URI
> points to the actual TV program/channel/feed or whatever you call it.
> 
yes, that's my understanding also.  but it's poor design to expect
existing web pages intended for humans to also contain machine-readable
information about TV feeds.  and it's poor architecture to effectively
expect future URI types to depend on HTTP.

>> IMHO there should be a way to use a tv: URI to do things that you'd
>> want to do with a tv broadcast - watch it (via the net, maybe via
>> broadcast radio, maybe via satellite), record it, find out its
>> schedule (say in XML so you could search through it for particular
>> programs), send them comments on particular programs, respond to
>> opinion polls, etc.
> 
> Again just in my understanding, watching it would indeed be the 
> primary purpose. So if you clicked on a URI like tv:bbc.co.uk/bbcone,
>  on a sufficiently equiped and configured device, you would view that
> channel. On the other hand, if you clicked http://bbc.co.uk/bbcone, 
> you would just be looking at a Web page, not a television program.

more generally you might have a pull-down menu that provided options
about what to do with the tv: URI - watch, look at the schedule for
future programs, schedule a recording of a future program, look at
recordings or transcripts of previously broadcast programs, etc.

even more generally, the URI might be processed by a very different tool
than a web browser.  (we shouldn't assume that the only vehicle to
resources on "the web" is via a single kind of tool)

> The association between the tv: URI and the actual channel can be 
> done in various ways.

true, but when you have a URI that is based on a DNS name, the natural
authoritative source of that data is DNS.

>> but if it turns out that the tv: URI is just equivalent to an http:
>> URI pointing to a web page,  that will cripple this potential.
>> it's not that you couldn't define a way to do all of the above via
>> the HTTP protocol, but having the tv: URI point to a web page would
>> require that the HTTP interface be overloaded to support both
>> functions (access to a human-readable web page, along with some
>> sort of method lookup to do the other things).  and there is a
>> tremendous amount of inertia behind web servers that makes it
>> difficult to add new methods to them to support such features.
> 
> While my understanding is that this is not what's intended,
> 'extension' of HTTP for the above purposes wouldn't be done by adding
> new methods to HTTP. It could be done much more easily through
> content negotiation (defining new mime types for the "other things").
> 
that's even uglier.

Keith