Subject: Update of RFC 2838, tv: URI

From: "Deventer, M.O. \(Oskar\) van" <[email-masked]>
Date: Fri, 18 Aug 2006 16:08:24 +0200

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
[email-masked] 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
[email-masked]
--------------------------------

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: Julian Reschke <[email-masked]>
Date: Sun, 20 Aug 2006 11:40:40 +0200

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

---

From: Eliot Lear <[email-masked]>
Date: Sun, 20 Aug 2006 13:09:10 +0200

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Aug 2006 08:23:42 -0400

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.

---

From: Tim Bray <[email-masked]>
Date: Sun, 20 Aug 2006 07:45:52 -0700

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

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 20 Aug 2006 13:48:40 -0700

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 20 Aug 2006 16:59:34 -0400

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

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

---

From: Ted Hardie <[email-masked]>
Date: Sun, 20 Aug 2006 15:26:08 -0700

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

---

From: Martin Duerst <[email-masked]>
Date: Mon, 21 Aug 2006 12:38:58 +0900

[Re. venue for follow-up discussions, I suggest that the URI mailing
list ([email-masked]), 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.

>> new form give you that a URL does not?

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 21 Aug 2006 07:03:57 -0400

> 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.
> 
>  on a sufficiently equiped and configured device, you would view that
> channel. On the other hand, if you clicked http://bbc.co.uk/bbcone, 

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)

> 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

---

From: Graham Klyne <[email-masked]>
Date: Mon, 21 Aug 2006 13:24:50 +0100

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

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

---

From: Eric Burger <[email-masked]>
Date: Sun, 20 Aug 2006 12:47:17 -0400

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?

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Aug 2006 17:36:45 +0200

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

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 21 Aug 2006 08:27:42 -0700

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:

> 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/ 
>> descriptor" file format which could be retrieved via HTTP,  
>> therefore have a http: scheme.
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 21 Aug 2006 17:57:02 +0200

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 21 Aug 2006 12:08:18 -0400

> 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

---

From: Martin Duerst <[email-masked]>
Date: Tue, 22 Aug 2006 09:57:56 +0900

At 20:03 06/08/21, Keith Moore wrote:
>> [Re. venue for follow-up discussions, I suggest that the URI mailing list ([email-masked]), in particular for syntax aspects.]
>information about TV feeds.

But that's not part of the design.

>and it's poor architecture to effectively

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

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

This is a good point.

>> content negotiation (defining new mime types for the "other things").

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.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 22 Aug 2006 10:04:38 +0900

>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 ([email-masked]).

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 22 Aug 2006 09:57:56 +0900

This is a good point.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Tue, 22 Aug 2006 10:04:38 +0900

Regards,   Martin.

---

From: Keith Moore <[email-masked]>
Date: Tue, 22 Aug 2006 00:15:49 -0400

> But that's not part of the design.

it was proposed to be part of the design.

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

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

> 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

---

From: Graham Klyne <[email-masked]>
Date: Tue, 22 Aug 2006 09:32:52 +0100

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 [email-masked]),
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
--

---

From: "Dan Zigmond" <[email-masked]>
Date: Mon, 21 Aug 2006 10:01:26 -0700

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

-- 

------------------------
[email-masked]

---

From: Tim Bray <[email-masked]>
Date: Wed, 23 Aug 2006 20:33:14 -0700

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

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

---

From: Tim Bray <[email-masked]>
Date: Wed, 23 Aug 2006 20:36:19 -0700

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

> 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  

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.

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Aug 2006 02:35:32 -0400

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

> 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

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Aug 2006 02:38:30 -0400

>> net.

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

> 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

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 24 Aug 2006 08:54:39 -0700

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

>> semantic information about the resource without having to access  
>> it across the net.
>
> 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