headers
Deventer, M.O. (Oskar) van | 18 Aug 16:08
Picon
Picon
Favicon

Update of RFC 2838, tv: URI

All,

We see a need for an update to RFC 2838, which is about the tv: URI for the identification of television channels. After speaking with Lisa Dusseault, Cullen Jennings suggested discussing such an update on the discuss <at> apps.ietf.org email list. The rest of this email describes the use cases, the problem statement, a rough proposal and items for the proposed update. We would like to invite feedback on these.

Background: RFC 2838 for the identification of TV channels

Unambiguous identification is needed when applications refer to TV channels. An example use case is clickable TV watching advice in an instant messaging application: “He John, check out BBC1 now”. Another example use case is a presence application: “Your buddy John is now watching TV5”. There does not exist an international naming authority for the identification of TV channels. RFC 2838 defines a harmonized alternative solution, namely the tv: URI. These DNS-style identifiers are deduced from the name of the broadcaster or television network, its nationality and possibly the name of the broadcast stream. The assumption of RFC 2838 is that the deduction of a tv: URI is unambiguous, which is usually true in the American context. Here are some tv: URI examples from RFC 2838: tv:wqed.org; tv:nbc.com; tv:abc.com; tv:abc.co.au; tv:east.hbo.com; tv:west.hbo.com.

Problem: Ambiguities with RFC 2838 in a European context

Because of the public network system in several European countries, the deduction of tv: URIs leads to ambiguities in the European context. In the Netherlands, for example, the public network system has more than ten TV stations who alternatingly broadcast on the three public TV channels. At one time, one TV station may be broadcasting different programs on different channels. Another issue is “code sharing” where cable companies broadcast on one TV channel different (foreign) TV channels at different times, e.g. a children’s channel at day time and a film channel at evening time. In all these examples, the deduction of a tv: URI for the TV channels is ambiguous.

Proposal: Take the website name of the TV channel

Our proposal is to deduce the name of the TV channel from the name of its official website. After a small investigation, we found that every TV channel seems to have a dedicated website. American TV channels, public TV channels in Europe and even small local TV channels have their own website. So that removes the problem of ambiguities. The deduction of a tv: URI then becomes a no-brainer: take the website name and replace “http://” by “tv:”. Here are some examples of European tv: URIs using this convention: tv:bbc.co.uk/bbcone; tv:nederland1.nl; tv:tv5.fr.

Update to RFC 2838: syntax and synonyms

-The proposed new RFC that updates RFC 2838 would keep most parts of RFC 2838 unaffected. The American tv: URI examples of RFC 2838 would remain unchanged, as these tv: URIs do already match with a website. The Australian ABC channel would become tv:abc.net.au, corresponding to their actual website name.

-There is an update to the RFC 2838 syntax needed, as some TV channels would be identified by a resource (using “/”) in our proposal and not only by a domain name. Two examples of this are tv:bbc.co.uk/bbcone and tv:nationalgeographic.nl/channel.

-Another issue for the update is synonyms. Some websites work both with and without the “www” part in its URI. Some websites redirect to other websites. The website http://nederland1.nl redirects to http://portal.omroep.nl/ned1. In order to achieve the highest level of interoperability, synonyms should be accepted as names of TV channels.

Please let us know your reaction on this proposal.

Best regards,

Oskar

--------------------------------
dr.ir. M. Oskar van Deventer
TNO Information and Communication Technology
P.O. box 5050
2600 GB  Delft
Netherlands
+31 651 914 918
oskar.vandeventer <at> tno.nl
--------------------------------


This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html
Permalink | Reply |
headers
Eliot Lear | 20 Aug 13:09
Picon
Favicon

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
Permalink | Reply |
headers
Keith Moore | 20 Aug 14:23
Picon

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
>
Permalink | Reply |
headers
Eric Burger | 20 Aug 18:47

Re: Update of RFC 2838, tv: URI

Said more strongly, most TV is IPTV is today carried by RTSP (although some of us would like to see SIP there, but that is an RAI, not APP issue).

