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.

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

The association between the tv: URI and the actual channel can be
done in various ways. One way is to embedd the URI into the metadata
part of the actual channel, i.e. having something in the program say
"hey, btw, I'm tv:bbc.co.uk/bbcone". A device would scan the channels every
so often and cache that information. While I don't know to what
extent this kind of scanning is feasible from a HW point of view,
it would be most reliable (assuming that TV stations wouldn't
want to claim that they are somebody else). Another way is to hard-code
that data when configuring the device, but this is only possible
to a certain extent. A third way is to get the data from a third
party (e.g. a TiVO like service). A fourth way would be to embedd
some data into the 'corresponding' Web page, but this is likely
going to be rather difficult, because the same TV program may appear
on different physical channels in different areas of a country
(at least that's the case here in Japan, NHK, the national program,
appears on channel 1 in the greater Tokyo area, and on channel
2 in and around Osaka).

>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").
[As for new methods, they would indeed meet with substantial inertia,
but it's important to see that the number of servers affected would
be minimal when compared to all the Web servers out there.]

>so I conclude that to get much benefit out of a tv: URI type they should not be constrained to point to web
pages, and probably should not be encouraged to point to web pages.  a better path would be to use NAPTR/SRV
lookup in DNS to allow a client to look up things that could be done with a tv: URI.

This would be in line with the DNS-based handling that Ted mentioned
is already in the current RFC:
          tv:east.hbo.com     HBO East
          tv:west.hbo.com     HBO West

Regards,     Martin.

>-------- Original Message --------
>
>> Hi,
>> Perhaps I fail to grasp the utility of the TV URI, but why bother going
>> to all of this work when a URL seems to be what you want?  What does the
>> new form give you that a URL does not?
>> Thanks,
>> Eliot
>> 
>
>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst <at> it.aoyama.ac.jp