Update of RFC 2838, tv: URI

Re: Update of RFC 2838, tv: URI

Hi,

first of all, I was surprised to hear that there a "tv" URI scheme. 
Turns out, it hasn't been published through the IESG, and the URI scheme 
hasn't been registered through IANA.

I do agree with your analysis that the URI scheme in itself is 
insufficient. Maybe this would have been discovered if it would have 
been published through the IESG.

Now, as an informational spec what it says may be OK - it just documents 
what some vendors (probably mainly in the US) have been using.

Now if what you're looking for is a URI to be used on the Internet, 
requirements are higher. In particular, you should demonstrate that you 
actually need a URI scheme, which is not completely obvious to me.

Best regards, Julian

Re: Update of RFC 2838, tv: URI

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

Re: Update of RFC 2838, tv: URI

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?

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.

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.

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.

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

Re: Update of RFC 2838, tv: URI

On Aug 20, 2006, at 5:23 AM, 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?

+1

  -Tim

Re: Update of RFC 2838, tv: URI

This is also supported by the W3C TAG group's findings on appropriate  
use of URIs/URLs <http://www.w3.org/2001/tag/doc/ 
SchemeProtocols.html>.  An alternative that solves some use cases  
(not sure what the TV use cases are)  is to have a "TV channel  
descriptor" file format which could be retrieved via HTTP, therefore  
have a http: scheme.

Lisa

On Aug 20, 2006, at 7:45 AM, Tim Bray wrote:

> On Aug 20, 2006, at 5:23 AM, 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?
>
> +1
>
>  -Tim
>
>
>
>
>

Re: Update of RFC 2838, tv: URI

Personally I think W3C goes a bit overboard on this.  Expecting 
everything on the web to use HTTP just to get a description file or a 
redirect is just wrong.  And there are many cases where, for the sake of 
a good user interface, you really want to expose some semantic 
information about the resource without the client having to access the 
net to get it.

There's nothing wrong with having a tv: URL, just don't cripple it so 
that it can never be more functional than an http: URL.

Keith

> This is also supported by the W3C TAG group's findings on appropriate 
> use of URIs/URLs <http://www.w3.org/2001/tag/doc/SchemeProtocols.html>.  
> An alternative that solves some use cases (not sure what the TV use 
> cases are)  is to have a "TV channel descriptor" file format which could 
> be retrieved via HTTP, therefore have a http: scheme.

Re: Update of RFC 2838, tv: URI

At 11:40 AM +0200 8/20/06, Julian Reschke wrote:
>Hi,
>
>first of all, I was surprised to hear that there a "tv" URI scheme. Turns out, it hasn't been published
through the IESG, and the URI scheme hasn't been registered through IANA.

Actually, this looks like a bug in the IANA registry. The TV uri scheme is
described in RFC 2838, as the original poster notes.  That means it should
be (at the very least) be in the registry as provisional. Have the proponents
of changing it talked to the original authors to see if it is still in use according
to the original spec?  I believe Liberate made set-top boxes, for example,
which may still be in use and are pretty tough to upgrade.

The salient bit for this discussion seems to come from section 3.2 of 2838;
especially this text:

  In some cases, networks have multiple broadcast streams that need to
   be distinguished.  This is also handled in DNS style:

          tv:east.hbo.com     HBO East
          tv:west.hbo.com     HBO West

   It is important to note that these DNS-style identifiers need not
   match real hostnames; they should not be resolved to IP addresses
   using DNS.  Thus, using the terms as defined in RFC 2396, the "tv:"
   scheme is a Uniform Resource Identifier and not a Uniform Resource
   Locator.

   In order to support these identifiers in a "tv:" URI, a receiver must
   implement a means to map known identifiers to frequencies. The nature
   of this map and the way in which it is used are currently browser-
   and device-specific and are beyond the scope of this document. In
   this way, the "tv:" scheme is somewhat analogous to the "news:" and
   "file:" schemes in [1]: it merely names a television broadcast signal
   but assumes that the local browser has some means for actually
   retrieving that signal on the local device.  A variety of software
   systems currently provide device-specific mappings from such
   identifiers to specific channel numbers or directly to frequencies.
   These systems can be incorporated into television sets or set-top
   boxes to facilitate the interpretation of television URIs by the
   client device.

That is, the original registrants presumed that you would be able to
mint dns-style identifiers for the mapping.  Sounds like this does
not satisfy the needs that have now been expressed.

I note as well that we already have a second URI scheme (CRID,
described in RFC 4078) that tackles the same space.  Is there any
hope of using it instead?  Or are we looking at a third, with possible
deprecation of a the first?
			regards,
				Ted Hardie

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     

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