It sounds like you are looking for some sort of location and guide service. For that, have you considered SAP or related protocols?


On 8/20/06 8:23 AM, "Keith Moore" <moore <at> cs.utk.edu> 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?

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
>
Permalink | Reply |
headers
Eliot Lear | 21 Aug 17:36
Picon
Favicon

Re: Update of RFC 2838, tv: URI

Has anyone considered taking the best of the CRID standard and of
iCalendar to transmit this information?  That way people can integrate
what shows they want to watch with their personal calendars.

Eliot
Permalink | Reply |
headers
Martin Duerst | 21 Aug 05:38
Picon
Gravatar

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
Permalink | Reply |
headers
Keith Moore | 21 Aug 13:03
Picon

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
Permalink | Reply |
headers
Martin Duerst | 22 Aug 02:57
Picon
Gravatar

Re: Update of RFC 2838, tv: URI

At 20:03 06/08/21, Keith Moore wrote:
>> [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.

But that's not part of the design.

>and it's poor architecture to effectively
>expect future URI types to depend on HTTP.

They don't depend on HTTP except for minting, with is a one-time
operation. If HTTP ever goes away, the URI scheme can easily be
redefined to mint new identifiers in a different way.

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

Yes. Please note above that I said "click", which is somewhat
problematic with respect to accessibility, but is completely
tool-agnostic. I regularly click on URIs in my MUA :-).

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

This is a good point.

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

Can you explain that. How is it uglier to define mime types video/...
or application/videometadata+xml or something like that than to use
a new method such as GETVIDEOMETADATA ?

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst <at> it.aoyama.ac.jp
Permalink | Reply |
headers
Keith Moore | 22 Aug 06:15
Picon

Re: Update of RFC 2838, tv: URI

>>> 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.
> 
> But that's not part of the design.

it was proposed to be part of the design.

>> and it's poor architecture to effectively
>> expect future URI types to depend on HTTP.
> 
> They don't depend on HTTP except for minting, with is a one-time
> operation. If HTTP ever goes away, the URI scheme can easily be
> redefined to mint new identifiers in a different way.

I think it's difficult to change the meaning of a URI scheme once that 
meaning is encoded in widely deployed software.  furthermore, it's bad 
design to require a DNS lookup, TCP connection setup, and HTTP GET 
(presumably over IPv4, because that's the de facto assumption for HTTP 
URLs on the web) for every new URI type, when that URI type might be 
intended to work with DNS in a different way (say NAPTR/SRV), and 
perhaps contact a different host than is advertised in the DNS A or AAAA 
records for that domain.  this defeats fate-sharing, introduces an 
unnecessary dependency on a web server that might be totally unrelated 
to the resource described by the URI, and can slow things down needlessly.

>> 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)
> 
> Yes. Please note above that I said "click", which is somewhat
> problematic with respect to accessibility, but is completely
> tool-agnostic. I regularly click on URIs in my MUA :-).

me too.  but clicking is a pretty limited way of interacting with a 
resource - it implies that there's only one or two things you can do 
with it.  so I don't want to think of user interfaces to resources as 
being just clicks.  for instance, if you embedded a tv: URL in a 
document, you might expect to be able to watch that tv station live from 
within the document, or browse its (past or present) schedule, or watch 
programs aired in the past, etc.

>>> 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.
> 
> Can you explain that. How is it uglier to define mime types video/...
> or application/videometadata+xml or something like that than to use
> a new method such as GETVIDEOMETADATA ?

because it tempts people to overload a resource name (URI) to mean 
completely different things - to be different resources - depending on 
content-type negotiation.  somehow I don't think that's what 
content-negotiation is intended to be.   also - if the content of the 
resource is the same modulo presentation format, it makes sense to use 
content-type negotiation, and content negotiation is designed to handle 
this case. but if what you're really trying to do is query a resource to 
find out what methods apply to the resource, content-negotiation doesn't 
work nearly so well.  and if you overload content-negotiation to do 
method selection, you get a less flexible way of interacting with a 
resource and it also cripples the ability to do content-negotiation on 
some particular method of that resource.

Keith
Permalink | Reply |
headers
Tim Bray | 20 Aug 16:45
Favicon
Gravatar

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
Permalink | Reply |
headers
Lisa Dusseault | 20 Aug 22:48
Favicon

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
>
>
>
>
>
Permalink | Reply |
headers
Keith Moore | 20 Aug 22:59
Picon

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.
Permalink | Reply |
headers
Tim Bray | 24 Aug 05:33
Favicon
Gravatar

Re: Update of RFC 2838, tv: URI

On Aug 20, 2006, at 1:59 PM, Keith Moore wrote:

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

Um, the W3C dogma doesn't say much about retrieval.  It just  
encourages using "http:" URIs to name things unless you have a good  
strong reason to use another scheme; and when you look closely at  
many of the alleged reasons, they tend to involve a lot of arm-waving.

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

I think that if it's going to be used as a distributed persistent  
naming scheme, that's a good argument for using http: URIs.  It is  
very unlikely that tv: URIs will ever be as remotely functional as  
http: URIs, which have software already widely deployed on  
essentially every desktop and server on the planet.

If you want to have this argument, please read http:// 
norman.walsh.name/2006/07/25/namesAndAddresses first.

   -Tim [former W3C TAG member]
Permalink | Reply |
headers
Keith Moore | 24 Aug 08:35
Picon

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.
> 
> Um, the W3C dogma doesn't say much about retrieval.  It just encourages 
> using "http:" URIs to name things unless you have a good strong reason 
> to use another scheme; and when you look closely at many of the alleged 
> reasons, they tend to involve a lot of arm-waving.

I agree that the purported reasons for always using http: involve a lot 
of arm-waving.

>> 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.
> 
> I think that if it's going to be used as a distributed persistent naming 
> scheme, that's a good argument for using http: URIs.  It is very 
> unlikely that tv: URIs will ever be as remotely functional as http: 
> URIs, which have software already widely deployed on essentially every 
> desktop and server on the planet.

if you insist on tv: being equivalent to (or dependent on) http: then 
it's very unlikely that it will ever be as remotely functional as http:. 
  on the other hand if you don't impose the constraint that tv: should 
be tied to http:, then there's a potential for tv: URIs to do things 
that far exceed what can reasonably be done with http:.

again, the widely deployed software tends to consist of web browsers and 
web servers which are optimized for certain kinds of user interfaces and 
use cases and pessimized for all others.  I don't think URIs should be 
constrained to that set of optimizations and pessimizations.

> If you want to have this argument, please read 
> http://norman.walsh.name/2006/07/25/namesAndAddresses first.

thanks for the ref, I'll take a look.

Keith
Permalink | Reply |
headers
Lisa Dusseault | 21 Aug 17:27
Favicon

Re: Update of RFC 2838, tv: URI


I agree there is a need, for a good interface, to expose some  
semantic information about the resource without having to access it  
across the net.  I'm not sure that means the scheme is a good place  
for this information though (and pretty clearly W3C TAG thinks it's  
not).

The Microformats mechanisms <microformats.org> uses "class"  
attributes on the "a" link element to indicate what kind of an HTTP  
link is in the "href" attribute: a friend's blog location, the page  
owner's calendar location, etc.  Of course, this approach works best  
in Web pages, and can work in email only if using rich email or ugly  
URLs, and can be used in other media similarly.

Lisa

On Aug 20, 2006, at 1:59 PM, Keith Moore wrote:

> 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.
>
Permalink | Reply |
headers
Tim Bray | 24 Aug 05:36
Favicon
Gravatar

Re: Update of RFC 2838, tv: URI

On Aug 21, 2006, at 8:27 AM, Lisa Dusseault wrote:

> I agree there is a need, for a good interface, to expose some  
> semantic information about the resource without having to access it  
> across the net.

I disagree.  It is a design axiom of the Web that URIs are opaque,  
and that the only way to authoritatively find out anything about what  
a URI identifies is to dereference it (which, given the caching  
infrastructure, in many cases won't require going across the net).   
This is one of the reasons why the Web exhibits good scaling behavior.

> I'm not sure that means the scheme is a good place for this  
> information though (and pretty clearly W3C TAG thinks it's not).

If you want to keep link metadata around (nothing intrinsically wrong  
with that as long as you're willing to eat the management overhead  
and scaling barriers), the URI scheme is a really lousy place for it.

  -Tim [former W3C TAG member]
Permalink | Reply |
headers
Lisa Dusseault | 24 Aug 17:54
Favicon

Re: Update of RFC 2838, tv: URI


On Aug 23, 2006, at 8:36 PM, Tim Bray wrote:

> On Aug 21, 2006, at 8:27 AM, Lisa Dusseault wrote:
>
>> I agree there is a need, for a good interface, to expose some  
>> semantic information about the resource without having to access  
>> it across the net.
>
> I disagree.  It is a design axiom of the Web that URIs are opaque,  
> and that the only way to authoritatively find out anything about  
> what a URI identifies is to dereference it (which, given the  
> caching infrastructure, in many cases won't require going across  
> the net).  This is one of the reasons why the Web exhibits good  
> scaling behavior.

I didn't say that the URI shouldn't be opaque.  I didn't say that  
this need was universal for every link (a solution shouldn't impose a  
cost when not wanted).  I didn't suggest a mechanism that would  
degrade scaling.  I still assert that in many use cases a good UI  
requires a bit of advertisement about the nature a linked resource  
that a user might want to retrieve.

Lisa
Permalink | Reply |
headers
Keith Moore | 24 Aug 08:38
Picon

Re: Update of RFC 2838, tv: URI

>> I agree there is a need, for a good interface, to expose some semantic 
>> information about the resource without having to access it across the 
>> net.
> 
> I disagree.  It is a design axiom of the Web that URIs are opaque,

the fact that this "axiom" is not followed in practice should give an 
indication that this "axiom" is a poor design choice.

> If you want to keep link metadata around (nothing intrinsically wrong 
> with that as long as you're willing to eat the management overhead and 
> scaling barriers), the URI scheme is a really lousy place for it.

mostly true, though pragmatically it works really well to convey a small 
number of bits of useful information.

Keith
Permalink | Reply |
headers
Keith Moore | 21 Aug 18:08
Picon

Re: Update of RFC 2838, tv: URI

> I agree there is a need, for a good interface, to expose some semantic 
> information about the resource without having to access it across the 
> net.  I'm not sure that means the scheme is a good place for this 
> information though (and pretty clearly W3C TAG thinks it's not).
> 
> The Microformats mechanisms <microformats.org> uses "class" attributes 
> on the "a" link element to indicate what kind of an HTTP link is in the 
> "href" attribute: a friend's blog location, the page owner's calendar 
> location, etc.  Of course, this approach works best in Web pages, and 
> can work in email only if using rich email or ugly URLs, and can be used 
> in other media similarly.

I agree that there are limitations to what can or should be exposed in a 
URI scheme name, though I don't think the example of "tv:" stretches the 
bounds too much.

I think it's a stretch to assume that URIs can generally be associated 
with metadata that exposes semantic information about the resource.  For 
better or worse, a URI is a natural container, and the URI is really the 
only thing that approaches being a universal coin of the web.  There's 
not nearly the degree of acceptance for any kind of metadata that there 
is for the URI, and I'd expect convergence on metadata (both schemas and 
presentation layers) to occur much more slowly than convergence on 
resource identifiers.

I find myself disagreeing with many of TAG's recommendations about URI 
use - basically I think they're being very unrealistic and idealistic in 
some areas while ignoring a number of practical considerations.  I don't 
think IETF should constrain itself, or the URI registry should be 
constrained by, the mere fact that TAG has made some contrary 
recommendations.

Keith
Permalink | Reply |
headers
Dan Zigmond | 21 Aug 19:01
Picon
Favicon

Re: Update of RFC 2838, tv: URI

Hello, all. I'm responding to the thread as a whole here, rather than the specific comments about microformats and TAG. I was the original author of RFC of RFC 2838 and so can give some background on the thinking behind it and how ti evolved in the process of RFC publication. (I vaguely remember that Keith was involved at the time, but Microsoft did not allow me to keep my emails from that period when I left, so I can't be sure.)

The original tv: Internet-Draft (circa 1996) used a much simpler syntax: tv:nbc, tv:cnn, tv:bbc1, etc. Of course, this required some sort of registry, so we envisioned that IANA would allow TV networks to reserve identifiers for their channels, and even started writing up an initial list of reserved identifiers for the major US networks and a few international ones.

Unfortunately, we ran into name collisions almost immediately: ABC signifies a very different TV broadcaster to US audiences than to Australian ones. So we started thinking about how to resolve such conflicts, and perhaps some way of qualifying these identifiers by geography, and so forth. It was my co-author, Mark Vickers, who then suggested that this seemed like a duplication of effort: the domain name system already provided all these mechanisms, and most TV broadcasters already had a domain name. So we changed the draft to mandate that identifiers include an assigned domain name, and the above examples became something like tv: nbc.com, tv:cnn.com, and tv:one.bbc.co.uk.

As someone else already pointed out on this thread, these were not intended to be actual hostnames. Instead, we were trying to design something closer to the Java package naming system, overloading domain names to ensure the uniqueness of an unrelated set of identifiers.

I'm not sure I agree that this approach runs into any particular problems in Europe. The issue, rather, is that broadcasters have not rushed to establish identifiers based on this scheme. So, for example, the BCC has not published a format for referring to their distinct broadcasts using this scheme; neither has NED1 in the Netherlands. Furthermore, there isn't a clear mechanism for publicizing such a decisions one a broadcast has made it; if BBC decided tomorrow to use the form tv: bbc1.bbc.co.uk, it's not clear how anyone would know.

We explicitly left everything beyond the usual hostname part of the URI undefined in this draft. Our assumption was that eventually people would want to use the other path components to refer to specific shows or segments of broadcasts (perhaps tv: bb1.bbc.co.uk/news or something like that). As far as I know, no one is doing this, but it still seems a possibility for the future. As Oskar points out indirectly, the identifiers are "ambiguous" in the loose sense that one can image multiple ways for someone like the BBC to name their broadcasts under this scheme, and so the broadcaster needs to pick one.

The tv: URIs are used today in the TV world, and I believe are implemented by most TV-based browsers. By far the most common usecase however, is simply the unadorned "tv:", used to refer to the current broadcast. When a browser wants to overlay graphics on the TV picture, for example, the background image is simply set to this URI, and when the browser wants to include a resized TV picture in the corner, they insert an image pointing to "tv:" in the desired location.

I would be happy to work on a revision of RFC 2838if one is desired. In my mind, the biggest problem is how to register identifiers under this scheme. But based on Oskar's comments, perhaps further clarifying the relationship (or lack of relationship) of these DNS-based identifiers to actual HTTP sites would also be helpful.

     Dan


On 8/21/06, Keith Moore <moore <at> cs.utk.edu> wrote:
> I agree there is a need, for a good interface, to expose some semantic
> information about the resource without having to access it across the
> net.  I'm not sure that means the scheme is a good place for this
> information though (and pretty clearly W3C TAG thinks it's not).
>
> The Microformats mechanisms <microformats.org> uses "class" attributes
> on the "a" link element to indicate what kind of an HTTP link is in the
> "href" attribute: a friend's blog location, the page owner's calendar
> location, etc.  Of course, this approach works best in Web pages, and
> can work in email only if using rich email or ugly URLs, and can be used
> in other media similarly.

I agree that there are limitations to what can or should be exposed in a
URI scheme name, though I don't think the example of "tv:" stretches the
bounds too much.

I think it's a stretch to assume that URIs can generally be associated
with metadata that exposes semantic information about the resource.  For
better or worse, a URI is a natural container, and the URI is really the
only thing that approaches being a universal coin of the web.  There's
not nearly the degree of acceptance for any kind of metadata that there
is for the URI, and I'd expect convergence on metadata (both schemas and
presentation layers) to occur much more slowly than convergence on
resource identifiers.

I find myself disagreeing with many of TAG's recommendations about URI
use - basically I think they're being very unrealistic and idealistic in
some areas while ignoring a number of practical considerations.  I don't
think IETF should constrain itself, or the URI registry should be
constrained by, the mere fact that TAG has made some contrary
recommendations.

Keith



--

------------------------
djz <at> google.com
Permalink | Reply |
headers
Julian Reschke | 21 Aug 17:57
Picon
Picon

Re: Update of RFC 2838, tv: URI

Lisa Dusseault schrieb:
> 
> I agree there is a need, for a good interface, to expose some semantic 
> information about the resource without having to access it across the 
> net.  I'm not sure that means the scheme is a good place for this 
> information though (and pretty clearly W3C TAG thinks it's not).
> 
> The Microformats mechanisms <microformats.org> uses "class" attributes 
> on the "a" link element to indicate what kind of an HTTP link is in the 
> "href" attribute: a friend's blog location, the page owner's calendar 
> location, etc.  Of course, this approach works best in Web pages, and 
> can work in email only if using rich email or ugly URLs, and can be used 
> in other media similarly.

Wait a second; please don't confuse this with Microformats. HTML already 
has a way to signal information about the nature of a relation, that's 
the "rel" attribute 
(<http://www.w3.org/TR/html4/struct/links.html#adef-rel>).

Best regards, Julian
Permalink | Reply |
headers
Julian Reschke | 20 Aug 11:40
Picon
Picon

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
Permalink | Reply |
headers
Graham Klyne | 21 Aug 14:24

Re: Update of RFC 2838, tv: URI

FWIW, discussion about including the tv: URI scheme (and some others that got
missed) in the URI registry is already under way.

(This comment is independent of the separate discussion about the
appropriateness or role of a tv: URI scheme.)

#g
--

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

--

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
Permalink | Reply |
headers
Martin Duerst | 22 Aug 03:04
Picon
Gravatar

Re: Update of RFC 2838, tv: URI

At 21:24 06/08/21, Graham Klyne wrote:
>FWIW, discussion about including the tv: URI scheme (and some others that got
>missed) in the URI registry is already under way.

Great to hear that. Can you give an idea where that's underway?
I was under the assumption I'm subscribed to the relevant
mailing list (uri-review <at> ietf.org).

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst <at> it.aoyama.ac.jp
Permalink | Reply |
headers
Graham Klyne | 22 Aug 10:32

Re: Update of RFC 2838, tv: URI

Martin,

Sorry, I should have given some context for my comment.

As the "designated reviewer" for URI scheme registration, I was asked by IANA to
review some helpful comments that have been submitted that note, among other
things, a number of URI schemes that appear in RFCs but have not been captured
in the registry.  tv: is one of them.

FWIW, my advice in this is that any scheme that is described in an RFC should be
recorded in the permanent URI scheme registry, in some cases as "historic" or
"obsolete", as developers out there may legitimately use these for their
documented purpose, and that we should try to avoid potential inconsistent use
of any scheme name.  Discouraging or encouraging widespread use of any such
scheme is a matter for the wider community (here and on uri-review <at> ietf.org),
and in my role as reviewer I try to avoid judgement concerning whether a scheme
is well-conceived, just that it meets appropriate criteria for registration.

#g
--

Martin Duerst wrote:
> At 21:24 06/08/21, Graham Klyne wrote:
>> FWIW, discussion about including the tv: URI scheme (and some others that got
>> missed) in the URI registry is already under way.
> 
> Great to hear that. Can you give an idea where that's underway?
> I was under the assumption I'm subscribed to the relevant
> mailing list (uri-review <at> ietf.org).
> 
> Regards,   Martin.
> 
> 
> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst <at> it.aoyama.ac.jp     
> 

--

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
Permalink | Reply |
headers
Ted Hardie | 21 Aug 00:26

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

Gmane